Feature Adoption

Deep reference for measuring feature adoption throughout the lifecycle - from launch through maturity or deprecation. Covers the adoption funnel, scorecards, launch metrics, kill criteria, and benchmarks by product category.

---

The Adoption Lifecycle

Feature adoption is not binary ("used" vs. "not used"). It progresses through four stages, each requiring different measurement and different interventions.

Stage 1: Awareness

Definition: The user knows the feature exists. They have been exposed to it through in-app discovery surfaces, announcements, tooltips, or onboarding.

Metric: Awareness rate = Users exposed to feature / Eligible users

Eligible users: Not all users should see every feature. Define eligibility based on plan tier, role, platform, or prerequisite actions. Using "all users" as the denominator deflates awareness rate for features behind plan gates.

How to track:

• Impression events on feature entry points (buttons, menu items, tooltips)
• Email/notification open events for feature announcements
• Onboarding step completion events that introduce the feature

Interventions for low awareness:

• Add feature to onboarding flow
• Create in-app announcements or spotlights
• Add contextual tooltips at the point of need
• Send targeted email campaigns to eligible non-aware users

---

Stage 2: Activation (Trial)

Definition: The user has tried the feature at least once. This is first meaningful interaction, not a hover or tooltip dismissal.

Metric: Trial rate = Users who performed feature action / Aware users

How to define "tried":

• The user completed the core action of the feature (not just opened the modal)
• Example: For a "Smart Filters" feature, trial = applied at least one filter, not just opened the filter panel

Interventions for low trial:

• Reduce friction to first use (pre-fill, templates, defaults)
• Improve value proposition copy on the entry point
• Add interactive walkthroughs or guided experiences
• Remove unnecessary steps before the core action

---

Stage 3: Engagement (Repeat Use)

Definition: The user has used the feature multiple times, indicating it provides ongoing value beyond initial curiosity.

Metric: Repeat rate = Users with 3+ uses in 14 days / Users who tried once

Why 3+ in 14 days? A single repeat could be accidental. Three uses within two weeks suggests intentional repeated engagement. Adjust the threshold based on expected feature frequency - a weekly reporting feature might use "2+ uses in 30 days."

Interventions for low repeat rate:

• Investigate first-use experience quality (was it confusing or buggy?)
• Check whether the feature solved the user's problem on first try
• Add follow-up prompts reminding users the feature exists for subsequent tasks
• Improve the feature's output quality or speed

---

Stage 4: Habitual Use

Definition: The feature is part of the user's regular workflow. They use it consistently over multiple weeks or months.

Metric: Habitual rate = Users with weekly usage for 4+ consecutive weeks / Repeat users

Interpretation: Habitual users are the feature's true adopters. They are the users to interview for improvement ideas, and their usage patterns should inform the feature roadmap.

Interventions for low habitual rate:

• The feature may solve a one-time need (not inherently habitual)
• Check if the feature creates output that drives return visits
• Add integrations that embed the feature into existing workflows
• Consider whether the feature should be repositioned or merged into another flow

---

Feature Adoption Scorecard

Track all four stages in a single view to diagnose adoption health at a glance.

Template

Feature: [Feature Name]
Launch date: [YYYY-MM-DD]
Eligible users: [Count and definition]
Measurement period: [Date range]

| Stage    | Metric          | Value  | Target | Status |
|----------|-----------------|--------|--------|--------|
| Aware    | Exposure rate   | 72%    | >80%   | Below  |
| Trial    | First-use rate  | 48%    | >40%   | Met    |
| Repeat   | 3+ uses / 14d  | 29%    | >30%   | Below  |
| Habitual | Weekly 4+ weeks | 61%    | >50%   | Met    |
| Overall  | End-to-end      | 6.1%   | >10%   | Below  |

Bottleneck: Awareness (72% vs. 80% target)
Action: Increase in-app feature surface visibility; add contextual tooltip.

How to calculate overall adoption

