RTP：配置模型

RTP（返回播放器）是游戏/变体数学给出的理论长距离返回的百分比。在生产中，RTP变成了一组受控的约束和信号：在哪里，谁以及在什么条件下允许特定的数学变体(97/96/94/92等），如何计算实际返回，如何响应偏差以及如何记录合规性的变化。

1）术语和级别

Theoretical RTP（tRTP）是声明的变体数学（认证）。
Effective RTP （eRTP）-预期的销售回报,包括选项（头奖附加费、奖励购买、边扣、提供商佣金）。
Realized RTP （rRTP）-时间窗口/回合（经验）的实际回报。

RTP变体-游戏的特定法案/配置文件（例如96。5%).

RTP乐队/政策-允许的司法管辖区/特定范围。

模型目标：将允许的tRTP绑定到启动上下文（tenant、区域、货币、通道）并能够通过SLO验证eRTP/rRTP。

2）配置测量（我们在其中设置规则）

1.提供商/游戏/变体-通常支持。
2.Tenant/Brand-商业和UX解决方案（显示哪个RTP）。
3.区域/管辖权-许可证和监管框架。
4.通道-web/native/retail/terminal（池/参数有时会有所不同）。
5.货币-与头奖和佣金重叠（影响eRTP）。
6.时间窗口是促销期，金丝雀布局。

3）等级，优先级，商务

GLOBAL_DEFAULT < PROVIDER < GAME < VARIANT < TENANT < REGION < CHANNEL < CURRENCY < WINDOW

没有具体说明的地方-我们从父母那里继承。任何显而易见的deny都会在下层重叠。

4）配置方案（YAML，示例）

yaml rtp_config:
schema_version: 1 global_defaults:
allowed_bands: [96, 95, 94] # percentages rounded to whole min_band: 92 show_rtp_label: true # show RTP in the providers directory/card:
prag_play:
games:
gates_of_:
variants:
"96. 5": { status: "allow", label: "96. 5%" }
"94. 0": { status: "allow", label: "94%" }
"92. 0": { status: "deny" }
jackpot_uplift_bps: 35       # +0. 35% to eRTP with tenant pool active:
brand_eu:
regions:
EE:
bands_allow: [96, 94]
default_band: 96 channel:
web:  { bands_allow: [96], default_band: 96 }
retail:{ bands_allow: [94], default_band: 94 }
DE:
bands_allow: [94]
default_band: 94 compliance:
mandate_rtp_label: true currencies:
EUR:
fee_bps: 0 # impact on eRTP
TRY:
fee_bps: 10           # -0. 10% eRTP on paid rollout features:
canary:
brand_eu: { region: "EE", game: "gates_of_", variant: "96. 5", traffic_pct: 10, ends_at: "2025-11-07T00:00:00Z" }
sla:
monitoring_windows:
- { name: "daily",  duration_h: 24, min_rounds: 1_000 }
- { name: "weekly", duration_h: 168, min_rounds: 10_000 }
ertp_tolerance_bps: 50  # eRTP vs tRTP, ±0. 50% for information alerts rrtp_tolerance_bps: 150 # rRTP vs tRTP, ± 1. 50% on weekly window

5）出版前验证

变体认证：变体具有验证证书/ID法案。
管辖范围：在该地区允许选定的乐队。
相容性：bonus buy/jackpot/side-bets不会将eRTP排除在外。
UI合同："show_rtp_label"标志/某些市场的强制性标签。
一致性：每个上下文都有默认乐队（因此没有"漏洞"）。
Dry-run：按公式计算eRTP并与SLO/tolerans进行比较。

6）如何计算eRTP

eRTP = tRTP
+ jackpot_uplift
+ side_bet_uplift
- provider_fee
- platform_fee
- bonus_buy_friction

• jackpot_uplift-累进池的附加费（bps，取决于池的大小和费率）。
• side_bet_uplift是side-bets的预期份额（如果适用）。
• provider/platform_fee是假的/每轮/利率的百分比，有时与货币挂钩。
• bonus_buy_friction是购买奖金机制的"摩擦"（如果价值高于公平价值）。

所有术语和源都被认为是确定性的，并且是在配置事件中确定的。

7） Fich对RTP的影响

Bonus Buy：可以改变结果分布；为购买模式分别捕获eRTP。
Jackpot：eRTP取决于积累；允许eRTP范围，但要保留检查点（例如，当池每增加N％-重新计票时）。
Side Bets/Feature Bets：单独的RTP配置文件；在有限制的地区禁止他们。
Volatility profile：RTP相同，但方差不同；将配置文件（low/med/high）存储在乐队旁边。

