Growth, Activation and Retention Questions

Direct answer

LTV (customer lifetime value: the total profit a customer is expected to generate before leaving) rises when more free users become payers, payers stay longer, and payers spend more. With acquisition off the table, I would split free users by how close they are to paying and how likely they are to leave, rank initiatives by incremental LTV per dollar of effort, and judge each one with a holdout group (a randomly chosen set of users who do not receive the change) so payback is measured, not assumed. A 25% rise needs several levers compounding; no single realistic lever gets there (conversion alone would need to rise from 10% to 12.5%, and churn alone would have to fall from 10% to 8% per month, both large moves for one initiative).

The LTV model and what the 25% means

For a freemium product (free tier, paid upgrade), per free user, using a simple steady-state model:

$LTV = c \times ARPU \times m \times \frac{1}{\text{churn}}$

where c is the share of free users who convert to paid, ARPU (average revenue per user, per month, paid users only) is in USD, m is gross margin, and churn is the monthly share of payers who cancel, so 1/churn is expected paying lifetime in months. Illustrative baseline (not a benchmark): c = 10%, ARPU = 8 USD per month, m = 80%, churn = 10% per month.

LTV per free user = 0.10 x 8 x 0.80 / 0.10 = 6.40 USD. A 25% rise means 8.00 USD.

Each lever below is changed alone and then all three together; because LTV is a product of the terms, the combined row multiplies the changes (1.10 x 1.111 x 1.05 = 1.283), all on the same basis (per free user):

Churn alone would need to fall from 10% to 8% per month. Together, three modest wins clear the target with a margin. Note the sensitivity: churn sits in the denominator, so the model is most sensitive to it, and the retention-first brief points there.

Segment, then prioritise

Segment free users by lifecycle state and intent: (1) never activated (signed up, never did the core action), (2) activated but free, (3) power free users near plan limits, (4) new payers in months 1 to 3, (5) established payers. Each state has a different retention problem, so each gets a different initiative: onboarding for 1, upgrade moments for 3, a first-90-days save flow for 4, and usage-based reminders or annual plans for 5.

Score each initiative as: (users reached x expected lift in c, churn or ARPU x value per unit) / cost, then discount for confidence. Run the top three, not twelve.

Judging whether each one pays back

Payback means incremental contribution (revenue times margin) exceeds the cost of building and running it. Worked example for a save flow (offers and reminders shown at cancellation): cost 60,000 USD in effort for the year, 20,000 payers, churn 10% to 9%. Expected lifetime moves from 10.0 to 11.1 months, so +1.11 months x 8 USD x 0.80 = 7.11 USD per payer, or about 142,200 USD across 20,000 payers. That is 2.4x cost on a lifetime basis (142,200 / 60,000 = 2.37), but most of it arrives after the 12 months. Inside the window the gain is smaller: a payer who stays at 10% monthly churn pays for an expected (1 - 0.9^12) / 0.1 = 7.18 of the 12 months, and at 9% churn for (1 - 0.91^12) / 0.09 = 7.53 months, a difference of 0.35 months. That is 0.35 x 8 x 0.80 = 2.26 USD per payer, or about 45,100 USD across 20,000 payers: 0.75x the 60,000 USD cost. So the save flow does not pay back inside the 12-month target (it gets there in the second year), which is why it is judged alongside faster levers.

How I would verify:

1. Randomise a holdout (for example 10% of eligible users) and compare churn and conversion at matched tenure (users of the same age, for example month 3 against month 3).
2. Judge on incremental results (treatment compared with the holdout over the same dates), not before-and-after, so seasonality and price changes do not get credit.
3. Because true LTV cannot be observed in 12 months, track leading indicators (early signals that predict the outcome before it is visible): activation rate (the share of new users who reach the first moment of real value), month-3 retention, and 90-day payer survival (the share of a group of new payers still paying 90 days later, plotted month by month as a survival curve). Project LTV by extending that curve forward, labelling it a projection.
4. Watch guardrails (metrics that must not get worse while you chase the target, such as a rise in refunds from 2% to 4%): support tickets, refund rate, and complaints, because forced-friction retention tricks can raise churn later.

Trade-offs and pitfalls

