Growth, Activation and Retention Questions

Direct answer

These are four successive stages of a customer relationship, each with its own question and metric. Activation: did the new user reach first real value? Initial adoption: did they start using the core of the product in a repeated way? Ongoing engagement: how deeply and frequently do they use it? Retention: do they keep coming back, or keep paying, over time? Mixing them hides where the problem sits: a product with great signup numbers and weak retention needs a different fix from one with strong activation and shallow engagement.

The four stages, with a product I can describe

Example product (illustrative): a team task-management app sold as a subscription, where a user is someone who signed up and a team is a workspace.

Worked example with numbers (illustrative cohort)

Of 1,000 signups in a week:

• 400 activate within 7 days: activation rate 40%.
• 280 of those 400 adopt the core workflow by day 30: 70% of activated users, 28% of all signups.
• 200 of the 1,000 are still weekly active in week 8: 20% of signups, and a retention-curve point.
• 150 are still active at week 12: 15% of signups.

Reading it: the biggest relative loss is signup to activation (60% never activate), so that is where I would start. If instead activation were 80% and adoption 20%, the diagnosis would move to guidance after first use.

Why the distinctions matter

• Different fixes: activation is addressed by onboarding and time to value; adoption by guidance and habit formation; engagement by feature depth and collaboration; retention by delivered outcomes, support and pricing.
• Different time horizons: activation reads in days, retention in months, which is why activation is the early proxy for a team that cannot wait.
• Different denominators: the activation and adoption rates each divide by the previous stage's survivors (40% of signups, then 70% of the activated). The retention curve is the exception: it is read against the whole signup cohort (20% at week 8 and 15% at week 12 in the example) so that points on the curve stay comparable with each other. State the denominator beside every number, because mixing denominators produces a misleading funnel.

Pirate-metric frameworks such as AARRR (Acquisition, Activation, Retention, Referral, Revenue) group these differently, but the key is to define each stage with an observable behaviour and a time window for your own product, and to check that the activation definition really predicts retention.

Pitfalls

Defining activation as "signed up" or "logged in" (no value delivered); using one blended "active user" definition for all stages; measuring engagement with volume metrics that reward noisy usage; never validating that the activation event predicts staying.

Direct answer

Churn is the rate at which customers or their revenue leave over a period. I would distinguish at least four splits: voluntary versus involuntary, customer count (logo churn: each customer account counts as one "logo", whatever it pays) versus revenue, gross versus net revenue, and early versus late in the customer's life. They matter because each has a different cause and a different owner. The easiest to fix is involuntary churn, meaning customers lost to failed payments rather than a decision to leave.

The kinds of churn

A denominator rule keeps these honest: churn for a period is customers (or revenue) lost during the period from those who were active at the start, divided by the number (or revenue) at the start. New customers acquired inside the period do not belong in the denominator.

Worked example (illustrative)

Start of month: 1,000 subscribers at 20 USD per month, so 20,000 USD monthly recurring revenue (MRR: the subscription revenue the business expects to receive every month).

• 30 cancel by choice: voluntary logo churn 30 / 1,000 = 3.0%.
• 12 lose service after payment failures: involuntary logo churn 12 / 1,000 = 1.2%.
• Total logo churn: 42 / 1,000 = 4.2%.
• Revenue lost to those 42 cancellations: 42 x 20 = 840 USD (4.2% of MRR).
• 20 customers downgrade from 20 to 10 USD: contraction of 20 x 10 = 200 USD (1.0%).
• Gross revenue churn: 840 + 200 = 1,040 USD, or 5.2% of 20,000 USD.
• Existing customers upgrade, adding 300 USD of expansion.
• Net revenue churn: (1,040 - 300) / 20,000 = 3.7%.

Same month, three headline "churn" numbers (4.2% logo, 5.2% gross revenue, 3.7% net revenue) plus a 3.0% and 1.2% voluntary and involuntary split. Quoting one without its definition is how teams argue past each other.

Why the distinction changes the action

Voluntary churn is a decision: you need to learn the reason (exit surveys, usage before cancellation) and respond with product or pricing. Involuntary churn is an accident: the customer did not decide anything, so recovering the payment recovers the customer. Revenue versus logo tells you whether to worry about many small customers or a few large ones. Gross versus net stops expansion from masking a leaking base. Early versus late tells you whether the problem is acquisition and onboarding or long-run value.

