Feature adoption rate: how to measure it and what to do with it

In short: Feature adoption rate is the share of eligible active merchants who used a feature in a period, usually 30 days, where "used" means the feature's real outcome and not a page view. Breadth is who tried it, depth is how far they went, frequency is how often they come back. Measure the three in PostHog with a trends insight and a formula, a breakdown, and a stickiness or retention insight, then compare against the target you set when you wrote the ticket rather than an industry average. A feature nobody uses is a discoverability problem first, a first-use problem second, and a removal candidate third.

What is feature adoption rate?

Adoption rate for one feature is a fraction:

Adoption rate = merchants who used the feature in the period / merchants who were eligible and active in the period, times 100.

Two words in the denominator do the work. Eligible means the merchant's plan includes the feature and it was switched on for them. A bulk payout feature on the top plan should not be judged against free-plan stores that cannot see it. Active means the store opened the app in the period, so churned and dormant stores do not drag the number down and hide a real signal.

The numerator needs the same care. Opening the payouts page is not adopting bulk payouts. Completing a batch is. Name the event at the real outcome, the same way an activation event sits at the first real result rather than the first click. If you only have page views, you are measuring curiosity, and curiosity is high for everything new.

One rate collapses three questions into one number.

Dimension	Question	Bulk payouts example
Breadth	What share of eligible active merchants used it at all?	31% of stores with 10+ affiliates ran at least one batch in 30 days
Depth	Of those, how far did they go?	40% of adopters paid 20+ affiliates in one batch or set a schedule
Frequency	How often do adopters come back to it?	Adopters ran a batch in 3 of the last 4 weeks

Breadth tells you whether merchants found it. Depth tells you whether it does the whole job or half of it. Frequency tells you whether it became a habit or a one-time try. A feature with high breadth and low frequency was interesting. A feature with low breadth and high frequency is loved by a few and hidden from the rest.

A fourth measure, time to adopt, is the days from a merchant first being exposed to the feature to their first real use.

How do you measure feature adoption in PostHog?

It starts before launch. The event has to be in the ticket, with its properties, or there will be nothing to count. I put that in the analytics section of every developer-ready handoff: for bulk payouts, bulk_payout_completed with affiliate_count, scheduled and plan.

Then, for each dimension:

Dimension	PostHog insight	Setup
Breadth	Trends, formula mode	Series A: unique users of bulk_payout_completed. Series B: unique users of any app event, filtered to eligible plans. Formula A / B
Depth	Trends, breakdown	The same event broken down by affiliate_count bucket or scheduled
Frequency	Stickiness	bulk_payout_completed, weekly, to see how many weeks out of four adopters used it
Return	Retention	First-time bulk_payout_completed as the start event and the same event as the return event

PostHog's trends docs explain that trends aggregate by total count by default, that you can switch to unique users or daily active users, and that you can break a series down by properties. The formulas docs add that with formula mode enabled, two series A and B can be combined as A / B, which plots A divided by B. That ratio, with the right filters on B, is your breadth over time, and breaking it down by plan shows which tier adopts.

For frequency, the stickiness docs describe the insight as showing how many times users perform an event within a time period, with the x-axis being the number of times they did it. A bulk payout feature where most adopters sit at one week out of four is a trial, not a habit.

For return, the retention docs describe first-time retention as counting a user in the cohort only if it was their first time performing the start event, which is the right cohort for a new feature, and note that the "on or after" option suits features that do not require users to come back in every period. Without it, a merchant who pays affiliates on the first of each month looks like churn.

Two practical notes. PostHog counts people, and a store can have four staff logins, so if your setup can count stores rather than people, use that for the denominator, and if it cannot, be consistent and say so when you report the number. And verify the event fires once, on the right action, before you trust any of this. The design QA checklist has that step because a double-firing event produces the most confident wrong numbers in the company.

What is a good feature adoption rate?

There is one benchmark I can verify. Userpilot's 2025 SaaS product metrics benchmark report puts the average core feature adoption rate at 24.5% and the median at 16.5%, from 181 B2B SaaS companies, measured from the core feature adoption dashboard in Userpilot's own product. By industry it ranges from 22.6% for fintech and insurance to 31% for HR. There is no e-commerce category, the companies are Userpilot customers, and each defines its own core feature, so treat it as a sanity check and not a target.

Even as a sanity check it says something. The core feature is the thing the app exists for. If fewer than one in five active merchants reach your core outcome in a month, the problem is either the definition or the product. For optional features there is no published number I would trust, and I would expect them to sit well below the core rate.

The benchmark that matters is your own, set when you wrote the ticket. "40% of stores with 10+ affiliates run a bulk payout within 30 days of release" is a target you can hit or miss. I write it in the ticket's evidence section next to the problem it came from, so that at the 30-day review the question is not "is 31% good?" but "we said 40%, we got 31%, what was in the gap?"

What do you do with a feature nobody uses?

In order, because the cheap causes come first.

Symptom in PostHog	Likely cause	First fix
Zero events at all	The event is not firing, or eligibility is wrong	Check the Activity tab, check plan gating
Few page visits, few completions	Discoverability	Move the entry point, announce in-app where the old workaround happens
Many page visits, few completions	First use	Fix the empty state and the first step
Completions in week one, none after	No habit, or the job is rare	Check frequency expectations, then depth
Adopted by one plan only	Packaging	Decide whether it is gated right

Discoverability is the usual answer, and the usual mistake is to announce the feature on a homepage banner nobody reads. Put the entry point where the merchant is doing the thing the feature replaces. A bulk payout button belongs on the payouts table, next to the row-by-row actions it makes unnecessary.

If they reach the page and leave, it is the first-use experience. The screen a merchant sees with no batches yet decides whether they try one, and I covered what it should contain in empty state design.

Removal is the third option, and teams avoid it longer than they should. My criteria: breadth under a few percent of eligible merchants after 90 days with the entry point fixed, no depth among the few, and a maintenance or support cost that is real. Remove it with a notice to the merchants who used it, keep their data, and write down what you learned in the request log so the next person does not rebuild it.

Sometimes the honest answer is that the problem the feature solved was not real. Go back to the ticket's evidence section. If it was a founder request with no data, you have your answer and a cheap lesson.

How does adoption feed the roadmap?

Adoption numbers are the closing entry on one ticket and the opening evidence for the next. Three loops run from them:

• High breadth, low depth. Merchants found it and stopped early. The next ticket is about the second step: scheduling, the 20+ affiliate case, the export. Depth breakdowns tell you which.
• Low breadth, high depth and frequency. A few merchants depend on it. The next ticket is discoverability or packaging, and the merchants who use it are your interview list.
• Adoption split by plan or by health band. If at-risk stores never touch the feature that healthy stores use weekly, it is a candidate for the health score and for onboarding, not just for the roadmap.

Review every shipped feature at 30 and 90 days against the target in its ticket, and put the result into the same queue as feature requests and support themes. I described how that queue is ranked in feature requests to roadmap. A feature that hit its target earns the next step. A feature that missed earns a diagnosis from the table above before it earns anything else.

Where to start

1. Pick the last feature you shipped. Write its adoption event, its eligible population and its "used" definition on one line. If you cannot, that is the first fix.
2. Build the breadth insight in PostHog: unique users of the event divided by unique active users of eligible plans, by week, broken down by plan.
3. Add a stickiness insight and a first-time retention insight on the same event.
4. Write a target into the ticket of the next feature before it ships, as a percentage of eligible merchants within 30 days.
5. Put a 30-day and a 90-day review on the calendar for each release, and bring the table above to the review.