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) Чек-лист перед продом

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

Заключение

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