iGaming Data Warehouse Design

The layering that works

Names vary by stack; the responsibilities do not. Four layers, each with one job:

Layer	Job	Rule that keeps it honest
Raw / landing	Events exactly as received from the schema	Immutable. Nothing is fixed here — fixes are new events upstream
Conformed core	Deduplicated, identity-resolved, currency-normalised facts at source grain	One player key, minor-unit integers, both clocks preserved
Metric layer	The dictionary implemented as code — one place per metric	Dashboards may not define metrics; they may only display them
Marts	Consumer-shaped views: finance periods, CRM player states, regulatory snapshots	Shapes diverge, definitions do not

The third layer is the one most operations skip, and it is where the recurring disputes come from: when every dashboard computes its own GGR from the core, the organisation has as many definitions as dashboards. Moving the computation into one governed layer is the structural fix — the dictionary made executable.

Grain: decide once, at the bottom

Keep facts at the finest grain the source produces — bet-selection, transaction, event. Every aggregate is derived and disposable; the fine grain is neither. Three iGaming-specific grain traps:

Ticket-level gameplay facts. Multi-leg bets misattribute margin across markets and products the moment anyone slices below the ticket. Selection level or regret.
Daily player aggregates as the base. They bake in one timezone and one cut-off forever. Aggregate views can be rebuilt per market timezone only if the base is event-grain.
Snapshot-only state. Balances, verification states and bonus states need transition history, not just current values — the difference between answering "what is" and "what was", and the second question is the audit question.

Time: the two-clock discipline, downstream

The schema carries event time and processing time; the warehouse decides what each consumer sees. The workable convention: operational and CRM marts read event time (players live in event time), finance and regulatory marts read settlement/accounting time with an explicit reopening window, and every externally reported figure gets a frozen snapshot. The revenue bridge then reconciles between clocks by design rather than by monthly negotiation.

Restatement: the rule nobody writes until it hurts

Late events are structural in this industry — settlements, chargebacks, voided markets, regulatory corrections. The design answer is a written restatement policy: which facts may change a closed period and for how long, which published aggregates re-state versus freeze, and how a restatement is itself recorded as an event. This is the same lineage discipline as regulatory reporting — the warehouse is where it either exists or does not.

The consumers, explicitly

Consumer	Needs	Design consequence
Finance	Stable periods, reconciled to the cashier and the ledger	Accounting-time mart, frozen snapshots, restatement log
CRM / operations	Fresh player state, actionable within minutes	Event-time mart with latency SLO; freshness monitored like uptime
Risk / RG	Complete protection and activity join, fast	Protection events in the core with money-grade completeness
Regulator / audit	Reproducible historical answers	Append-only lineage from filed figure back to raw events

Writing this table for your own operation — with named owners per row — is worth more than any tooling choice. Most warehouse redesigns are really the discovery that one consumer's needs were never stated.

What to monitor

Freshness per mart, against its stated SLO — staleness discovered by a user is a trust event, not an incident ticket.
Reconciliation deltas — warehouse revenue versus cashier and ledger, daily, with a tolerance and an owner.
Restatement volume — a rising trend means an upstream source is degrading, long before anyone complains.
Definition drift — any metric computed outside the metric layer, caught by review; the count should be zero and stay zero.

Continue reading: Cohort analysis — the discipline the marts exist to serve. Dashboards by role — the last mile.

Warehouse design — common questions

What grain should the core fact tables keep?

The finest grain the source produces: bet-selection level for gameplay, transaction level for wallet, event level for bonus state. Aggregates are cheap to build up and impossible to build down — every question you have not thought of yet is a question about the fine grain. Storage is the cheapest line in the whole data budget; re-ingesting history because the facts were pre-aggregated is the most expensive.

How should late-arriving settlements be handled?

With an explicit, written restatement rule — the same discipline as regulatory reporting. Decide the reopening window (how long a closed day can change), publish which metrics re-state and which freeze, and version the snapshots that were reported externally. The failure mode is not lateness itself; it is lateness handled silently, so last month's number differs depending on when you ask.

One warehouse or one per brand?

One warehouse, brand as a dimension. Multi-brand operators who shard by brand rediscover the cost at every group-level question: cross-brand players, shared-wallet flows, group revenue bridges and exclusion enforcement all need the joined view. Access control solves confidentiality; sharding only relocates the join to the least-equipped consumer.

Should CRM and BI read the same tables?

The same core, different marts. CRM needs low-latency, player-grain, action-oriented views; finance needs stable, period-grain, reconciled ones; the regulator needs the reproducible snapshot. Serving all three from one set of tables forces the strictest latency and the strictest stability onto everyone. Marts diverge in shape; they must not diverge in definitions — that is what the metric dictionary pins.

Where do responsible-gambling data belong in the warehouse?

In the core, with the same completeness guarantees as money — not in a side system. Interventions, limits and exclusion states are joined against activity in audits and in harm analyses, and a warehouse that cannot produce that join quickly fails exactly the review where speed matters. Access to it is tightly controlled; existence of it is not optional.

The warehouse.