Churn Prevention Documentation

Use Case Description

A Churn Prevention journey supports players who have been active but are becoming less likely to return. It uses a churn score from the Churn Classification model, which runs in Infinity AI, Xtremepush's machine learning product. The model estimates each active player's probability of stopping betting within a set window, and you use the score in a journey. The journey runs on a schedule, picks up players above a risk threshold who haven't deposited or logged in recently, and caters for each player's value tier. Players whose score passes the threshold for their tier receive a timely, relevant message on their preferred channel, with an optional reward.

To take full advantage of the Churn Prevention Journey, please review the technical requirements.

Deploying Your Use Case

Understanding The Flow

The Churn Classification model scores every active player with a churn_score between 0 and 1. Higher means more likely to stop betting, which the model defines as ceasing to place bets within a set window (14 days in the example). The score is written to the player's profile and refreshed daily or weekly. The journey uses that score, together with the player's value tier, to decide who receives a message and what it contains. The screenshot below shows one example of how a Churn Prevention journey can be built. Your own can differ in tiers, thresholds, channels and number of steps.

Unlike Welcome Journey and Deposit No Bet, this journey isn't triggered by an event. Disengagement is the absence of activity, so players enter from a segment that is evaluated on a schedule.

In the example, players are split by value tier, and players with negative value are excluded. Each eligible tier has its own 14-day churn-score threshold: 75% for low, 60% for medium and 50% for high. Players below their threshold leave the journey as not eligible. In the medium and high tiers, a reward is credited first, and the high tier also alerts your team through a Slack webhook when the bonus is credited. The low tier goes straight to an email message. A preferred-channel check then sends an email, push or SMS, with email as the default.

Each run re-evaluates the segment, so a player who stays at risk could enter again. Set a re-entry cooldown, and use Engagement Categories to cap how often messages are sent. Every path must finish at an endpoint.

Adjusting the Use Case

The Churn Prevention journey can be adapted to your player base, retention strategy and risk appetite. Key areas to consider:

Below are some key optimisation areas:

Entry and Run Frequency

• Choose how often the journey runs. Players are picked up at the next run after they match the segment. With a 10-day inactivity period, a monthly run contacts players 10 to 40 days into their inactivity, a weekly run 10 to 17 days, and a daily run 10 to 11 days. Weekly is a sensible start. Don't run more often than the score refreshes.

• Set the inactivity period to suit how your players actually play. A weekly bettor isn't lapsing after a quiet Tuesday, and off-season gaps are normal.

• Set a re-entry cooldown and cap how many messages a player receives. Set rules in Engagement Categories.

Content Personalisation

• Use dynamic fields such as first_name.

• Use content that suits the player's usual product, such as this weekend's fixtures in their favourite sport or new casino games.

• Send on the player's preferred channel, with a default for players without one. Players who haven't opted in to a channel won't receive it.

Rewards (optional)

• The example credits a free bet or bonus money before the message.

• Rewards need an integration with your bonus or wallet system.

• If you send webhooks to Slack or another tool, include only the data your team needs.

Regulatory compliance

• Include the responsible gaming messaging and terms your licence requires in every message. Requirements vary by jurisdiction, so check with your compliance team.

• Include an unsubscribe route in every email. Consent Manager is an optional feature, enabled on request. See Managing User Consent. If you don't use it, make sure channel marketing permission is held elsewhere in your project.

• Make sure self-excluded, blocked and bonus-abuse-flagged players do not enter the journey, using entry criteria or your project's global include conditions.

Use Case Requirements

The Churn Prevention Journey is a critical retention automation for any operator. Before deploying this use case, ensure your data infrastructure supports the technical requirements outlined below. This use case relies on the churn score, recent activity, profile attributes and the events behind them. If you build a different journey from the example, your requirements may differ.

The following tables specify which  data and profile attributes are required, recommended, or optional for optimal performance. A strong data foundation is the difference between a high-performing automated journey and one that underdelivers on its potential.

Profile Attributes

Learn more about managing attributes in Managing Project Data.

Rule-based option (computed attributes)

If the model isn't live yet, or you prefer inactivity rules, use the same segment without the churn score. Add bet recency to the login and deposit conditions, and define "at risk" relative to each player's usual pattern. See Creating Computed Attributes.

L7D, L14D and L30D mean the last 7, 14 and 30 days.

Optimising Your Churn Prevention Journey for Maximum Retention

Many players flagged as at risk would have returned anyway, so measure what the journey adds. Keep improving it with your own performance data.

Measure

• Track the share of messaged players who return to bet within 7 and 14 days, and the time to return.

• If you use rewards, track reward cost per returning player.

• Watch unsubscribe rate and message engagement.

• Keep a control group so you can see the difference against players who weren't messaged.

Test one variable at a time

• Compare score thresholds and inactivity periods.

• Compare run frequencies.

• Compare content-only messages against messages with a reward.

• Compare channels and send times.

• Run these with decision branches.