Retention and responsible gaming do not have to pull against each other, if you build the second as a hard gate on the first. Score every player if you wish, but keep self-excluded players and those flagged for responsible gaming out of the outreach queue, and check that status twice: when you score and again when you send. I am not a lawyer and the rules differ by licence and country, so treat this as an engineering pattern to discuss with your compliance team, not as legal advice.
Why is this an engineering question and not only a policy?
Because policies fail at the seams between systems. A scoring model sees a high-value player who has gone quiet and ranks them near the top. A campaign tool picks up the list and sends. Unless something in between knows that the player self-excluded three days ago, a reactivation bonus goes to a person who asked not to be contacted.
That is not a hypothetical edge case. It is what happens when the list is built on one day and sent on another, and the state of the player changes in between. The fix is structural: a gate that cannot be skipped.
It also helps to remember who is on the other end. A reactivation message that reaches someone who has just asked for a break is a failure of care as well as of process, and no uplift in turnover justifies it. Building the gate first, before any forecast is used for sending, keeps that order of priorities clear for everyone on the team.
What does it mean to score everyone but act selectively?
It means separating two jobs. The scoring layer produces a complete picture of every player and does not care about consent. The delivery layer decides who may actually be contacted. The same pattern appears in the engineering write-ups on per-player scoring architecture: scoring is unrestricted, action is gated.
There are two reasons to keep them apart. First, an analyst can inspect suppressed players for quality checks, such as asking why a self-excluded player scored as high risk. Second, the gate can be audited on its own, which is what a compliance team will ask to see.
Which statuses should block outreach?
At minimum:
- Self-exclusion.
- Responsible gaming flags raised by your team or your systems.
- Deposit limits or time-played thresholds that your policy treats as a reason to stop promotion.
- Missing or withdrawn consent for the channel in question.
Your licence and local law may add more. List them with your compliance team and write them into the gate as rules, not as a note in a wiki. In a regulated market this is a hard requirement. In a less regulated one it is still what a responsible operator does.
Why check twice?
Because time passes between scoring and sending. The check at scoring time keeps blocked players out of the worklist. The check at send time catches anyone whose status changed after the list was built. Doing only the first leaves a window. Doing only the second hides suppressed players from analysts who need to see them.
I would add a log of every blocked contact and the reason. When someone asks why a player was or was not contacted, you can answer from the record.
Can a retention model make gambling harm worse?
It can, if you let it. A model that finds players likely to leave and pushes them to play more could target exactly the wrong behaviour. That is why value must never override a safeguard, and why I would not tune a model on turnover alone without a responsible gaming screen on the outputs.
I do not claim our system solves this by itself. What we do is keep scoring separate from sending, keep a person in the loop on every send (the system suggests, your team decides and sends), and leave the rules about who may be contacted to you. If you see a pattern in your data that worries you, such as sharply rising deposits from a single player, that is a case for your responsible gaming team, not a retention campaign.
What should you ask a vendor?
- Where in the flow is responsible gaming status checked, and how often?
- Is the check done at send time as well as at scoring time?
- Can suppressed players be inspected separately?
- Does anything send without a person approving it?
- What is logged, and for how long?
- Where is the data stored, and is it separate from other clients?
At Sellrise, nothing goes out on its own: automatic scenarios are switched on only by your decision, after the pilot. Each client has a separate database, and retention and deletion terms are agreed before the start.
Does this reduce the benefit of retention work?
Slightly, in the sense that you contact fewer players. In the sense that matters, no. Players who asked not to be contacted were not a source of sustainable revenue, and contacting them creates regulatory and reputational risk. Your control group test should exclude them from every arm, so the comparison is fair. See how to run a control group test.
For the practical side of winning players back while respecting these limits, read how to win back lapsed casino players.
Where do you start?
Map the statuses in your platform and where each lives. Write the gate rules. Put the gate between the list and the send, and add a second check at send time. Review the log monthly with compliance. If you are choosing software, test the gate before the forecasts. The page on player retention gives the overview and a pilot is a safe way to check how it behaves on your data.