• Raising conversion by discounting can raise c but lower ARPU, so check the combined product.
• Retention gains on payers need months to show in cohorts, so start the long-lead initiatives first.
• Beware survivorship bias (judging only the users who are still around, who were more engaged to begin with): compare against holdouts, not against churners.
• If the sum of the credible levers lands at 15% rather than 25%, say so and bring the gap to the owner of the target rather than inflating estimates.

Direct answer

Treat it as a funnel from licence to value and find where the 80% went missing before changing anything. Break "fewer than one in five licensed users has done anything meaningful" into stages (provisioned, invited, logged in, took the first valuable action), then split each stage by team, role and setup path. The cause is usually one of four things: users never got access, users never heard why to use it, the first valuable action needs a setup step nobody finished, or the licences were bought for people who do not need the product. The fix follows the stage that leaks most: product changes for friction, onboarding changes for awareness and setup.

(Terms: provisioned means the account is created and a licence assigned to the person. An event is a logged record that the product writes each time a user does something, such as sharing a report; "events fire" means those records are actually being written. Enablement is the training and help that teaches a team to use the product. Right-sizing licences means matching the number of paid seats to the people who will use them. Mid-market means mid-sized customers, roughly a few hundred to a couple of thousand employees. A Solutions Architect or implementer is the vendor-side person who sets up the customer's account. Activation means a user reaches the first action that delivers real value. Time to value is the elapsed time from getting access to that action. SSO is single sign-on, logging in with the company identity provider. A champion is the customer-side person who pushes adoption internally.)

Step 1: Define and instrument before diagnosing

Agree on the "meaningful action" with the customer's stated goal (for example "created and shared a report", not "logged in"). Confirm the events fire for this account, meaning the product really records each action for these users (a mid-market customer on SSO or an unusual setup can silently drop events, which would show up as users who did nothing when they did). Pull time to first value as a distribution, not an average.

Step 2: Build the licence-to-value funnel (illustrative account: 200 licences)

38 of 200 is 19%, matching "fewer than one in five". The biggest relative leak is login to first valuable action (about 68%), and the biggest absolute loss across the early stages is split between access (80 users never logged in) and value (82 users logged in then stopped). So I would work both, starting with the one with the faster fix.

Illustrative findings for this account after the cuts: of the 160 invited, 120 logged in, and 30 of the 40 who did not log in share one email domain (a subsidiary whose invites were filtered as spam). Of the 82 who logged in and stopped, 51 (62%) stopped at data import, 19 at permissions and 12 at an empty first screen (51 + 19 + 12 = 82). And 30 of the 38 users who took the first valuable action sit in two departments, finance and operations. That points to a fixable import step plus a fit problem for the other teams, which is the diagnosis the rest of the plan follows.

Step 3: Cut each leak to find its cause

Step 4: Changes, in the order I would make them

1. Remove the blocker found in Step 3. For example, if users stall at data import, ship sample data and templates so the first action works with zero setup, and make import asynchronous with a progress screen.
2. Role-based onboarding. Ask the role on first login and show that role's shortest path to its first valuable action, instead of one tour for everyone.
3. Admin adoption view. A page for the customer admin showing adoption by team, who has not logged in, and a one-click reminder. This gives the champion a lever.
4. Targeted enablement. A short live session for the two teams with the highest potential, scheduled around their real workflow, not a generic training.
5. Right-size licences. If one department will never use it, say so and re-allocate seats, which protects renewal trust.

Success measure and pitfalls

Target (illustrative): 14-day activation of licensed users from 19% to 45% within 60 days, plus median time to first valuable action. Why 45% and not more: if every licensed user is invited (200), 75% of them log in as now (150) and 60% of those take the first valuable action once import is fixed (90), that is 90 of 200 = 45%. Today those three rates are 80%, 75% and about 32%, so the target assumes fixing access fully and roughly doubling the login-to-action rate, not that every user adopts. Pitfalls: counting logins as adoption, fixing the account with a manual rescue rather than the product cause (if three similar accounts show the same stall, it is a product defect, not an account problem), and a Solutions Architect or implementer closing "implementation complete" without checking an activation criterion. What would change my call: if the stalled users are all in teams that were never meant to use it, the answer is licences and scope, not onboarding.

Direct answer

The viral coefficient (K) is the number of new users each existing user brings in: K = invites sent per user x share of invites that become users. A spike in invites with weak signups is a quality problem, not a growth win. I would stop counting raw signups as the goal and pay out only on activated referrals, add layered fraud signals (device, velocity and social-graph patterns, meaning who invited whom), simplify the flow for honest sharers, and monitor a quality-weighted K (activated referred users per inviter) that falls when the programme is gamed.

Why raw K misleads (illustrative example)

The activated counts come from activation rates of 30% of 300 signups (90) before and 10% of 450 signups (45) after. Raw K rose 50% (0.30 to 0.45) while quality-weighted K halved. Quality-weighted K keeps the idea of K, new users per existing user, but counts only referred users who reach the first key action, so it falls when signups are fake or low value. A dashboard showing only invites and raw K would congratulate the team during an abuse spike.

Cross-functional plan

Fraud detection heuristics

1. Velocity: invites per user per hour and per day well above the normal range; many signups from one device, IP range or payment instrument.
2. Signup quality: disposable email domains, signups that never complete the first key action, many accounts created and abandoned within minutes.
3. Reward-chasing patterns: referred accounts that go quiet right after the reward threshold is passed.
4. Social-graph signals: draw users as dots and invitations as arrows. A legitimate referral graph is mostly trees: each user has one inviter, with chains (A invites B, who invites C) and stars (one user invites many) but no loops. Abuse leaves different shapes: reciprocity (A invites B and B invites A back), a high clustering coefficient (the share of a user's contacts who are also connected to each other, normally near zero in a referral tree), and unusual connected-component size (a connected component is a group of accounts where each can be reached from any other by following invitations in either direction; here, one with more links than a tree would have). The code below computes two simpler stand-ins for the same tight-cluster shape, reciprocal edges and edges per node within each component, rather than the clustering coefficient itself:

from collections import defaultdict

# (inviter, invitee) referral edges: a legitimate tree plus a ring and a mutual pair
legit = [("u1","u2"),("u1","u3"),("u2","u4"),("u2","u5"),("u3","u6"),("u7","u8")]
ring  = [("f1","f2"),("f2","f3"),("f3","f4"),("f4","f1"),("f1","f3"),("f3","f1")]
edges = legit + ring
E = set(edges)

reciprocal = sum(1 for (a, b) in E if (b, a) in E)
print("reciprocal directed edges:", reciprocal, "of", len(E))

adj = defaultdict(set)
for a, b in E:
    adj[a].add(b); adj[b].add(a)
seen, comps = set(), []
for n in adj:
    if n in seen: continue
    stack, comp = [n], set()
    while stack:
        x = stack.pop()
        if x in comp: continue
        comp.add(x); stack.extend(adj[x] - comp)
    seen |= comp
    edges_in = sum(1 for (a, b) in E if a in comp)
    comps.append((len(comp), edges_in))
for size, e in sorted(comps, reverse=True):
    print(f"component size {size}, edges {e}, edges per node {e/size:.2f}")

Output: reciprocal directed edges 2 of 12; component size 6 with 5 edges (0.83 edges per node), size 4 with 6 edges (1.50), size 2 with 1 edge (0.50). How the code works: E holds each invitation once. The reciprocal count checks, for every (a, b), whether (b, a) also exists. The adj dictionary lists each account's neighbours in both directions, and the stack loop starts from an unseen account and keeps adding neighbours until the whole component is found. edges_in counts the invitations whose inviter lies in that component, and the last loop prints size, edge count and edges per node. A tree of n nodes has n-1 edges, so the ring (4 nodes, 6 edges, with a reciprocal pair) stands out. These signals prioritise review; none should auto-ban alone, because families and flatmates also form tight clusters. Velocity and signup-quality checks are the cheap ones to ship first; graph signals come later and exist to prioritise manual review.

Flow changes that help legitimate invites

• Share from a moment of success with a personalised, pre-filled message and a link that shows who invited the receiver; avoid "invite all contacts" defaults that create blast spam.
• Let senders choose a few close contacts and show which of their contacts are not yet users.
• Give the receiver a clear, honest landing page with the value they get, so conversion rises from real interest.

Incentives that favour quality

Pay the reward only when the friend completes the first key action, add a hold period (a delay before credit can be spent, so fraud can be caught first), give a larger reward when the friend is still active at day 30, cap monthly rewards per sender, and prefer in-product value (a premium feature) over cash so the incentive attracts users, not arbitrageurs (people who farm rewards for profit). If fraud rises, throttle the reward before you remove the programme.

Metrics to monitor referral health

Quality-weighted K, invite-to-signup conversion, share of referred signups who activate, day-30 retention of referred vs other users, reward cost per activated referral, flagged-pair rate, share of rewards reversed, and percentage of signups from the top 1% of senders (concentration). Set alert thresholds from the programme's own history rather than from an industry rule of thumb.

Trade-offs

Tighter rules protect budget and also delay rewards for honest users, so measure complaint volume and appeal outcomes. Roll changes out as experiments with a holdout so a drop in referrals can be attributed to the change.

Direct answer

I would first decide who is worth chasing, then segment by why they left, send different messages through the channels they already accept, make a narrow and conditional offer rather than a blanket discount, and measure the programme against a randomised holdout: a random slice of lapsed customers who receive nothing, so you can see how many return anyway. It "paid for itself" if the incremental contribution (profit after variable costs) from customers who came back only because of the programme exceeds its cost.

1. Who is worth chasing (re-qualification)

Drop or deprioritise before any message goes out:

• Customers who left for reasons we will not reverse: payment fraud, abuse, a chargeback (a payment dispute raised with the bank), or a company that closed.
• Anyone who unsubscribed or has no consent for the channel.
• Customers who never reached value (never activated). They may be better served by an onboarding offer than a win-back.
• Accounts whose cost to serve (support, infrastructure and payment fees) exceeded their contribution.

Then rank the remainder by prior value (tenure, usage depth, plan) and recency of lapse.

2. Segments by reason for leaving

Example messages, three segments:

• Price: "Last spring you paused your plan. We now have a plan at $9/month for the features you used most. Your saved projects are still here."
• Dormant: "Your workspace has been quiet since March. Here is a five-minute setup for the reports most teams start with, and your data is untouched."
• Missing feature: "You asked us for calendar sync. It shipped on 12 August. Reconnect and see your old schedules inside it."

Channels: email first (consent-based), in-app message the moment they log in, push only if still opted in, and paid retargeting audiences (lists of past customers uploaded to an ad platform so they see your ads) if the platform and privacy rules allow, with a suppression list (people to exclude, such as those who have already returned) so they do not see ads. Cap contact at three touches over three weeks.

3. Offers: what I would and would not do

• Would: a one-time, time-limited offer for the price segment only; a free re-activation that restores saved data; a downgrade or pause instead of a goodbye.
• Would not: a blanket discount to everyone, an offer to the missing-feature segment (it does not address their reason, and it gives away margin), or a deep discount without an expiry. Offering a discount teaches customers that cancelling earns one (the discount-precedent risk: next quarter's active customers learn to cancel and wait). Keep the offer rule public to the team, one per customer per 12 months.

4. Did it pay for itself

The discount goes only to the price segment, so I would measure that segment directly (the other segments get no discount and cost only send time; they are read the same way against their own holdouts). Hold out a random 10% of the eligible price-segment list who get nothing. Illustrative numbers: 10,000 eligible, 9,000 treated and 1,000 held out. Reactivation in 30 days: 4.0% treated, 1.5% held out. Contribution per reactivated customer: $12 monthly price x 80% gross margin (the share of revenue left after the direct cost of serving the customer; take the real figure from finance) x 5 months retained (an assumption here; in practice take it from how long previously reactivated customers stayed) = $48. The offer is one month at 50% off ($6 given up per reactivator). Fixed programme cost (design, send, team time): $1,500.

treated, rate_t, rate_h = 9000, 0.04, 0.015
reactivated = treated * rate_t            # 360
would_return = treated * rate_h           # 135 returned anyway
incremental = reactivated - would_return  # 225
value_each = 12 * 0.80 * 5                # 48 dollars contribution
discount_cost = reactivated * 6           # discount goes to ALL 360 who return
cost = discount_cost + 1500
print(reactivated, would_return, incremental)
print(round(incremental * value_each), round(cost), round(incremental * value_each - cost))

This prints 360.0 135.0 225.0 and 10800 3660 7140: 225 incremental customers worth $10,800, against $3,660 of cost, for a net of +$7,140. Note the discount cost covers all 360, including the 135 who would have returned anyway: that is the real price of an untargeted offer, and why I restrict it. The result depends most on retention months per reactivator (5 here): at 2 months the value falls to $19.2 per customer and incremental contribution to $4,320, which is only $660 above the $3,660 cost. So track 90-day survival of the reactivated, not just the reactivation.

Pitfalls

• Counting every return as programme credit. The holdout shows 135 would have returned anyway.
• Treating a day-30 return as success when many reactivated customers churn again in a month.
• Messaging someone who left over a billing dispute with a "we miss you" email.

Direct answer

Build one churn-reasons pipeline: collect from every source into a single taxonomy, link each reason to the account's value and behaviour, review it on a fixed cadence with product, support and customer-facing teams, and score each candidate fix on evidence (accounts and revenue affected, not mention volume), confidence and effort. This avoids building for the loudest customer because volume of complaints from one account counts once, stated reasons are checked against observed usage, and the score ranks impact per engineering week.

(Terms: a reason code is one label from the taxonomy, such as "missing capability". A churned account gets a primary reason (the main cause) and may get secondary reasons so it is not counted twice. A synthesis is a summary of patterns across many records. Churn is customers leaving or cancelling. ARR is annual recurring revenue. Taxonomy is a controlled list of reason codes. Triage is sorting incoming items by urgency and ownership.)

Intake

Normalise to 8 to 12 reason codes (for example missing capability, reliability, price, onboarding, champion left, competitor, no longer needed) plus a free-text field. Tag with a rule or language model first, then a person samples 10% weekly to check accuracy. Each record carries account ID, ARR, segment, tenure and the usage trend before leaving. Example tagged record: account 4821, ARR $45k, mid-market, tenure 14 months, primary reason "missing capability: bulk export", secondary "onboarding", usage down 62% over the 8 weeks before cancelling, sources: exit survey plus CRM note.

Cadence

• Weekly (30 minutes): triage new churn records with customer success, support and the product manager; fix tags, flag urgent saves.
• Monthly: a synthesis of reasons by segment and revenue, presented to product and engineering leadership.
• Quarterly: inputs to roadmap planning, with the top 3 churn drivers and the proposed fixes.

Scoring requests without the loudest-customer bias

Score = (ARR of distinct accounts affected / engineering weeks) x confidence (0.5 to 1.0). Two rules: a single account counts once no matter how many tickets it files, and a request is only "evidence of churn" if the usage data supports it (did the account actually try the workflow or stop using it?). The evidence is the ARR of distinct accounts that cite the request; the confidence multiplier says how far the usage data backs it up. The product manager sets confidence with a fixed rubric so two people score the same way: 0.9 to 1.0 when the usage data shows nearly all citing accounts hit the problem and the fix is well understood; about 0.8 when most do but a few are uncorroborated; 0.5 when it rests on one account's claim, or the usage data does not show the problem, or the fix is unclear.

Worked example (illustrative; last quarter 40 churned accounts, $600k ARR):

Where the confidence values come from: A is 0.8 because usage logs show 7 of the 9 accounts tried to export before leaving and the build is well understood. B is 0.5 because it is one account, the usage data does not show the workflow was used, and the design is uncertain. C is 0.9 because load-time logs show slow reports for all 6 accounts and the fix is small. For a new request, apply the same rubric and compute ARR / weeks x confidence.

Ranking: A, C, B. The 31 tickets in B do not change the score. Note that ARR affected is an upper bound on what the fix saves, because not every citing account would have stayed.

Closing the loop and pitfalls

Pitfalls: treating exit-survey text as truth (cross-check with usage), double counting accounts that cite several reasons (allow a primary reason plus secondary), ignoring retained accounts (interview a few to see what keeps them), and no feedback to customers or support after a fix. Track whether shipped fixes lowered the matching reason code and the churn rate in that segment. What would change my call: if one large strategic account's request carries more revenue than all others, handle it as an explicit exception decision by leadership, not as a ranking artefact.