Six families, one discipline
An iGaming data platform does not need hundreds of event types; it needs six families captured completely and consistently:
| Family | Covers | The capture mistake that hurts most |
|---|---|---|
| Identity | Registration, verification-state transitions, account status | Recording the current state instead of the transition — history becomes unreconstructable |
| Wallet | Deposits, withdrawals, adjustments — every balance movement with its reason | Movements without a typed reason code; "adjustment" as a catch-all |
| Gameplay | Bet placed → settled/voided/cashed-out, at selection level | Capturing only settlements — open liability becomes invisible |
| Bonus | Granted, wagering progress, converted, expired, forfeited | Skipping progress events — the liability curve between grant and outcome is lost |
| Session | Login, device, locale, entry context | Sessions synthesised downstream from gaps, differently per consumer |
| Protection | Limits, cool-offs, exclusions, interventions | Stored only in the operational tool, invisible to analytics and audit |
The last row is the one most operations discover late: protection events are as analytically important as revenue events, and regulators treat their completeness as non-negotiable.
The contracts that make the schema trustworthy
- Append-only, corrections as events. Nothing is edited in place; a void, a reversal, a re-settlement is a new event referencing its predecessor. This single rule is what makes "what did we know on that date" answerable — the property audits and disputes turn on.
- Idempotency by construction. Producer-assigned event IDs, defined deduplication windows, replay-safe consumers. Retries happen; double-counting must not.
- Two clocks minimum. Event time and processing time on every record, settlement time where it exists. Which clock a metric uses is a dictionary decision; carrying both is what makes the decision available.
- One player key. Immutable, internal, mapped to brand- and product-level identifiers. Everything cross-product — cross-sell measurement, exclusion enforcement, cohorts — joins through it.
- Money as integers in minor units, with currency. Floating-point money and implied currencies are the two schema decisions that are cheapest on day one and most expensive to repair.
- Schema changes are versioned and additive. New fields are optional; renames are new fields plus a deprecation window. A breaking change to a live event stream re-states history for every consumer at once.
The bet lifecycle, specifically
Gameplay is where grain decisions bite. Three rules prevent the classic distortions:
- Selection-level attribution. A multi-leg ticket carries stake and outcome per selection, or cross-product and per-market analysis silently misattributes margin. (The same rule that made the personalization case study measurable.)
- Open bets are first-class. Placed-but-unsettled is a state the schema represents, not an absence — open liability is a risk number someone reads every day.
- Settlement references placement. The settlement event carries the placement ID, never a recomputed join key. Reconciliation between the two streams is a daily check, not an annual project.
What consumers get to rely on
The schema is a contract with three downstream customers, and it is worth writing their guarantees explicitly: the warehouse relies on ordering, idempotency and the two clocks; regulatory reporting relies on completeness and append-only history; operational tools (CRM, risk, RG) rely on latency and typed reason codes. When a schema decision is contested, resolving it in favour of the strictest consumer — usually the regulatory one — is almost always the cheap path, because the strict consumer's requirements cannot be retrofitted.
Continue reading: Warehouse design — where these events become answers. The Turbo Stars platform — the stack these contracts run on.