Casino Monitor
Whether the casino is paying out what it should, game by game and provider by provider.
The report is marked BETA.
What It Answers
- Is any game or provider paying out far more than it usually does?
- Is that a real problem, or just a quiet month with few rounds?
- How many of the room's games can be judged at all?
- Are poker players trying the casino, and do free-spin players ever stake their own money?
The first two questions are the point of the report. A game paying out 200 % looks alarming and is usually variance; the page exists to tell those two cases apart.
How It Works
Every game and provider is compared against its own recent past, not against a book value or a supplier's stated RTP.
The baseline is the 90 days before the month began. The tile at the top shows the room's baseline; each row of the table carries its own, over the same days, and is judged against that one. So a game that has always run hot is not flagged for running hot — only for changing.
RTP = Payouts ÷ Turnover, over real rounds
Real rounds are rounds that carried a stake. Free spins and demo rounds carry none, so they are in no RTP at all — they are counted separately.
Why Most Games Are Never Judged
Before a game can be alerted on, it needs:
- 200 real rounds in the month,
- 500 of turnover,
- and a baseline of 500 rounds.
Anything under those floors is listed but never alerted. This is why Games monitored is often far smaller than the number of games listed — in the screenshot above, 16 games are listed and none can be judged.
That is the honest answer for a small casino, not a fault. A game with 40 spins in a month can post any RTP at all, and flagging it would be noise.
Reading an Alert
Findings name the provider or game, both RTP figures, and the statistics behind the call:
provider pragmaticplay pays out 230.4 % against its own 120.3 % (z 2.22, p 0.0267; 204 real rounds this month, 1 750 in the baseline): unusually high.
The parts, in the order that matters:
- The two RTP figures — what it paid, against what it usually pays.
- The round counts — 204 rounds against a 1 750-round baseline is a thin month judged against a reasonable history. The thinner the month, the more the gap can be luck.
- z and p — how unusual the gap is. A p around 0.03 means a gap this large turns up by chance roughly three times in a hundred.
A second kind of finding looks at the shape of the month rather than its total, naming days that stand out against the game's other days or against the same weekday. Several unusual days clustered together is a stronger signal than one large total.
A high observed RTP over a few hundred rounds is usually variance, not a leak. The 95 % interval under Observed RTP is the check: when it spans a range like 137–281 %, the number is not yet saying much.
Tiles
| Tile | What it counts |
|---|---|
| Observed RTP | What the month actually paid out, over real rounds, with the interval it could move by chance. |
| Baseline RTP | What the room paid out over the 90 days before the month began. |
| Games alerted / monitored | Games standing out, of the games that can be judged. The line below counts every game listed, including those that can never be alerted. |
| Real rounds | Rounds that carried a stake, with free rounds on the line below. |
| Cross-sell | Of the poker players of one month, how many staked in the casino the next. A rate straight from the data, not a model output. |
| Free-spin conversion | Free-spin players who then staked their own money, within 30 days of their first free round. A bonus-funded round is not a conversion. |
"No data" on Free-spin conversion means no round of the month carries a package id: either the platform does not write it, or no package was used. It is a wiring gap, not a zero.
Table Views
- RTP by game, RTP by provider, RTP by skin – the RTP check at three grains. The provider view also carries a line with the month's casino ledger beside the rounds, as an independent cross-check of the same money.
- Poker → casino – last closed month's real-money poker players, ranked by how likely they are to stake in the casino next month.
- Casino → poker – last closed month's casino players, ranked by how likely they are to start a real-money poker session next month.
- Free-spin packages – one row per package first used in the month.
RTP Views
Rows under the volume floor are listed in grey so the table adds up to the month, and are never alerted.
| Column | Shown in | What it shows |
|---|---|---|
| Provider | RTP by game, RTP by provider | The game provider. |
| Game ID | RTP by game | The game. |
| Skin | RTP by skin | The skin. |
| Real rounds | All three | Rounds that carried a stake. |
| Free rounds | All three | Rounds with no stake: free spins and demo. |
| Players | All three | Players who played at least one round. |
| Turnover | All three | Everything staked on real rounds. |
| Payouts | All three | Everything won on real rounds. |
| Free-round payouts | All three | What free rounds paid out. Kept apart and in no RTP. |
| RTP, % | All three | Payouts ÷ Turnover, over real rounds. |
| RTP 95 % interval | All three | How far the RTP could move by chance, given how many rounds it stands on. |
| Cash RTP, % | All three | The same ratio on real money alone: bonus stakes and bonus winnings taken out of both sides. |
| Bonus payout share, % | All three | The part of the payouts that was bonus money. |
| Baseline RTP, % | All three | The row's own RTP over the 90 days before the month began. |
| Baseline rounds | All three | The real rounds that baseline stands on. |
| Population RTP, % | All three | The RTP of all rows of the month together — what a row with too little baseline is compared with instead. |
| z vs baseline | All three | How many standard deviations this month's RTP sits from the row's own baseline. |
| p | All three | The chance a month this far from the baseline happens by luck. The smaller, the harder it is to call luck; 0.05 is the usual line. |
| z vs population | All three | The same distance, measured against all rows of the month instead of the row's own past. |
| Days flagged (Tukey / STL) | All three | Two separate day-level checks, never added: days unlike the row's other days, then days unlike that same weekday. "—" means the check could not judge the row. |
| Status | All three | warning at 3 standard deviations from the baseline or more; info from 2; normal below that; low-volume under 200 real rounds or 500 of turnover in the month; no-baseline when the baseline has fewer than 500 rounds to judge against. Only info and warning raise an alert. |
RTP (formula) — the calculation behind the RTP, as text — is available on hover and is not a column of the export.
Poker → Casino and Casino → Poker
The model learns from earlier months and is checked on a month it did not learn from. A model that fails its checks lists nobody, and the list is cut to the 500 highest scores.
| Column | Shown in | What it shows |
|---|---|---|
| Player | Both | The player, linked to their card. |
| Score | Both | The model's raw score. It orders the list; it is not a probability. |
| Probability, % | Both | How many players of the same rank group actually converted in the checked month. Everyone in a group shows the same figure — it is not this player's own chance. |
| 95 % interval | Both | The range that group's conversion rate lies in, given its size. |
| Rank decile | Both | The player's tenth of the list: 1 is the most likely to convert. |
| Drivers | Both | The signals that pushed the score, strongest first. Hover the cell for all of them. |
| Sessions, Hands, Active days | Poker → casino | The player's poker table sessions, hands and active days in the scored month. |
| Rake | Poker → casino | The rake the player paid in the scored month. |
| Deposits | Poker → casino | Deposits made in the scored month. |
| Casino rounds this month | Poker → casino | Real casino rounds the player already played in the scored month. |
| Played casino before | Poker → casino | yes when the player had staked in the casino in that month or earlier. |
| Rounds, Real rounds | Casino → poker | The player's casino rounds in the scored month, and the ones that carried a stake. |
| Turnover | Casino → poker | What the player staked in the casino in the scored month. |
| Poker sessions this month | Casino → poker | Real-money poker sessions the player already had in the scored month. |
| Played poker before | Casino → poker | yes when the player had a real-money poker session in that month or earlier. |
Free-Spin Packages
There is no control group and no base rate — the data does not say who was offered a package — so these numbers describe what happened, they do not show what a package caused.
| Column | What it shows |
|---|---|
| Package | The package id. |
| Provider, Game ID | Where the package's free rounds were played. |
| Players | Players who used the package. |
| Free rounds | Free rounds played from the package. |
| Won on free rounds | What those rounds paid out. |
| Of it bonus | The part of that paid as bonus money — a part of Won on free rounds, not an addition. |
| First used, Last used | When the package was first and last used. |
| Staked own money, 7 d | Players who staked their own money within 7 days of their first free round. A bonus-funded round does not count. |
| Staked own money, 30 d | The same within 30 days. |
| Conversion, 30 d, % | Staked own money, 30 d ÷ Players. |
| Conversion lower bound, % | The lowest the true conversion is likely to be, given how many players it stands on. |
| New money players | Players who had never staked their own money before the package. |
| Own stakes, 7 d, Own stakes, 30 d | What they staked of their own money within 7 and 30 days. |
| Cash GGR, 30 d | The real-money GGR of those own-money rounds. |
| Own stakes per player, 30 d | Own stakes, 30 d ÷ Players. |
| Censored | yes when the package was last used less than 30 days before the data ends, so its 30-day numbers are not complete yet. |
Acting on It
- Read the round counts before reacting to any RTP figure.
- Take a provider-level alert more seriously than a single game's, since it aggregates more rounds.
- Ask the provider about a sustained gap, not a one-month one — this report compares a month against 90 days, which is enough to notice a change and not enough to prove one.
- If nothing is ever monitored, the casino is too small for this report to work; the floors are there to stop it inventing findings.
For the filters, the Highlights block and the table controls, see General Reports.