Business value
This page is for investors and advisors. It explains the problem PlayerPal is built for, why its approach works for every party in the network, and what exists today. It contains no pricing, market sizing or traction figures.
The problem
In online gaming, loyalty stops at the edge of each casino. A player who plays at several operators, and plays one studio's games at all of them, has a separate, short-lived relationship with each. Points do not travel, and no party sees the player's wider behaviour.
Sharing data across companies is the obvious fix, and the reason it does not happen. Operators will not hand competitors or a new intermediary a copy of their player database. Studios serve many casinos and must not be able to track players across them. Any network that pools personal data takes on that risk for everyone in it.
The approach
PlayerPal is a loyalty and analytics layer that sits beside casinos and studios rather than in front of them.
ONE PRIVATE PLAYER IDENTITY
MANY AUDIENCE-SPECIFIC ALIASES
NO PLAYER EMAIL, NAME OR PHONE
- One Account, many Aliases. The player holds one PlayerPal Account. Each Operator, and each provider-casino pair, receives its own random Alias for that player. No two parties can match players by comparing identifiers.
- No personal data. PlayerPal never receives a player's email, name or telephone number. Sign-in uses passkeys and similar methods.
- Off the game path. Casinos and studios keep running if PlayerPal is unavailable. Activity arrives in batches after the fact.
- Partners report facts, PlayerPal calculates. Points and KPIs are computed centrally from reported Activity, so they are consistent across the network.
Value for each party
| Party | What they get | Status |
|---|---|---|
| Player | One Account that earns Points across casinos and games, with control over each connection | Available |
| Operator | Analytics on linked players and an anonymous view of how they compare with the network | Available |
| Game provider | Studio analytics across all its casinos, counted per Account, without cross-casino tracking | Available |
| Affiliate | Overview built on operator-reported attribution | In development |
| Reward partner | A place in the shop and redemption flow | Planned |
Spending Points on rewards is Planned; earning is Available. See Capabilities for the full list.
Network effects
Each new party adds value for the others:
- Players get more places to earn as more operators and studios join.
- Operators get a more meaningful comparison. Network figures become available in more markets once there are enough peers to keep them anonymous.
- Game providers see the share of a player's turnover that their games capture across the casinos they serve.
- Reward partners, once live, reach players from every casino in the network through one integration.
Comparisons are suppressed in thin markets by design. Early on, partners will mostly see global figures, and market-level detail grows with the network.
Why privacy-first identity matters
Without personal data, the main reason a partner would refuse to join disappears: PlayerPal cannot become a leak of their player base, and cannot be used by a competitor to identify their players. It also limits what a breach of PlayerPal could expose. Players can Unlink a casino or delete their Account themselves, without asking each partner.
Defensibility from the design
| Design choice | Why it matters |
|---|---|
| Random pairwise Aliases per Audience | Unlinkable identifiers have to be designed in from the start; adding them later means re-issuing every partner's identifiers |
| Provider Aliases scoped to each casino | Gives studios analytics that operators can accept, because cross-casino tracking is impossible |
| Anonymous comparison with floors and dominance rules | Partners see how they compare without learning anything about a named competitor |
| Asynchronous sidecar | Integration does not touch the wallet, launch or settlement path, so partners can adopt it with low risk |
The value of the comparisons grows with the number of participating parties, which a new entrant would have to rebuild.
Current stage
"Available" means built and tested in the platform; it is not a statement about live partner traffic.
| Area | Status |
|---|---|
| Player Account, sign-in without personal data, passkeys | Available |
| Linking, pairwise Aliases, Unlink and Delete Account | Available |
| Activity ingest and Points earning | Available |
| Partner KPIs, network comparison, peer benchmarks | Available |
| Embeddable widget | Available |
| Per-partner credentials on every partner route | In development |
| Partner and staff portals with production sign-in | In development |
| Reward shop | In development |
| Points redemption in the platform API | Planned |
| Reward partner integration | Planned |
| Workforce single sign-on | Planned |