PLG Metrics: Instrumenting Free-to-Paid and the Reverse Trial

The free-to-paid moment is not a single event, it's a sequence of upgrade-intent signals that start well before someone hits a paywall. Instrument the sequence — activation depth, gate collisions, and reverse-trial taste events — not just the "upgrade clicked" button, or you'll optimize the wrong lever entirely.

Quick Answer: PLG metrics require instrumenting three layers — usage depth (are they doing real work), gate collisions (where they hit limits), and willingness-to-pay signals (did they act on the gate). Reverse trials need a fourth: decay-from-premium tracking after the trial ends.

Why Paywall-Hit Rate Is a Vanity Metric

Paywall-hit rate tells you where users stop, not why they'd pay to continue. A high hit rate can mean your gate is well-placed on a valuable feature, or it can mean users are bouncing off a limit they never wanted to cross in the first place. Without context, the number is directionally useless.

The distinction that matters is between an event and a signal. paywall_viewed is an event — it fires whenever code executes. A signal requires that event to correlate with actual purchase behavior across a cohort, which only shows up after you've tracked it against outcomes for weeks or months.

This is the same trap covered in the complete guide to analytics instrumentation: teams instrument what's easy to fire (a click, a page view) rather than what's diagnostic (a moment tied to a later paid conversion). Three things tend to get conflated:

