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的可觀察性、金絲雀版本和嚴格的審核將有爭議的主題轉變為一個可預測的工程過程--產品友好、玩家可以理解和合規性安全。