SaaS & technology
Churn prediction with named drivers
Retention models that say who is leaving and why — so retention spend targets the persuadable instead of the already-lost.
This page describes a problem class and the architecture we deploy for it, written against a named public benchmark — the open dataset or competition where the world's data scientists have tested approaches to this exact problem against a hard metric. It is not a client engagement, and the benchmark's results, prizes and rankings belong to its host and participants, not to us. Client work is confidential and is only ever published with written permission.
The problem
What it costs when this goes unsolved.
Retention budgets fail in two directions: discounts offered to customers who were staying anyway, and silence toward the ones already halfway out. A churn score alone does not fix this — the commercial team needs the driver behind each risk score, because 'contract ending and support tickets rising' and 'price-sensitive from day one' call for different plays.
Churn data is a wide table of tenure, plan, usage and billing signals with a class imbalance that flatters accuracy. The known traps: features that encode the outcome (the cancellation call logged before the churn flag), survivorship in the training window, and drivers read off a correlated model as if they were causes. Attribution needs care, not just a SHAP plot.
How we build it
The architecture, stage by stage.
01
Cohort-honest framing
The target is defined per renewal cycle with the decision point fixed in time, so every feature is knowable when the intervention would actually run.
02
Boosted ensembles with calibrated scores
Gradient boosting with class weighting and probability calibration — the score reads as a real risk, which is what makes ROI arithmetic on retention offers possible.
03
Driver attribution per customer
Per-customer attributions grouped into a handful of named, actionable driver patterns the commercial team can build plays against.
04
Measured interventions
Retention actions run against holdouts, because the model's job is not to predict churn — it is to reduce it, and only an experiment shows that.
Model families on this problem class: XGBoost / LightGBM · SHAP attribution · Survival analysis · Uplift measurement.
What you get
What an engagement hands over.
Everything below goes in the scope document before you sign it, with a fixed price or a rate with a ceiling — the same terms as every other engagement in the catalogue.
- A churn model scored every cycle, with calibrated risk per account
- Driver patterns with recommended retention plays per pattern
- A holdout design that measures whether interventions actually work
- Dashboards in your BI tool, not another login
Provenance
The benchmark behind this page.
Telco Customer Churn, run by IBM (sample dataset), is the public proving ground for this problem class. The figures below are the host's, cited as context for how seriously this problem is tested in the open — they are not our results and we do not claim them.
How to buy this
The services this build draws on.
More proof
Next step
Thirty minutes on whether this fits your problem.
Bring the constraint — the regulator, the data boundary, the latency budget. If your data cannot support this build yet, the call will conclude with what to fix first, not with a proposal.