# 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.

```text
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](./capabilities.mdx) 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] |

## Related

  - [Overview](./overview.mdx): 
    What PlayerPal is, in one page.
  
  - [Capabilities](./capabilities.mdx): 
    Status of every capability.
  
  - [Privacy](../trust/privacy.mdx): 
    The commitments behind the design.