Product & DesignFree
Product Feature Adoption Measurement Review
Every feature split four ways: who was eligible, who tried it once, who came back, and who now reaches for it every week.
River's adoption review reads the usage export rather than the adoption dashboard. Events by user, account, plan and week go in. Every feature comes back split four ways: the users who were eligible to use it, the users who tried it once, the users who came back in a later week, and the users for whom it is now routine. Four numbers where the dashboard shows one, and the gaps are the finding: a feature everyone tries and nobody repeats is a different problem from one nobody finds.
The published definition of the metric is the problem. Pendo, whose product exists to measure this, defines the rate as feature MAU divided by monthly logins. A denominator of logins counts every user who cannot reach the feature at all, on the wrong plan or without the permission, as a user who saw it and declined. PostHog states the other half plainly: retention counts anyone who came back and performed the event at least once. Once is the word doing the damage.
Built for the product manager three weeks past a launch holding one percentage and no way to tell whether it is good, and for the team deciding between investing again and cutting. Reach for it before the roadmap argument, not during. The launch itself gets sized by the experiment design brief, drop-off inside the feature belongs to funnel and retention analysis, and why a segment ignored it comes out of research synthesis.
The novelty and the hit report the same number
Take two features launched the same week. One is tried by 71 percent of users and used again by 8 percent of those triers. The other is tried by 31 percent and used again by 89 percent of them. On a single-number dashboard the first is the runaway success and the second barely registers. Eight weeks later the first has 224 regular users and the second has 298, from an eligible pool eighteen times smaller. The ranking was inverted the whole time.
The denominator does most of that damage. A feature restricted to admins on one plan tier has an eligible population of a few thousand inside a base of tens of thousands, and dividing its usage by total logins buries a genuinely excellent feature under one percent. Pendo's own guidance names the fix without putting it in the formula, advising teams to measure at the account level to separate out any users who may not need the feature. Eligibility is the denominator. Everything else is arithmetic on the wrong base.
Then the definition moves the number without anyone touching the product. Amplitude's own API exposes retention as three different modes, and its documentation notes that the rolling setting implies unbounded retention, which counts a user who returned on any later day as retained on every earlier one. Depth is a separate question again: PostHog's stickiness chart measures the exact number of times a user performed an action in a window. Breadth and depth are two findings, and one percentage cannot hold both.
How it works
Send the usage
Events or weekly rollups by user, account and week, from any analytics tool or your warehouse.
Set eligibility
Which plan, role and permission each feature needs, so every rate has an honest denominator.
Split the users
Tried once, came back later, and habitual, counted separately for every feature and segment.
Read the verdict
Each feature named as adopted, a novelty, undiscovered or unwanted, with what to do next.
What you get
- An eligible population per feature, from plan, role and permission, not total logins
- Tried once, came back, and habitual as three separate counts per feature
- The kept rate, meaning the share of triers still using it, ranked across features
- Adoption by segment, plan and account, with the gaps that beat the overall figure
- Every feature labelled adopted, novelty, undiscovered or genuinely unwanted, with the numbers
- A sheet holding the definitions and arithmetic, so a disputed figure is read rather than rerun
Common questions
What is the difference between tried once and adopted?
A trier performed the action at least one time. An adopter came back in a later week and kept coming back. The review counts both separately, plus a habitual tier for users active in four or more of the last eight weeks. You can move that threshold and every downstream number moves with it.
Our adoption rate is 34 percent. Is that good?
Nothing can be said until the denominator is named. Thirty-four percent of every account is a very different result from thirty-four percent of the admins who can actually reach the feature. The review recomputes against the eligible population first, then tells you whether the number was flattering or brutal.
How does it know who was eligible?
From whatever your export carries: plan, role, permission, seat type, feature-flag state. Where that is not in the data you describe the rule in the intake form and it applies it. Eligibility is stated on the report in every case, so anyone reading the number can see the base it used.
Does it work at the account level as well as the user level?
Both, and the two disagree in a useful way. A feature used by one power user in ninety accounts is broad account coverage and shallow seat coverage, which is a training problem. The same total concentrated in three accounts is a different problem. Give it an account id and it reports both.
Which exports can it read?
Amplitude, Mixpanel, PostHog, Pendo, Heap, or a warehouse query with one row per user per feature per period. Raw events, weekly rollups and pivot tables all work. Send it what you already have rather than building something new, and it states which fields it used. Where the events themselves are suspect, run the tracking audit first.
We only have four weeks of data. Is that enough?
Enough for breadth, first repeat and segment gaps, which is most of the value. Not enough for duration, so the review says so rather than extrapolating a curve from four points. It also names the week you would need to reach for the habitual tier to mean anything.
What does it recommend for a feature nobody adopted?
That depends on which number is low, and the two branches lead opposite ways. High trial with low repeat means the feature was found and rejected, so the fix is the feature. Low trial with high repeat means it works for everyone who finds it, so the fix is discovery. Read the funnel analysis next for the second case.
Product Feature Adoption Measurement Review
Fill in the form and your workspace opens with the work already underway.