RTP: модель конфігурування

RTP (Return To Player) - відсоток теоретичного повернення на довгій дистанції, заданий математикою гри/варіанту. У продакшені RTP перетворюється на набір керованих обмежень і сигналів: де, кому і за яких умов дозволений той чи інший варіант математики (97/96/94/92 і т. п.), як вважати фактичне повернення, як реагувати на відхилення і як документувати зміни для комплаєнсу.

1) Терміни та рівні

Theoretical RTP (tRTP) - заявлена математика варіанту (сертифікована).
Effective RTP (eRTP) - очікуване повернення в проді з урахуванням опцій (джекпот-надбавка, bonus buy, side-bets, провайдерські комісії).
Realized RTP (rRTP) - фактичне повернення за вікном часу/раундів (емпірика).
RTP Variant - конкретний білд/профіль гри (наприклад, 96. 5%).
RTP Band/Policy - дозволені діапазони для юрисдикцій/тенантів.

Мета моделі: прив'язати дозволений tRTP до контексту запуску (тенант, регіон, валюта, канал) і вміти верифікувати eRTP/rRTP по SLO.

2) Вимірювання конфігурації (де задаємо правила)

1. Провайдер/Game/Variant - що взагалі підтримується.
2. Тенант/Бренд - комерційні та UX-рішення (які RTP показувати).
3. Регіон/Юрисдикція - ліцензії та регуляторні рамки.
4. Канал - web/native/retail/terminal (іноді розрізняються пули/параметри).
5. Валюта - перетинається з джекпотами і комісіями (впливають на eRTP).
6. Тимчасові вікна - промо-періоди, канарні викладки.

3) Ієрархія, пріоритети, мердж

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

Де відсутня конкретизація - успадковуємо від батька. Будь-яке явне deny перекриває allow на нижчих рівнях.

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 білда.
Юрисдикційні рамки: обраний band дозволений в регіоні.
Сумісність фіч: bonus buy/джекпот/side-bets не виводять eRTP за межі.
UI-контракти: прапор'show _ rtp _ label '/обов'язковий лейбл для деяких ринків.
Консистентність: є дефолтний band на кожен контекст (щоб не було «дірок»).
Dry-run: розрахунок eRTP за формулами і порівняння з SLO/толерансами.

6) Як вважати eRTP

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

• jackpot_uplift - надбавка від прогресивного пулу (bps, залежить від розміру пулу і ставки).
• side_bet_uplift - очікувана частка від side-бетів (якщо застосовується).
• provider/platform_fee - фікс/відсоток на раунд/ставку, іноді зав'язаний на валюту.
• bonus_buy_friction - «тертя» від механіки покупки бонусу (якщо вартість вище fair value).

Всі терміни і джерела вважаються детерміновано і логуються в події конфігурації.

7) Вплив фіч на RTP

Bonus Buy: може змінювати розподіл результатів; фіксуйте eRTP для buy-режиму окремо.
Jackpot: eRTP залежить від накопичення; допускайте діапазон eRTP, але тримайте контрольні точки (наприклад, при зростанні пулу кожні N% - перерахунок).
Side Bets/Feature Bets: окремі профілі RTP; забороняйте їх у регіонах з обмеженнями.
Volatility profile: RTP однаковий, але дисперсія різна; зберігайте профіль (low/med/high) поруч з band.

8) Каталог, запуск і адаптери

Каталог/Read Model: зберігаємо'tRTP _ band','eRTP _ range','label', прапори фіч.
Game Launch: при запуску сесії адаптер перевіряє дозволений band для контексту; забороняє старт, якщо несумісне.
Round Events: в події'Round. Started/Resulted'додаємо'rtp _ context'( variant_id, band, flags) - це спростить аудит і метрики.

9) Моніторинг, SLO і дрейф

• 'rRTP _ window _ 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) Анти-аб'юз і захист

