How to calculate a PQL (Product Qualified Lead) in SQL

In the past, acquiring new customers meant targeting specific audiences with marketing campaigns and having your sales team outbound specific accounts. However, with products like Grammarly, Calendly, and Slack, this approach is shifting as companies have introduced a product-led growth (PLG) approach. A PLG approach lets you try their products before you buy them – thus creating a growth model where customer acquisition, conversion, expansion, and retention is reliant upon the product.

The freemium business model of letting you try out basic features at no charge has seen tremendous success. Calendly went viral because users started adding individual Calendly links to their email header. However, this land-and-grab approach creates a problem because, with so many leads, it's challenging to prioritize the ones that matter and nurture the less qualified ones.

What is a PQL?

Product-qualified leads (PQLs) are a lifesaver for companies inundated with new leads. Whereas marketing qualified leads (MQLs) represent leads who've interacted with your brand in some capacity, and sales qualified leads (SQLs) represent users who have booked a meeting, PQLs are actual users actively leveraging your product.

Instead of trying to convince a potential customer to buy something they haven't yet tried, PQLs allows you to try out a product before you buy it. And instead of asking people to fill out forms or visit multiple pages on your site, you can gather valuable information about what they really care about. PQLs are reliable because they create a self-serve model that is not reliant upon your sales teams. They let your customers sell themselves on why they should use your product, creating super high-quality leads for your sales team.

How to Define a PQL

Your definition of what you classify to be a PQL will drastically differ from another company's definition. For example, a key metric for Slack might be messages sent, while a key metric for Grammarly might be words typed. An app like Spotify most likely looks at time spent (e.g., minutes) in the app.

When defining your PQL definition, there are two main options, you can either build a lead scoring system and assign points to specific events, or you can simplify this model and define specific actions instead.

Either way, you'll need to identify the key attributes you want to track. The easiest way to do this is to look at your existing customers to answer questions like:

• What is your most popular feature?
• What does your ideal customer profile (ICP) look like?
• What do your most active customers have in common?
• When are your free tier customers exceeding their product usage threshold?
• Why/when do your free tier customers look to upgrade?
• When/where do users get stuck in your product?

You’ll also want to look at your core metrics like:

• Signups
• Active users
• Messages sent
• Workspaces created
• Last-login date
• Number of integrations
• Playlists
• Time-spent in app
• Users who failed to on-board
• Users who opted in for self-serve billing

These are just a few examples, but most likely, you can fill in the blank for what matters most to your business. Once you've defined your core criteria, you can assign points to specific actions (e.g., +5 points for active workspaces or +25 points for users who opted in for self-serve billing.) However, you might also want to apply negative points for specific actions.

For example, you could deduct five points if a user hasn't logged in within the past seven days. Once you've set up your scoring criteria, you'll also want to define grading criteria (e.g., 0-100.) Once a lead has reached the required threshold or performed a specific action, you can automatically tag that user as a PQL and pass it to your sales team.

Ultimately, there are many types of PQLs, and it's important not to have a single cookie-cutter definition that applies to all your leads. This is exactly why scoring your PQLs is the most accurate. However, it's important to remember that your PQL definition right now might be different in a year, so you should update it regularly to align with your business goals. For example, the north star metric at Hightouch is active workspaces, whereas the north star metric at a company like Slack sends messages.

Why Do PQLs Matter?

PQLs matter for several reasons. Firstly they give you direct visibility into how users are leveraging your product. Secondly, PQLs will likely convert into paying customers because they're already actively using your product. In addition, PQLs that convert to paying customers are far less likely to churn because their first interaction with your brand/product was not through a salesperson.

PQLs are also helpful in that they allow you to track specific user-related behavior so you can understand exactly where someone is in the buying cycle and what needs to happen for that user to convert to paying customers. SQLs and MQLs can be somewhat biased because your sales and marketing teams define the criteria. However, PQLs remove any guesswork because they're based on your customers' actions within your product.

PQLs are also highly beneficial for forecasting sales cycles every quarter. Suppose you know that 50% of your PQLs will convert to SQLs, and 25% of SQLs will convert to paying customers. In that case, you can identify red flags, hire accordingly, and implement sales processes to optimize your efficiency.

What Are the Impacts of PQLs?

