How to Measure Feature Adoption

Choose an event that represents useful progress, such as successfully sharing a report, rather than simply opening a menu. Decide whether you measure people or accounts, and use that unit consistently. For a limited rollout, identify who actually had access during the measurement window.

Amplitude's feature engagement documentation describes adoption as the percentage of active users engaging with a feature and reports frequency separately. For a restricted beta, you can use eligible active users as your cohort, but label that choice explicitly when comparing it with other reports.

Source: Amplitude: Feature engagement and adoption

For that cohort, adoption rate = distinct eligible active users who completed the usage event during the window / all eligible active users during the same window × 100. The numerator must be a subset of the denominator. If there are no eligible active users, report the rate as unavailable rather than zero.

In a fictional example, 40 of 200 eligible active administrators share a report during one week, giving 20% adoption. If those 40 people share 120 reports, adoption is still 20%; the extra events describe frequency. If 18 of those same 40 share again the following week, that is 45% repeat usage for the original group, assuming all remain eligible for follow-up.

Speak with people who never tried the feature, people who started but failed, and people who used it successfully. Ask the first group how they currently do the task, the second where the attempt stopped, and the third what outcome they achieved. Avoid assuming everyone needs the feature every week.

Choose a next action that matches the evidence: improve discovery, remove a permissions problem, simplify a confusing step, or revisit the original need. Set a review date and compare consistent cohorts. An increase after a change is useful evidence, but it does not by itself establish that the change caused the increase.