• Frequency (how often the gate fires) — tells you about your limits, not your users.
• Friction (how annoyed users are) — inferred from repeat hits, retries, or rage clicks.
• Intent (whether they'd pay to remove the friction) — only visible through what happens after the hit: upgrade page visit, pricing page dwell time, sales chat opened.

Teams that only track frequency end up "fixing" gates that were actually working as intended — the friction was the product. Kathy Sierra's framing of building "bad-ass users" applies directly here: the goal of the free tier isn't to minimize friction everywhere, it's to build competence up to the exact point where the paid tier's extra capability becomes obviously worth paying for.

Mapping the Free-to-Paid Funnel Before You Instrument It

A free-to-paid funnel has five stages — signup, activation, habit, gate collision, and conversion — and each stage needs its own event, not a single "converted" flag. Skipping stages in your tracking plan means you can measure the outcome but never diagnose where it broke.

Before writing a single tracking call, map this funnel against the guidance in tracking plan before code: define the activation milestone with your team first, because a vague definition ("logged in once") will quietly inflate every downstream conversion rate you report.

Activation Is Not a Login

Activation should be defined as the first moment a user experiences the product's core value, which is almost never the same as signing in. For a project-management tool, that might be "created a project with 3+ tasks and assigned one to someone else" — not "opened the dashboard."

Get specific with your team about the activation milestone before instrumenting anything downstream:

1. What action, if a brand-new user takes it, correlates most strongly with 30-day retention in your existing data?
2. Can that action happen accidentally, or does it require deliberate effort? Accidental actions make weak activation signals.
3. Does it involve a second party (invited teammate, shared document)? Multiplayer activation tends to predict paid conversion better than solo activation, because it's a leading indicator of organizational lock-in.

Feature-Gating Signals: Instrument the Collision, Not Just the Click

Every feature gate needs a structured collision event that captures which limit was hit, how close the user was to it beforehand, and what they did immediately after — clicking upgrade is only one of several outcomes worth tracking. Treating "gate hit" as binary throws away the richest data in the whole funnel.

A well-instrumented feature_gate_hit event should carry:

• Gate type: usage-based (seat count, storage, API calls) vs. feature-based (SSO, advanced permissions, custom fields).
• Proximity before hit: was the user at 60% of the limit a week ago, or did they jump from 20% to 100% in one session? Sudden hits and slow-approach hits predict different things.
• Post-hit action: dismissed, viewed pricing, started checkout, contacted sales, invited a teammate to work around the limit.
• Retry count: how many times they hit the same gate in a session or week before acting.

Follow event naming taxonomy and convention here — feature_gate_hit with a gate_type property scales far better than a bespoke event per gate (storage_limit_hit, seat_limit_hit, export_limit_hit), which fragments your funnel analysis and makes cross-gate comparison require a join across a dozen event names.

Usage-Based vs. Feature-Based Gates Need Different Instrumentation

Usage-based gates (seats, storage, API volume) are quantitative and give you a distance-to-limit metric for free. Feature-based gates (SSO, audit logs, advanced roles) are binary — the user either has access or doesn't — so the signal has to come from attempted access, which means instrumenting the click on a locked feature, not just its existence in the UI.

Usage Signals vs. Willingness-to-Pay Signals: The Distinction That Matters Most

Usage signals show that a user is getting value; willingness-to-pay signals show they'll trade money for more of it — and the two correlate less than most PLG teams assume. A power user who's maxed out engagement inside the free tier's limits may never upgrade if the free tier already satisfies them completely.

Willingness-to-pay signals tend to cluster around:

1. Active seeking behavior — visiting the pricing page unprompted, opening a comparison of plans, searching help docs for "upgrade" or "billing."
2. Workaround abandonment — a user who previously worked around a limit (exporting manually instead of using an integration) suddenly stops working around it and hits the gate instead. That shift often means the workaround cost more effort than they're now willing to spend.
3. Second-user involvement — a teammate, not the original signer-upper, hits the gate. This is a strong signal because it means the product has already spread inside an account before money has changed hands.
4. Explicit intent actions — starting a checkout flow and abandoning it, entering a coupon code, or contacting sales. Even an abandoned checkout is a stronger signal than ten feature_gate_hit events with no follow-through.

This is where survivorship bias in analytics is worth revisiting: if you only study users who converted, you'll conclude that heavy usage causes upgrades. But plenty of heavy users never convert because the free tier fully serves them — and plenty of light users convert fast because of a single willingness-to-pay signal like a teammate hitting a seat limit. Study the non-converters with equal rigor, or your model of "what predicts upgrade" will be built entirely on hindsight.

Instrumenting the Reverse Trial Correctly

A reverse trial gives users the paid tier by default for a limited window, then downgrades them to free — which means the metric that matters isn't adoption during the trial, it's the decay curve after it ends. Standard trials measure "did they use the premium features"; reverse trials must measure "did they keep behaving like a paid user once the premium features were taken away."

The reverse-trial pattern (used by tools like Slack, Calendly, and Loom's early growth motion) inverts the usual funnel: taste first, gate later. That changes what you need to track:

• Premium-feature touch rate during the trial window — which specific premium capabilities did the user actually engage with, not just have access to.
• Trial-end downgrade reaction — do they immediately hit the newly-reinstated gate (strong signal), or does usage just quietly decline (ambiguous — could be churn, could be indifference)?
• Decay-adjusted retention — cohort retention measured specifically in the two weeks after trial-end, compared against a cohort that never had trial access. If the trial cohort's retention converges with the never-trialed cohort within days, the trial didn't build a habit.
• Re-engagement after downgrade — does the user come back and hit the same premium gate again within 30 days? This is often the strongest single reverse-trial signal, because it means they remember what they lost.

Reverse trials work by loss aversion, not discovery — the mechanism only fires if the user actually formed a habit around the premium feature during the window. If your instrumentation only tracks trial-period usage and stops there, you're measuring the wrong half of the experiment.

The customer's actual job they were hiring the premium feature for is the frame worth returning to here — see the complete guide to jobs to be done for how to separate "used the feature" from "the feature did the job they needed done," since a reverse-trial user can touch a feature without it ever becoming load-bearing to their workflow.

A Practical Reverse-Trial Event Set

Tying Monetization Experiments to a Measurable Bar

None of this instrumentation matters if a monetization experiment ships without a predefined success threshold — "we'll know it worked if conversion goes up" isn't a bar, it's a hope. Every reverse-trial variant, gate placement change, or pricing test needs a conversion-rate threshold agreed before the experiment launches, not interpreted afterward from whatever the number happened to be.

This is the discipline Prodinja's Prioritization workspace is built around: PLG and monetization experiments get logged with the same RICE-style reach, impact, confidence, and effort inputs as any other roadmap bet, plus a conversion threshold attached up front. That keeps a reverse-trial redesign from getting graded on vibes just because it's a growth experiment rather than a feature — it carries the same measurable bar as everything else on the roadmap.

Key Takeaways

• Instrument the funnel stage, not the outcome — signup, activation, habit formation, gate collision, and conversion each need their own event, or you can't diagnose where a drop-off actually happens.
• Define activation as value delivered, not login — a vague activation milestone silently inflates every downstream conversion number you report.
• Structure gate-collision events with type, proximity, and post-hit action — a single generic feature_gate_hit event with rich properties beats a dozen bespoke event names.
• Usage and willingness-to-pay are different signals — heavy usage doesn't guarantee conversion, and light usage with one strong intent signal (abandoned checkout, teammate hitting a seat limit) can convert faster.
• Reverse trials live or die on the decay curve after the trial ends, not adoption during it — track post-trial gate hits and 30-day re-engagement as your strongest signals.
• Study non-converters as carefully as converters — otherwise survivorship bias will convince you usage alone drives upgrades.
• Attach a conversion threshold to every monetization experiment before it ships, so growth bets are judged against a predefined bar instead of a post-hoc read of the numbers.