Your betting platform knows which players bet in-play, which ones deposit every weekend, and which went quiet three weeks ago. If your push tool treats all of them as one list, none of that knowledge ever reaches the channel that could act on it. Player segmentation closes the gap: it maps what a player actually does — the sports they follow, the bets they build, the deposits they make, how recently they played — onto the audiences your push campaigns send to.
We have already covered why push notification segmentation is now a deliverability requirement for every sender in every industry. That is the general case. This post is the betting and gaming case: the player model itself. The seven dimensions worth tracking, whether each belongs in a segment or an attribute, how to feed the model from your platform without a data project, and the two action-triggered campaigns it powers from week one.
Why player segmentation is not list segmentation
Generic segmentation is built around engagement signals: who clicked recently, who subscribed from which page, who reads on mobile. Useful, and table stakes. But a player carries states no generic model has a column for.
A player has a wallet state: registered but never deposited, low-stakes regular, high-tier VIP. A player has an event calendar: match day reshuffles what is relevant hour by hour. A player belongs to a vertical, and a sportsbook bettor and a slots player on the same site want almost nothing from the same notification. And a player can self-exclude, which turns suppression from a courtesy into an obligation.
The commercial stakes differ too. When a retail subscriber churns, you lose a purchase. When a player churns, a competitor re-acquires them through the same affiliate networks you paid the first time, at full CAC. Your push list is the one owned asset that re-engages a lapsing player at near-zero marginal cost — the retention playbook for betting sites makes that argument in full. Segmentation is how the list earns it.
The player segmentation model: seven player segments that matter
PushEngage gives you two data primitives to build player segments with. Segments are named groups a subscriber joins and leaves — best for interest and lifecycle states. Attributes are key-value fields on the subscriber record — best for dimensions and counters. The next section covers how to choose between them; first, the model.
| Dimension | Type | Example values | What it powers |
|---|---|---|---|
| Sport / league / team | Segmenter | premier-league, nba, tennis, one segment per big club | Match alerts only to followers; a derby sequence goes to both clubs’ segments |
| Bet type | Attribute or segment | live-bettor, pre-match, accumulator, cash-out user | In-play alerts go to live bettors, not the whole book |
| Deposit tier | Attribute | deposit_tier: none / low / mid / high | Offer sizing; suppressing deposit prompts where they do not belong |
| Session recency | Segments (rolling) | active-7d, lapsing-8-20d, dormant-21d+ | The hygiene backbone: who gets full cadence, who gets a win-back, who gets silence |
| VIP tier | Segment + attribute | vip-silver, vip-gold, vip-platinum | Milestone workflows, exclusive offers, higher-touch cadence |
| Game provider / title preference | Segmenter | provider fans, individual slot titles, live-casino | New-game launches and free-spin drops to players who actually play them |
| Vertical | Segmenter | sportsbook, casino, live-casino, lottery, fantasy, esports | The top-level router — most players are not all six |
Two additions. First, opt-in context — the page a player subscribed on, device, language — is captured automatically, so day-one segmentation exists before any behavioral data does. A player who subscribed from a fixture page has already told you their vertical and probably their team; the match-day push sequence shows what to do with that.
Second, one segment is mandatory: self-excluded. When a player self-excludes, an API call moves them into it, every audience excludes it, and their active workflows stop. Hard suppression, fast, is a commercial trust practice — players keep notifications on for operators who respect the off switch.
Segments vs attributes: the rule of thumb
Most dimensions in the table work as either, so the segments vs attributes decision comes up on every row. The rule of thumb: if you want to send to it, make it a segment; if you want to branch or personalize on it, make it an attribute.
“Everyone who follows the home club” is a send-to audience, so it is a segment. Deposit tier is something a workflow branches on (“has this player deposited yet?”) and an offer is sized with, so it is an attribute. VIP status is legitimately both: a segment for VIP-only campaigns, an attribute so a workflow can check tier before picking a message.
Audience groups handle the combinatorics. PushEngage combines segments and attributes with AND/OR/NOT logic, so “live bettors who follow the home club AND were active in the last 7 days” is one saved audience, reusable across every campaign and workflow that needs it.
Here is what makes the segments vs attributes rule pay off later: both sides double as workflow triggers. Joining or leaving a segment is an event that can start a workflow, and so is an attribute update. Build the model once and you have also built your automation trigger map.
Feeding the model from your platform: a thin integration, not a data project
Half the model needs no engineering at all. Page-based signals — a player browsing a fixture page, spending ninety seconds in the live-casino lobby, subscribing from a slots page — populate segments through the SDK automatically.
The other half lives in your backend: deposits, bet settlement, VIP changes, session activity. Those arrive through the PushEngage REST API or SDK as the events happen — an API call updates an attribute or moves a player between segments the moment your platform records the underlying event. Operators typically wire the handful of events that matter (deposit, settlement, eligibility flags) in days. This is a thin integration, not a warehouse project.
Deposit tier: the dimension only your backend can set
No page visit reveals a deposit. Your platform sets deposit_tier at signup and updates it on every deposit event. That single attribute powers offer sizing, the first-deposit workflow below, and a responsible-messaging gate: if your platform can flag loss-chasing patterns, feed that flag in as an attribute too, and every bonus workflow checks it before sending. The deposit tier attribute is the highest-value few lines of integration code you will write this quarter.
Session recency: rolling segments that maintain themselves
Session recency segments — active-7d, lapsing-8-20d, dormant-21d+ — are rolling: membership updates automatically from engagement recency, so nobody rebuilds them weekly. They are the hygiene backbone. Active players get full cadence, lapsing players get a lighter reactivation rhythm, and dormant players exit broadcasts entirely, receiving one short win-back sequence instead. Frequency caps shrink as segments cool.
That last rule is worth real money. Chrome now automatically revokes notification permission from sites showing very low user engagement and high notification volume (announced October 10, 2025). Dormant subscribers who keep receiving your full cadence are the exact profile it removes, silently. Session recency segmentation is how you stop feeding it.
Action-triggered campaigns: the two workflows the model powers
Everything above is plumbing. Action-triggered campaigns are the payoff: sends that fire because one player did one thing, at the moment it matters. Two blueprints earn their place first, because they target the two highest-value moments in any operator’s funnel — the player who registered but never deposited, and the player who started something and walked away. Casino push notifications from first deposit onward walks both through a casino funnel; here is the model-level view.
Blueprint: first-deposit conversion
Runs on the registered segment and the deposit_tier attribute. Build it as an audience-triggered workflow on the Business plan or above; on Growth, trigger it from a registration_completed custom event instead, so timing runs off real funnel events. Quiet hours 00:00–09:00, reschedule.
- Trigger — audience: segment
registeredANDdeposit_tierisnone. - Send — “Your welcome bonus is ready.” The bonus is presented as available, never expiring. No urgency framing on deposit prompts, ever.
- Wait 2 days, then check
deposit_tier. Deposited → end. - Send — clarity, not pressure: how the bonus actually works, terms in plain language.
- Wait 3 days, then check again. Deposited → end.
- Send — product, not bonus: this weekend’s card, the new titles in the lobby. End.
Any change to deposit_tier exits the sequence wherever the player stands; the deposit itself is the exit. Three touches over five days is the ceiling. A non-depositor drip that never ends is precisely the low-engagement, high-volume profile that gets a sender throttled.
Blueprint: continue where you left off
The gaming equivalent of cart abandonment, aimed at the highest-intent audience you have: players who were mid-action minutes ago. Your platform fires a custom event at the abandonment moments it can see — betslip_abandoned, deposit_abandoned, game_session_ended — and custom-event triggers need the Growth plan. Quiet hours 00:00–09:00, skip: a resume nudge nine hours later is noise. The bet-slip version:
- Trigger — custom event
betslip_abandoned. - Wait 45 minutes — inside the intent window, not so fast it feels watched.
- Check — has
last_bet_atupdated since the event? Yes → end; the player finished on their own. - Send — “Your slip is still ready. Three legs saved — finish it in one tap,” deep-linked straight to the slip. End.
For game_session_ended, personalize on the title the player left. For deposit_abandoned, send one neutral resume push and stop — no bonus sweetener, no countdown. An abandoned deposit is sometimes a player deciding not to deposit, and that decision is respected. Cap the whole family at one resume push per player per day.
The payoff: roughly triple the click-through rate
Betting and gaming sites on PushEngage have sent over 3.5 billion notifications, and the spread inside that data is the whole argument for the model above: the median betting-site sender sees ~2.1% CTR on viewed notifications; the top decile does 6.9% — roughly triple.
Same channel, same vertical, same kind of players. The top decile is not writing better copy. It is sending fewer, more targeted notifications — pushes that land because a player segment or an action trigger said they should.
The 2026 platform rules turn that from an optimization into a requirement. Since January 2026, Chrome scores every sending origin daily on push volume relative to engaged time, and throttles senders it classifies as disruptive. Segmented, triggered sends to recently active players keep that score healthy; blasts to a dormant list erode it. The compliant sending profile and the top-decile sending profile are the same profile — the general-case segmentation post linked in the introduction covers the mechanics.
Start with six player segments, not sixty
The model has seven dimensions; your first build should not. Start with six player segments: the vertical split (sportsbook, casino), two or three big teams or leagues your book actually trades on, session recency, and VIP. Add the deposit-tier attribute and you can run both blueprints above in week one.
Add granularity when a campaign needs it, not before. A segment nobody sends to is maintenance debt: it costs attention, drifts stale, and clutters every audience picker. The test for a new segment is a named campaign waiting to use it.
One subscriber model for web and app push
Nothing in this post is web-only or app-only. The segments, attributes, audience groups, and triggers above form one subscriber model: build it once and both channels inherit it. App push notifications through the iOS, Android, React Native, and Flutter SDKs run from the same dashboard, the same audiences, and the same workflows as your site’s web push.
That matters more for operators than for most senders, because players split across surfaces. Web push reaches the player who never installed your app; app push survives after the browsing session ends. Which channel to lead with, and when you need both, is the subject of web push vs app push for betting and gaming; the app-side setup is covered in push notifications for betting apps.
If you are building the player model now, stand up the six starter segments, wire the deposit-tier attribute, and run the first-deposit workflow before scaling anything else. PushEngage pricing scales with active subscribers — the recency pruning above keeps the bill honest — and every paid plan carries a 14-day money-back guarantee. Player segmentation is the gap between the median sender and the top decile, and it is the cheapest gap in your program to close.
