Per-player Scoring Architecture for Online Casino Operators (2026)

This is the architecture guide for building a per-player scoring system in an online casino. It is the more technical companion to our retention playbook and it assumes you have decided that per-player scoring is the right lever for your operator. If you are still evaluating that decision, the retention playbook covers the strategic case.

The architecture we describe here is the one we have shipped for a European online casino operator and refined across the discovery conversations that led to it. Different operators run different platforms. The specific tables, field names, and services will differ. The structure is portable.

The system has five layers. Source data at the bottom, the adapter that reads from source, the feature pipeline that computes per-player features, the scoring layer that produces churn and reactivation probabilities, and the delivery layer that pushes scored worklists into the retention team's CRM.

Each layer has a clean interface with the layer above and below. The scoring layer does not know how the features were computed. The delivery layer does not know which model produced the scores. This separation is what lets you replace pieces independently - swap in a different model, add a new feature source, change the CRM - without rewriting the whole system.

Four categories of source data feed the system. Player master data - the identity of each player, geo, registration source, account type, consent state. Transactional history - deposits, withdrawals, bonuses granted and redeemed, timestamped and denominated in a base currency. Session history - login timestamps, session length, device, IP where privacy allows. Game event history - which games were played, bet sizes, win/loss outcomes, timestamps.

Every casino platform stores some form of these. The names of the tables, the field types, and the way currencies and timezones are represented vary wildly. The first job of the adapter layer is to normalise these into a standard shape without changing anything in the operator's platform.

The adapter is one or more lightweight services that read from the operator's source database or API and produce records in a standard schema. We build it as a set of ETL jobs that run on a schedule - typically hourly for player master data, hourly to daily for transactions depending on scoring cadence needs. Each ETL job has a defined output schema and defined tolerances for late-arriving data.

The critical design decision here is idempotency. Every ETL job must produce the same output for the same input data regardless of how many times it runs. This is what lets us run the pipeline continuously without accidentally double-counting transactions or missing session records because of a network blip during ingestion.

For self-written platforms - which is most casino operators - the adapter is where 30-50% of the initial engagement effort goes. It is unglamorous work. It is also the single highest-leverage part of the build, because everything above depends on the adapter producing clean, correct, timely records.

The feature pipeline turns the adapter's normalised records into a per-player feature card. One row per player, wide, with features scoped to specific prediction windows. Trailing 7-day and 30-day behavioural features. Trailing 90-day lifetime deposit and outcome features. Point-in-time flags for account type, consent state, and responsible-gaming markers.

The scoping is the important part. Every feature has a defined time window relative to the scoring moment. If the model predicts churn in the next 14 days, the features must be computed on data available up to the scoring moment - never on data that includes the prediction window. This sounds obvious. It is violated constantly in production ML systems, and the resulting future-data leakage produces models that look brilliant offline and degrade in production.

The pipeline is a set of SQL queries or Spark jobs, depending on data volume. For most operators, SQL on Postgres or ClickHouse handles the volume up to tens of millions of transactions per day. Above that, or if the operator already runs a data warehouse, Spark on the warehouse is the natural fit. The specific engine matters less than the schema of the resulting feature card.

The scoring layer takes the feature card and produces two probabilities per player - churn in the next N days, and reactivation probability if the player has already gone silent for M days. These are two separate models. Trying to fit one model to both is a common temptation - it produces a model that predicts neither well.

The model we default to is gradient boosting - XGBoost, LightGBM, or CatBoost depending on the specific data characteristics. Gradient boosting on tabular data with dozens to hundreds of features and up to a few million rows reliably beats neural networks on this class of problem. The training is faster. The predictions come with SHAP explanations that the retention analyst can read. The model is smaller and faster at inference time.

The training pipeline includes time-aware cross-validation, class imbalance handling (weighted loss or focal loss depending on how extreme the imbalance is), and calibration as a post-fit step. Uncalibrated gradient boosting models rank well but produce probabilities that do not correspond to real risk. If your retention team is going to trust the probabilities as probabilities, calibration is not optional.

The scored feature card is not yet a product. The product is the prioritised worklist that flows into the retention team's existing CRM.

A useful worklist has four properties. It is sorted by expected value, not raw score - a player with high churn probability and low deposit history is lower priority than a player with modest churn probability and high deposit history. It is grouped by suggested action - hold, reactivate, monitor - because analysts think in actions. It is explainable - each row shows the top three feature drivers so the analyst can decide whether to trust the flag. It respects consent - self-excluded and responsible-gaming-flagged players appear in a separate lane for QA but never in the outreach queue.

The delivery layer pushes the worklist into the CRM either via API or through a database write. It runs at the scoring cadence - typically hourly for VIP scoring, daily for mass-market. The retention analyst opens their CRM as usual and sees the enriched worklist instead of the flat player list they had before.

Self-exclusion, deposit-limit, time-played, and other responsible-gaming flags are read at both scoring time and at trigger time. A player who self-excluded three days ago is scored (the analyst may need visibility on them for internal purposes) but is never surfaced in the outreach worklist. Any retention trigger that fires after the scoring must check RG state again immediately before executing, because state can change between scoring and action.

This structure - scoring is unrestricted, action is gated - lets the model produce a complete picture while the delivery layer enforces the constraint. It is separated so it can be audited independently, which is what the compliance team will ask for.

Player behaviour drifts. Churn and reactivation patterns shift with product changes, market changes, and player mix changes. A model trained six months ago on a different player mix will silently degrade in production. Weekly retraining on rolling 90-day windows is a reasonable default. Monthly is the maximum before drift becomes visible.

The retraining pipeline reuses the same feature pipeline that produced the scoring features - if it does not, you have introduced a divergence between training features and production features that will produce silent bugs. Model versioning and drift monitoring belong in the same infrastructure that runs scoring.

A realistic first deployment for a mid-size operator takes six to twelve weeks depending on the state of the source data and how self-written the platform is. Weeks one to three cover the adapter build and data audit. Weeks four to six cover the feature pipeline and first model training. Weeks seven to eight run offline evaluation and calibration. Weeks nine and ten integrate with the retention CRM in shadow mode. Weeks eleven and twelve run the pilot on real analyst worklists with a subset of the player base before opening up to the full base.

That is the substantial version. A minimum viable version that produces useful scored worklists on a subset of players can ship in as little as three weeks if the data is very clean. That is rare. Plan for the substantial version and celebrate if you finish faster.