Аномалії: різкі сплески виграшів, послідовності feature buy → перевірка по пристрою/акаунту/IP/сегменту.
Політики лімітів: тимчасово відключати bonus buy/side bets при аномаліях.
Вендор-фід: звіряти ймовірність фічевих результатів з референсним фідом провайдера.
Семплінг ручних рев'ю: за іграми з високою дисперсією і частими скаргами.

11) Комплаєнс і прозорість

Юрисдикції: список дозволених band і обов'язкових маркувань (наприклад, відображення RTP/вікових попереджень).
Сертифікація/ID білда: зберігайте посилання на звіт, версію math profile.
Звітність: видавайте регуляторні звіти з'tRTP','eRTP','rRTP'і подіями зміни.
UI/Контент: в картці гри - коректний лейбл RTP і примітки (якщо eRTP залежить від джекпоту).

12) Канарські релізи та A/B

Canary: включайте новий band на 5-10% трафіку в одній юрисдикції → стежте за'rRTP','rounds _ count', скаргами.
A/B: порівнюйте конверсію/залученість/ARPU при різних band бізнесово, не тільки по RTP.
Автовідкат: при виході 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) Тестування

Contract tests: валідність схеми, наявність дефолтів, deny/allow логіка.
Property-based: 'eRTP'не виходить за розумні рамки для будь-яких комбінацій фіч.
Replay: прогін історичних раундів поверх нової конфігурації (оффлайн) → перевірка звітів.
Chaos: перезапуски адаптера, лаги джекпот-фіда, пропуски фічових прапорів.
Golden set: набір ігор/варіантів з еталонними розрахунками eRTP.

15) Плейбуки (runbooks)

1. rRTP поїхав нижче tRTP на тижні

Перевірити вибірку, частку bonus buy/side bets, актуальність джекпоту і фід.
Відключити спірні фічі (прапор), повідомити провайдера, включити посилений лог.
При необхідності тимчасово перемкнути band/варіант.

2. Скарги гравців на «нечесний RTP»

Віддати'as _ of'конфігурації, ID білда, тижневий rRTP і методику розрахунку.
Перевірити сегмент гравця на обмеження/ліміти/відповідальну гру.

3. Невідповідність маркувань UI

Порівняти'rtp _ label'з конфігом для контексту, відкотити вітрину, запустити e2e валідацію.

4. Збій джекпоту

Відключити uplift/лейбли, фіксувати separate accounting, тримати гравця в курсі статусу.

16) Типові помилки

Змішувати tRTP і eRTP: показувати теорію там, де практика залежить від джекпоту/фіч.
Відсутність дефолтів → гра запускається з «дірявим» контекстом.
Конфіг «на провайдера в цілому» без конкретики щодо варіантів/юрисдикцій.
Немає порогів вибірки → помилкові алерти по rRTP на малих даних.
Зміни без аудиту і канарок → інциденти відразу на всіх ринках.
Ігнорування комісій/fees в eRTP → розбіжність очікувань і факту.

17) Чек-лист перед продом

• У кожного Variant є сертифікат/ID і зафіксований tRTP.
• Для кожної комбінації (tenant/region/channel) заданий default_band.
• Розрахований eRTP (джекпот, фічі, fees) і проходить толеранси.
• Лейбли RTP і вимоги юрисдикцій коректно відображені в UI.
• Моніторинг rRTP/eRTP і пороги за вибіркою включені; алерти налаштовані.
• Канарські викладки для нових band; Автовідкат.
• Аудит змін та експорт звітів для регулятора.
• Плейбуки на дрейф, спірні виграші, збій джекпоту.
• Тести: контракт/порогові/property/реплей.

Висновок

Модель конфігурування RTP - це не «відсоток в картці гри», а система управління ризиком і довірою. Чітка ієрархія правил, детермінований розрахунок eRTP, спостережуваність rRTP, канарські релізи і строгий аудит перетворюють спірну тему в передбачуваний інженерний процес - зручний для продукту, зрозумілий гравцям і безпечний для комплаєнсу.