The casino BI metrics that actually run the business

Business intelligence in a casino has a strange failure mode: there is too much of it. Every platform ships a reporting module with hundreds of fields, most operators look at four of them, and the ones they look at are rarely the ones that explain why last month was worse than the month before.

This is the short list we would put in front of an operator on day one, in the order we would read it.

1. GGR, NGR, and the gap between them

Metric	Definition	What it is for
Turnover	Total stakes placed	Activity, not money. Ignore it for financial decisions.
GGR	Stakes minus wins paid to players	The gross revenue of the casino. Game studios and regulators are paid from this.
NGR	GGR minus bonus cost, gaming tax, payment fees and provider fees	What you actually keep. Affiliates on revenue share should be paid from this.
Hold	GGR divided by turnover	The house edge you are actually realising across your game mix.

The number to watch is not GGR or NGR alone, it is the ratio between them. A healthy casino keeps 70 to 80% of GGR as NGR. If that ratio drifts down while GGR is flat, something in bonuses, tax or fees has moved, and GGR will not tell you.

2. Bonus cost as a share of GGR

Bonus cost is the biggest controllable line between GGR and NGR. The useful way to see it is as a percentage of GGR, broken down by campaign and by player segment.

The arithmetic is unforgiving. On €4.8M of monthly GGR, the difference between bonus cost at 12% and at 15% is €144,000 a month. It is also one of the fastest numbers to move: a welcome pack with 40 times wagering versus 35 times, a cashback tier that was set once and never reviewed, or a tournament prize pool that is paying the same ten players. You need to see bonus cost per campaign, per segment and per provider, because a bonus that is efficient on one studio's games can be a leak on another's.

3. Hold, and what a drop in hold means

If hold falls from 4.3% to 3.8% with the same traffic, you have lost about 12% of GGR and nothing in your marketing changed. The usual causes are a shift in game mix toward higher-RTP titles, a provider changing an RTP setting on a popular game, or a bonus that pushes players into low-house-edge games to clear wagering. Each has a different fix, and only a per-provider, per-game view of hold shows you which it is.

4. Lifetime value against acquisition cost, by cohort

A blended LTV is almost useless. What you want is a cohort table: players who signed up in each month, and how much NGR each cohort has produced per player at 30, 60, 90 and 180 days. Put the CPA you paid for that cohort next to it and you can read off the payback day.

Two things fall out of this immediately. First, the quality of traffic by source and by month becomes visible, which is the number your affiliate programme should be paying on. Second, product changes show up as a step change between cohorts. In the dashboard we rendered for this article, the July cohort retains best, and July was the month that brand cut welcome wagering from 40 times to 35 times. Without cohorts you would never connect the two.

5. Retention curves

The companion to LTV is the share of each cohort still depositing month by month. The shape of the curve matters more than any single point on it. A curve that drops to 60% in month one and then flattens is a good casino with a weak first week. A curve that keeps sliding is a retention problem, and the retention journeys you run should be measured against it, not against open rates.

6. Provider performance: GGR share versus bonus cost

Every studio contract is a revenue share, usually between 8 and 15% of GGR, so provider mix is a direct cost line. But the useful view is two numbers side by side per provider: share of GGR, and bonus cost as a share of that provider's GGR. A studio that drives 11% of your GGR with a 19% bonus cost is producing less than a studio that drives 9% at 12%. The lobby should be arranged around the second kind, and most lobbies are arranged around the first.

7. Payment health

Deposit approval rate, by method and by market, and withdrawal time to completion. These are operational numbers, but they sit in BI because they explain revenue swings that nothing else explains. A two-point drop in approvals in your top market is a GGR drop two weeks later. The full treatment is in why your deposit approval rate is low.

Why speed is the real feature

All of the above is useless if it arrives tomorrow. The classic setup is a data warehouse that loads overnight, so every question is answered with yesterday's data, and anything that needs a new cut of the data goes into a queue for an analyst. By the time you see that hold fell on Tuesday, it is Thursday.

A casino generates billions of events: every spin, every bet, every bonus wager, every cashier step. BI that is built for that volume answers a cohort question across all of it in under a second, on data that is minutes old, and lets the person who had the question build the report. That is the difference between reporting and a control loop.

What to ask your platform about BI

• Is it real-time or T+1? Ask them to show you an event that happened five minutes ago.
• Can a non-analyst build a cohort report? Watch someone do it.
• Is NGR defined the way your affiliate contracts define it? If not, every statement is a dispute.
• Per-provider and per-game hold and bonus cost. Not just GGR.
• Payment metrics in the same tool. Not in the PSP's portal.
• Export and API access. It is your data.

How we handle it

The BI in the BetCode platform is built for the event volumes a casino actually produces: billions of rows, queries in seconds, data that is minutes old rather than a day. GGR, NGR, hold, bonus cost, LTV, cohorts and provider performance are standard views, and anyone on your team can build a new one. If you want to see your own numbers in it, get in touch.

Questions we get asked