Churn Prediction in iGaming: Data, Models and Retention Decisions

Suppose a retention manager can review 500 accounts this week. The existing inactivity rule produces 4,000 names. A churn model should improve which 500 get reviewed first. The operator needs a way to check whether it does.

Churn prediction in iGaming uses player history to estimate a defined future disengagement outcome. Putting it to work requires two tests: whether the model improves the selection of accounts for review, and whether the response improves subsequent activity enough to justify its costs.

Define the activity you want to predict

In iGaming, a player can stop using an account without closing it. An absence of activity provides evidence about a period of time; it rarely establishes that the person has left permanently. A churn model needs a measurable event that can later be checked against what happened.

For example, an operator might define the target as no qualifying cash-funded bets during the next 30 days among an agreed population of previously active accounts. That is an illustrative definition. Another use case could concern casino sessions, deposits or a particular product. Each would produce different labels, training examples and operational decisions.

Bet placement, settlement and revenue also need separate treatment. A customer can place several bets, win overall and generate negative GGR for the operator. An unsettled bet can establish participation before its revenue is known. If the question concerns continued play, define that activity directly. If the target concerns a financial result, describe the financial result being forecast.

The account boundary matters too. A casino customer who starts using the sportsbook may have stopped playing casino while remaining active with the operator. A product retention question and a whole-account retention question require different outcomes. Resolve that distinction before interpreting a score or calling a campaign successful.

Define the population at the same time. Recently acquired players, established customers and accounts already inactive for a long period have different histories. Record who receives a score, who falls outside coverage and how insufficient history is handled. An unscored account should remain distinguishable from an account assessed as low risk.

Put the prediction on a timeline

A churn prediction connects information available at one moment with an outcome observed later. The historical observation window, forecast horizon and scoring schedule describe different parts of that process.

For a prediction made on 1 October about the following 30 days, an assessment on 2 October cannot yet establish whether the full outcome occurred. Evaluation must wait for the observation period to mature. The same principle applies when training a model: future labels for historical examples must have become available before those examples can be used in a realistic training process.

A model can assess a reduction in activity before a fixed rule reaches its inactivity threshold. Useful lead time is the interval in which that signal leaves room for an appropriate response. Measure that interval from the data and workflow, rather than assuming it from the forecast horizon.

Updating a forecast each day provides a new assessment of the agreed future period. Treat the scoring schedule, model update policy and CRM processing times as separate implementation choices.

Use player history to understand the change

Elapsed time since the last bet is a useful starting point. A longer history can show whether that gap follows a reduction in active days, shorter visits, a change in deposit frequency or a shift between products. The aim is to assess a pattern using information that will also be available when the model is running.

Frequency and recency need context. Five active days in the past month could represent growth for a previously occasional customer or a sharp reduction for someone active most evenings. Tenure matters because a newly acquired player has had less time to establish a pattern. Acquisition cohorts can differ because they arrived for different products, promotions or events.

Sportsbook data needs particular care around the event calendar. An absence of relevant fixtures can change the opportunity to bet. If calendar information is used, its coverage should match the question: a feed extending only a few days ahead cannot fully describe a 30-day sporting schedule. Calendar effects also need to be tested on later periods, rather than assumed to explain every pause.

Transaction history can add context, but a deposit is not a wager, and a withdrawal is not proof of departure. A failed payment, an unresolved service issue and a voluntary break can produce superficially similar reductions in play. A model may associate these patterns with future inactivity without establishing which explanation applies to an individual account.

Data quality belongs in this discussion. If yesterday’s betting feed is missing, replacing missing values with zero can manufacture an apparent fall in activity across thousands of accounts. Check source completeness before interpreting a change in scores. Keep the time of the underlying events visible alongside the time of the calculation.

Feature selection should reflect the operator’s population and target. Adding every available attribute can introduce noise, unreliable shortcuts or information that arrives too late. The useful question is whether an input improves performance on later, unseen observations and remains dependable in production.

Read the score before choosing a threshold

Before setting a threshold, confirm what the output represents. A high probability of continued activity has the opposite meaning from a high probability of inactivity.

