Worth keeping: customer lifetime value from survival and revenue
Retention and marketing budgets were being allocated on current-state numbers — this month's ARPU, this month's churn score. Customer lifetime value asks a forward question instead: how much will this customer bring over the relationship that remains? Answering it took two forecasts, one for how long and one for how much, and a way to multiply them.
From the current state to the future value
Customer lifetime value measures the expected total value over a customer relationship. For subscription businesses it supports retention strategy, marketing resource allocation, customer segmentation and profitability management — but only if it is estimated rather than assumed. The model needed to estimate two things that are usually kept apart: future revenue, which drifts with upgrades, downgrades and add-ons, and the probability that the customer is still there to pay it.
What was built
- A data structure for both forecasts. Static customer attributes, historical usage, product information, service behaviour and time-varying variables were combined into one customer-month structure that both models read from.
- Revenue trajectories. A Temporal Fusion Transformer modelled future revenue month by month, taking static, past and known-future inputs together.
- Survival. Retention probability was modelled with survival analysis: Multi-Task Logistic Regression, which estimates a hazard per discrete time period, and a Cox proportional-hazards model with elastic net for variable selection.
- Combination. Predicted future revenue and survival functions were combined to estimate customer-level long-term value — a number per customer, with the curves behind it.
Live model, computed in your browser. Generated customers with 24 months of outcomes train a monthly hazard model and a revenue-trajectory model; a thousand others are scored today and checked against what they went on to pay. Left: today's bill carried forward, and who it would send the retention budget to. Right: survival × revenue for the same customer, what actually happened to them, and the same budget allocated by CLV. The production models — a Temporal Fusion Transformer and MTLR/Cox — are stood in for by a logistic hazard and a regression. Open the live model on its own page ↗
Architecture, stack and core formulation
A customer-month data structure feeding two models — a revenue-trajectory model and a survival model — whose outputs multiply into long-term value per customer.
Customer-month structure
Static attributes, historical usage, products, service behaviour and time-varying variables in one structure.
Trajectory model
A Temporal Fusion Transformer over static, past and known-future inputs forecasts monthly revenue.
Retention curve
Multi-Task Logistic Regression and a Cox model with elastic net estimate each customer's survival function.
Multiply and sum
Expected revenue in each future month times the probability of still being a customer.
Allocation
Retention and marketing resources prioritized by long-term value and retention likelihood.
| Layer | Technology | What it does here |
|---|---|---|
| Data | Customer × month features: static, past observed, known future | Shared input for both models |
| Revenue model | Temporal Fusion Transformer | Variable selection, sequence encoding and attention over mixed inputs |
| Survival model | Multi-Task Logistic Regression; Cox proportional hazards with elastic net | Discrete-time survival curves; variable selection |
| Value | Σ expected revenue × survival | Customer-level long-term value |
CLV_i = Σ_(t=1..H) E[ R_it ] · S_i(t) S_i(t) = Π_(k ≤ t) ( 1 − h_ik ) discrete-time survival MTLR P(T_i = k) ∝ exp( Σ_(j ≥ k) (θ_jᵀ x_i + b_j) ) logistic model per interval, jointly Cox-EN h(t | x) = h₀(t) · exp(βᵀx), max ℓ(β) − λ[ α‖β‖₁ + (1−α)/2 · ‖β‖²₂ ] TFT R̂_(t+1 … t+H) = f( static s, past z_(≤t), known future x_(t+1 … t+H) )
- Curves, not scores. A survival function puts the contract-end step where it belongs and handles customers still active at the end of the data correctly.
- Trajectories, not constants. Upgrades, downgrades and known future events enter the revenue forecast instead of a flat ARPU.
- Value changes the ranking. Ranking by CLV instead of ARPU moves retention effort toward customers whose long-term value is at risk.
| Component | In production | In the live model above |
|---|---|---|
| Revenue | Temporal Fusion Transformer | Regression on trend, history slope, bundle and ARPU |
| Survival | MTLR and Cox with elastic net | Person-month logistic hazard model |
| Evaluation | Business use for retention allocation | Realized 24-month value on 1,000 held-out generated customers |
Design notes
Why survival, not a churn score
A churn score is a probability for one window. Value needs a whole curve: how likely the customer is to be present in month three, month twelve, month twenty-four, with the step at a contract end where it belongs. Discrete-time survival models give exactly that, and treat customers still active at the end of the data correctly instead of as non-churners.
Why a trajectory, not a constant
Carrying today's bill forward is wrong in both directions: it ignores upgrades that make a growing customer more valuable, and it ignores the slow downgrades that precede many departures. Modelling revenue as a sequence lets known future events — a promotion ending, a contract renewing — enter the forecast.
What changes downstream
With value as a forward estimate, the retention question becomes "where is long-term value at risk?" rather than "who pays the most today?". The two rankings overlap less than people expect, and the difference is exactly the set of customers a retention programme should be built around.
Outcome
The project shifted customer management from current-state metrics such as ARPU and churn score to a future-value perspective, and provided a basis for deciding which customers should receive retention or marketing resources based on long-term value and retention likelihood.
Limitations
- CLV is an expectation under the current environment; a competitor's move or a pricing change shifts every curve at once.
- Long horizons compound model error; the estimate is most reliable in the first year and most useful as a ranking.
- The live model's generator plants the drivers of churn, so its hazard model is better specified than any real one; its revenue model is a regression rather than the production transformer.
About the demo and confidentiality
Customers, revenue histories, contracts, churn and value in the embedded model are generated from a planted process. No subscriber, billing or churn data from any operator appears here.