What it means
A software company launches a reporting feature and sees many logins but few new reports, because login counts cannot show whether the feature landed. Feature adoption rate compares meaningful users of that feature with people who could reasonably use it.
Pendo describes feature adoption as interaction with a particular feature and highlights breadth, duration and account-level views, while Amplitude provides analysis methods for feature uptake. Neither source implies that a click alone equals lasting value, so define the feature boundary and a qualifying event that matches the product's purpose; a report builder might require saving a report, not merely opening its menu.
Choose a cohort of eligible users who had access during the period, exclude roles that cannot use the feature, and state whether free-trial users are included. For example, 180 of 600 eligible users creating a report in a month gives a 30% adoption rate, and a feature available only on a paid tier should not be divided by the entire user base.
A user who creates ten reports counts once in a user-level rate, not ten times, because usage frequency and depth are separate measures. An account-level rate might count organisations with at least one qualifying user, and it can differ greatly from the user-level rate.
Keep the period consistent as well, since a seven-day rate and a monthly rate cannot be compared directly. Read the number against the feature's purpose.
A low rate may be perfectly normal for a specialised tool used only by a small role, and a feature that solves a quarterly task should not be judged against a daily-use goal. Check launch exposure too, because users who never saw an announcement behave differently from those who did, and a new feature may need onboarding or documentation before people can benefit.
Guard against distortions. A default screen that loads automatically can inflate apparent adoption, a high early trial rate can fade (so measure repeat use over later weeks or cohorts), and a rising rate may only reflect eligible users leaving the denominator after a plan or access change, so check absolute counts.
Annotate instrumentation changes after an interface update before interpreting a trend, and segment by customer tenure, plan and role while avoiding small groups that reveal private behaviour. Adoption measures reach, not value or revenue, since customers may use a free feature without changing payment or retention.
Track task completion, time saved or error reduction if the purpose is productivity, and interview users who tried and stopped, because they may face a usability or reliability problem rather than lack of interest. An experiment can test in-app guidance if it compares similar eligible groups over enough time, and a feature with low adoption might still matter for compliance or a small high-value segment, so the aim is to ask whether intended users found and used a feature and whether it helped, not to pressure everyone to use everything.
In practice
Real-world examples.
Example
In a month, 180 of 600 eligible users of an accounting platform create a report, giving 30% user-level adoption. The product team also records that 90 of those 180 returned to build a second report the following month. That repeat figure is reported separately from the adoption rate.
Example
A quarterly tax-export feature in a payroll product is evaluated over a quarter rather than a week, because customers only need it at filing time. Judging it by weekly active use would make a healthy feature look neglected. The team compares each quarter's rate with the previous quarter's.
Example
One administrator per company uses a user-permissions feature in a project management tool, producing a low user-level rate but a high account-level rate. The product manager reports both and explains that the feature is intended for administrators only. Eligibility is set to administrators, so the denominator is restricted to them.
Formula
Calculation
Feature adoption rate = unique eligible users with a qualifying feature action / unique eligible users in the same period x 100. An account-level version substitutes accounts consistently in both the numerator and the denominator.
Worked example, user level: in March, 180 of 600 eligible users save at least one report. Rate = 180 / 600 x 100 = 30%.
Worked example, account level: the 600 users belong to 100 customer accounts, and 40 of those accounts have at least one user who saved a report. Account-level rate = 40 / 100 x 100 = 40%, which is higher than the user-level rate because one active person is enough to count an account.
Worked example, denominator effect: in April the same 180 users save a report, but a plan change removes access for 150 users, leaving 450 eligible. Rate = 180 / 450 x 100 = 40%. The rate rose by 10 percentage points although the absolute number of adopters did not change, which is why counts should be reviewed alongside the percentage.Case study
Seen in the real world.
This entirely fictional case follows Quay Software, an invented company. Its new dashboard showed many menu opens but few saved reports: only 90 of 600 eligible users, or 15%, had saved one. User interviews found the report template was confusing, and several people had opened the menu by accident.
The team revised onboarding, simplified the template and then tracked report completion and repeat use alongside adoption. Three months later, 180 of 600 eligible users had saved a report, a 30% rate, and the team checked that repeat use and support tickets moved in a healthy direction too. The case is invented and the figures are for illustration only.
Watch out
Common mistakes.
- Dividing feature users by all users when most lack access.
- Counting an accidental open as a completed meaningful action.
- Treating early trial as proof of sustained value.
Questions
People also ask.
Should users or accounts be counted?
Choose the unit that matches the product decision and label it.
Is a high rate always good?
No. Relevance and outcomes matter, especially for specialised features.
How is repeat use measured?
Use a separate frequency or cohort-retention view.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%