Modeling the Customer Lifecycle: One Dataset, Five Questions

A template for entities with lifecycles, events, heterogeneity, and interventions

Machine learning
Bayesian modeling
Survival analysis
Customer analytics
A layered modeling portfolio that turns a single transaction log into a sequence of models — from a churn score, to a belief, to a dollar figure of revenue at risk with uncertainty.
Published

July 1, 2026

The crucial reframe

This looks like a churn project. It isn’t.

What follows is a template for modeling entities that have lifecycles, events, heterogeneity, and interventions — demonstrated on customers and revenue because that data is rich, legible to any reviewer, and freely available. The same architecture transfers to equipment reliability, patient outcomes, or student retention. Customers are the vehicle; the modeling pattern is the point.

The pattern rests on one rule: a single transaction log is the spine. Every layer derives from the same log, so the models stay comparable and can be chained — not five disconnected notebooks that happen to share a topic.

Why one model isn’t enough

A lifecycle doesn’t pose a single question. It poses a sequence of them, and each one needs a different tool:

  • Who is likely to leave?
  • How sure are we about each of those predictions?
  • What is each customer actually worth?
  • When will they lapse — not just whether?
  • So how many dollars are at risk, and how confident are we in that number?
  • And does any intervention actually change the outcome?

No single model answers all of these well. A classifier ranks customers but hides its own uncertainty. A Bayesian model quantifies that uncertainty but still leans on a target you had to invent. A survival model tells you when but not how much. So rather than stretch one model to cover everything, this portfolio uses a short stack of focused models — each answering the question the previous one couldn’t.

Two choices turn that stack into a system:

  • Adjudicate, don’t accumulate. Where two models answer the same question different ways — a supervised churn label versus a latent “probability alive” — I show where they agree, where they diverge, and which one I’d deploy. Breadth only counts when you’re willing to say which tool wins.
  • The same feature/target window honored in each model. Features come from on-or-before a cutoff; labels come from strictly after it, enforced with runtime assertions rather than convention. Every layer is scored on the same genuine future window. (Leaking the future into the past is the single most common flaw in portfolio churn notebooks — so it’s the first thing this project gets right.)

One wrinkle makes the customer substrate a good teacher: this is non-contractual data. Nobody cancels a subscription, so there’s no clean churn label to be found — you have to define one from a temporal cutoff. Deciding what “churn” even means is itself a modeling choice, and it’s exactly the choice Layer 3 later reframes. The mechanics of labeling without leakage are the subject of the next post.

The map

flowchart TD
    L0["Layer 0<br/>Leakage-safe target &amp; windowing"] --> L1
    L1["Layer 1<br/>XGBoost ranking + calibration baseline"] -->|"probabilities carry no uncertainty"| L2
    L2["Layer 2<br/>BART posterior over churn probability"] -->|"still needs a hand-labeled target"| L3
    L3["Layer 3<br/>BG/NBD + Gamma-Gamma<br/>latent P(alive) + CLV"] -->|"says whether, not when"| L4
    L4["Layer 4<br/>Survival: time-to-lapse"] --> INT
    L3 --> INT
    INT["★ Integration<br/>Revenue-at-Risk<br/>P(churn) × CLV, uncertainty propagated"]
    INT -.optional.-> L5["Layer 5<br/>Double-ML<br/>causal effect of interventions"]
Figure 1: Each layer answers a decision-relevant question the previous one couldn’t. Edge labels name the limitation that motivates the handoff.
Layer The question it answers The model What it still can’t do
0 — Foundation What does “churn” mean in non-contractual data, and how do we label it without leakage? Temporal cutoff + windowed behavioral features (Enables everything below)
1 — Ranking Who is most likely to churn in the next 90 days? XGBoost, with a calibration baseline Gives a number with no sense of its own uncertainty
2 — Uncertainty How confident is the model in each prediction, and are its probabilities honest? BART — a posterior over churn probability Still depends on a hand-engineered target
3 — Latent value With no label at all, is a customer still “alive,” and what are they worth? BG/NBD + Gamma-Gamma Says whether, not when
4 — Timing When will a customer lapse, and how do covariates shift that timing? Survival (Cox PH / Weibull) Reports timing in isolation from value
★ Integration How many dollars are at risk per customer, and how sure are we? P(churn) × CLV, uncertainty propagated (This is the payoff)
5 — Causal (optional) Does an intervention actually cause retention? Double-ML

Where this ends up

The layers don’t stay separate. Because the churn and value models produce distributions over the same customers, the capstone multiplies them into a single figure — expected revenue at risk = P(churn) × predicted value — and propagates the uncertainty, yielding a credible interval on the dollars at stake per account. The arc runs from a probability, to a belief, to a dollar amount you can rank and act on.

Start here

  • Post 1 — Churn Prediction, Done Honestly (Foundation + Layer 1): leakage-safe labeling, out-of-time evaluation, and measuring calibration instead of stopping at AUC. → Churn Prediction
  • Post 2 — Not All 70%s Are Equal (BART, uncertainty) — forthcoming
  • Post 3 — Churn Without a Label (BTYD + CLV) — forthcoming
  • Post 4 — When, Not Whether (survival) — forthcoming
  • Post 5 — Revenue at Risk (the capstone) — forthcoming