Six stages, defined by what the data actually shows
Each stage below is defined by an observable change in behaviour, not by intuition or a uniform day-count applied across the whole base. Every stage carries the same four questions: how it is actually defined, which CRM lever applies, what to measure, and the mistake most commonly made there.
Registration to first deposit
- How the stage is defined
- The stage ends at the first successful deposit-to-play event, not at account creation. An account with no deposit carries no play data to design CRM against, so the meaningful boundary is the first monetary event, not the moment a form was submitted.
- The CRM lever
- Friction removal inside compliance limits. KYC is usually run as a risk-owned compliance workflow, but every verification step sitting between registration and the ability to deposit is also a conversion event with its own measurable drop-off — CRM should have a say in which checks happen before first deposit and which can happen after, not just in what happens once a player has already converted. Sequencing, not skipping, is the lever: the compliance requirement itself does not move, only where it sits in the funnel.
- What to measure
- Registration-to-first-deposit conversion rate, time-to-first-deposit, and the drop-off attributable to each individual KYC step in the funnel, rather than one lumped "registration abandonment" figure that hides which step is actually losing accounts.
- The common mistake
- Treating KYC as someone else’s problem. A CRM team that only starts measuring once a player has deposited has already lost visibility over the point where the largest share of registered accounts are typically lost.
Early life and onboarding
- How the stage is defined
- From first deposit through the point session frequency and stake size stop moving and start repeating. This pillar treats the first 30 days after first deposit as the working early-life window — a real behavioural boundary to test against, not a fixed number chosen for its own sake.
- The CRM lever
- Welcome-journey design and early-life bonus offers — but the offer itself is a bonus-economics decision before it is a goodwill gesture. The same wagering-basis and grind-ratio math that prices a reactivation offer prices a welcome offer, and a team that skips that pricing step usually discovers the cost later, once it already shows up in acquisition economics.
- What to measure
- Deposit frequency across the first 30 days, the share of first deposits that see a second deposit, and time from first deposit to first bonus claim.
- The common mistake
- Shipping a generically generous welcome offer without pricing what it actually costs to convert — see the required-turnover and grind-ratio math in bonus conversion math.
Established and active
- How the stage is defined
- Frequency and value have stabilised into a recognisable, repeatable pattern. A player is established once behaviour is predictable enough to build a segment around, not simply because a fixed number of days have passed since first deposit.
- The CRM lever
- Segmentation as the operating unit, not one blanket journey for the whole established base. Frequency and value are two separate axes — a high-frequency, low-stake player and a low-frequency, high-stake player can sit at the same revenue contribution and still need different treatment, and collapsing them into one segment is the most common design error at this stage.
- What to measure
- Frequency and value distributions by segment, segment migration rate over time, and offer response measured against a held-out control group, not against uplift assumed from an offer’s face value. A segment with no control group has no honest way to separate the offer’s effect from what those players would have done anyway.
- The common mistake
- Building segments once and never re-measuring them. A segmentation model is a working hypothesis, not a fixed classification, and it degrades as player behaviour and the product mix underneath it both change. The practical mechanics of building and maintaining that model are covered in CRM segmentation for online casino.
At-risk
- How the stage is defined
- A decline in frequency or value measured against that specific player’s own established baseline, not an absolute threshold applied uniformly across the base. A player whose normal cadence is once a month is not at-risk on day 14 the way a daily player is.
- The CRM lever
- Early, targeted intervention before a decline compounds into churn — priced with the same bonus-economics discipline as any other offer. An at-risk offer built with a grind ratio above one is not going to retain the player it is aimed at, on average, no matter how urgent the trigger that sent it.
- What to measure
- Rate of decline relative to individual baseline, the lead time between the first detectable decline and eventual lapse, and intervention response rate measured against a control group.
- The common mistake
- Applying one absolute inactivity threshold to the entire base. A uniform trigger either fires constantly on naturally low-frequency players or misses the early signal on high-frequency ones entirely — a baseline-relative definition is what actually generalises across a mixed player base.
Lapsed and churned
- How the stage is defined
- Explicit, per-vertical definitions, because casino and sportsbook do not share a seasonality pattern. A sportsbook player who deposits only during a major fixture window is not lapsed in the gaps between fixtures the way a casino player with the same gap almost always is.
- The CRM lever
- Getting the definition right before anything downstream is built on it. A definition set too aggressively burns reactivation budget on players who were never actually gone; one set too conservatively leaves genuinely lost players untouched for too long to reactivate economically.
- What to measure
- Time-to-lapse by vertical and by segment, and the share of players classified as lapsed under the current definition who return without any intervention at all — a high natural-return rate is the signal that the definition is too aggressive. Tracking that return rate over time also shows whether a fixture calendar has shifted the naturally-quiet windows without anyone updating the definition to match.
- The common mistake
- Importing a casino churn window into sportsbook unchanged, or the reverse. Fixture calendars make sportsbook activity naturally cyclical in a way casino play is not, so a between-fixtures gap treated as churn wastes budget reactivating players who were always going to come back on their own. See sportsbook CRM consulting.
Reactivation
- How the stage is defined
- Begins the moment a lapsed player re-engages with an offer or a journey, and ends the same way early life does — a second stabilisation of behaviour, this time following a gap rather than a first deposit.
- The CRM lever
- Bonus economics again, and priced by exactly the same grind-ratio and wagering-basis math as every other offer in this pillar. An offer with a grind ratio above one reactivates almost nobody profitably, no matter how generous its headline percentage looks — the full mechanics are in
- What to measure
- Reactivation rate against whatever definition classified the player as lapsed, redeposit-to-second-deposit conversion after reactivation, and bonus cost per successfully reactivated player, not per offer sent.
- The common mistake
- Measuring a reactivation campaign by offer uptake rather than by whether the player’s behaviour actually re-stabilises. A player who takes a reactivation bonus, plays it through, and never returns has not been reactivated — they have simply been given one more bonus. bonus conversion math.
VIP is a tier, not a stage
Every stage above can contain a VIP player. A player can reach a high-value tier during early life, stay in it through established play, decline into at-risk status, lapse, and get reactivated — VIP status describes where a player sits on a value axis, and the six stages describe where they sit on a time axis. Treating VIP as a seventh stage after reactivation is a common modelling mistake, because it implies every player eventually graduates into VIP, when in reality a player can enter a high-value tier from any stage in the sequence and can also leave it without lapsing at all.
The practical consequence for CRM design is that a VIP tier needs its own segmentation logic layered across the stage model, not a separate journey bolted on at the end of it. An at-risk VIP player and an at-risk non-VIP player are both, by definition, showing a decline against their own baseline — but the intervention budget and the acceptable grind ratio on an offer aimed at each of them are not the same decision, and collapsing both into one at-risk journey loses exactly the distinction the tier exists to capture.
The same reasoning applies going the other way: a segmentation model built at the established stage that only scores frequency and value, with no tier flag layered on top, will happily group a high-value VIP with a merely frequent non-VIP player if their raw numbers happen to land close together. The tier exists precisely to stop that from happening — it is metadata the segmentation model needs as an input, not an output the segmentation model produces on its own.
One lifecycle, two verticals
The six stages above describe the same lifecycle shape for casino and sportsbook players, but the definitions inside each stage are not interchangeable between the two. Casino play has no external calendar forcing activity into windows — a gap in deposits is a gap in interest. Sportsbook play is structured around a fixture calendar the operator does not control: a player who deposits heavily around a major event and goes quiet between fixtures is behaving normally for that vertical, not showing early signs of lapsing.
That difference has to be built into the at-risk and lapsed definitions directly, not patched on afterwards. A baseline-relative at-risk definition (stage 4, above) already handles part of this — a sportsbook player's own baseline naturally reflects their fixture-driven cadence — but the lapsed definition still needs an explicit, per-vertical threshold, because the length of a normal between-fixtures gap varies by sport and by season in a way a single sitewide number cannot capture.
Reactivation timing follows the same logic in reverse. A reactivation offer sent to a sportsbook player mid-way through their normal between-fixtures gap is being sent to someone who was never actually lapsed — the offer is wasted regardless of how well it is priced. The same offer timed to land just ahead of the next relevant fixture window is working with the vertical's natural rhythm instead of against it, which is a scheduling decision layered on top of the reactivation stage's own bonus-economics discipline, not a substitute for it.
The stage model is the operating system, not the offer
None of the six stages above are useful in isolation — the value of defining them explicitly, in data, is that early-life onboarding, at-risk intervention and reactivation all draw on the same underlying baseline, the same segmentation logic, and the same bonus-economics discipline, instead of each running as a separate campaign built on its own assumptions. A team that defines “at-risk” one way for one campaign and a slightly different way for another has, in effect, two lifecycle models running at once, and neither one is fully trustworthy — the definitions have to be shared and versioned the way any other piece of production logic is, not re-derived informally each time a new campaign needs one.
Turning that model into a working operating rhythm — the actual baselines, the actual segment definitions, the actual triggers — is what a lifecycle and retention strategy engagement is for.
A note on responsible gambling
Everything in this pillar describes aggregate behaviour — how a base of players moves through stages on average, and which levers move that average. A real player is not an average, and at-risk detection built purely as a revenue-retention signal misses half of what it is actually observing: a meaningful decline in frequency or value against a player's own baseline is exactly the kind of signal affordability and player-protection processes also depend on. Lifecycle and CRM teams that treat at-risk detection as a revenue problem alone, and a separate compliance team that treats affordability as a checklist alone, are both working from the same underlying data without talking to each other — that gap is worth closing before it is worth optimising either process in isolation.