Overall adoption = Awareness * Trial * Repeat * Habitual
Example: 0.72 * 0.48 * 0.29 * 0.61 = 6.1%

The overall number is useful for comparison across features, but the stage-level breakdown is where actionable insight lives.

---

Launch Metrics

When launching a new feature, define success criteria before launch and measure at predefined checkpoints.

Pre-launch checklist

1. Define eligible user population
2. Set instrumentation: awareness event, core action event, error event
3. Define the activation event (what counts as "tried the feature")
4. Set targets for each adoption stage at Day 7, Day 30, and Day 90
5. Define guardrail metrics (error rate, support tickets, page load time)
6. Agree on kill criteria (see below)

Checkpoint cadence

Checkpoint	When	What to evaluate
Day 1	24 hours post-launch	Error rates, crash rates, page load impact
Day 7	1 week post-launch	Awareness rate, trial rate, first-use completion
Day 30	1 month post-launch	Repeat rate, early habitual signals, support ticket volume
Day 90	3 months post-launch	Full adoption scorecard, habitual rate, impact on NSM

Comparing new vs. existing user adoption

New users encountering the feature during onboarding and existing users discovering it later adopt at different rates and for different reasons. Always segment:

Segment	Typical pattern
New users (onboarding)	Higher awareness (shown in flow), lower trial (overwhelmed)
Existing users (discovery)	Lower awareness (must find it), higher trial (self-selected interest)

---

Kill Criteria

Not every feature should persist. Define criteria before launch that trigger a deprecation discussion.

When to consider killing a feature

Signal	Threshold	Action
Overall adoption below target at Day 90	<50% of target	Investigate causes; if no clear fix, deprecate
Trial rate below 10%	<10% of aware users try it	Value proposition is not compelling; redesign or kill
Habitual rate below 20%	<20% of repeat users stick	Feature solves a one-time need or has quality issues
Support ticket spike	>2x baseline in feature area	Feature is confusing or buggy; fix or pull back
Negative impact on guardrails	Any guardrail regression	Roll back immediately; investigate before re-launch

Deprecation process

1. Confirm the decision with adoption data and qualitative feedback
2. Communicate timeline to habitual users (give 30+ days notice)
3. Provide migration path if the feature stored user data
4. Monitor for churn among habitual users during wind-down
5. Remove instrumentation and clean up code after full deprecation

---

Benchmarks by Product Category

Adoption benchmarks vary significantly by product type, feature type, and whether the feature is core or peripheral.

Core feature adoption (expected as part of main workflow)

Product category	Awareness	Trial	Repeat	Habitual
SaaS productivity	>90%	>60%	>50%	>40%
E-commerce	>85%	>50%	>30%	>20%
Mobile social	>95%	>70%	>60%	>50%
Developer tools	>80%	>55%	>45%	>35%

Peripheral feature adoption (optional, enhances main workflow)

Product category	Awareness	Trial	Repeat	Habitual
SaaS productivity	>60%	>30%	>20%	>15%
E-commerce	>50%	>25%	>15%	>10%
Mobile social	>70%	>40%	>25%	>15%
Developer tools	>50%	>25%	>20%	>12%

---

Feature Adoption vs. Feature Usage

A common mistake is conflating adoption with usage. They are related but distinct.

Concept	What it measures	Example
Feature adoption	Whether users integrate the feature into their workflow	15% of eligible users use Smart Filters weekly
Feature usage	How much the feature is used in aggregate	Smart Filters applied 50,000 times this month

High usage with low adoption means a small group of power users drives all the volume. This is fragile - losing those users would collapse the feature's metrics.

Low usage with high adoption means many users use it occasionally. This is healthy but may not justify significant further investment.

Always report both together to get the complete picture.

Funnel Methodology

Deep reference for building, analyzing, and optimizing conversion funnels in product analytics. Covers funnel types, time-window selection, segmentation strategies, statistical comparison, and debugging common funnel problems.

---

Funnel Types

Linear funnel

