Product-led growth has been a dominant GTM framework in B2B SaaS for several years, but the analytics discipline that should accompany it lags significantly behind the strategic intent. Most PLG teams can tell you their free-to-paid conversion rate and their PQL count. Fewer can tell you what behavioral signal most reliably predicts PQL status before the user has hit any usage limit. Even fewer have instrumented the expansion loop — the behavioral path from single-seat to multi-seat within an account — as a first-class analytics object.
This article covers the data questions that PLG teams consistently miss or under-invest in, and why each one matters for building a self-sustaining growth engine rather than just a low-friction signup flow.
What PLG Analytics Is Not
Before getting into what to measure, it's worth being clear about what product-led growth analytics isn't. PLG analytics is not just standard SaaS analytics applied to a free tier. Adding a free plan to your product and measuring free-to-paid conversion as your primary PLG metric is not a PLG analytics practice — it's a funnel measurement applied to a pricing model change.
PLG, in the Reforge / OpenView framing, is a go-to-market motion where product usage itself generates the acquisition, retention, and expansion loops that traditional SaaS relies on sales and marketing to drive. The analytics questions for a PLG motion are correspondingly different:
- Which users are generating acquisition loops (inviting others, creating shareable content, triggering network effects)?
- Which behavioral signals most reliably identify users who are approaching the natural moment to upgrade — before they hit a usage cap?
- What does the expansion path within an account look like at a behavioral level, and which events predict seat expansion?
- Is the product's viral coefficient measurable and, if so, what user behaviors most increase it?
None of these questions appear in a standard SaaS analytics playbook. They require PLG-specific instrumentation and a PLG-specific measurement framework.
The PQL Signal: More Than Usage Caps
Product-qualified lead identification is one of the most-discussed concepts in PLG, and also one of the most poorly implemented. The standard PQL definition — a user who has hit a certain usage threshold — is a trigger signal, not a behavioral signal. It tells you the user has run out of runway on the free tier; it doesn't tell you whether that user has actually experienced the product's value deeply enough to be ready to buy.
The behavioral PQL definition is more useful and more predictive: a user who has completed the behavioral sequence most correlated with conversion to paid, regardless of whether they've hit any usage cap. This typically involves:
- The user has completed the aha moment sequence (they've experienced core value, not just set up the product)
- The user has returned to the product on at least 3 distinct days within their first 14 days (habit formation is detectable)
- The user has used at least one feature that is only meaningful at scale — a feature that becomes more valuable as usage volume grows, which creates the natural pull toward the paid tier
Defining PQLs this way requires behavioral instrumentation of each criterion as a separate, measurable event sequence. It's more complex than "user hit 10 projects" but it's substantially more predictive. Teams that implement behavioral PQL definitions typically see their PQL-to-paid conversion rates increase by 20–40% over usage-cap-only definitions, because they're now identifying higher-intent users rather than all users who happen to have generated enough activity to hit a limit.
The Data Questions About Viral Loops That Most Teams Skip
What Is Your Product's Viral Coefficient?
The viral coefficient (k-factor) is the number of new users generated, on average, by each existing user. A k-factor above 1.0 means the user base grows without any additional acquisition spend. A k-factor of 0.3 means each user generates 0.3 new users on average — still meaningful as a supplement to paid acquisition, but not self-sustaining.
Most PLG teams know this concept and don't measure it. Computing it requires: tracking all invite or share events as first-class objects with a referrer_user_id property, tracking signup completions that are attributable to a share or invite, and measuring the conversion rate from share-to-signup (not just the share count). The viral coefficient = (average invites per user) × (invite-to-signup conversion rate).
If your product has a share or invite mechanic but you're not tracking referrer attribution end-to-end, you don't know your viral coefficient and you can't optimize it.
Which Users Are Generating the Most Viral Loops?
Viral activity is not distributed evenly. In most PLG products, 10–20% of users generate 60–80% of the viral invites. These are your "viral supernodes" — users who share the product widely, bring in teammates, or generate shareable content that attracts new signups. Understanding what behavioral characteristics these users share (their use patterns, their role if captured, their onboarding path) tells you who to accelerate in your onboarding and how to design for more of them.
This requires a "viral activity" event or property on users — something that aggregates their outbound sharing behavior and makes it filterable. Without it, viral supernodes are invisible in your analytics.
The Expansion Analytics Gap
For multi-seat B2B SaaS products, expansion — the path from one seat to many seats within an account — is often the highest-leverage PLG opportunity and the least-instrumented one. The expansion loop is distinct from the acquisition loop and the retention loop; it has its own behavioral signature.
What Triggers Expansion Events?
Seat expansion (adding users to a team account) is almost always preceded by detectable behavioral signals: a single user is using the product at high frequency, they've shared content with non-users, or they've started using collaboration features in a context where the value clearly requires more participants. These pre-expansion behavioral signals are instrumentable and predictable. If you can identify users in the 2–3 weeks before they trigger a seat expansion, you can build an in-product expansion prompt triggered by the behavioral signal rather than waiting for the user to navigate to a pricing page on their own.
This is one of the more direct connections between behavioral instrumentation and revenue. Teams that instrument pre-expansion signals and build in-product expansion triggers report 15–30% lift in expansion events attributable to the in-product prompt — events that would not have happened, or would have happened later, without the behavioral trigger.
Account-Level vs. User-Level Analytics
PLG expansion analysis requires account-level instrumentation, not just user-level. The question "is this account likely to expand" is an account-level question — it depends on the aggregate behavior of all users within the account, the account's current seat utilization, and the behavioral patterns of the highest-activity users. User-level event data needs to be aggregated to the account level (using group() calls in your SDK and account-level properties in your analytics system) before expansion signals become visible.
Without account-level instrumentation, PLG analytics is necessarily incomplete. You can see individual user behavior but not account-level health. And for B2B SaaS where churn and expansion are account-level decisions, individual user behavior is insufficient as the primary analytical lens.
Self-Serve Activation vs. Sales-Assist Activation
PLG products often have two activation paths: fully self-serve (user activates entirely through the product, no human contact) and sales-assisted (user triggers a sales touchpoint — books a demo, contacts support, or is flagged as high-value and proactively contacted by the sales team). The analytics question most PLG teams don't ask: are these two paths producing users with different long-term retention and expansion profiles?
In many early-stage PLG products, sales-assisted activations have significantly higher Day-90 retention and expansion rates than fully self-serve activations. This isn't necessarily a problem with the self-serve path — it might mean that sales assist is appropriately targeted at high-value accounts. But it becomes a problem when the PLG team's KPI is "percentage of activations that are fully self-serve" without accounting for the quality difference.
The right measurement is: for each activation path, what is the distribution of account-level NRR (net revenue retention) at 90 days? If self-serve and sales-assist produce similar NRR profiles, the self-serve path is genuinely better on a cost-adjusted basis. If sales-assist produces materially higher NRR, the cost of the assist might be well worth it for the accounts that receive it, and the analytics question becomes "which accounts benefit most from sales assist" — a behavioral scoring problem, not an aggregate ratio problem.
The Metrics That Tie It Together
A minimal PLG analytics dashboard that actually tells you about the health of the growth motion should include:
- Behavioral PQL rate: % of weekly new signups who meet the behavioral PQL criteria within 14 days
- PQL-to-paid conversion rate: of behavioral PQLs, % who convert to paid within 30 days
- Viral coefficient: computed monthly from invite/share-to-signup attribution
- Expansion trigger rate: % of accounts showing pre-expansion behavioral signals in any given 30-day window
- Account-level L28 active rate: % of paying accounts with ≥3 active users in the last 28 days (the leading indicator of expansion vs. contraction)
None of these metrics requires a custom SQL query if your instrumentation is set up correctly. All of them require that you've thought carefully about what your product's viral loop, expansion signal, and behavioral PQL look like before writing your tracking plan — which is where most PLG analytics practices break down. The measurement plan for PLG is more complex than the measurement plan for traditional SaaS, and it needs to be designed in advance of instrumentation, not reverse-engineered from whatever events happen to be firing.