Feature Adoption Metrics: What to Track and How

Feature adoption metrics tell you whether people who could use a feature actually do, how quickly they get there, and whether they keep coming back. The core set is adoption rate, breadth, depth, time to adopt and repeat use. Read them together, because any one of them alone will mislead you.

This guide covers what each metric means, how to calculate adoption rate without fooling yourself, how to set up the events behind it, and how to put the numbers where your team will see them. We build dashboards for a living, so we’ll show where a dashboard fits and where it doesn’t.

dashrendrapp.dashrendr.comPut Feature Adoption Metrics in ViewBuild custom dashboards to track feature adoption internally, embed them in your product, or schedule metrics reports by email.Try the playground

TL;DR

• Feature adoption rate is adopters divided by eligible users, not by everyone. Define eligibility and the adoption event before you measure anything.
• Use a small set together: adoption rate, breadth, depth, time to adopt and repeat use. Each one points at a different kind of failure.
• Track a feature as a funnel: exposed, activated, used, used again. The step with the biggest drop tells you what to fix.
• Compare cohorts that have had the same time to convert, or later funnel steps will look worse than they are.
• dashrendr is an analytics platform for SaaS teams. Dashboards can sit in your product, on internal screens or in a scheduled email, with a 14-day free trial and no credit card required.

Table of Contents

• What a feature adoption metric actually measures
• The core feature adoption metrics
• Define eligible users and the adoption event first
• Build the funnel: exposed, activated, used, used again
• Instrument the events properly
• Read the numbers without fooling yourself
• Turn the data into action
• Perspective: where the numbers should live
• Put adoption metrics on a dashboard
• A simple setup you can start this week
• FAQ
• Sources

What a feature adoption metric actually measures

A feature adoption metric tracks usage of one specific piece of functionality. Product adoption looks at the product as a whole. Product Led Alliance frames it as micro versus macro: feature adoption is analysis of individual components, while product adoption is the holistic view of whether the product delivers value.

The distinction matters in practice. A customer can be a healthy, active account and still never touch your new reporting feature. Product-level numbers (logins, weekly active accounts) will look fine while the feature you spent a quarter building sits idle. Feature-level metrics are how you catch that.

It also helps to keep activation separate. Activation is the first moment a new user reaches value in the product overall. Feature adoption is what happens after, feature by feature. If you want the product-level version, we cover it in our guide to activation rate.

The core feature adoption metrics

Vendors define these slightly differently, so name your own definition and stick to it. These are the ones worth tracking.

Metric	What it answers	Typical formula or definition
Adoption rate	What share of eligible users use the feature?	Adopters / eligible users x 100
Breadth	How widely is it used across the base?	Accounts or users with at least one use / eligible base
Depth	How intensely and consistently is it used?	Uses per user per week, or distinct actions inside the feature
Time to adopt	How long from first access to first real use?	Median days or hours from eligibility to adoption event
Repeat use	Do people come back?	Share of adopters who use it again within a set window
Drop-off rate	Where do people stop in the flow?	Users lost between two funnel steps

Adoption rate: your baseline

Plane’s guide describes the calculation as users who adopted the feature divided by the total number of eligible users. Two words in that sentence do the work: adopted and eligible. We’ll come back to both below.

Breadth and depth: a diagnostic pair

Breadth tracks how widely a feature is used across your user base. Depth measures the intensity and consistency of that use, per the same Plane guide.

Low breadth and high depth usually means a discovery problem. The people who find the feature love it, but most people never see it. High breadth and low depth usually means curiosity without value: everyone clicked once, nobody stayed. GraphJSON’s feature lifecycle docs make the same point, warning that broad trial without repeat use is a different situation from deep value in a smaller audience.

Time to adopt

Time to adopt is the gap between a user being able to use the feature and actually using it for something real. A long gap points to friction in the path: buried navigation, a confusing first step, a missing prerequisite. It is also the metric that most clearly connects feature work to onboarding, since a slow path to your key features is a slow path to value.

Repeat use and frequency

One use proves curiosity. A second and third prove habit. Amplitude’s feature adoption docs list examples of adoption measures that include first-time-use percentage, average uses per user per day, 30-day uses per user and users who return after first use. Pick the window that fits how often the feature should be used. A monthly billing export and a daily inbox feature need different definitions of “repeat”.

Other measures you will see

Heap’s documentation defines several more: usage frequency (interactions per user), workflow conversion (the share who finish the feature’s flow) and session adoption (the share of sessions that include the feature). They are useful, but add them only when a core metric raises a question they can answer. Ten metrics per feature is a reporting habit, not an insight.

Define eligible users and the adoption event first

Most bad adoption numbers come from two sloppy definitions.

