How to measure feature adoption

Feature adoption rate is the share of eligible users who actually use a feature. The formula is simple — adopters divided by the population who could adopt — but the number is meaningless until you pin down three things: who counts as eligible (breadth), how deeply they use it (depth), and over what window (time). Get those wrong and you ship a dashboard that says 80% when the honest number is 12%. This is a how-to: instrument the feature, compute the three metrics, and act on them.

Prerequisites

• An analytics tool that captures custom events tied to a stable user/account ID — Amplitude, Mixpanel, Heap, or Pendo. Heap auto-captures clicks (less upfront instrumentation, messier event taxonomy); Amplitude and Mixpanel need explicit track() calls (more work, cleaner data).
• A defined “eligible population.” Not every user can use every feature — a feature gated behind an Enterprise plan has a denominator of Enterprise seats, not all seats. Write this rule down before you compute anything.
• A definition of what “using the feature” means as one or more concrete events, not a page view. Opening the page is not adoption; completing the core action is.

Step 1 — instrument the core action, not the page

Fire a single named event on the action that delivers the feature’s value. For a bulk-export feature, the event is bulk_export_completed, not export_page_viewed. In Amplitude or Mixpanel, add the track('bulk_export_completed', { row_count, format, account_id }) call at the success callback of the export, after the file is generated — never on button click, because clicks include failures and rage-clicks. In Pendo or Heap you can tag the success-state DOM element instead, but a server-side event is more reliable because it survives ad-blockers and client crashes.

Attach account_id and plan_tier as event properties so you can later filter the denominator to eligible accounts. Without these, you can compute breadth across all users but never across the eligible population — and the eligible-population number is the one that matters.

Step 2 — compute the three formulas

Breadth = adopters / eligible users        (did they touch it at all?)
Depth   = core actions / adopter           (how hard do adopters lean on it?)
Time    = adopters within N days of eligibility / eligible users in that cohort

• Breadth is the headline adoption rate. An adopter is any eligible user who fired the core event at least once in the window. Breadth answers “did this feature land at all?”
• Depth separates a feature people try once from a feature people depend on. Compute it only over adopters (not the whole base), or a low breadth will mask high depth. A feature with 15% breadth and 40 actions per adopter per month is a power-user feature, not a failure — treat it differently from one at 15% breadth and 1.2 actions.
• Time-to-adopt is breadth measured against a cohort clock. “What share of accounts that became eligible in March used the feature within 30 days?” This is the metric that tells you whether your onboarding surfaces the feature, and it is the one most teams skip.

Worked example: a feature is gated to 500 Enterprise accounts. In a 30-day window, 145 fired the core event, generating 1,160 total core actions. Breadth = 145 / 500 = 29%. Depth = 1,160 / 145 = 8 actions per adopter. If only 60 of the 145 adopted within 30 days of becoming eligible, time-to-adopt(30d) = 60 / 500 = 12%.

Step 3 — pick the window deliberately

The window is not cosmetic. A daily-use feature (a dashboard) should be measured on a rolling 7- or 28-day active window — someone who used it last quarter is not an adopter today. A quarterly-use feature (a compliance export) needs a 90-day window or you will report churn that is just seasonality. Match the window to the feature’s natural cadence, write it into the metric definition, and never compare two features measured on different windows.

Step 4 — set the denominator floor

For a feature under one release cycle old, the eligible population is still growing, so breadth is artificially depressed by accounts that became eligible yesterday. Exclude accounts eligible for fewer than the feature’s natural cadence (e.g. drop accounts eligible under 28 days for a weekly-use feature). Report breadth on the seasoned population and time-to-adopt on the full cohort — they answer different questions.

What good looks like

There is no universal benchmark; adoption rate is feature-specific. A core workflow feature in the 40-60% breadth range is healthy; a power-user or admin feature living at 5-15% breadth can be entirely successful if depth is high among the few who adopt. The number that should alarm you is a feature with both low breadth and low depth after a full cadence window — that is a feature nobody needed, and the action is to sunset or rebuild it, not to push harder on enablement.

Acting on the data

• Low breadth, high depth — discovery problem. The people who find it love it. Surface it in onboarding and in-app (Pendo guides, empty-state prompts), then re-measure time-to-adopt.
• High breadth, low depth — shallow value or a one-time-use feature. If it should be recurring, the activation moment isn’t sticking; investigate the second-use drop-off.
• Low breadth, low depth, full window elapsed — kill candidate. Confirm with a churn/expansion cross-tab before sunsetting, but don’t keep investing enablement in a feature the eligible population has voted down.

Common pitfalls

• Page views as adoption. Counting page_viewed inflates breadth by everyone who clicked in by accident. Guard: the core event fires on the value-delivering action’s success callback, never on navigation or click.
• Denominator = all users. Dividing by total accounts when the feature is plan-gated understates adoption among people who can actually use it. Guard: filter the denominator by plan_tier/entitlement, set in Step 1.
• No window, or mismatched windows. A lifetime-cumulative “ever used it” number only ever goes up and tells you nothing about current health. Guard: define a rolling window matched to the feature’s cadence (Step 3) and never compare features measured on different ones.
• Breadth and depth averaged together. Reporting “average actions per user” across the whole base blends adopters and non-adopters into a meaningless middle. Guard: compute depth over adopters only.

Related

• NRR vs GRR — adoption is a leading indicator of retention
• Pendo — in-app guides to drive adoption of low-breadth features
• Amplitude — cohort and funnel analysis for time-to-adopt