A strict sequence of steps where users must complete step N before reaching step N+1. Most common for signup, checkout, and onboarding flows.

Landing Page -> Sign Up -> Verify Email -> Complete Profile -> First Action

When to use: The path is deterministic and enforced by the product (e.g., you cannot purchase without adding to cart first).

Branching funnel

Multiple paths lead to the same goal. Users may take different routes depending on their entry point, device, or behavior.

                  -> Feature A use -+
Entry -> Signup --                  +--> Activation
                  -> Feature B use -+

When to use: The product has multiple paths to value (e.g., a project tool where activation could be "created a project" OR "joined a shared project").

How to analyze: Build separate linear funnels for each branch and compare conversion rates. Then build a combined funnel that counts any path to the goal.

Reverse funnel

Start from the goal event and work backwards to identify which preceding behaviors correlate most strongly with conversion.

When to use: You know users are converting but don't know why. Reverse funnels surface unexpected high-conversion paths.

Method:

1. Select all users who completed the goal event in a period
2. Look at their behavior in the 7/14/30 days before conversion
3. Identify the most common action sequences
4. Compare against users who did NOT convert in the same period
5. The actions with the highest differential are your conversion drivers

---

Time Window Selection

The conversion window defines the maximum time allowed between funnel entry and goal completion. Choosing the wrong window distorts conversion rates.

How to choose

1. Pull the time-to-convert distribution for users who eventually reach the goal
2. Find the 90th percentile of time-to-convert
3. Set the window at or slightly above the 90th percentile

Example:

Time to first purchase (from signup):
  P50:  2 days
  P75:  5 days
  P90:  12 days
  P95:  21 days

Recommended window: 14 days (covers 90%+ of natural converters)

Common windows by product type

Product type	Funnel	Typical window
E-commerce	Browse to purchase	1 session or 7 days
SaaS (self-serve)	Signup to activation	7-14 days
SaaS (enterprise)	Trial start to paid	30-45 days
Marketplace	Search to transaction	1-7 days
Mobile app	Install to core action	1-3 days

Window pitfalls

• Too short: Excludes legitimate converters; understates true conversion rate
• Too long: Includes coincidental converters who would not have converted due to the funnel experience; overstates conversion rate
• No window at all: "Ever converted" is meaningless for optimization - it mixes Day 1 converters with Month 6 converters

---

Segmentation Strategies

Never analyze a funnel in aggregate alone. Always segment by at least two dimensions.

High-value segments to compare

Segment dimension	Why it matters
Acquisition channel	Paid users may have different intent than organic
Device / platform	Mobile funnels often have different friction points
Geography	Localization, payment methods, and trust differ by region
User plan / tier	Free vs. trial vs. paid users behave differently
First-touch feature	Users who entered via Feature A may convert differently
Cohort (signup week)	Newer cohorts should convert better if product is improving

Segmented funnel analysis workflow

1. Build the aggregate funnel as a baseline
2. Break down by acquisition channel - identify the highest and lowest converting channels
3. Break down by device - find mobile-specific drop-offs
4. Break down by cohort - confirm whether product changes are improving conversion
5. Cross-segment the top finding (e.g., "paid + mobile" or "organic + desktop") to identify the most actionable audience

---

Comparing Funnels Statistically

When comparing funnel conversion rates across segments or time periods, use statistical tests to confirm the difference is meaningful.

Chi-square test for step conversion

Use when comparing conversion rates between two segments at a specific funnel step.

             Converted   Not Converted   Total
Segment A      120           880          1000
Segment B      150           850          1000

chi2 = sum of (observed - expected)^2 / expected for each cell
df = 1

If chi2 > 3.84 (alpha = 0.05), the difference is statistically significant.

Confidence interval for conversion rate

CI = p +/- z * sqrt(p * (1 - p) / n)

Where:
  p = observed conversion rate
  z = 1.96 for 95% confidence
  n = sample size

Report confidence intervals when presenting funnel metrics to stakeholders. A conversion rate of "12% (95% CI: 10.5% - 13.5%)" communicates uncertainty honestly.