8）目录、启动和适配器

目录/读取模型：保留'tRTP_band'、'eRTP_range'、'label'和幻灯片标志。
Game Launch：启动会话时,适配器会检查允许的上下文带；如果不兼容，则禁止启动。
Round Events：在Round事件中。Started/Resulted"添加"rtp_context"（variant_id、乐队、旗帜）-这将简化审核和度量标准。

9）监视，SLO和漂移

• 'rRTP_windows_daily/weekly'是窗口的实际返回。
• `rounds_count`, `stake_sum`, `win_sum`, `jackpot_contrib`.
• `deviation_bps = rRTP - tRTP` и `rRTP - eRTP`.
• "bonus_buy_share"，"side_bet_share"-了解漂移的原因。
• "jackpot_level"和触发频率。

10）防暴和防守

异常：收益激增、功能购买序列→ 设备/帐户/IP/段检查。
限额策略：在异常情况下暂时禁用奖金购买/面组。
Vendor-fid：与提供者的参考支线核对菲奇结局的可能性。
手动咆哮采样：通过高分散性和频繁投诉的游戏。

11）合规与透明度

司法管辖区：允许的乐队和强制性标记的列表（例如，显示RTP/年龄警告）。
认证/ID法案：存储报告链接,math profile版本。
报告：通过'tRTP'、'eRTP'、'rRTP'和更改事件发布监管报告。
UI/内容：在游戏卡中-正确的RTP标签和注释（如果eRTP取决于头奖）。

12）金丝雀发行版和A/B

金丝雀：在一个司法管辖区以5-10%的流量启用新乐队，→关注"rRTP"、"rounds_count"、投诉。
A/B：比较不同乐队业务下的转换/参与/ARPU，而不仅仅是RTP。
Autoccat：在临界阈值处输出rRTP时,配置回滚。

13）审核和变更管理

json
{
"event_type":"RTPConfigChanged",
"changed_by":"user@company",
"tenant_id":"brand_eu",
"scope":"regions. EE. games. gates_of_",
"old":{"default_band":94},
"new":{"default_band":96},
"reason":"licence_update_2025Q4",
"occurred_at":"2025-10-31T12:00:00Z"
}

维护不可更改的日志可以简化争议解决和合规性。

14）测试

合同测试：方案的有效性，默认的存在，deny/allow逻辑。
基于属性的：'eRTP'不超出任何相组合的合理范围。
重播：在新配置（离线）之上运行历史回合→检查报告。
Chaos：重新启动适配器,lagi头奖,跳过菲奇标志。
Golden set：一组具有eRTP参考计算的游戏/变体。

15）花花公子（runbooks）

1.rRTP本周离开低于tRTP

检查样本，奖金购买/面组份额，头奖相关性和fid。
禁用有争议的fici（标志）,通知提供商,启用增强的日志。
如果需要,可临时切换乐队/变体。

2.球员抱怨"犯规RTP"

给出"as_of"配置、ID Bold、每周rRTP和计算方法。
检查玩家的限制/限制/负责任的游戏段。

3.UI标记不匹配

将"rtp_label"与上下文的config进行比较，滚动展示，启动e2e验证。

4.头奖失败

禁用uplift/标签,固定separate accounting,让玩家保持最新状态。

16）典型错误

溷合tRTP和eRTP：在实践依赖于头奖/拳头的地方展示理论。
没有违约→游戏以"漏水"上下文启动。
Config"到一般提供者"，没有选项/司法管辖区的具体说明。
没有采样阈值→小数据上的rRTP误差。
没有审计的变化和金丝雀→所有市场的事件。
忽略佣金/fees在eRTP →期望和事实的差异。

17）售前支票清单

• 每个Variant 都有证书/ID和已提交的tRTP。
• 每个组合（tenant/region/channel）都设置了default_band。
• 计算出eRTP（头奖，fichi，fees）并通过tolerans。
• RTP标签和司法管辖区的要求正确地反映在UI中。
• rRTP/eRTP监控和样本阈值包括在内；Alertes设置。
• 新乐队的金丝雀布局；自动送货。
• 审核更改并向监管机构导出报告。
• 花花公子漂移，有争议的胜利，头奖失败。
• 测试：合同/门槛/财产/继电器。

结论

RTP配置模型不是"游戏卡中的百分比"，而是风险和信任管理系统。明确的规则层次结构、eRTP的确定性计算、rRTP的可观察性、金丝雀版本和严格的审核将有争议的主题转变为一个可预测的工程过程--产品友好、玩家可以理解和合规性安全。