How do you calculate 'true' LTV when you have variable churn by cohort age, and some customers never expand in 2027?

What true LTV actually is, and why the shortcut breaks

Nearly every RevOps deck contains LTV = ARPA / monthly churn, sometimes dressed up as LTV = ARPA × gross margin / churn. It is seductive because it needs two numbers and one division. It is also, in most real subscription businesses, materially wrong — and wrong in a direction you cannot predict without doing the work.

That formula is the closed-form solution to one very specific model: a customer pays a fixed amount every month and faces an identical, constant probability of cancelling in every month. Under that model expected lifetime is 1/churn months. The algebra is correct. The model is a fiction. The constant-hazard assumption is the load-bearing wall, and it collapses under contact with real data.

Real retention curves are convex. Churn is high in the first few months while a buyer is still deciding whether the product earns its place in the stack, then flattens dramatically as survivors become habituated, integrated, and contractually entrenched. A cohort that loses 8% in month one might lose 1.5% in month twenty-four. The 1/churn formula has to pick one number to represent that entire curve, and whichever number it picks is wrong somewhere — too pessimistic about the loyal tail, too optimistic about the early cliff, or both.

The magnitude is not a rounding error. Consider a cohort losing 6% in month one, decaying to roughly 1% per month by month twelve and holding there. The blended first-year monthly churn might be 2.5%, implying a naive lifetime of 40 months. But survivors past month twelve churn at 1%, implying a conditional lifetime of another 100 months for that group. The blended figure understates the loyal tail by more than 2x. Layer expansion on top and it gets worse: if 30% of accounts expand at 130% NRR and 70% sit flat or contract at 95%, blended NRR is 0.3 × 1.30 + 0.7 × 0.95 = 1.055. Applying 105.5% to every account overstates the value of the non-expanding majority and understates the whales. The blended number is right only for a customer who does not exist.

The "some customers never expand" pattern deserves its own paragraph because it breaks models quietly. A meaningful share of accounts buy once and never grow. They are not unprofitable — they pay reliably, often for years, and their churn is frequently *lower* than average because they have reached a stable equilibrium. But if your model bakes in net revenue retention above 100%, it implicitly assumes every account is on an upward revenue path. The non-expanders are not. The clean framing: every customer has (a) a survival process governing whether they still pay, and (b) a revenue-trajectory process governing how much they pay conditional on survival. Model those separately and only blend at the very end, weighted by true population share.

Six assumptions hide inside 1/churn, and each biases the answer: churn is constant across cohort age (it decays, understating survivor lifetime); every customer expands at the average rate (the population is bimodal, overstating non-expanders); revenue per account is fixed (it drifts both directions); one blended rate represents all segments (SMB typically churns 3-5x faster than enterprise, so the blend is a meaningless middle); lifetime is infinite (boards discount cash and horizons are finite); and gross margin is 100% (SaaS gross margin runs 70-85%, so revenue-based LTV overstates by 15-30% immediately).

The step-by-step process, from billing events to a defensible number

The master formula replaces the shortcut with an explicit sum over months:

LTV = Σ over t=1..T of [ S(t) × R(t) × GM × 1/(1+d)^t ]

Where S(t) is survival probability at month t, R(t) is expected revenue per surviving account at month t including expansion or contraction, GM is gross margin as a decimal, d is the monthly discount rate, and T is your horizon cap. Notice that this collapses back to ARPA × GM / churn only when S(t) is a constant-hazard exponential, R(t) is flat, d = 0, and T is infinite. Every refinement moves you further from the shortcut, which is the point.

Step one: get event-level data, not aggregates. You need the date each subscription started, every MRR-change event, and the end date if it ended. Monthly aggregate MRR cannot support survival analysis. Before you model anything, resolve five data-quality questions. Is the churn date unambiguous — is a downgrade to a free tier a cancellation or not? Are reactivations tracked as new spells or new cohorts? Are free-trial users excluded, since non-converting trials will wreck early-life churn? Are pauses and billing-system migrations flagged, so a platform migration that re-created subscription records does not read as 1,000 new customers? And is there a "last date we have data" per customer, so censoring computes correctly?