Practical significance vs. statistical significance

A 0.1 percentage point improvement that is statistically significant with n=1M users is real but may not justify the engineering investment. Always pair statistical significance with a practical significance threshold defined before analysis.

---

Debugging Common Funnel Problems

Problem: Step conversion is unexpectedly low

Diagnostic checklist:

1. Check event instrumentation - is the step event firing correctly on all platforms?
2. Check for tracking gaps - ad blockers, consent banners, and network failures cause event loss; estimate the gap with server-side vs. client-side event comparison
3. Check for UX friction - session recordings at the drop-off step reveal confusion, rage clicks, or error states
4. Check for technical errors - error rates on the API call that powers the step
5. Check for segmentation effects - one segment may have near-zero conversion (e.g., a specific browser or region)

Problem: Funnel shows 0% at a step

Almost always an instrumentation issue. Verify:

1. The event name matches exactly (case-sensitive)
2. The event is firing in production (not just staging)
3. The event is within the conversion window
4. User identity is stitched correctly (anonymous to authenticated)

Problem: Conversion rate improved but revenue didn't

Possible causes:

1. Lower-value users are converting (more volume, less revenue per user)
2. Conversion window was shortened, excluding high-value but slower converters
3. The improvement is in a low-traffic segment that doesn't move the overall number
4. There is a downstream drop-off (e.g., more trials start but trial-to-paid is flat)

---

Advanced: Multi-Touch Funnels

For products where the conversion path spans multiple sessions over days or weeks, single-session funnels miss the full picture.

Multi-session funnel construction

1. Define a user-level funnel (not session-level)
2. Track the first occurrence of each step event per user within the window
3. Order steps by their first occurrence timestamp
4. Allow steps to occur in different sessions
5. Report median sessions-to-convert alongside the conversion rate

Attribution within the funnel

When a user completes steps across multiple touchpoints (email, web, mobile app), attribute each step to the platform/channel where it occurred. This reveals which channels drive which funnel stages.

Example:
  Step 1 (Awareness):   Email campaign (42%), In-app banner (38%), Blog (20%)
  Step 2 (Trial):       Web app (78%), Mobile app (22%)
  Step 3 (Activation):  Web app (65%), Mobile app (35%)

This attribution view tells you email drives awareness but web drives conversion - different channels serve different funnel stages.

Product Metrics Catalog

A reference catalog of common product metrics organized by category. Each entry includes a definition, formula, and notes on interpretation and common mistakes.

---

Acquisition metrics

Traffic volume

Definition: Total sessions or unique visitors arriving at a product surface in a period.

Formula: Count of sessions (or unique user_id / anonymous_id) within date range.

Notes: Traffic alone is meaningless without conversion context. Always report alongside acquisition channel breakdown. Direct/organic vs. paid vs. referral ratios matter as much as the total.

---

Customer Acquisition Cost (CAC)

Definition: The average cost to acquire one new paying customer.

Formula: CAC = Total sales and marketing spend / New customers acquired (same period)

Notes: Segment by channel. Blended CAC hides that paid search CAC may be 10x organic CAC. Compare against LTV; healthy SaaS businesses target LTV:CAC of 3:1 or better. Recovery time (months to recoup CAC from gross margin) should be under 12 months.

---

Organic vs. paid split

Definition: The proportion of new user acquisition coming from paid channels vs. unpaid (SEO, word of mouth, referral, direct).

Formula: Organic % = Organic new users / Total new users

Notes: High paid dependency is a risk factor. If you turn off paid, does growth stop? Growing organic share over time indicates product-led or brand-led growth compounding.

---

Activation metrics

Activation rate

Definition: The percentage of new users who reach the product's "aha moment" - the first experience of core value - within a defined window.

Formula: Activation rate = Users who completed activation event / New users in cohort