The biggest drivers of PQLs are your business teams across marketing, sales, and support. With a continuous stream of PQLs, your sales team can build automated workflows in your CRM to route leads to the appropriate teams and notify your sales reps when specific accounts are in overage or exceeding product usage. This same example also applies to your outbound team because they can build customized sequences to try and book the first meeting and convert your PQLs to SQLs.

Your marketing team can also benefit from PQLs. For example, maybe you have a subset of users who signed up for your product, but they’re not actively using it because they don’t fully understand the value. With this information in hand, your marketing team can enroll users in a nurture campaign to encourage usage of your product to increase their PQL score.

PQLs can also have huge implications for your customer success teams. Onboarding is often the trickiest step for PLG companies because users often fail to set up the product or understand the value correctly. PQLs allows you to identify red flags in your onboarding flow so your customer success team can hop on a quick call or reach out with helpful content related to the problem your customers are experiencing.

Calculating PQLs Using SQL

Although most customer relationship management (CRM) platforms provide a cookie-cutter way to calculate various lead scores, you must create new fields if you want to calculate a truly accurate score to leverage the data within your product. Doing this can quickly become complicated if you have to build a field for every metric you want to track. And this isn't even mentioning that you must find a way to ingest your behavioral data directly into these fields.

In most cases, your data warehouse already houses all of your key customer data, so it’s much easier to simply calculate your lead score using simple SQL and sync that definition to a PQL field in your various business tools (e.g., Hubspot, Iterable, Salesforce, Zendesk, etc.)

The first step is to define all the events that a lead could do in your product (ex: Sign Up, Create a Workspace, Invite coworkers, Set up an integration, click a button, etc) that signal intent. To do that, you’ll likely need to join your sales data (likely in your CRM like Salesforce or HubSpot) with your website/product analytics data (ex: Google Analytics, Segment, Amplitude, or Mixpanel events). Your data warehouse is the best place to join all that data together.

For example, here’s a subquery we use at Hightouch to pull all product events that show intent. We first pull all relevant leads and intentionally exclude leads/signups from low-intent domains. Then we join those leads with event data.

with leads as (
  select 
    email, 
    min(created_date) as created_at 
  from 
    leads 
  where 
    lead_source in (‘relevant lead sources’) 
    and email not like '%hightouch.com' 
  group by 
    1
), 
pql_events as (
  select 
    distinct event_id, 
    anonymous_id, 
    email, 
    event_time, 
    event_type, 
    event_index 
  from 
    events 
  where 
    event_type in (‘List of events we care about’)
), 
priority_events_of_leads as (
  select 
    pql_events.* 
  from 
    pql_events 
    join leads using (email)
),

Finally, we can use the COUNT() function to count how many unique events each lead has to give a basic lead score.

select 
  email, 
  count(*) as lead_score 
from 
  priority_events_of_leads 
group by 
  1

That’s it! You now have a basic lead score based on how many high intent actions a lead has done.

If we wanted to get fancier, we could assign “points” to each action/event based on intent (ex: booking a demo is much higher intent than just reading a blog post).

with lead_score_inputs as (
  select 
    id, 
    email, 
    -- creating score for email (simplified)
    case when email similar to '%(gmail|yahoo|outlook|hotmail)%' then -1 else 0 end as email_score, 
    -- creating score for visited pricing page
    case when viewed_pricing = TRUE then 1 else 0 end as pricing_page_score, 
    -- creating score for inviting other members to join
    case when invited_other_users = TRUE then 1 else 0 end as member_invitation_score, 
    -- creating score for daily activity
    case when daily_active = TRUE then 1 else 0 end as activity_score, 
  from 
    fct_users
) 
select 
  (
    email_score + pricing_page_score + member_invitation_score + activity_score
  ) as lead_score, 
  id, 
  first_name, 
  last_name, 
  email 
from 
  lead_score_inputs 
order by 
  1 desc;

How to Implement PQLs

In the past, syncing data from your warehouse to your downstream business tools was challenging because it required you to integrate with third-party APIs and build custom pipelines for tools in your technology stack. However, this is no longer an issue thanks to Reverse ETL and platforms like Hightouch. Hightouch is a Data Activation platform that runs on top of your data warehouse.

Hightouch enables you to sync data to 200+ destinations using simple SQL or the existing models you've defined in your warehouse (e.g., your single source of truth). With Hightouch, you must define your data and map it to the appropriate fields in your destination. Best of all, you can schedule your syncs to run every time your data updates in your warehouse. Sign up for a free Hightouch workspace today to get started!