Eligible users. An eligible user is someone for whom the feature is relevant, for instance by role, plan or account type. If your approvals feature only exists on the Premium tier, counting every free-tier user in the denominator makes the rate look terrible and tells you nothing. The same logic applies to admins versus viewers, or accounts that have not connected the data the feature needs.

The adoption event. Plane’s guidance says the event should be a meaningful action that signals the user realised value. Opening the settings page is not adoption. Saving a configured report is. Exporting a file is. Sending the first invite is.

A quick test: if you showed the event to a customer, would they agree they had used the feature? If not, pick a later event.

Write both definitions down in one sentence each. For example: Eligible: owner or admin on any paid account created more than 7 days ago. Adopted: has scheduled at least one report. That sentence belongs on the dashboard next to the number.

A worked example

Say 400 accounts are eligible for a scheduled-reports feature. In the last 30 days, 88 of them have scheduled at least one report. The adoption rate is 88 / 400 = 22%. Of those 88, 61 sent a report on at least two separate schedules, so repeat use is 61 / 88, about 69%. The exposure number might say that only 150 of the 400 eligible accounts ever opened the reports page.

Now the story is clearer. Of those who saw the feature, 88 out of 150 (about 59%) adopted it, and most of those stuck. The weak link is discovery, not value. You would spend your next sprint on placement and onboarding prompts, not on rebuilding the feature. That is the sort of decision these metrics exist to support.

Build the funnel: exposed, activated, used, used again

Userpilot describes a four-stage feature adoption funnel: exposed, activated, used, and used again. It is a handy frame because each drop-off suggests a different fix.

1. Exposed to activated. People saw it but did not start. Fix: discoverability, naming, in-product prompts.
2. Activated to used. They started but did not finish the core action. Fix: friction, setup steps, missing defaults.
3. Used to used again. They finished once and left. Fix: the value was thin, the habit trigger is missing, or the feature is a one-off task by nature.

For workflow-style features, Heap suggests defining Feature Start and Feature End events, building a funnel to see how many users complete the flow, adding steps to find the largest drop-offs, and grouping by segment to compare performance. Segments worth trying first are plan, role, company size and sign-up cohort.

Get the funnel settings right

A funnel is only as reliable as its settings. Kolom’s product analytics course lists them: the unit you count (users, accounts, stores), the exact event definitions, whether order is required, the conversion window (say, 7 days) and the cohort definition. Change any of these and the number changes, so record them next to the chart.

Instrument the events properly

You cannot measure adoption you did not record. Amplitude’s event planning docs explain that events record user actions and properties add context such as plan tier or role, and that those events power segmentation, funnels and cohorts. For SaaS they point to measures like key-event frequency, time to key event and analysis by role or paying status.

A practical starting checklist for each feature you care about:

• One event for exposure (the feature was visible or the page was opened).
• One event for first meaningful action (your adoption event).
• One event for completion, if the feature is a workflow.
• Properties on every event: user ID, account ID, plan, role and timestamp.
• A stable naming convention, written down, so “report_scheduled” never becomes “ScheduleReport” six months later.

If you do not have a tracking tool, you may not need one to begin. If your product writes its own activity to a database, the answer may already be sitting in a table. We show one version of that in our PostgreSQL SaaS metrics dashboard guide. If your events live in Google Analytics, GA4 feature adoption guidance says to separate exposure, first use and repeat use, and notes that a closed funnel can measure that progression along with the time between steps.

Read the numbers without fooling yourself

Compare like with like

The most common funnel mistake, according to Kolom, is mixing cohorts at different stages. If half your users signed up yesterday and your conversion window is 7 days, they cannot have completed the later steps yet, so the funnel looks worse than reality. Only include cohorts that have had the full window. Cohort views also make it obvious whether a feature improves for newer sign-ups. We walk through that in our cohort analysis guide.

Decompose a drop before panicking

When feature events fall, abandonment is only one explanation. GraphJSON recommends splitting the change into eligibility, adopter count, adopter frequency, seasonality, tracking or delivery failure, migration to a replacement feature and genuine abandonment. In our experience of reading product dashboards, the tracking failure is the one people check last and should check first. A deploy that renamed an event looks exactly like users losing interest.

Be careful with benchmarks

You will find published “average feature adoption” figures. Treat them as a loose reference at best. Definitions of eligible users, adoption events and time windows vary wildly, and a 20% rate on a niche admin tool can be healthier than 60% on a button in the main navigation. Your best benchmark is your own history, by cohort, on a fixed definition.

Use a system, not one number

Teams that rely on a single metric tend to optimise it into meaninglessness. Product people such as Aakash Gupta and Ramli John argue for a north-star metric with secondary guardrail metrics. For a feature, that might be adoption rate as the headline, with repeat use and time to adopt as guardrails.

Turn the data into action

Measurement matters when it changes what you do next. Three moves work well.