Notes: The activation event must be defined specifically. "Logged in" is not activation. Define it as the earliest action that predicts long-term retention. A/B testing activation flows is high-leverage; each percentage point improvement compounds through the entire funnel.

---

Time to activate

Definition: The median and 90th-percentile time between signup and completion of the activation event.

Formula: median(activation_timestamp - signup_timestamp) across activated users.

Notes: Long time-to-activate often indicates friction in onboarding, not user disinterest. Reduce steps, pre-fill data, and use progressive disclosure to compress it. Track the 90th percentile - a long tail means a significant group never activates in time.

---

Onboarding completion rate

Definition: The percentage of new users who complete each step of the onboarding flow.

Formula: Funnel conversion at each onboarding step.

Notes: Report as a funnel, not a single number. The step with the steepest drop-off is the highest-leverage fix. Compare completion rates across acquisition channels; users from different sources often have different onboarding behavior.

---

Engagement metrics

Daily / Weekly / Monthly Active Users (DAU / WAU / MAU)

Definition: The count of unique users who complete a qualifying action within a day / week / month.

Formula: Count of distinct user_id where core_event occurred in window

Notes: "Active" must be defined as a meaningful action, not just a session open. DAU/MAU ratio (stickiness) is more informative than MAU alone. A ratio above 20% indicates habitual use; above 50% is strong for productivity tools.

---

DAU/MAU ratio (Stickiness)

Definition: The proportion of monthly active users who also use the product daily. Measures habit formation.

Formula: Stickiness = DAU / MAU

Benchmarks:

• 50%+ - world-class (WhatsApp, Instagram)
• 20-50% - strong (Slack, Notion)
• 10-20% - moderate; investigate use case frequency
• Under 10% - low; may be expected for low-frequency tools (e.g., tax software)

Notes: For low-frequency-by-nature products (quarterly review tools, annual planning), WAU/MAU or a custom "expected use interval" is more appropriate than DAU/MAU.

---

Session depth and duration

Definition: The number of actions or pages viewed per session (depth) and the time spent per session (duration).

Formula: avg(actions per session), avg(session_end - session_start)

Notes: Higher is not always better. A shorter session that completes the user's job faster may indicate better UX. Compare depth and duration against task completion to determine whether long sessions reflect engagement or confusion.

---

Feature engagement rate

Definition: The percentage of active users who use a specific feature within a period.

Formula: Feature engagement rate = Users who triggered feature event / Total active users

Notes: Segment by user plan, acquisition cohort, and user role. Low engagement may indicate poor discoverability, irrelevance to a segment, or a broken experience. Combine with qualitative research before concluding the feature should be removed.

---

Retention metrics

D1 / D7 / D30 retention

Definition: The percentage of users from a cohort who return and complete a qualifying action on day 1, 7, or 30 after their first use.

Formula: D7 retention = Users active on day 6-8 / Users in cohort

Notes: Use a ±1 day window for day markers to smooth for timezone and activity timing variance. D1 is an early signal of first-run experience quality. D30 is a proxy for product-market fit. See SKILL.md retention curve benchmarks.

---

Net Revenue Retention (NRR)

Definition: The percentage of recurring revenue retained from existing customers over a period, including expansion and contraction. Also called Net Dollar Retention (NDR).

Formula:

NRR = (MRR at start + expansion MRR - contraction MRR - churned MRR) / MRR at start

Benchmarks:

• 130%+ - best-in-class (Snowflake, Twilio)
• 110-130% - strong SaaS
• 100-110% - healthy; expansion offsets churn
• Under 100% - revenue is leaking; fix churn before scaling acquisition

Notes: NRR above 100% means the business can grow revenue without acquiring a single new customer. It is the most powerful indicator of a healthy B2B SaaS model.

---

Gross Revenue Retention (GRR)

Definition: The percentage of recurring revenue retained from existing customers, excluding expansion. Measures raw churn.

Formula:

GRR = (MRR at start - contraction MRR - churned MRR) / MRR at start