Which are easiest to fix

1. Involuntary churn: mechanical, measurable and low-risk (retry schedules, automatic card updating, emails before expiry, a grace period). It is a fix to the process rather than a change to the customer's mind.
2. Early voluntary churn from poor onboarding: next easiest, because the cause is usually visible in the first-week funnel and under your control.
3. Late voluntary churn (a competitor, a changed need, budget cuts) is hardest, because much of it lies outside the product.

Pitfalls

Counting a paused or downgraded customer as active without saying so; changing the definition of "active" for free users mid-year; reporting only net revenue churn; including new customers in the denominator.

Direct answer

Time to value (TTV) is how long it takes a new customer to reach the first moment where the product has actually delivered the benefit they signed up for. To measure it, name one specific value event for the product, timestamp it relative to signup, and report the distribution (the whole spread of times rather than one average: the median, a slow-tail percentile such as the 90th, meaning the time within which 90% of arrivers got there, and the share who get there within a target window), counting people who never arrive. To improve it, decompose the path into stages, give each stage an owner, and report the stage times weekly to a cross-functional group.

Define it for one product

Take an invoicing product for freelancers. The signup is not value. Value is the freelancer sending a first invoice to a client, and the proof of value is that the client pays. So:

• TTV event: first invoice_sent, measured as time from signup_completed.
• Validation: check that users who reach the event within 7 days retain better than users who do not. If they do not, the event is the wrong choice and you pick another. This check is how a team avoids defending a metric that does not matter.
• Report on a cohort basis: a cohort is all users who signed up in the same week, so changes are comparable.

What to instrument

Each event needs user id, account id, timestamp (stored in UTC), plan and acquisition channel, so you can cut the numbers.

Computing it correctly

The common mistake is to average only the users who reached value, which hides everyone who did not and improves the number when onboarding gets worse. Report the share reaching value within windows, and keep unreached users in the denominator.

WITH first_value_event AS (
  SELECT user_id, MIN(ts) AS first_ts FROM events
  WHERE event = 'invoice_sent' GROUP BY user_id
), t AS (
  SELECT s.user_id,
         (julianday(f.first_ts) - julianday(s.signed_up_at)) * 24 AS hours_to_value
  FROM signups s LEFT JOIN first_value_event f USING (user_id)
)
SELECT COUNT(*) AS signups,
       SUM(hours_to_value IS NOT NULL AND hours_to_value <= 24)  AS within_1_day,
       SUM(hours_to_value IS NOT NULL AND hours_to_value <= 168) AS within_7_days,
       SUM(hours_to_value IS NULL) AS never_reached
FROM t;

How the query reads: julianday is SQLite's function that turns a timestamp into a day count, so subtracting two of them gives days and * 24 converts to hours. LEFT JOIN keeps every signup even with no matching event, and USING (user_id) joins on that shared column; a user with no invoice_sent gets NULL for hours_to_value. SUM(condition) counts the rows where the condition is true, and the final SUM(hours_to_value IS NULL) counts the users who never arrived, which is why they stay in the result.

Run on a six-user sample, where the time from signup to the first invoice_sent is:

it returns:

signups  within_1_day  within_7_days  never_reached
-------  ------------  -------------  -------------
6        2             4              1

Reading it: users 1 and 4 are within 24 hours, so 2 of 6 (33%) reach value within a day; users 1 to 4 are within 168 hours, so 4 of 6 (67%) reach it within a week, and user 6, 1 of 6, never has. The user who reached value after 16 days counts as reached but not within 7 days. Cohorts that are younger than the window must be flagged as incomplete, since their recent signups have not had time to reach value yet; otherwise last week's cohort always looks worse.

Improving it

1. Break the path into stages (signup to profile, profile to first client, client to sent invoice) and find where time and drop-off pile up. Session recordings and a handful of onboarding calls show why.
2. Remove steps rather than speeding them up: prefill from the signup data, import clients from a contacts list, offer a template invoice.
3. Add leading indicators (early signals that predict the outcome) you can see within a day of signup, because TTV itself takes a week to read: percent who complete the profile in session one, percent who add a client within 24 hours.
4. Test each change as an experiment (random split of new signups) and judge it on the within-7-days share and the unreached share.

