A product-led growth company hits 5,000 free users. The founder opens the CRM and sees 5,000 identical contact records: name, email, signup date. No plan tier. No usage data. No indication of which users activated a core feature, which ones hit the free tier limit, and which ones signed up and never came back. The sales team starts calling users alphabetically. Three out of four calls reach people who opened the product once and forgot about it.
This is the default state of user segmentation in most PLG companies. The product database knows everything about user behavior. The CRM knows nothing. And the gap between those two systems is where qualified leads disappear. For background on segmentation types and methods, we covered the full landscape in our guide to customer segmentation.
What user segmentation means in a product-led growth context
Traditional audience segmentation groups people by demographics, firmographics, or survey responses. In a product-led growth company, those categories are nearly useless. A marketing manager at a 30-person startup and a marketing manager at a 30-person agency might look identical on paper, but one logs in daily, has connected three integrations, and invited four teammates. The other created an account during a trial and never returned.
Product-led growth segmentation starts with product data, not profile data. The defining characteristic of PLG is that the product is the primary acquisition and qualification channel. Users sign up, try the product, adopt features, and either expand or leave. Every step in that journey generates data that matters more than any demographic field.
The challenge is that this data lives in the wrong place. Feature flags, session counts, records created, integrations connected, and teammates invited all live in your product database. Your CRM, where your sales and success team works, sees none of it. User segmentation in PLG is fundamentally a data sync problem: getting product behavior data into the system where your team can act on it.
User segmentation models for PLG: usage-based, engagement-based, and plan-based
There are three behavioral segmentation models that matter in product-led growth. Each one uses different product data and answers a different business question.
Model | Data source | Question it answers |
|---|---|---|
Usage-based | Records created, API calls, storage used | Which users are approaching plan limits? |
Engagement-based | Login frequency, features adopted, teammates invited | Which users are deeply embedded vs. at risk? |
Plan-based | Current tier, trial status, billing changes | Which users upgraded, downgraded, or stalled? |
Usage-based segmentation groups users by how much of the product they consume. A project management tool might track projects created, tasks completed, and file storage used. Users approaching the free tier ceiling (80%+ of limits) are expansion candidates. Users who created one project and stopped are activation failures. Usage data is the most reliable predictor of upgrade intent because it measures the one thing demographics can't: whether the product is delivering value.
Engagement-based segmentation measures how deeply a user has adopted your product. Login frequency alone is a weak signal. Better engagement variables: number of features used, integrations connected, teammates invited, and workflows created. A user who logs in daily but only uses one feature is less engaged than a user who logs in weekly but has connected three integrations and invited their team. Engagement-based segments identify power users, casual users, and dormant accounts.
Plan-based segmentation uses billing data to group users by their commercial relationship. Free vs. trial vs. paid is the obvious split. More useful: trial users past day 7 who haven't activated, paid users whose plan renewed this month, paid users who downgraded from a higher tier. Plan-based segments drive retention and expansion conversations when combined with usage or engagement data.
In practice, the most useful user segments combine two or three models. "Free plan + usage above 80% of limit + logged in this week" is an expansion-ready user segment. "Paid plan + no login in 14 days + no teammates" is a churn risk. Single-model segments are a starting point. Multi-model segments drive decisions.
How to build user segments from product analytics and billing data
Most PLG segmentation guides route everything through a warehouse: instrument events via an SDK, pipe them to Snowflake, model in dbt, push audiences via reverse ETL. That architecture takes 3-6 months and requires a data engineer. Here is the approach that works for PLG teams without a dedicated data function.
Step 1: Pick your segmentation variables. Choose 4-6 fields from your product database and billing tool that directly map to the three models above. Good starting set:
From your product database:
features_used_count,last_active_date,teammates_invited,records_createdFrom Stripe:
plan_name,subscription_status,trial_end_date
Step 2: Sync those fields to your CRM. Create custom contact properties in HubSpot or Attio for each variable. Set up automated sync between your product database, Stripe, and your CRM. Every contact record now shows both profile data and product behavior data on the same screen.
Step 3: Build segment definitions. Use your CRM's native filters to create lists. Start with three user segments that trigger specific actions:
Expansion-ready: Free plan +
records_created> 80% of free limit +last_active_datewithin 7 daysActivation stalled: Signed up 7+ days ago +
features_used_count< 2 +teammates_invited= 0Churn risk: Paid plan +
last_active_date> 14 days ago +teammates_invited< 2
Step 4: Connect segments to actions. Each user segment should trigger something: an in-app message, a sales outreach sequence, a customer success check-in. Segments that exist as lists but don't trigger actions are vanity metrics.
User segmentation examples: PQLs, expansion candidates, and churn risks
Abstract models become useful when you see specific segment-building examples applied to real PLG scenarios.
Product-qualified leads (PQLs). A PQL is a user who has demonstrated through product behavior that they are ready for a sales conversation. Unlike marketing-qualified leads, PQLs are based on what someone did in the product, not which ebook they downloaded. Define PQL criteria from your strongest conversion signals:
Exceeded 90% of free tier usage limits
Invited 3+ teammates in the last 7 days
Connected a paid-tier integration (e.g., Salesforce, when only CRM-lite is free)
Used the product for 5+ consecutive business days
A user who triggers two of these four criteria enters your PQL user segment. Your sales team reaches out with context: "I see your team connected Salesforce and you're approaching the project limit on the free plan. Want me to walk through what the Team plan adds?"
Expansion candidates. Not every paid user is worth an upsell conversation. Expansion segments identify the ones who are: paid plan + approaching the next tier's usage threshold + high engagement. A team on a $100/month plan that has used 90% of their seat allocation and connected 5 integrations is a stronger expansion candidate than one at 40% utilization. The data for this user segment lives in Stripe (plan, seats) and your product database (integrations, usage).
Churn risks. The simplest churn risk segment combines three signals: declining login frequency, no new teammates invited in the last 30 days, and a support ticket filed in the last 14 days. A customer who stops using the product, stops growing their team, and contacts support is telling you something. This segment triggers a customer success outreach before the customer reaches the cancellation page.
Implementing user segmentation by syncing product data to your CRM
The infrastructure that PLG user segmentation requires is not a warehouse, an SDK, or a CDP. It is a connection between your product database and your CRM. Every segmentation model above depends on the same data flow: product behavior data moving from where it is generated (your database, your analytics tool, Stripe) to where your team acts on it (your CRM).
Without that sync, behavioral segmentation degrades into a manual process. Someone exports a CSV from the product database, someone else merges it with CRM data in a spreadsheet, and by the time the segment list reaches the sales team, the data is three days old. The user who was expansion-ready on Monday already downgraded by Thursday.
Oneprofile connects your product database, Stripe, and your CRM directly. Map product usage fields (features used, last active date, records created) and billing fields (plan name, subscription status, trial end) to CRM contact properties. Set a 15-minute sync schedule. Every contact record in your CRM now shows real-time product behavior alongside profile data.
Your CRM's native filters become your user segmentation engine. Build a list where plan_name = Free AND records_created > 80% of limit AND last_active_date is within 7 days. That is your PQL segment, built in 30 seconds, updating automatically every 15 minutes. No warehouse, no SQL, no data engineer. Free to start.
What is user segmentation in product-led growth?
User segmentation in PLG groups users by product behavior: feature adoption, usage frequency, and plan-qualifying activity. Unlike traditional segmentation, PLG segments predict upgrade readiness and churn risk from real product data.
How do I identify product-qualified leads without a data team?
Define 2-3 usage thresholds that correlate with upgrades (e.g., exceeds free tier limits, invites teammates, uses a paid feature). Sync those flags from your product database to your CRM. Any user who crosses the threshold is a PQL.
What data do I need for PLG user segmentation?
Three sources: product usage data (login frequency, features used, records created), billing data (plan tier, MRR, trial status), and engagement data (last active date, invite count, integration connections).
Can I build user segments without a warehouse or CDP?
Yes. Sync product usage data and billing data to your CRM using tool-to-tool sync. Build segments with your CRM's native filters. No warehouse, no SQL, no CDP required.