Step two: distinguish the three objects. Survival analysis gives you three related functions and confusing them is the second most common error after 1/churn itself. The survival function S(t) is the probability a customer is still active at month t — it starts at 1.0 and decays monotonically. That is your retention curve. The hazard rate h(t) is the probability a customer who survived to month t churns *during* month t — conditional churn, high early and low late. Period retention is S(t) / S(t-1), the share of last month's survivors who remain, and it is what your cohort triangle actually shows. The 1/churn formula assumes h(t) is a flat line. Your job is to recover the real, downward-sloping one.

Step three: fit Kaplan-Meier. The Kaplan-Meier estimator builds the survival curve directly from observed data without assuming a functional form. For each month it computes (n_t − d_t) / n_t, where n_t is the number at risk at the start of the month and d_t is the number who churned; survival is the running product. Its superpower is right-censoring. Most of your customers have not churned — they are still paying. Someone who joined eight months ago and is still active contributes eight months of survival and then leaves the at-risk pool without counting as a churn event. Naive cohort math either discards these accounts or treats the edge of the observation window as churn, which inflates churn badly. Kaplan-Meier handles this correctly by construction. Python's lifelines implements it in three lines: fit KaplanMeierFitter on a duration column and an event-observed boolean.

Step four: fit a parametric tail. Kaplan-Meier produces a step function that stops where your data stops. To reach your horizon cap you need the curve to continue. Weibull is the recommended default for subscriptions — a two-parameter model whose shape parameter below 1 produces a hazard that *decreases* with age, which is exactly the convex retention shape real businesses exhibit. Log-logistic allows hazard to rise then fall, useful when there is an early honeymoon before risk peaks. Exponential is the constant-hazard model — 1/churn in disguise, worth fitting only as a baseline to demonstrate how wrong it is. Generalized Gamma nests several forms when you want the data to pick the shape. Fit two or three, compare with AIC/BIC, then sanity-check the extrapolation: a Weibull tail implying 0.1% monthly churn at month 60 is probably fantasy, and you should cap it.

Step five: build R(t) with segments, not an average. Classify each historical account at a fixed observation point — month 12 is common — as expander, flat, or contractor based on whether revenue grew, held, or shrank past a threshold. Then estimate a revenue path per class. Expanders get a compounding uplift that saturates toward a ceiling. Flat accounts hold constant. Contractors decay slowly toward a floor or churn. An illustrative shape: 28% expanders going from $1,000 to roughly $1,720 by month 24 (≈135% contribution), 55% flat at $1,000 (≈100%), 17% contractors falling to about $760 (≈88%) — blending to roughly $1,160 and ~111% NRR. That blended bottom line is what most dashboards display. The three rows above it are what you should actually manage.

Step six: apply margin, discount, and cap, then report a range. Multiply by gross margin defined identically to the P&L line. Discount at 8-12% annually for venture-stage SaaS (divide by 12 for the monthly rate). Cap the horizon at 36-60 months; 48 is a defensible default that captures the bulk of discounted value without betting the business on a seven-year extrapolation.

Costs, timelines, typical ranges, and the tooling ladder

The rigor you need scales with your stage, and so does the cost. There are four tiers, and picking one above your data volume wastes months producing spurious precision.

Tier 1, the cohort-triangle spreadsheet. Export a retention triangle — rows are signup cohorts, columns are months since signup, cells are dollar retention. Average down each column for an empirical S(t) by cohort age, straight from data. Sum S(t) × R(t) × GM × discount. Non-parametric, intuitive, board-legible, and it beats 1/churn immediately with zero statistics. Its limits: it cannot extrapolate past your oldest cohort's age, and thin recent cohorts make late columns noisy. Timeline: a few days. Cost: an analyst's week.