For a hypothetical binary target of at least one qualifying activity during the next 30 days, an estimated probability of 0.80 corresponds to 0.20 for no qualifying activity in that period. The calculation depends on those events being exact complements and the output representing a probability.

Record the event, population, horizon and score direction in the model definition. Compare changes across compatible definitions and versions. A change after a model replacement may have a different interpretation from a change within the same model.

A probability estimate also needs calibration. Broadly, among comparable cases assigned a probability near 0.80, the event should occur about 80% of the time if the model is well calibrated. This is a property evaluated across observations, not certainty about one person. Scikit-learn’s calibration guidance explains how predicted probabilities can be compared with observed frequencies.

Keep the current assessment alongside its history. One deposit or session is evidence that an event occurred. Whether a repeatable activity pattern is returning requires further observation. Avoid turning a single return into a permanent recovered label when the next decision still concerns future behaviour.

Test the model against the rule it would replace

An operator already using an inactivity rule has a baseline. The model should earn its place against that baseline on the same population, outcome period and review capacity. Comparing a large model-selected audience with a much smaller rule-selected audience makes the result difficult to use.

Build the evaluation around information available at each historical prediction time. Train and select the model on earlier data, then assess it on later observations kept out of those decisions. Where future outcome windows overlap, the split also needs to respect when the training labels would actually have become known. A calendar boundary alone does not remove that issue. This applies the general principle behind validation with time-ordered data.

Protect the feature-building process too. A later account status, a payment resolution recorded after the prediction or a future campaign response can make a historical model look unusually accurate. They would have been unavailable to the original decision. Preprocessing and feature selection can also leak information from the evaluation data. Scikit-learn’s guidance on data leakage describes this source of inflated performance estimates.

The following hypothetical comparison returns to the 500-account review capacity. Both methods are evaluated on the same 5,000 eligible accounts. The existing process takes the 500 accounts with the longest inactivity gaps among its 4,000 matches, using a fixed account-ID order to break ties. The model selects its 500 highest-risk accounts from the same eligible population. Both selections use information available at prediction time.

Over the agreed future window, 1,000 accounts meet the inactivity definition. The outcomes reflect the historical contact policy; this is an offline prediction comparison, not a test of a new intervention.

In this example, the model identifies 50 more future inactive accounts within the same review capacity. That is an improvement in selection. None of those 50 accounts has yet been retained because of a new action.

Precision describes how many selected accounts meet the defined outcome. Recall describes how many of all the accounts meeting that outcome were identified. Report both at a threshold or selection size that reflects the intended workflow. Overall accuracy can conceal the problem: predicting continued activity for all 5,000 accounts would be 80% accurate here while identifying none of the future inactive accounts. The standard classification metrics make those distinctions explicit.

Check results across later periods and relevant activity groups. A model that performs well overall may be weak for new customers or an important product population. Report sample sizes and uncertainty. A small apparent improvement should not carry the same weight as a consistent result across several mature observation periods. Our article on precision, ranking and business value develops these evaluation questions further.

Review the account before choosing a response

A risk score gives the reviewer a reason to look. The next step depends on what they find and whether contact is appropriate.

An unresolved payment issue calls for investigation and service recovery. A customer who moved between products may need a different interpretation of their activity. Someone already receiving a relevant communication may need no additional contact. The operator’s existing protection and contact rules apply before a commercial audience is selected, regardless of predicted value.

Expected value can help organise review priorities. Player GGR Prediction addresses a different question from churn risk by estimating a defined future revenue outcome. Combining the two can add context, but it still does not show that an incentive will change behaviour. GGR also needs its own definition and should not be treated as net profit or an available bonus budget.

In two field experiments reported in Retention Futility, Eva Ascarza found that customers at highest churn risk were not necessarily the best targets for a retention intervention. The finding gives operators a reason to test responsiveness instead of treating risk as evidence that an offer will help.

The proposed action should have an owner and a record of what actually happened. Distinguish an account selected for review, an audience sent to a CRM, a journey enrolment and a delivered contact. Each is a different stage. An accepted webhook confirms a handoff at that point; it does not establish every subsequent event.

