Skip to main content
InternalMarkdown

ADR 0009. Mandatory One-Time Link Before Any Data Reaches PlayerPal

Status​

Accepted.

Link mechanics (signed assertion, PlayerPal-hosted popup, result-code exchange) are ADR 0017. Product policy in spec §33 confirms no pre-registration shadow profiles and no historical points by default.

Context​

A PlayerPal identity must not come into existence purely from passive first-contact, i.e. the player never acting, never seeing PlayerPal, data simply starting to flow. Two problems rule that out:

  1. PlayerPal is a standalone product in its own right, not invisible infrastructure fully hidden behind whichever party integrates it (operator or provider). A player should be aware they have a relationship with it.
  2. Also, there was no point at which the player had agreed to anything from PlayerPal, or even been told PlayerPal exists. Data about them was being transmitted to and processed by a third party with zero touchpoint. That is not a defensible legal-basis story, and it doesn't match the intended product positioning either.

Decision​

No activity data for a given player is transmitted to or processed by PlayerPal until that player has registered or linked at least once. This is a one-time, per-(player, audience) action, not a per-session login. Concretely:

  • A party_identifier row (and any associated identity/ledger state) is created only at the point this one-time link/registration completes, not at "first exposure" as earlier phrasing in §2.3a implied.
  • Before that link exists, PlayerPal has no record of the player and processes nothing for them; that activity stays entirely inside the audience's (operator's or provider's) own systems.
  • After the one-time link, subsequent earning is automatic. The player does not need to log into PlayerPal again on every visit or every event. The friction goal from the original requirement is preserved at the session/event level; it just no longer extends to eliminating the touchpoint entirely.
  • This one-time action is also the natural place to satisfy a lawful basis for processing (consent/notice specific to PlayerPal). The mechanics of what that touchpoint actually shows and who presents it (the integrating party's own UI vs. a PlayerPal-hosted widget) are still open, see docs/open-questions.md.

Linking establishes one (player, audience) relationship; it does not by itself unify relationships across different audiences. A player could in principle be linked independently at several operators and/or providers, whichever parties integrate PlayerPal directly, without ever unifying them. Whether and how a later link joins an existing account instead of creating a new one is decided in ADR 0010.

Consequences​

  • §1's non-negotiable requirement is reworded: earning requires no repeated login, not no touchpoint at all.
  • §2.3a's "generated at first exposure to that audience" is corrected to "generated at the point the one-time link completes."
  • §2.4's "a loyalty identity can exist before any explicit sign-up" is no longer accurate and is removed.
  • §4 (ingestion) gains an implicit precondition: an event for a (player, audience) pair that has never linked has nowhere to be attributed and is out of scope for PlayerPal. It is the integrating party's (operator's or provider's) event, not PlayerPal's, until linked.
  • New open question: the concrete UX/consent mechanics of the one-time link flow (surface, content, timing, who presents it) are undefined.