Tier 2, Kaplan-Meier plus a parametric tail. Correctly handles censoring and extends the curve to your horizon. This is the recommended default for any company past Series A — rigorous enough for diligence, cheap enough to refresh quarterly. Timeline: two to four weeks for a first build, then a day per refresh. Cost: one analyst with Python, plus warehouse compute that rounds to nothing.

Tier 3, Cox regression and Markov chains. The Cox proportional hazards model estimates how attributes — plan tier, acquisition channel, company size, onboarding completion, time-to-first-value — shift the hazard. Instead of one curve you get a baseline plus multipliers. A hazard ratio of 0.45 for "completed onboarding milestone" means those accounts churn at less than half the rate, which is simultaneously an LTV input and a product roadmap mandate. A Markov-chain model treats each customer as occupying one state per month — Onboarding, Active-Flat, Active-Expanded, Active-Contracted, At-Risk, Churned, Reactivated — with transition probabilities estimated from history and a monthly margin reward per state. LTV becomes the expected total discounted reward starting from Onboarding, with a clean closed form from the transition matrix.

Markov deserves emphasis because it is the most natural fit for the "never expand" problem. "Stays flat forever" is simply a customer who keeps transitioning Active-Flat → Active-Flat with high probability. There is no awkward exception, no blended growth rate misrepresenting the majority. Expanders are accounts with meaningful Active-Flat → Active-Expanded probability. And reactivation becomes a first-class event: the Churned → Reactivated transition, however small, can be material in products with seasonal or project-based usage. Neither 1/churn nor basic Kaplan-Meier can represent win-back at all.

Tier 4, Bayesian hierarchical and BG/NBD-family models. Put a probability distribution on every parameter. A hierarchical model shares information across cohorts, shrinking a small young cohort's noisy estimate toward the all-cohort prior and stabilizing late-life columns. The output is a full posterior — report the median and a 90% credible interval directly. For contractual subscriptions, hierarchical survival models are the gold standard; for non-contractual or usage-based revenue, the BG/NBD and Gamma-Gamma "buy-till-you-die" family is the established choice. Timeline: one to three months with someone who has done it before.

The stack is predictable. Billing source of truth: Stripe Billing, Recurly, Chargebee, or Zuora emitting raw subscription and MRR-change events. Subscription analytics: ChartMogul, Maxio (the merged Chargify + SaaSOptics entity), or Baremetrics for cohort triangles and GRR/NRR by segment. Warehouse: Snowflake, BigQuery, or Databricks to join billing with product and CRM data. Transformation: dbt builds the duration and event-observed columns. Modeling: Python lifelines or R's survival for Kaplan-Meier, Weibull, and Cox; lifetimes for BG/NBD; PyMC or Stan for Bayesian. Presentation: Looker, Tableau, Hex, or Mode reading one final ltv_by_segment table.

That separation matters more than the tool choice. Raw events land hourly. dbt staging normalizes to one row per subscription-month with a status, daily. A dbt intermediate model collapses that into one row per customer with tenure_months and event_observed — the exact two columns Kaplan-Meier consumes. A scheduled Python job in Airflow or Dagster fits the models weekly or quarterly and writes results back. The BI layer reads only that table. The statistics live in version-controlled Python, the SQL stays simple, and the dashboard is a thin presentation layer that survives staff turnover.

Two judgment calls quietly swing the answer by 30% or more. On discount rate, an illustrative cohort worth $27,900 undiscounted lands near $23,100 at 8% (−17%), $21,740 at 10% (−22%), $20,550 at 12% (−26%), and $18,900 at 15% (−32%). On horizon, letting the sum run to infinity hands a fragile tail fit undue weight. Pick a rate and a cap, document both, and hold them constant across reporting periods so trends stay comparable.