Measure what the intervention changed

The test of a prediction and the test of a retention action need different comparison groups. A model test set contains observations excluded from model development. A campaign control group receives an agreed alternative to the new action, such as the existing contact policy. Calling both a holdout can hide the difference.

After defining the eligible population, randomly assign comparable accounts to the proposed intervention and its control. Agree the main outcome, follow-up period and relevant costs before seeing results. Required service and player protection processes continue in every group. The experiment concerns the commercial action being evaluated.

If the objective is to improve the entire retention policy, compare the new selection-and-response policy with the existing policy at an agreed resource level. Randomising a message only within a model-selected audience answers a narrower question: whether that message helps that audience. Both designs can be useful, but their conclusions differ.

Measure outcomes for all assigned accounts, including those that never open a message or redeem an offer. Comparing redeemers with non-redeemers selects on behaviour that occurs after assignment. Keep the original evaluation population even when returning players leave a dynamic audience. Microsoft’s experimentation guidance explains why segmentation affected by treatment can distort interpretation. Our player segmentation guide applies this issue to retention audiences.

Report the difference in qualifying activity alongside contribution per assigned account. Define which revenue and costs enter that contribution, and deduct each cost once. A higher return rate can be expensive if the intervention funds activity that would otherwise have happened, shifts it forward from a later period or costs more than the additional contribution it produces.

Allow enough follow-up for the result being claimed. A single qualifying session can satisfy a short-term activity target while leaving longer-term retention unresolved. Show uncertainty around the estimate, especially where a few large betting results dominate revenue. A positive point estimate from a small test is a reason to investigate further, rather than a guaranteed effect for the next audience.

With suitable experimental data, uplift modelling can address differences in the incremental effect of an action. That is a separate modelling problem from forecasting inactivity. A churn score on its own does not identify who will benefit from a particular offer.

How Gamblitude makes the prediction available

Gamblitude’s Predictive Models are built individually using the operator’s historical data. For churn, that means agreeing the target and population, selecting relevant attributes and evaluating the result for the intended use.

The Player Churn Prediction configuration described on our product page covers sportsbook activity over a 30-day horizon, with daily scoring for eligible players. The current assessment and changes between assessments can be used in player Attributes, Segments and analysis. The qualifying activity and outcome remain part of the model definition agreed for the operation.

A practical implementation uses those outputs to define a review condition, adds relevant player context and applies the operator’s eligibility rules. An existing VIP relationship can route review to the responsible manager, while other eligible accounts enter an agreed CRM process. The response and its measurement are configured around that process.

The Business Intelligence Platform supports Segments and configured webhook delivery to a connected CRM. Its documented dynamic Segment refresh runs on a 24-hour schedule. Model scoring, membership recalculation and CRM processing each have their own timing, which should be checked for the intended use.

To measure what happened afterwards, link assignment, contact, activity and cost records to the original evaluation population.

Keep checking the data and the result

Deployment introduces two monitoring schedules. Source completeness and scoring coverage can be checked as data arrives. Prediction quality needs later outcomes, so a model forecasting a 30-day period requires mature observations before those forecasts can be fully assessed.

Watch for changes in the distribution of scores, the number of eligible accounts and the share with missing or stale inputs. Then compare mature predictions with actual outcomes and the existing baseline. A new acquisition source, product change or seasonal shift may alter performance even when the technical process runs without errors.

Retraining should be evaluated against the version already in use. Newer data alone does not establish that a replacement is better. Preserve enough information to compare versions and explain changes in the review population. Review the contact policy separately, because a model can continue predicting well while the response becomes less effective or more expensive.

Start with a decision you can evaluate

Start with one inactivity rule and the action it triggers. Compare its selection with the model at the same review capacity, then test the response against the current policy. That gives the first implementation two results to establish: better prioritisation and a worthwhile change in player outcomes.

Bring us your inactivity rule and the audience it produces. We can discuss where Player Churn Prediction would change the decision and what evidence would establish whether the change worked.