Notes: GRR has a ceiling of 100%. Compare GRR and NRR together: high GRR + high NRR indicates a healthy expanding base. Low GRR + high NRR means expansion is masking churn - a risk if the expansion pool runs out.

---

Churn rate

Definition: The percentage of customers (or revenue) lost in a period.

Formula:

• Logo churn: Churned customers / Customers at period start
• Revenue churn: Churned MRR / MRR at period start

Notes: Always clarify whether "churn" refers to logo churn or revenue churn - they differ significantly for businesses with tiered pricing. Measure churn at multiple time horizons (monthly and annual) and by customer segment. Early-cohort churn is often higher and skews aggregate numbers; normalize by cohort age.

---

Resurrection rate

Definition: The percentage of previously churned users who become active again in a period.

Formula: Resurrected users / Churned users from prior period

Notes: A high resurrection rate is a positive signal and an acquisition efficiency win - reactivating a lapsed user is typically cheaper than acquiring a new one. Investigate what triggers re-activation: product changes, marketing campaigns, or natural lifecycle events.

---

Conversion metrics

Free-to-paid conversion rate

Definition: The percentage of free or trial users who convert to a paid plan.

Formula: Paid conversions / Free or trial users in cohort

Notes: Measure within a defined window (30-day or 90-day trial cohort). Analyze by acquisition channel, activation status, and feature usage. Users who activated typically convert at 2-5x the rate of users who did not. Improving activation is usually the highest- leverage lever for conversion.

---

Funnel conversion rate

Definition: The percentage of users who complete each step in a defined conversion funnel, from entry to goal.

Formula: Step N+1 completions / Step N completions

Notes: See SKILL.md funnel analysis section for full methodology. Always set a conversion window. Report step-level rates, not just overall conversion.

---

Revenue metrics

Monthly Recurring Revenue (MRR)

Definition: The normalized monthly value of all active recurring subscriptions.

Formula: Sum of (subscription value / subscription period in months) for all active subscriptions.

Notes: Track MRR movement components separately: new MRR, expansion MRR, contraction MRR, churned MRR, and reactivation MRR. The MRR waterfall chart makes growth drivers and drags immediately visible.

---

Average Revenue Per User (ARPU)

Definition: The average revenue generated per active user in a period.

Formula: ARPU = Total revenue / Active users

Notes: Segment by plan tier and user cohort. ARPU trends upward when expansion revenue is working; it trends downward when a product moves down-market or discounting increases. Compare ARPU against CAC: if ARPU is low and CAC is high, the unit economics are broken.

---

Customer Lifetime Value (LTV / CLV)

Definition: The projected total revenue a customer generates over their relationship with the product.

Formula (simple): LTV = ARPU / Churn rate

Formula (with gross margin): LTV = (ARPU * Gross margin %) / Churn rate

Notes: LTV is a projection based on current churn; it is sensitive to churn rate assumptions. A 2% monthly churn implies ~12-month average lifetime; 0.5% monthly churn implies ~17-year average lifetime. Use gross-margin-adjusted LTV when comparing against CAC to get a true picture of unit economics.

---

Product-market fit signals

Sean Ellis PMF score

Definition: The percentage of surveyed users who would be "very disappointed" if they could no longer use the product.

Benchmark: 40%+ is considered a threshold indicating product-market fit.

Notes: Survey active users only. If the number is below 40%, the open-ended responses explaining "very disappointed" answers reveal what the product is already doing right for its core segment.

---

NPS (Net Promoter Score)

Definition: A measure of customer loyalty based on likelihood to recommend.

Formula: NPS = % Promoters (9-10) - % Detractors (0-6)

Benchmarks:

• 70+ - exceptional
• 50-70 - excellent
• 30-50 - good
• 0-30 - room for improvement
• Negative - urgent issue

Notes: NPS is most useful as a trend signal and a segmentation tool (what do promoters have in common?). A single NPS number without verbatim qualitative feedback is low-value. Survey timing matters: surveying immediately after onboarding vs. 90 days in yields different scores for different reasons.