Building an Eligible-Cohort Adoption Rate Metric for Gated Features
Measure adoption only among customers who could actually use the feature.
A single adoption percentage, measured across an entire user base, hides the exact segments a product team needs to see clearly. An acceptable aggregate number can sit on top of a split where top-plan accounts are running far above it and at-risk accounts are running far below it, and the average simply erases that gap. That erasure is the whole problem: a team staring at one healthy-looking number has no way of knowing whether its highest-value customers are thriving while its most fragile accounts are quietly failing.
The damage gets worse because most teams define "adopted" the same sloppy way: one click, one view, one encounter with the feature. Treating activation (a single encounter) and adoption (repeated, workflow-integrated use) as the same event erases a distinction that actually points to two different failure modes, one about discovery and one about value. A user who opened a feature once and never returned is not a data point to celebrate. That person is a warning sign dressed up as a success metric.
For product-led growth companies, the distortion runs deeper, because the denominator itself is broken. Free-tier users who were never eligible for a gated feature still get counted in the base rate, dragging the number down for something they could not have used. Median PLG activation rates are around 37%, so the majority of signups never even reach the activation moment, let alone a feature that sits behind a paywall. A metric built on that kind of base cannot tell a growth team what it needs to know: among the people who actually had a shot at using this feature, how many are using it well. That question is what the rest of this piece is built to answer.
What "Eligible" Means and Why the Denominator Is the Hardest Design Decision
Every adoption rate is only as trustworthy as the group of people it's measured against. Getting that group right requires three independent filters, and most teams apply them inconsistently or skip them altogether.
The first filter is plan or entitlement access. A user sitting on a free or lower-tier plan who literally cannot see the feature does not belong in the denominator. Counting them inflates the pool of "eligible" users and deflates the adoption rate for a feature those people never had a chance to touch. This sounds obvious written down, but it's the single most common mistake in self-reported adoption numbers: teams pull "total users" from a dashboard without checking which plan tiers actually have the feature turned on.
The second filter is role relevance. Two users can sit on the identical plan and still have completely different reasons to touch a feature. A tool built for administrators means nothing to an end user, even if billing says they're on the same contract. Role needs to be baked into who counts as eligible from the start, not bolted on afterward as a segment to slice the data by once the numbers look disappointing.
The third filter is a fair opportunity window. Someone granted access yesterday and someone who's had access for months are not standing in the same place. Including both in the same denominator at the same moment makes the rate look worse than it is, because the recent arrival hasn't had a real chance to find the feature yet. The denominator should only include people who've had a meaningful stretch of time to encounter what's being measured.
A fourth consideration applies specifically in 2026: AI agents now fire product events inside many platforms, and those events can make an account look active even after the humans behind it have gone quiet. Separating agent-generated signals from human signals is a prerequisite for measuring adoption honestly. A denominator that mixes bot traffic with human behavior will tell a team its feature is thriving right up until renewal season proves otherwise.
Together they define who actually belongs in the count, and skipping even one of them quietly corrupts everything calculated downstream.
Building the denominator without a new instrumentation layer
Most teams already have everything required to build this denominator correctly. There's no need for new tracking, new events, or a new analytics platform. The two sources already exist: a backend database that tracks plan, role, and configuration state, and a product analytics layer that tracks behavior over time. The denominator is simply the join between them.
The database side answers the structural questions: what plan tier is this account on (the entitlement filter), what role does this user hold (the relevance filter), is the feature even switched on for this account, and when did eligibility start (the opportunity-window filter). The analytics side answers a different question entirely: has this eligible user fired any event inside the feature's surface area during the defined window. That distinction separates "eligible and never exposed" from "eligible, exposed, but never adopted," and those are two very different problems requiring two very different fixes.
Put together as a query, it looks like this: eligible users are the accounts or people where the plan includes the feature, the role falls into the relevant set, the first-eligibility date is at least N days in the past, and the user_id belongs to an actual human rather than an API key or bot. Every piece of that query draws on data that already lives somewhere in a typical SaaS stack. The plan, role, and configuration fields exist in any operational data model, and the usage events exist in any product analytics setup already running. The actual work is defining the join and writing it down clearly enough that it doesn't get redefined differently by every team that touches it.
Where event naming across a product is inconsistent, a structured naming convention has to come before any adoption number gets calculated, because mismatched event names will quietly corrupt the join before it even runs. That convention is the unglamorous prerequisite that makes everything downstream trustworthy.
Once the join is built, it should live somewhere permanent, as a reusable notebook or saved query, so growth, RevOps, and product teams are all pulling from the same denominator instead of each recalculating eligibility their own way. A metric that gets redefined every time someone new runs the numbers is a guess with a decimal point.
One more distinction belongs in this same build step: eligibility and adoption both need to be measured at the account level and the person level, separately. A feature can be eligible at the account level because the plan supports it, while remaining completely unused at the person level because no individual inside that account has touched it. Collapsing those two into a single number hides exactly the kind of gap a team most needs to see.
Defining a numerator that measures repeated successful use, not first contact
A denominator built with this much care deserves a numerator that matches its rigor. Counting any interaction, a click, a page view, a single open, as "adoption" produces a number that treats a feature a customer depends on daily the same as one they poked at once and abandoned.
The standard to hold here is consistent, repeated use driven by actual value to the user. Adoption is a feature integrated into someone's regular workflow, and that requires seeing the behavior show up more than once. The fourth stage of a typical feature adoption funnel, where a user returns and uses the feature again, is the only stage that actually counts as adoption. Everything before that, first click, first login, first glance, is just a precondition that has to happen before adoption can even become possible.
What that means practically is choosing the right event to count. The numerator should never be "viewed the feature." It should be the completion of whatever action the feature exists to produce: a saved report built from live data, a shared workflow carried through to completion, a support ticket resolved using the feature's built-in process. A team measuring report views instead of saved reports is measuring curiosity, not value delivered.
A defensible standard also needs a depth threshold: a minimum number of qualifying interactions inside the measurement window before a user counts as adopted. That threshold turns a binary adopted-or-not label into something that actually tracks habit formation rather than a one-time accident. Feature stickiness, measured as the feature's own daily-active over monthly-active ratio, sharpens this further by distinguishing a feature people reach for weekly from one they touch once a month out of habit rather than reliance.
The numerator and denominator have to share the same eligibility window. A user who adopted the feature before the measurement window even opened shouldn't be counted toward a new cohort's numerator, because doing so inflates the rate with behavior that happened outside the period being measured. Finally, time-to-second-use deserves tracking as a leading indicator sitting just outside the adoption rate itself. Users who don't come back to a feature quickly after trying it once show a high probability of abandoning it altogether, and catching that early, as its own signal rather than folding it into the adoption number, gives a team a chance to intervene before the user disappears from the numerator for good.
The three-stage progression that turns a rate into a diagnostic tool
A single adoption rate, however carefully built, is still just one number. A three-stage progression gives it its real power by separating three distinct failures: a discoverability failure, a value failure, and a habit failure. Picture it as a funnel with three gates, each one answering a separate question.
Stage one is the key feature adoption rate: eligible users who completed the defined adoption action, divided by eligible users who were actually exposed to the feature. This stage is where the most important diagnostic fork in the whole framework happens. A low rate paired with high exposure means users found the feature, tried it, and chose not to come back, a value problem. A low rate paired with low exposure means eligible users aren't even encountering the feature, a discoverability problem. Diagnosing which of those two is happening determines which intervention a team should run, and running the wrong one burns engineering time on a fix that was never going to move the number.
Stage two is the repeat key-action rate: activated users who repeat the key action in the next period, divided by activated users. This stage answers whether that first success turned into a habit. A healthy stage-one rate sitting on top of a weak stage-two rate means the feature is getting adopted once but not sticking, which is a retention problem dressed up as an adoption win.
Stage three is retained adoption: activated users still active in a later cohort, divided by activated users from the starting cohort. The shape of the retention curve matters as much as the number itself. A curve that drops sharply and then flattens suggests curiosity-driven trial without lasting value. A curve that declines gradually and then stabilizes suggests a subset of users has formed a genuine habit, and 14-day and 30-day windows are useful points for comparing the two shapes.
Every stage in this progression needs to be segmented by role, plan tier, and acquisition cohort, because a single blended number at stage one can hide two completely different realities. Power users near 70% adoption and new users in their first weeks at a fraction of that are two separate problems, not one problem with one fix. They're two separate interventions that need to run in parallel, aimed at two different populations with two different needs.
Benchmark Ranges and Where They Mislead
Benchmarks exist to calibrate expectations, not to hand a team a target to chase. The right adoption rate for any given product depends entirely on how tightly the denominator was drawn, and a loosely defined denominator will always produce a worse-looking number than a well-defined one, regardless of how the product is actually performing.
Industry data from Q3 and Q4 of 2025 shows core feature adoption measured against an entire user base landing at a median well below what a tightly segmented eligible-cohort metric would produce for the same feature. Most of that gap comes down to measurement method, not product performance. Major feature releases also tend to land lower in their early weeks than product teams expect going in, and minor features carried a 6.4% median adoption rate in 2025, so most shipped features barely move usage even under a generous, broad definition.
That gap between the median and the top performers isn't mostly a product quality gap. Top-performing SaaS companies achieve substantially higher adoption rates for their strategic features through systematic measurement, which suggests the companies pulling ahead are doing exactly the denominator and numerator work laid out in this piece, not necessarily building a fundamentally better feature.
The activation gap matters here too. A meaningful share of free users inside a typical PLG funnel never reach the activation milestone at all. Those accounts sit in the denominator and will never reach the numerator without some kind of intervention, and until that intervention runs, they make the eligible-cohort metric look worse than the underlying product actually deserves.
The right way to use any benchmark is to compare a team's own eligible-cohort rate against its own prior period, using the exact same cohort definition, rather than against an industry median built on a completely different denominator. Benchmarks are useful for spotting trend direction. They are far less useful for judging whether a number is good in any absolute sense, because no two companies are measuring the same population the same way.
One last caveat belongs here for anyone building this in 2026: if AI agent activity isn't filtered out of both the denominator and the numerator, the resulting rate reflects a mix of human and synthetic behavior that no benchmark, industry-wide or internal, was ever built to account for.