A worked comparison makes the stakes concrete. Take a cohort at $1,000 month-one ARPA, 80% gross margin. The naive approach observes ~3% average monthly churn over 18 months and computes 1000 × 0.80 / 0.03 = $26,667. The survival approach, using segmented revenue paths, 10% annual discounting, and a 48-month cap, sums roughly $4,310 (months 1-6), $3,560 (7-12), $5,890 (13-24), $4,420 (25-36), and $3,560 (37-48) — about $21,740. Here the true figure is *below* the naive one, because discounting and the cap bite harder than the convex-curve uplift. In cohorts with very low late-life churn the true figure exceeds the naive one. The direction is not the lesson; the lesson is that an 18-23% gap routinely flips a CAC payback decision, and you cannot know the sign without doing the work.

Where RevOps teams get it wrong

Ten errors survive into board decks even at teams that have abandoned 1/churn. Treat this as a pre-flight checklist.

Survivorship bias in the triangle. Averaging only mature cohorts that "made it" while quietly excluding weak recent ones flatters the curve. Detection: are recent cohorts in the average at all? Fix: include every cohort and weight by recency.

Censoring treated as churn. If churn spikes right at the edge of your data window, you are counting "we stopped observing" as "they cancelled." This is the exact bug Kaplan-Meier exists to fix.

Revenue instead of margin. Reporting LTV on gross revenue overstates by the full COGS percentage — 15-30% for typical SaaS. Multiply by gross margin, defined identically to the P&L.

No discount rate. Treating a month-48 dollar as equal to a month-1 dollar is not conservatism, it is an error. Document d.

Infinite horizon. An uncapped sum lets the least reliable part of the model — the extrapolated tail — dominate the total.

Blended NRR applied per customer. The core failure this question names. Folding expansion into one rate misrepresents the non-expanding majority in both directions.

Bookings instead of recognized revenue. LTV is a management metric, not a GAAP figure, but it must be *consistent* with recognized revenue. A three-year prepaid deal is one large booking whose recognized revenue spreads across 36 months under ASC 606, and that recognized stream — net of margin, discounted — is the LTV-relevant cash. When diligence reconciles your model against audited financials, an LTV whose "revenue" cannot tie back to recognized revenue gets discounted along with your credibility.

One-time services revenue in ARPA. Implementation and professional-services fees inflate R(t) with non-recurring dollars. LTV uses recurring revenue only.

Whale-dominated blends. A handful of hyperscale accounts drag the mean far from the median. Report both, always.

Stale descriptive LTV used as predictive. This one deserves unpacking because it is the most expensive. There are two distinct LTV questions. Descriptive LTV asks what historical cohorts were actually worth — answered with full history including post-hoc expander labels, useful for channel attribution and segment P&L. Predictive LTV asks what the cohort you are acquiring *today* will be worth, and that is the number that should drive CAC decisions. You cannot use a customer's month-24 expansion behavior to predict someone who signed yesterday; that information does not exist yet. Predictive LTV must be built from early signals only — plan tier at signup, seat count at day 30, onboarding-milestone completion, acquisition channel, firmographic fit. The Cox model is the right tool because it maps early covariates onto a hazard multiplier and a revenue path. Companies that compute descriptive LTV from mature cohorts and then spend CAC against it are either under-investing (if ICP, pricing, or onboarding improved) or over-investing into a leaky bucket (if the market got harder or they drifted down-market).

Two more traps sit adjacent to the list. The first is classification leakage: if you label an account an "expander" using month-12 data, you cannot then use that label to predict its month-3 behavior — that is using the future to predict the past. Descriptive work can use full-history labels; predictive work cannot. The second is uncapped expansion. Let an expander segment compound at 2.5% monthly for 48 months and a $1,000 account becomes $3,260, which the model treats as routine. In reality expansion saturates — customers run out of seats to add, departments to onboard, and use cases to fund. Model expansion as an S-curve toward a ceiling estimated from your own month-36 median expander, not a straight exponential. Capping typically removes 10-20% from a naively-modeled expander LTV, and that is 10-20% of error you would rather find before a diligence team does.

