What it means
A software company sees 10,000 signups, but only 2,000 complete a meaningful first task, and product usage analytics asks where users stop and whether a design or onboarding problem prevents them from reaching value. Begin with a decision, such as whether a new feature is used, whether customers return or whether a workflow causes abandonment, because tracking every click without a question can create cost and privacy risk.
Define meaningful events too: opening a screen may show exposure while completing a task shows a stronger action, and Amplitude's feature-adoption guidance suggests selecting events that reflect successful use or a value moment for the particular product. Document identity and units, since one person may use several devices and a business account may have many users, and state whether a metric counts unique people, active accounts, sessions or actions.
Choose the timeframe, because daily active use may matter for a messaging app while monthly activity can be more meaningful for accounting software used at month-end, so a low daily rate is not necessarily poor adoption. Check data collection as well, because a missing event after an app update can look like a sudden drop, so compare instrumentation versions and sample sessions before telling a team that customers stopped using the feature.
An illustrative feature-adoption rate is eligible active users who completed a defined feature event divided by eligible active users in the same period. If 400 of 2,000 qualify, the rate is 20%, and eligibility matters when a feature is unavailable on some plans.
The broader Amplitude guide describes product analytics as understanding behaviour across a product journey, and vendor tools can help organise events and cohorts, but the business must choose meaningful definitions and protect user data. Look at sequences, not only totals, because a feature may be opened often since users repeatedly fail and retry, so follow the steps toward an intended result and inspect support feedback.
Compare cohorts, since people who joined after an onboarding change may behave differently from older users, keeping acquisition channel, plan and device differences in view without treating correlation as causation. Combine quantitative and qualitative evidence, because interviews, support tickets and usability testing can explain why an event rose or fell, and a dashboard can identify where to investigate but cannot read customers' minds.
Separate account health from individual surveillance: a B2B service may legitimately use aggregate adoption to improve support, while tracking a named person's detailed actions can raise privacy concerns, so follow the notice, access and retention rules that apply. Avoid vanity metrics, because more sessions can mean the product is useful or that a task takes too many attempts, and link metrics to completion, value and customer outcomes.
Test product changes carefully, since a staged release or experiment can help compare outcomes but the groups and measurement window must be sound, and external marketing or seasonality can also shift behaviour. Connect usage to revenue cautiously, because an active free user may not pay and an infrequent but essential professional workflow may support strong retention, so avoid claiming a usage increase automatically raises income.
Maintain an event dictionary naming the action, when it fires, properties, exclusions and version, and share results with uncertainty, since small segments can fluctuate and bot traffic or shared accounts can distort counts. For an owner, product usage analytics helps locate friction and genuine adoption, and its value is in better questions and verified improvements, not collecting the largest possible pile of behavioural data.
In practice
Real-world examples.
Example
A signup cohort is measured by completing a useful first task rather than by opening the app. The team finds that 2,000 of 10,000 signups complete it and studies where the rest stop.
Example
A feature launch excludes plans that cannot access the feature from the adoption base. The team reports the rate for eligible users only and notes how many users were excluded.
Example
A sudden usage drop is traced to a broken event after an app update. Engineers restore the tracking and the team compares versions before drawing any conclusion about customers.
Formula
Calculation
Illustrative adoption = eligible active users completing a defined feature event / all eligible active users x 100.
Worked example. A fictional app has 2,000 eligible active users in a month, and 400 of them complete the defined feature event.
- Adoption = 400 / 2,000 x 100 = 20%.
- If 500 more users are on a plan that cannot access the feature, they are excluded from the base, so the rate stays 20% and is not diluted to 400 / 2,500 = 16%.
The exclusion keeps the figure honest about the people who could actually use the feature.Case study
Seen in the real world.
In this entirely fictional example, Willow Apps sees a drop in reported feature use. Its team checks event tracking and finds an app release stopped recording the action. It fixes instrumentation before changing the product. Later, it studies task completion and user feedback.
The case does not equate an event count with satisfaction. After the fix, the team writes an event dictionary naming each tracked action, when it fires and which app version introduced it. It also adds a check that flags any event whose count falls sharply after a release. The product team treats that flag as a prompt to investigate, not as proof that customers have changed behaviour.
Watch out
Common mistakes.
- Treating clicks as evidence of value without checking task completion.
- Comparing usage across plans without accounting for feature eligibility.
- Using individual tracking beyond legitimate privacy and access limits.
Questions
People also ask.
What is a product usage event?
A defined action recorded when someone uses a product feature or completes a task.
Does high usage prove a product is good?
No. Repeated use can reflect friction; pair counts with outcomes and feedback.
Why use cohorts?
They help compare groups with different start dates or experiences.
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%Related