Product Adoption Rate: Choose the Right Denominator Before You Calculate
By Ulas ArslanPublished Updated
Product adoption rate is useful only when you define who could adopt, what behavior counts as adoption and how long you observe it. For a defined cohort, divide the number meeting your adoption rule by the eligible population and multiply by 100. Keep user adoption, account adoption and feature adoption separate.
Write the definition in a single sentence
Before building a dashboard, complete this sentence: “Among [eligible population], an adopter is someone who [observable behavior] within [time window].” If different teams fill in different answers, settle that difference before reporting a rate.
Pendo’s product adoption guide describes several measures and notes that the choice depends on what active use means for the product. The formula here is an explicit cohort-based operating measure. It should not be presented as the only definition used in product analytics.
For a weekly planning tool, an illustrative rule might require publishing a valid plan in at least three of the first four weeks. For a tool used only at month-end, that weekly rule would be inappropriate. Design around the customer’s working rhythm.
Choose who is eligible
Purchased seats, invited users and people expected to perform the core task are different populations. A finance viewer may need access to read a report but never be expected to create it. Putting that person in a creator-adoption denominator would lower the rate for the wrong reason.
Define the population at the start of the measurement window and keep later changes visible. If a team removes inactive users halfway through the month, the reported rate can rise without any additional use. Record the cohort and the rule version so the change can be explained.
Exclude test users and internal service accounts where they do not represent customer behavior. Keep exclusions documented. A clean CRM data-quality process helps maintain the identity and company mapping behind the analysis.
A worked user-adoption example
Suppose a fictional rollout has 120 licensed seats. Of those, 100 people are designated planners and 20 are read-only viewers. All 100 planners have the same four-week observation period. Sixty meet the agreed repeat-planning rule.
| Measure | Calculation | Interpretation |
|---|---|---|
| Planner adoption | 60 ÷ 100 × 100 = 60% | Share of eligible planners meeting the rule |
| Adopters as a share of licensed seats | 60 ÷ 120 × 100 = 50% | A different seat-based measure |
| Planners who logged in | 85 ÷ 100 × 100 = 85% | Access activity; does not establish repeat planning |
Do not let the denominator change the story
All three percentages can be arithmetically correct. They answer different questions. The 60% figure is the chosen planner-adoption measure. The 50% figure describes the same adopters against all licensed seats. The 85% figure counts a less demanding action.
If the team wants to improve adoption, investigate the forty eligible planners who did not meet the rule. Some may lack permissions, some may have changed responsibilities and others may find the workflow unsuitable. Those explanations lead to different actions.
If a customer confirms that someone was never intended to plan, correct the population transparently. Do not silently rewrite earlier cohorts to make the current result look better. Show the effect of the correction when it materially changes the rate.
Account adoption needs its own rule
A company with one active user may or may not have adopted the product. Define the account-level behavior based on the customer outcome. In this example, an account might need its designated planning team to publish and use a shared plan over several cycles.
If six of ten eligible companies meet that account rule, account adoption is 60%. That result does not follow automatically from the user-level 60% above. One large customer can dominate a user count while several smaller companies remain stuck.
Report both when they support different decisions. User-level results can guide training and access fixes. Account-level results can guide the CSM’s review of the agreed rollout. Link each measure to the specific goal in the customer success plan.
Use adoption to investigate, then verify value
Compare customers with the same use case, expected frequency and observation window. Newly invited users need enough time to meet a repeat-use rule. Keep them pending until that window is complete, or report a clearly defined partial-period measure.
Pick one concrete barrier to address and check the next comparable cohort. If access is the problem, fix access. If the workflow fails to support the customer’s job, more reminders will not be enough. Ask users where the work breaks and validate the change with them.
Finally, compare behavior with the customer’s intended result. Repeated use can be useful evidence, but it does not by itself prove time saved, higher revenue or future retention. Combine the rate with a direct outcome check and use time to value separately to understand how quickly new customers first benefit.