Arguing about features with no data
Someone in the team is convinced the reporting module is barely used. Someone else says customers love it. The only evidence is a handful of support tickets and what the loudest customer said on a call. You would like to know what share of active accounts use each feature, whether the feature you shipped last quarter was taken up, and which features the customers who stay tend to use. Nobody can answer.
There may be an analytics script on the site that counts page views, but a page view is not usage. Opening the reports page is not the same as running a report.
Why adoption is so hard to see
Feature adoption rate is simple to define: of the accounts or users who could use a feature, how many did, in a given period. The hard part is having data that supports it.
- Nothing records meaningful actions, only page loads or nothing at all.
- Events that do exist have inconsistent names, added by different developers over time.
- Events are tied to users but not to accounts, so B2B adoption cannot be counted properly.
- There is no record of who had access to a feature, so the denominator is guesswork.
- Internal and test accounts are mixed in with real customers.
Auto-capture tools that record every click can help, but they tend to produce a lot of noise with little meaning. A button click is not the same as a completed task.
What not knowing costs
| Blind spot | Consequence |
|---|---|
| Which features are used | Effort spent on features nobody touches |
| Whether launches land | No way to tell if a new feature was worth building |
| What retained accounts do | Onboarding pushes the wrong features |
| Early warning of churn | Accounts stop using key features and nobody notices |
| Pricing decisions | Features gated or bundled without evidence |
How we set up feature adoption tracking
- Agree the questions. We start from what you want to know: adoption per feature, adoption by plan, how quickly new accounts reach key features, which features go with retention.
- Write a tracking plan. A short list of named events for meaningful actions, such as report created or integration connected, with the properties each carries. Consistent names from the start.
- Instrument in the code. Events are sent from the server where possible, so they are accurate and not blocked by browser extensions, and every event carries the user and the account.
- Record eligibility. Which plan each account is on and which features it can access, so adoption is measured against the right denominator.
- Filter out noise. Internal users, test accounts and demo data are flagged and excluded.
- Choose where it lives. A product analytics tool such as PostHog, Mixpanel or Amplitude, or your own warehouse if you prefer to own the data, with the same events either way.
- Build the reports. Adoption per feature, adoption by plan and cohort, time to first use, and feature use compared between retained and churned accounts.
- Keep it honest. A simple check that alerts when an event stops arriving, so a broken release does not silently flatten a chart.
What your product team gets
Debates about features are settled with numbers everyone understands. Each launch has an adoption figure after a few weeks, so you know whether it landed. Customer success can see accounts whose use of key features is dropping. And the next roadmap discussion starts from evidence, not from whoever spoke to a customer most recently.
The tracking plan also keeps the data clean as the product grows, because new features come with their events agreed up front instead of added later by guesswork.
Is this your situation?
- You cannot say what share of customers use a given feature.
- Your analytics only record page views.
- Event names are inconsistent or nobody knows what they mean.
- You cannot separate adoption by account, plan or cohort.
- Decisions about features rest on anecdotes.