Reading the curve itself is a skill worth building, because it catches retention problems months before they appear in MRR. The onboarding cliff (months 0-3) is the steepest region of almost any SaaS survival curve; a 6-12% cumulative drop is normal, above 20% is an activation emergency governed by time-to-first-value. The habituation bend (months 4-12) should visibly flatten; if churn stays linear into month 12, customers tolerate the product but never come to depend on it, and expansion revenue can mask that on the NRR line while doing nothing for survival. The plateau (months 13-30) carries your most valuable signal, because the discounted tail is dominated by it — a 0.5%/month plateau hazard versus 1.5% is the difference between a 60-month and a 24-month effective life. And if you bill annually you will see a renewal sawtooth: flat for eleven months, a sharp drop at the anniversary, flat again. You cannot smooth a staircase into an exponential, but the concentration of risk into predictable calendar moments is operationally a gift.

Finally, segment before you average, and understand what GRR and NRR each tell you. Gross Revenue Retention excludes all expansion and caps at 100%; it measures pure leakage and maps to the downside of your survival curve. Net Revenue Retention adds expansion and can exceed 100%; it captures the revenue-trajectory process. A business at 95% GRR and 115% NRR is healthy-but-leaky. One at 88% GRR and 115% NRR is masking a serious retention problem with aggressive expansion, and only the split reveals it. The segmentation cuts that consistently change the curve: plan tier (SMB churns 3-5x faster than enterprise), acquisition channel (self-serve and paid-search cohorts typically churn 2-3x faster than sales-led or referral), billing term (monthly churns roughly 2x annual, which front-loads risk to the renewal date), onboarding completion (Cox hazard ratios commonly land around 0.4-0.5), industry and use-case criticality, and cohort vintage as a drift signal.

Decision framework: when to choose what, and when not to model at all

Knowing when *not* to build the full model is judgment, not laziness. Rigorous survival analysis is right for most established subscription businesses. It is wrong, or at least premature, in five recognizable situations.

Pre-product-market-fit, under ~100 paying customers and under 12 months of history. A Kaplan-Meier curve will be almost entirely censored and a Weibull tail will be pure imagination. Build the cohort triangle and state the uncertainty plainly: "we do not yet know our true LTV; here is the six-month retention we have observed." That is more credible than a precise-looking figure resting on 40 data points. Spurious precision is worse than admitted uncertainty.

Usage-based or non-contractual revenue. Where customers never formally churn — they just stop using the product, then maybe return — the survival framing is the wrong instrument because there is no clean churn event. The BG/NBD plus Gamma-Gamma family, which models latent churn and spend separately, is the correct choice. Applying contractual Kaplan-Meier to a non-contractual business produces confident nonsense.

Enterprise with a few dozen logos a year. Six-figure contracts sold to a small named-account list do not provide the sample size for statistical survival modeling. Bottoms-up estimation — renewal probability assessed account by account with the CS team — beats any curve fit. The law of large numbers is not on your side; named-account judgment is.

After a repricing, ICP shift, or major product launch. Survival models assume a stable data-generating process. If you repriced six months ago, your historical curve describes a company that no longer exists. Weight recent cohorts heavily, flag the discontinuity explicitly, and treat old-cohort LTV as a separate legacy number rather than blending two different companies into one figure.

When LTV is being used to justify rather than to decide. The honest counter-case: if leadership has already committed to aggressive acquisition spend and wants a number that supports it, no amount of statistical rigor helps — the model gets tuned until the ratio looks fundable. The fix is governance, not mathematics. Agree the discount rate, horizon cap, and margin definition *before* running the model, and have finance own the assumptions rather than growth.

Once you have the number, the framing determines whether it survives contact with a sophisticated reader. Never present "our LTV is $48,000" as a fact; it invites "computed how?" and if the answer is ARPA/churn, the rest of your unit economics gets discounted too. Present a range ("$19K-$24K depending on cohort and discount rate"), the method named explicitly ("Kaplan-Meier survival curve, Weibull tail, 10% discount, 48-month cap"), the segmentation (enterprise versus SMB shown separately), and the confidence interval if you are on Tier 3 or 4.

