You find players about to leave by scoring every player on their recent behaviour, checking that the scores are honest on past data, and giving your team a short ranked list each morning. The model is the smaller part. Most of the work is data, validation and what your team does with the list. Here is the process I would follow, step by step, including where it tends to go wrong.
What data do you need to predict churn?
Four tables, all keyed by Player ID. That is the minimum we ask for at Sellrise, and it is enough for useful forecasts:
- Players: registration, source, account type, consent state.
- Deposits: amounts and timestamps, plus bonuses granted and redeemed if you have them.
- Bets: game, stake, outcome, time.
- Sessions: logins, length, device.
Names, phones and emails are not needed to forecast. They only matter when you start sending messages. Before you build anything, check how much clean history you have. If you have fewer than six months of reliable player history, the honest answer may be to wait, or to start with simpler rules while you collect data.
Also remove test, service and bot accounts before you train anything. They are small in number and have a large effect on the result.
Which behaviour signals show a player is leaving?
Players rarely leave in one step. They fade. The signals I would compute first are changes against the player's own normal:
- Bet size dropping compared with the player's recent average.
- Shorter sessions, or fewer of them per week.
- A shift in the mix of games the player usually plays.
- No deposit for a long stretch relative to their own deposit rhythm (a 14-day gap is a common starting point to test).
Compute these over fixed windows, for example the last 7, 14 and 30 days for behaviour and the last 90 days for lifetime deposit totals. Use one row per player. Build the features from raw transactions, not from your platform's pre-calculated statistics, because those are often refreshed in ways that leak future information into the past.
That last point is the most common mistake I see. If a feature was calculated after the moment you are pretending to predict, your model will look brilliant on history and fail in production.
Which model should you use?
A gradient boosting model on tabular features is a sensible default: it is fast, small, and its decisions can be explained with SHAP values that an analyst can read. Neural networks do not buy you much on this kind of data and are harder to audit.
Build two separate models rather than one. One estimates the probability that an active player leaves in the next 7 to 30 days. The other estimates the probability that a player who has already gone quiet comes back. They answer different questions and lead to different actions: hold in one case, reactivate in the other.
Churn is imbalanced, since most players do not leave in any given week, so use a weighted or focal loss. After fitting, calibrate the probabilities so that "30 percent risk" actually means roughly three in ten. Uncalibrated scores are the reason teams stop trusting forecasts.
I covered the architecture and the modelling choices in more depth in per-player scoring architecture and the gradient boosting playbook.
How do you check the forecast is honest?
Three checks, in this order.
- Time-aware validation. Train on earlier weeks, test on later ones. Random splits let the model see the future and flatter itself.
- Calibration. Plot predicted risk against what actually happened, in buckets. The lines should sit close together.
- Shadow mode. Run the scores for about two weeks while your team sees them but does not act. Then check whether the flagged players really went quiet. Only then spend campaign money.
Shadow mode is the step teams skip, and it is the one that builds trust. It also shows you early if the forecast is mostly flagging players your team already knows about.
How do you turn scores into a list your team can use?
Do not hand the team a table of probabilities. Hand them a worklist, sorted by expected value rather than raw risk. A high-deposit player at moderate risk should outrank a low-value player at high risk, because the cost of losing them is higher.
For each row show the suggested action (hold, reactivate or monitor), the top reasons behind the flag, the channel and the time to contact. In Sellrise this is the "today's queue" screen: a reason, a priority, a channel, a time and an offer for each player, so a manager can act without opening another report.
Keep a clear rule that scoring is unrestricted but action is gated. Players who are self-excluded or flagged for responsible gaming can be scored, but they must stay out of the outreach queue, and the check should run both when you score and when you send, because a status can change in between.
What should the offer be?
A churn score tells you who. It does not tell you what to give. Match the offer to the player's stage and value, from your own promotion catalogue, and remember the cases where the right offer is none. A player who is currently winning does not need a bonus to come back tomorrow.
Decide the economics of a bonus outside the model. Margins, wagering terms and legal limits belong to you, and a forecast should not pretend to know them. Your team decides and sends. If a vendor proposes to send automatically from day one, ask why they trust a model that has not yet been checked on your players.
How do you prove it moved revenue?
Run a controlled test. Hold back a control group that nobody contacts. Split the rest into players handled as your team handles them today and players handled by following the forecast. Run it for a month and compare average turnover per player across the three groups. Agree the group sizes and the metric before you start.
Do not accept a percentage from anyone, including me, until it has been measured on your own players. Lifts quoted from other operators depend on their markets, their ARPU and their offers.
How long does this take, and how often do you retrain?
For a build from scratch, the write-ups I linked above put a first deployment at roughly six to twelve weeks, depending mostly on data quality and how custom your platform is. Adapters for self-written platforms take a large share of the effort: currency units, cents versus whole units and time zones are the usual traps.
Once live, retrain on a rolling window, weekly as a default and monthly at the outside, reuse the same feature pipeline for training and scoring so the two never drift apart, and watch for drift.
If you would rather not build this yourself, that is what Sellrise is for: four tables in, a daily list out, and the effect measured in a pilot against a control group. You can look at the demo or read about the player retention use case.