Build an unengaged segment per feature. Heap recommends creating a segment of users who have not performed the usage event in the past 30 days for each underused feature, so you can study and target that group. Eligible users who never tried it are your best audience for an email or in-app nudge.

Trigger interventions from cohorts. Amplitude documents syncing cohorts to in-app tools, for example to CommandBar, so users who have not adopted key features get a prompted walkthrough.

Share the metric across teams. Gupta and John also stress that product, marketing and customer success should align around shared activation metrics. If success is chasing different numbers from product, onboarding changes stall. A shared dashboard is a cheap way to fix that.

Perspective: where the numbers should live

We think the biggest adoption problem is not the formula. It is that the numbers sit in a tool only one person logs into, so nobody acts on them.

That is why we built dashrendr as a middle layer. Chart libraries leave you building layouts, multi-tenancy and exports yourself. Enterprise BI tools can run past $1,000 a month and take real effort to set up. A feature adoption view is a small thing: a handful of tiles, a funnel, a cohort table. It should not need a project.

Our view is that you should put each number in front of the people who can change it. The adoption rate and funnel go on a screen your product team sees weekly. A short summary goes to customer success in an email on Monday. If the feature matters to customers, show them their own usage inside your product, as we describe on our product analytics use case page. Customers who can see what they use, and what they have not tried, tend to ask better questions of your team.

And keep the definitions on the dashboard. A number without its eligibility rule and adoption event is a number someone will argue about.

— Paloma

Put adoption metrics on a dashboard

dashrendr is an analytics platform for SaaS teams. You can connect your data sources or push your own data through the REST API, then build dashboards in a drag-and-drop editor. Supported sources include PostgreSQL, MySQL, MongoDB, BigQuery, Google Analytics and Google Sheets.

For feature adoption, that means you can:

• Chart adoption rate, breadth and repeat use from your own events table, with segments by plan or role.
• Use dashboards internally to track your product KPIs on a team screen. See internal dashboards for how that works.
• Embed a dashboard in your product so customers see their own usage.
• Email a dashboard on a schedule, daily, weekly or monthly, through automated reports.

Plans start at $6/month (Hobby), with Starter at $15/month, Grow at $39/month and Premium at $99/month. Extra team members are $3/month each. Every plan starts with a 14-day free trial, and no credit card is required. See the pricing page for what each plan includes.

A simple setup you can start this week

1. Pick one feature that you shipped in the last quarter and that matters to retention or revenue.
2. Write the eligibility rule and the adoption event in one sentence each.
3. Confirm the events exist and carry account ID, plan and role. Fix gaps before you chart anything.
4. Build the four-stage funnel with a fixed conversion window.
5. Add three tiles: adoption rate, repeat use and median time to adopt, each split by plan.
6. Review cohorts that have completed the window only.
7. Schedule a weekly email to product and success. Change one thing, then see what moves.

If you want to think through who sees what once customers are involved, our piece on metrics to show customers is a good next read. And if you need to justify the work, our analytics ROI guide gives a way to work it out.

FAQ

What is a good feature adoption rate?

There is no honest universal number. It depends on how you define eligible users, what counts as adoption and how long you wait. Compare your own cohorts against each other on a fixed definition, and set targets per feature based on how often it should naturally be used.

How do you measure feature adoption?

Divide the users who performed a meaningful action in the feature by the users for whom the feature is relevant. Then add repeat use and time to adopt so you can tell curiosity from habit. A funnel from exposure to repeat use shows where people drop.

What is the difference between feature adoption and product adoption?

Feature adoption looks at one function, such as whether people use scheduled reports. Product adoption looks at overall acceptance and use of the whole product. You can have strong product adoption and weak adoption of a specific feature, which is why you need both views.

Which metrics help improve onboarding?

Time to adopt and the drop-off between funnel steps are the most direct. They show how long it takes new users to reach a key feature and where they stall. Pair them with cohort views so you can see whether recent onboarding changes actually helped.

Sources

• Feature adoption vs. product adoption: Key differences, Product Led Alliance
• Measuring feature adoption and usage, Plane
• Feature adoption metrics, Userpilot
• Analyze the adoption of a feature, Amplitude Docs
• Measure Feature Adoption, Heap Help Center
• Increase Usage of Key Features, Heap Help Center
• Feature lifecycle and deprecation analytics, GraphJSON Docs
• Funnels, activation and adoption, Kolom
• Select events, Amplitude Docs
• Measuring Feature Adoption in GA4
• How to Measure Onboarding: Advanced Topics in Activation
• CommandBar (Cohort), Amplitude Docs

Recommended

• Embedded Analytics for SaaS Onboarding
• How to Calculate Analytics ROI for Your SaaS
• Activation Rate: Definition, Formula & Benchmarks
• Show users how they are using your product