LTV is rarely the headline anyway — LTV:CAC and CAC payback period are. Roughly speaking, an LTV:CAC below 1.5:1 is weak, 3:1 is acceptable, above 4:1 is strong, and it must be computed on gross-margin LTV against fully-loaded CAC. Payback above 24 months is weak, 12-18 is acceptable, under 12 is strong. GRR below 80% is weak, 85-90% acceptable, above 90% strong, with enterprise expected to exceed SMB. NRR below 100% is weak, 105-115% acceptable, above 120% strong — and it must be segmented, because a bimodal base hides inside any blend. Note the arithmetic: a 3:1 ratio computed from an inflated 1/churn LTV may really be 1.8:1, which is the difference between a fundable growth motion and a leaky bucket. That is precisely why diligence teams rebuild LTV from raw data rather than accepting the slide.

Always pair LTV with payback, because LTV says nothing about *when* the cash arrives. A customer worth $30,000 over five years is a different animal from one worth $30,000 in eighteen months, especially if you are capital-constrained. A long payback with a beautiful LTV:CAC ratio is a financing problem wearing the costume of a good business.

Expect five questions from anyone who has sat through SaaS diligence. *What churn assumption is baked into the tail?* — have the observed-versus-extrapolated split ready ("we have data through month 30 at 0.7% monthly churn; the tail assumes 0.7% holds, not an improvement"). *Is this gross-margin LTV?* — if you cannot immediately say yes at a stated margin matching the P&L, the number is discounted. *What is the payback, not just the ratio?* *How does this differ by segment?* — never let a blend stand alone. *What changed since last quarter and why?* — LTV should move slowly, so attribute any jump to a specific cause: a cohort maturing, a discount-rate change, a data fix.

Validate before you present. Run a holdout backtest: fit on cohorts through two years ago, predict the following year's retention, compare to reality. If the model said 0.58 survival at month 30 and reality was 0.51, it is optimistic — recalibrate before it sets CAC budgets. Watch vintage stability: re-estimate quarterly and investigate large swings in the Weibull shape parameter, which mean either the business is changing or the data is noisy. Publish sensitivity bands on the two parameters that swing the result most, usually discount rate and plateau hazard. A wide band honestly disclosed is more credible than a narrow one quietly assumed.

One last governance point: maintain one model, not two. Companies sometimes keep an "operating LTV" and a "fundraising LTV." Investors rebuild the number from your data room anyway, so divergence between the two is exactly the inconsistency diligence is designed to surface. Keep one set of assumptions, governed by finance, presented identically to the board, the data room, and the growth team.

Related questions

How long does it take to replace 1/churn with a real model?

Roughly 90 days. Days 1-30: audit the event log, build the cohort triangle, and get finance to sign off on margin definition, discount rate, and horizon cap. Days 31-60: fit Kaplan-Meier plus Weibull, segment, run a Cox model. Days 61-90: wire it into the board dashboard with payback alongside.

Do non-expanding customers actually hurt LTV?

Not necessarily. Flat accounts often churn *less* than average because they have reached a stable equilibrium — they are not unhappy, just done growing. Their long survival at constant revenue can produce a respectable LTV. The harm comes from averaging them with expanders, not from their existence. Price and serve them deliberately.

Should partner-sourced or regional cohorts get their own LTV?

Yes. Partner economics rarely match direct, and regional cohorts diverge on churn, ARPA, and expansion. Never set a regional hiring budget or partner commission structure against a blended global LTV — use the segment-specific LTV:CAC, or you will overfund the weak channel and starve the strong one.

How does LTV connect to burn multiple and other capital-efficiency metrics?

LTV feeds the efficiency stack: LTV:CAC sets channel budgets, payback governs cash timing, and burn multiple measures net cash burned per dollar of net new ARR. Build the warehouse and dbt layer once — the same customer-level tables that produce survival curves also produce burn-multiple inputs.

What refresh cadence does an LTV model need?

Quarterly for most companies. LTV is a slow-moving structural metric, not an operational dashboard number, and refreshing it monthly invites reading noise as signal. Re-fit quarterly, watch parameter drift between fits, and re-baseline immediately after any repricing or ICP change.

