Customers only: preview

Designing a KPI cube for iGaming self-serve analysis

A technical design guide to measures, grains, dimensions and prior-period comparison for a KPI cube that operators can explore without a new dashboard for every cut.

For Heads of BI, data engineers and analytics leads

Built for Head of BI and Data teams

A KPI cube earns its place by answering questions a dashboard was never built for, without an analyst assembling a new view each time. The engineering that makes that safe is unglamorous: agreed measures, an explicit grain, modelled dimensions and a comparison that does not quietly double count. Get those right and self-serve exploration is trustworthy. Get them wrong and a cube becomes a fast way to produce confident, incorrect numbers.

Executive summary

A cube resolves a request into a measure, a set of dimensions and a grain before it executes. The measure carries its own definition (which deductions, which event date, which currency treatment); the dimensions are the allowed ways to slice it; the grain is the level at which rows are aggregated before anything is summed. The design here separates the agreed semantics from the interactive surface, so a Head of BI has something concrete to test and a commercial user cannot accidentally ask for a number that cannot be computed correctly. These are reference-design recommendations, not a description of an audited Bounty AI deployment.

Step 1: define the measures and their grain first

Before a single filter is exposed, each measure needs an executable definition. NGR is not a column; it is a calculation with an owner, a version and an aggregation grain. Agree which bonuses are deducted and when, whether a sportsbook result is grouped by settlement or placement date, and how late-arriving adjustments are treated. A cube that lets a user pick any dimension against a loosely defined measure will produce cuts that look precise and are not.

The discipline that protects a cube is the same one that protects any governed metric: distinguish zero from unavailable, pin currency and timezone, and record the version of the definition a result was computed under so two people comparing the same cut are comparing the same thing. dbt's documentation describes semantic models connected by entities that define join relationships; that illustrates the modelling mechanism, and does not establish that Bounty AI uses dbt. Source: dbt semantic models.

Once the measures and their grain are settled, the interactive part of the cube, dimensions, comparison, exports, can be built on top without re-litigating what each number means. The rest of this guide walks that build step by step, with the product screens for each stage.

Customers only

The rest of this guide is for Bounty AI customers.

Full guides, product screens and walkthroughs are available to Bounty AI customers and pilot partners. Access is by invitation, and customer sign-in is not open yet.

  1. Step 2: model dimensions and the fact-to-dimension grain
  2. Step 3: prior-period comparison without double counting
  3. Step 4: top-N, pagination and the table-to-chart switch
  4. Step 5: saved team presets and governed exports
  5. Operational outcome: one cube instead of forty dashboards
Pilot on your data

Pilot partners get the full library when their pilot starts.

Free to read now

More dashboards is not more clarityRead the article

More in the Client library

All guides