01

Capability · Churn prediction

Churn prediction that answers when, not just who

Survival models built in your environment, on your own data, that put a date on the risk. A date is the only thing an intervention can be scheduled against.

Start a conversationAll three services in detail

02

Short answer

Churn prediction estimates which customers are likely to leave. A survival model estimates when: it returns a time to event for every customer, usually from a gradient-boosted accelerated failure time model, so a retention program can act in the weeks that matter rather than working a ranked list on the first Monday of the month. I build them inside the client’s own environment, on their own data, with the team that runs them afterwards.

Who is at risk, and when

Most churn work stops at a probability. A model reads recent behaviour, scores every customer between zero and one, and the program contacts the top decile on whatever day the calendar had free. The ranking is usually right. The timing is a coincidence.

A survival model answers a different question: not how likely someone is to leave, but how long they are likely to stay. It returns a curve rather than a point — the probability of still being a customer next week, next month, next quarter. That is a date, and a date goes into a plan.

Why the distinction pays

Two customers can share a risk score and sit four months apart. One is drifting and can be reached cheaply in eight weeks; the other is a fortnight from cancelling and needs an expensive decision now. A ranked list treats them identically, so half the budget arrives too early to matter and the rest arrives too late.

Censoring, and why classifiers struggle here

Most of your customers have not churned yet, so their true lifetime is unknown — you only know it is longer than what you have watched. Survival models are built for that: a still-active customer counts as partial evidence rather than being discarded, or labelled “did not churn”, which teaches a classifier that everyone on the books today is safe. In practice that means XGBoost-AFT; a Cox model is easier to explain and sometimes better, and the choice gets made in your data.

Method
Survival analysis — gradient-boosted accelerated failure time
Output
A time to event per customer, refreshed on your cadence
Where it runs
Your environment, your data, your access reviews
Stack
Databricks · SQL · Python, or the equivalent you run
Measured by
Holdout groups agreed before anything ships
Bought as
Part of a retention program or a fractional seat

03

How it gets built

The order matters more than the calendar. Each step is worthless without the one before it.

  1. 01

    Agree what churn is

    The expensive mistake is modelling the wrong event. A cancellation, a lapsed subscription, a customer who has not transacted in a window somebody picked — each gives a different model and a different program. It gets written down first.

  2. 02

    Build the history honestly

    Features as they looked at the time, not as they look now. A table that leaks the future produces a beautiful validation score and no predictive value, and it is the most common way this work quietly fails.

  3. 03

    Beat the naive rule, or say so

    The model has to beat the obvious version — tenure, or days since last activity — by enough to be worth maintaining. Usually it does, comfortably. When it does not, that is a cheap finding to have early.

  4. 04

    Wire it into the program

    A prediction that lands in a dashboard changes nothing. The score goes where the orchestration can read it, on a cadence the business needs, with the holdout defined before the first message goes out.

If you already know when your customers leave, you don’t need this. If you don’t, write.hello@andersson.consulting

04

What it needs from you

Less than most teams expect, and none of it exotic.

  • Customer-level history you can query. A warehouse is ideal; a database someone can grant access to will do.
  • Dates. When each relationship started, and when it ended for the ones that did. Timestamps are the substance of the model.
  • Enough completed departures to learn from. A business with very few churn events cannot support this yet, and I would rather say so in week one.
  • Behaviour, in whatever shape you keep it. Usage, transactions, payments, support contact. Breadth beats polish at this stage.
  • One person who can grant access. The work happens inside your environment, and nothing needs to leave it.

Not on that list: a data science team. Nor a plan for what to do with the output — on its own a good model is a slide, and it earns its cost inside the program that reads it.

How the program around it works

05

Questions about churn models

How is this different from the predictive scores in our messaging platform?

Two ways. A platform-native score is trained on what the platform can see — opens, clicks, sessions inside its own SDK — which is rarely where the churn signal lives. And it returns a probability, not a time. They cost nothing extra, so if one is already good enough for your program, that is what I will tell you.

How accurate is it?

Accuracy is the wrong question, and a figure quoted from another company’s data is worthless in yours. What matters is whether the model beats the naive rule by enough to justify maintaining it, and whether acting on it beats not acting on it against a holdout.

Can this be done without touching customer-level data?

No, and be careful with anyone who says otherwise: a survival model is fitted on individual histories. What can be arranged is that none of it leaves your environment — I work inside your systems with the minimum access needed, and everything built stays there.

Every question, answered

06

Related services

07

Available for new engagements

Start a conversation

If the timing fits, email me directly. There is no funnel behind it, and the reply comes from me.

hello@andersson.consulting