Reporting to a cross-functional team

• Baseline first: one weekly cohort table (signups, within 1 day, within 7 days, never reached, plus the stage-by-stage drop-offs) with the last 8 weeks, so everyone sees the starting point.
• One headline number (share reaching value within 7 days) and the stage breakdown beneath it, each stage with a named owner: onboarding design owns the profile step, engineering owns import speed, support owns help friction.
• Cadence: a weekly dashboard post and a short monthly review of what moved and what experiment is next. Annotate the chart with ship dates so cause and effect are visible.
• Honest labels: mark incomplete cohorts, and note when a change in acquisition mix, not onboarding, explains a shift.

Trade-offs and pitfalls

• Choosing an easy-to-hit event (account created) because it makes the number look good.
• Optimising speed at the cost of quality: users who rush an invoice with bad details may not get paid. Pair the metric with invoice_paid or 30-day retention as a guardrail (a second metric that must not get worse).
• Reporting medians only: the slow tail is where churn lives.

Direct answer

I would treat the survey as a map of hypotheses, not a verdict: weight each reason by the revenue behind it, test it against what the same customers actually did in the product before leaving, split each reason into a fixable cause, size the fix against its cost, and sequence the plan by recoverable revenue per unit of effort. I would doubt the answers where they are self-reported, incomplete, or hide the real cause: "no return on investment" often means the customer never became successful with the product, and "price" is often a polite way to say "not worth it".

Step 1: weight by money, not by headcount

Illustrative figures: 300 churned customers. The stated reasons are lack of return on investment 33% (99 customers), product fit 25% (75), support problems 20% (60), and price or competition 22% (66). Counts add to 300. Now attach average monthly recurring revenue (MRR, in USD) per customer, which differs by reason: say 400, 250, 150 and 200.

Headcount says return on investment is a third; revenue says it is about half, and support drops from 20% to about 11%. The ranking can change with revenue weights, so check it.

Step 2: validate each reason with behaviour

For each reason, find the product evidence you would expect, using the 30 to 90 days of usage before they left:

• "No return on investment": did these customers reach the first valuable outcome? If most never activated, the real problem is onboarding, not the product's value.
• "Product fit": which missing features or use cases do they mention, and are they a distinct segment that sales should not have signed?
• "Support problems": ticket counts, time to resolution, and whether the issue was a bug (engineering) or a how-to question (documentation).
• "Price": did usage collapse before the price complaint, in which case price is a symptom? Compare with customers of similar usage who stayed at the same price.

If a cluster of same-industry customers churned within one quarter, run a structured root-cause analysis (RCA): timeline of changes, what they share (a regulation, a competitor entering, an integration that broke), then the same comparison against retained customers in that industry. Example (illustrative): 12 dental clinics churn in one quarter; the timeline shows all 12 used one scheduling integration that broke in March, while retained clinics used a different one. That points to a fixable integration defect, not to price or fit.

Step 3: turn it into a prioritised plan

For each cause that survives validation, estimate recoverable MRR (lost MRR x share plausibly fixable), cost and time to fix, and confidence. Illustrative inputs and ordering (fixable share, confidence and effort are assumptions to replace with your own):

So: first, the onboarding programme (largest dollar share); second, qualification changes for fit; third, support quality and documentation fixes; price tests last, because discounting costs margin and should follow the evidence on value. Each item gets an owner and a measure (for example early-life churn, ticket resolution time) and a holdout to prove the effect.

What would make me doubt these answers

• Response bias: exit surveys are answered by a minority, usually the most vocal. Compare responders with non-responders on size, plan and usage.
• Social desirability: customers pick safe reasons ("price", "budget") rather than "we never got it working".
• Single choice forced: real churn has several causes; a drop-down hides the combination.
• Timing and recall: reasons given months later are rationalised.
• Coding noise: two people may categorise the same free-text comment differently; check inter-rater agreement by having two people code the same 50 comments independently and measuring how often they choose the same category.
• Mismatch with behaviour: the strongest warning sign is a stated reason that the logs contradict.

Pitfalls

