Identify Product Qualified Leads

Your database already knows which users are about to buy. The columns are right there: last_login_at shows daily activity, features_activated shows depth, teammates_invited shows expansion intent. But your sales team works in a CRM that has none of this. They see job titles and email domains while the strongest buying signals sit in Postgres, invisible. You should be able to identify product qualified leads with warehouse optional, no SDK, and no six-month data engineering project.

For the fundamentals of how lead scoring works and where PQL fits alongside demographic and behavioral scoring, see our guide to lead scoring.

What a product qualified lead is and why PQLs convert better than MQLs

A product qualified lead is a free or trial user whose in-product actions signal readiness to buy. The concept is straightforward: someone who connected two integrations, invited a teammate, and logged in four times this week is closer to purchasing than someone who downloaded a whitepaper. PQLs convert at 5-6x the rate of marketing qualified leads because the signal is rooted in action, not interest.

The distinction matters for how you build your pipeline. MQLs are generated by marketing engagement. SQLs are validated through sales conversations. The PQL sits between them but carries a stronger signal because the user has already experienced your product's value. Our PQL explainer covers the concept in detail. This guide is about the practical mechanics: getting the data from your database into your CRM so you can actually build PQL scoring.

Which product data signals identify a product qualified lead

Not every product metric matters. The signals that predict conversion cluster into three categories.

Activation signals measure whether the user hit your product's core value moment. For a data sync tool, that might be connecting two tools and running a first sync. For a project management app, it might be creating a project and adding a collaborator. The specifics vary, but the pattern holds: users who reach the activation threshold convert at dramatically higher rates.

Engagement depth signals track sustained usage beyond initial activation. Login frequency over 7 days, number of distinct features used, session duration trends. A user who comes back four times in a week is in a different category than one who activated once and disappeared.

Expansion signals indicate the user is outgrowing their current plan. Inviting teammates, hitting usage limits, attempting gated features, visiting the pricing page after a week of active use. These suggest the user has already decided the product is valuable and is evaluating whether to pay.

Start with 3-5 signals from across these categories. Review your last 50 free-to-paid conversions and look for the fields that appeared most consistently before the upgrade event.

Step-by-step: sync product usage data to your CRM for PQL identification

This is where every competitor guide loses you. They tell you to instrument an SDK, load events into Snowflake, write SQL scoring models, and push via reverse ETL. That path works if you have a data engineer and three months to spare. Here is the alternative.

1. Pick your PQL fields. Based on your conversion analysis, select the database columns that matter. A reasonable starting set:

• users.last_login_at (recency)

• users.features_activated (depth)

• users.teammates_invited (expansion)

• subscriptions.plan_status (trial, free, paid)

• users.created_at (age of account)

2. Map each field to a CRM property. Define the destination property name and type before you connect anything. This prevents mismatches during sync.

3. Connect your database to your CRM in Oneprofile. Add your PostgreSQL (or MySQL, or any database) as a source using a read-only connection string. Add your CRM as a destination via OAuth or API key. Oneprofile validates both credentials against the live APIs before saving.

4. Configure the sync. Select email as the matching key so Oneprofile knows which database user maps to which CRM contact. Map the fields from step 2. Oneprofile creates custom CRM properties automatically when they don't exist yet. Set the sync to "Update or Create" mode and a 15-minute schedule.

5. Run the initial sync. The first run backfills all existing database users into your CRM. Every historical user gets product usage fields populated on their contact record. After that, each sync processes only the records that changed since the last run.

The whole process takes about 30 minutes. Your CRM now has product usage data on every contact, updated every 15 minutes.

How to score a product qualified lead in your CRM using synced data

With product data flowing into your CRM, you can build PQL scoring where your sales team already works.

HubSpot has the "HubSpot Score" property (Professional plan) or predictive scoring (Enterprise). Salesforce has Einstein Lead Scoring or custom formula fields. Attio supports custom score calculations. The HubSpot scoring with external data guide walks through the CRM-specific setup.

Define rules against your synced fields:

• last_product_login within 3 days: +15 points

• features_activated_count >= 3: +20 points

• teammates_invited >= 1: +15 points

• plan_status = "free" and features_activated_count >= 2: +25 points (free user hitting value)

• No login in 14 days: -20 points

• plan_status = "canceled": -30 points

Most teams use a 0-100 scale. Contacts above 70 go to an account executive. Contacts between 40-70 enter a nurture sequence. Below 40, they stay in marketing.

The scores update automatically as the synced fields change. When a user invites a teammate at 10 AM, your CRM knows by 10:15 AM, the score adjusts, and if it crosses the threshold, the assigned rep gets notified. No manual checking, no CSV exports, no stale data.

One thing worth noting: the scoring rules themselves are simple. Any RevOps lead can define "activated + returning daily + invited teammate = hot PQL." The hard part was always getting the product data into the CRM in the first place. With that solved, the scoring is a 15-minute configuration.

From product qualified lead to closed deal: automating the sales handoff

A PQL that nobody acts on is worse than no PQL at all, because you built the infrastructure and still missed the opportunity.

Set up threshold-based routing. When a contact's score crosses your threshold, trigger an assignment. In HubSpot, use workflow automation to assign the contact to a rep and send a Slack notification. In Salesforce, use flow builder to create a task. The rep should know within minutes, not hours.

Give the rep context on the first call. The CRM contact record now shows last_product_login, features_activated_count, teammates_invited, and plan_status. The rep can open the record and immediately understand what the user did, not just who they are. "I see you connected Stripe and HubSpot last week and you've been logging in daily" is a different conversation than a cold outreach template.

Separate PQL tiers. Not every product qualified lead needs a phone call.

• Warm PQLs (activated, light usage): automated email sequence with tips and upgrade prompts

• Hot PQLs (activated, returning daily, hitting limits): direct outreach from an AE within the hour

• Expansion PQLs (existing paid user, adding seats or hitting higher-tier features): routed to customer success for upgrade conversation

Decay inactive PQLs. A product qualified lead from three weeks ago who stopped logging in is no longer qualified. Subtract 5-10 points per week of inactivity after the first 14 days. This keeps your sales queue clean and prevents reps from chasing cold leads with stale high scores.

The feedback loop matters too. After a quarter of PQL-driven outreach, pull your closed-won and closed-lost deals. Check whether the PQL scores at time of close correlated with outcomes. If 40-score contacts convert at the same rate as 80-score contacts, your signal weights are off. Adjust and retest.

The infrastructure scales naturally. Start with Postgres-to-CRM for product usage data. Later, add Stripe for billing signals and Intercom for support context. Each source feeds more fields into the same contact record, and your PQL scoring model gets more accurate without any architectural change. The database already has the signals. The CRM already has the scoring engine. The only thing that was missing was the connection between them.