TL;DR: Casino retention is a per-player decision, not a cohort blast. Score churn and reactivation with gradient boosting on raw transactions, feed the output into the analyst team's CRM as a prioritised worklist, and keep LLMs out of anything that touches money. Player payback is five to seven months - a hallucinated risk score is real loss. This playbook is from a live pilot for a European online casino operator.
Online casino retention is one of the last frontiers of B2C where cohort blasts are still the norm. Analyst teams build segments by hand, push the same bonus to everyone in the segment, and hope the numbers move at the end of the month. The signal that a single VIP is about to go silent gets averaged away in the cohort. By the time anyone notices, the window to hold that player has closed.
This post is the technical playbook for building a retention CRM that actually decides per player. It is not vendor pitch. It is what we shipped in a two-week scoring core for a European casino operator, plus what we learned in the discovery calls that led up to it - including the parts where we told the operator not to do things.
Why cohort retention breaks down
Take the standard retention workflow. Analysts pull yesterday's active players, segment by deposit tier and recency, and push a bonus to each segment. The bonus is either a percentage cashback, a bonus-hunter-bait match, or an untargeted freespins bundle. The retention team measures conversion by segment at the end of the week.
Three problems compound. First, bonus economics leak. Bonus hunters in the cohort collect the same offer as your loyal whales. The margin gets eaten by the wrong audience. Second, VIP silence gets missed. A high-frequency depositor whose bet size just dropped by 60% is a churn signal that no cohort segmentation surfaces - his tier and recency still look fine. Third, the analyst worklist is flat. A dashboard with 4,000 active players sorted by yesterday's deposit tells the team nothing about who to act on.
The problem is not the analysts. The problem is that the retention layer was never designed to produce per-player decisions.
Why not use an LLM for scoring?
This is the question we get on every discovery call. The answer is no, and it is not a religious no.
Player payback periods in iGaming run five to seven months. A hallucinated risk score - and every LLM hallucinates in some percentage of calls - is not an amusing error. It is real money that either walks out the door in the form of a bonus given to the wrong player, or gets saved in the form of a churn that would have been catchable. Compounded over a rolling week of scoring, the drift adds up to material P&L movement.
There is a second issue. LLMs are not auditable in the sense that a retention analyst can trust. When an XGBoost model returns a churn probability of 0.72 for player X, the analyst can pull the top ten SHAP features and see exactly why - bet size dropped, session length dropped, game-mix shifted from slots to blackjack, no deposit in fourteen days. When an LLM returns a churn probability of 0.72, there is no audit trail. The analyst either trusts the black box or does not, and if they do not, the whole system loses adoption.
LLMs have a real place in the retention loop - drafting the copy of a retention message, summarising a player's history for the analyst before a call, generating human-language explanations of an already-auditable score. Anywhere the wrong output is recoverable by a human review pass, we use them freely. Anywhere the wrong output leaks money before a human sees it, we do not.
The scoring architecture
Four source tables aggregate into a per-player feature card. Players, transactions, sessions, and game events. Every casino platform has some form of these, whether the schema is documented or has to be reverse-engineered from a self-written platform's database.
The feature card is one row per player, wide, with features scoped to prediction windows. Critically, the aggregation runs inside the feature pipeline and not upstream. This is not a small technical detail - it is the single most important choice that separates a scoring model that works from one that pretends to work.
Why raw transactions, not pre-aggregated averages
Casino platforms typically produce pre-computed player statistics - average bet, favourite game, lifetime deposits - available as an API. Nice, convenient, and a trap. Those aggregates are usually computed over the player's full history, including the period the model is supposed to predict. That is future-data leakage. Trained on those features, a model will look brilliant offline and degrade in production, because in production the features are being computed on partial history.
We take raw transactions and let the pipeline compute the aggregates fresh at scoring time, scoped to the exact time window the model was trained on - typically the trailing 7, 14, and 30 days for behavioural features, and the trailing 90 days for lifetime deposit statistics. This is boring engineering work. It is also the reason the model generalises.
Account-type filtering
Real players are not the only things in a casino database. There are test accounts from QA, service accounts from support tools, and bot accounts. Training a model on unfiltered data teaches it that test accounts are real players with strange behaviour. In production, that shows up as noisy predictions for edge-case real players.
We ask the operator for account-type flags before training - real, test, service, bot - and filter aggressively. If the platform does not maintain those flags, the first sprint of the engagement is adding them. The scoring model will not perform without them.
Consent and responsible gaming as a gate
Marketing consent, service consent, self-exclusion, deposit limits, and time-played thresholds are read at scoring time and again at trigger time. A player who self-excluded three days ago must not receive a reactivation bonus, even if the model would rank them as high-value. This is not optional. In regulated markets (MGA, UKGC, regional licences), it is a hard gate. In unregulated markets, it is still what a responsible operator does.
Structurally, we build the responsible-gaming check as a suppression layer between the scored worklist and the outreach queue. The scoring model does not know about consent - it scores every player. The trigger layer filters. This separation matters because it lets the analyst inspect scored players who are suppressed - useful for QA and edge cases.
Model choice: gradient boosting
XGBoost, LightGBM, or CatBoost - the specific choice is less important than the choice to use tabular gradient boosting over neural networks for this problem. Tabular data with under a few million rows and dozens to hundreds of features is the exact terrain where gradient boosting reliably beats neural networks. It trains faster. It is auditable. Its predictions come with SHAP explanations that the retention analyst can read.
The two scores we return per player are churn probability in the next 7 to 30 days, and reactivation probability if the player has already gone silent. These are two separate models. Trying to fit one model to both is a common temptation - it produces a model that predicts nothing very well.
Training details that matter in practice: class imbalance is real - most active players will still be active in seven days, so class balance techniques (weighted loss, focal loss for the extreme cases) are the difference between a model that predicts one class always and one that surfaces real signal. Cross-validation must be time-aware, not random - a random split leaks future information into the training fold. Calibration is essential if the retention team is going to trust the probabilities; a well-ranking but poorly-calibrated model is common with gradient boosting and needs an isotonic or Platt post-fit.
Output: the prioritised worklist
The scoring model produces two numbers per player. That is not yet a product. The product is what happens on top - specifically, the prioritised worklist that flows into the retention team's existing CRM.
A good worklist has four properties. It is sorted by expected value, not raw score - a player with a churn probability of 0.9 and a monthly deposit of $100 is lower priority than a player with a churn probability of 0.5 and a monthly deposit of $10,000. It is grouped by suggested action - hold, reactivate, monitor - because analysts think in actions, not scores. It is explainable - each row shows the top three features that drove the flag, so the analyst can decide whether to trust it. It respects consent - self-excluded and responsible-gaming-flagged players are visible in a separate lane for QA but never in the outreach queue.
We do not decide the bonus, the script, or the channel. The operator decides those. Our layer says who to act on, in what order, and why. This separation is intentional - it is how the retention team stays in the loop rather than being replaced by a black box.
Adapter architecture for self-written platforms
Almost every casino operator we talk to runs a self-written platform. Off-the-shelf retention CRMs assume a standard schema that these platforms do not have. Integration efforts drag on for months and the result still does not understand how the platform actually works.
We build an adapter - one lightweight service that maps the operator's specific schema to a standard feature card. Once the adapter is in place, the scoring layer plugs in on top without any changes to the operator's platform. The operator does not migrate off their own stack.
The adapter is where most of the discovery work happens. Which table has the transactions. Which field means what. Which player states exist. Which currency codes are used and whether amounts are stored in cents or in units. Time zones - are timestamps stored in UTC or in the operator's local. These are the questions that make or break the pilot, and they are boring, and there is no way around them.
The pilot: two phases, not one
We scope every retention engagement as two phases and refuse to bundle them into one price. Phase one is the data audit and the adapter. Phase two is the model and the pilot itself.
Phase one takes two to four weeks. We map the schema, verify account-type flags exist or add them, check consent state, verify time-window correctness in the source data, and confirm that six or more months of clean player history is available. At the end of phase one, we either have a working adapter and a confirmed dataset - or we stop and tell the operator the data is not ready. Both outcomes are honest. Neither is spun as bad news.
Phase two takes another four to eight weeks. We train the two scoring models, run offline evaluation on held-out windows, calibrate the outputs, integrate into the operator's existing retention CRM as a prioritised worklist, and run the pilot in shadow mode for two weeks before the retention team starts acting on the scores. Shadow mode is important - it produces the first evidence that the model's flagged players actually go silent, without any campaign spend.
What does not work
A few patterns we have seen fail on other retention services, mostly because the vendor was selling a product they did not have to engineer.
The patterns that reliably fail:
Segment-level scoring dressed up as per-player - if the score comes from a cohort membership, it is not a per-player decision no matter how the dashboard displays it
Robocalls with hardcoded scripts scripted by the operator - anti-fraud filters kill a large percentage of the calls, and the ones that connect sound like scam calls
Real-time scoring on aggregated features from the platform's own API - the future-data leak we described above, dressed up as low-latency
Bonus recommendation as part of the scoring output - bonus economics are the operator's decision, tied to margin and legal constraints the model does not know about
Anything that markets itself as 'AI retention' with no auditable scoring layer underneath
Cost model that works for the operator
The cost structure of this kind of build has a useful property for operators. The scoring service runs at very low operational cost per player - inference is cheap once trained, retraining is a weekly batch job. The expensive parts of retention - outbound calls, SMS, WhatsApp, incentive spend - sit on the operator's side. The operator pays the telco and the bonuses. We are responsible for scoring quality and worklist ranking.
This alignment matters. When our incentive is scoring accuracy and the operator's incentive is bonus spend efficiency, both sides pull in the same direction. When a vendor's incentive is per-call revenue, the model gets pushed to score more players as at-risk than they actually are.
Where this goes next
Beyond the retention score itself, the same feature card supports downstream work - LTV prediction for affiliate quality assessment (score affiliates on the 90-day value of players they bring, not on registrations), fraud scoring (bonus abuse and multi-account detection), personalised game-mix ranking. Once the adapter is in place and the feature card is populated cleanly, each of these is a new model trained on the same substrate.
The technical work of casino retention is one hundred percent about the substrate - the raw transactions, the account flags, the consent state, the currency and timezone hygiene. Get those right and every model on top of them works. Get them wrong and no amount of sophistication above rescues you.
Running a casino or sportsbook platform and thinking about retention scoring? Book a scoping call - we run a two-phase pilot starting with a data audit. If the data is not ready we tell you and stop rather than push to phase two. See the live pilot at /work/igaming-retention.
Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.
Top comments (0)