Prioritising by the biggest percentage rather than the biggest recoverable revenue; offering discounts to customers who say "price" without checking usage; building a plan from the survey alone.

Direct answer

Monitor leading indicators of adoption (depth, breadth, frequency and seat coverage of the core action) at both account and feature level, compare each account to its own trailing baseline rather than a global threshold, and alert only when the decline is sustained, large enough to matter and on an account big enough to act on. Alerts go to whoever can act: the account owner for account-level decay, the product manager for feature-level decay, and a weekly digest to leadership. Then tune thresholds by backtesting against accounts that actually churned.

(Terms: ARR is annual recurring revenue, the yearly value of an account's subscription. A trailing baseline is an account's own average over its recent past. A volume floor is a minimum activity level below which an account is too small to judge. Backtesting means running the rule on past data where you already know who churned. Precision is the share of alerts that were real problems; lead time is how many weeks before cancelling the alert fired. A tenure cohort is a group of accounts that signed up in the same period. Adoption is how much of the product's value an account actually uses. A cohort is a group that shares a start period. MAU/DAU are monthly/daily active users. CRM is the customer relationship management system where account records live.)

What to monitor

The adoption dashboard (account and feature level)

• Sources: product events (usage), CRM (owner, segment, renewal date), support (ticket volume and theme), billing (seats, plan, ARR). The join key is an account ID; most dashboard bugs are duplicate or missing IDs, so reconcile counts across systems first.
• Views: an account table (adoption score, trend, ARR, renewal date) for owners; a feature view (adoption by feature, by tenure cohort) for product.
• Segmentation: by plan, company size, tenure cohort, industry and integration; a decay that appears in only one segment points to a cause.
• Refresh: product events daily, billing daily, CRM nightly, support daily; the weekly digest is generated from the same tables so numbers match.

Alerts that fire for real problems

1. Own baseline: compare the last 3 weeks of core actions to the prior 8-week average for that account.
2. Sustained and material: trigger only if the 3-week average ratio is below a threshold (start at 0.75, then tune), each of the 3 weeks is below the baseline, AND the baseline is above a volume floor (small accounts are noisy).
3. Seasonality control: compare against the same segment in the same weeks so holidays do not alarm everyone. Illustrative: in the holiday weeks the whole mid-market segment runs at 0.80 of its baseline. An account at 0.70 is 0.70 / 0.80 = 0.875 relative to its peers, so it does not alert; an account at 0.55 is 0.55 / 0.80 = 0.69 relative, below 0.75, so it does.
4. Prioritise: rank by ARR at risk and renewal proximity.
5. Alert budget: if owners can review about 10 alerts per week, tune until the alert volume fits, otherwise alerts are ignored.

Worked example (illustrative): Account A averaged 400 core actions per week over 8 weeks, then 310, 270 and 240. The 3-week average is (310 + 270 + 240) / 3 = 273.3, a ratio of 273.3 / 400 = 0.68, below 0.75 with all three weeks under the baseline, so it alerts. Account B averaged 40 per week and fell to 25; it is below the volume floor of 100, so it goes to a low-priority weekly list rather than an alert.

Backtest and who sees what

Take the accounts that churned in the last 12 months and ask: would this rule have fired, how many weeks before cancellation, and how many non-churning accounts would it have also flagged (false alarms)? Adjust until the lead time is long enough to act (for example 6 or more weeks) and precision is acceptable. Illustrative backtest: 50 accounts churned in the last 12 months. The rule would have fired on 41 of them (82%), with a median lead time of 7 weeks. Across all accounts over the same 12 months it would have fired 120 times, so precision is 41 / 120 = 34%: one alert in three was a real churner and 79 were false alarms. 120 alerts in 12 months is about 2.3 a week, well inside a budget of 10 a week, so volume is not the problem here; the trade-off to tune is precision (34%) against the share caught (82%). Tighten the threshold or raise the volume floor and re-run until both are acceptable, and tighten for volume too if a run ever exceeds about 10 a week. Recipients: account owner or customer success manager (account alerts, with the evidence), product manager (feature decay and cohort trends), support lead (ticket-linked decay), leadership (weekly count of at-risk ARR). Pitfalls: alerting on raw logins, one global threshold for all sizes, and no feedback loop on whether alerts led to saves.