FAQ

What is the biggest mistake teams make when they calculate LTV?

Using LTV = ARPA / churn. It assumes churn is constant over cohort age and that every account expands at the average rate. In reality churn declines with tenure and a large share of customers never expand, so this shortcut can misstate LTV dramatically — often overstating it by 40% or more, and occasionally understating the loyal tail by 2x.

How do I handle customers who never expand?

Segment before you average. Classify accounts as expanders, flat, or contractors at a fixed observation point, fit a separate survival curve and revenue path for each, and blend only at the end weighted by true population share. A Markov-chain model handles this most naturally, since "stays flat" is just a high self-transition probability rather than an exception.

What is a survival curve and why do I need one?

It is the probability a customer remains active at each month of tenure, estimated with Kaplan-Meier or a parametric hazard model. It replaces the constant-churn assumption with the actual, convex retention shape your data shows, and it handles right-censoring correctly — crucial, since most of your customers have not churned yet and never should be counted as if they had.

Do I really need gross margin and a discount rate?

Yes, and boards notice when they are missing. Gross revenue LTV overstates by the full COGS percentage — 15-30% for typical SaaS. Skipping the discount rate treats a month-48 dollar as equal to a month-1 dollar. Use gross margin defined identically to the P&L, discount at 8-12% annually, and document both so period-over-period trends stay comparable.

Can I do this in a spreadsheet?

Tier 1, yes. A cohort retention triangle with a per-column empirical survival rate, multiplied by segmented revenue paths, margin, and a discount factor, already beats 1/churn decisively and is board-legible. What a spreadsheet cannot do is extrapolate past your oldest cohort or handle censoring rigorously — for that you need Kaplan-Meier plus a parametric tail, which is a few lines of Python.

How should I report LTV to a board or an investor?

As a range with the method named, segmented, and paired with CAC payback — never a single hero number. "Enterprise $41K, SMB $11K, Kaplan-Meier with Weibull tail, 10% discount, 48-month cap, 14-month blended payback" survives interrogation. A precise-sounding point estimate invites "computed how?" and takes the rest of your unit economics down with it.

Sources

1. Kaplan, E. L. & Meier, P., "Nonparametric Estimation from Incomplete Observations," *Journal of the American Statistical Association*, 1958 — https://www.jstor.org/stable/2281868
2. Cox, D. R., "Regression Models and Life-Tables," *Journal of the Royal Statistical Society Series B*, 1972 — https://www.jstor.org/stable/2985181
3. lifelines documentation — Kaplan-Meier, Weibull, and Cox proportional hazards in Python — https://lifelines.readthedocs.io/
4. lifetimes documentation — BG/NBD and Gamma-Gamma models for non-contractual settings — https://lifetimes.readthedocs.io/
5. Fader, P. & Hardie, B., research notes on probability models for customer-base analysis — https://www.brucehardie.com/papers/
6. ChartMogul, SaaS metrics and cohort analysis guides — https://chartmogul.com/resources/
7. Bessemer Venture Partners, "State of the Cloud" — https://www.bvp.com/atlas/state-of-the-cloud
8. OpenView Partners, SaaS Benchmarks Report — https://openviewpartners.com/saas-benchmarks/
9. David Skok, "SaaS Metrics 2.0," For Entrepreneurs — https://www.forentrepreneurs.com/saas-metrics-2/
10. FASB, ASC 606 "Revenue from Contracts with Customers" — https://www.fasb.org/revenuerecognition

Related on PULSE

• What metrics should you include in a board-ready unit economics dashboard?
• What is 'burn multiple' and how does it change capital allocation?
• What specific metrics are B2B RevOps teams using to measure AI's impact on lead quality in the top-of-funnel?
• Why are longer sales cycles now correlating with a shift from pipeline velocity to deal value predictability?
• How does the expanding size of B2B buying committees increase the risk of vendor consolidation paralysis?