RTP: modelo de configuración

RTP (Return To Player) es el porcentaje de retorno teórico a larga distancia dado por las matemáticas del juego/variante. En la producción, RTP se transforma en un conjunto de restricciones y señales controlables: dónde, a quién y bajo qué condiciones se permite una u otra variante de las matemáticas (97/96/94/92 etc.), cómo contar el retorno real, cómo responder a las desviaciones y cómo documentar los cambios para el cumplimiento.

1) Términos y niveles

La RTP teorética (tRTP) es una matemática de variante declarada (certificada).
Effective RTP (eRTP) es el retorno esperado en la venta teniendo en cuenta las opciones (premio mayor, bonus buy, side-bets, comisiones de proveedor).
RTP realizado (rRTP): retorno real por ventana de tiempo/rondas (empírica).
RTP Variant es un build/perfil específico del juego (por ejemplo, 96. 5%).
RTP Band/Policy - rangos permitidos para jurisdicciones/tenantes.

Objetivo del modelo: vincular el tRTP permitido al contexto de inicio (tenante, región, moneda, canal) y poder verificar eRTP/rRTP por SLO.

2) Medidas de configuración (donde especificamos reglas)

1. Proveedor/Game/Variant - que es generalmente compatible.
2. Tenant/Brand son soluciones comerciales y UX (qué RTP mostrar).
3. Región/Jurisdicción - Licencias y marco regulador.
4. El canal es web/native/retail/terminal (a veces los grupos/parámetros varían).
5. Moneda: se cruza con botes y comisiones (que afectan a eRTP).
6. Las ventanas temporales son periodos promocionales, colocaciones canarias.

3) Jerarquía, prioridades, medida

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

Donde no hay especificación - heredamos de los padres. Cualquier deny explícito se superpone a allow en los niveles subyacentes.

4) Esquema de configuración (YAML, ejemplo)

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) Validación antes de la publicación

Certificación de la opción: la variante tiene un certificado válido/ID bild.
Marco jurisdiccional: la banda seleccionada está permitida en la región.
Compatibilidad fich: bonus buy/jackpot/side-bets no lleva eRTP más allá.
Contratos de UI: la bandera 'show _ rtp _ label '/etiqueta obligatoria para algunos mercados.
Consistencia: hay una banda de default en cada contexto (para que no haya «agujeros»).
Dry-run: cálculo de eRTP por fórmulas y comparación con SLO/tolerancias.

6) Cómo contar eRTP

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

• jackpot_uplift es una prima del grupo progresivo (bps, depende del tamaño del grupo y de la tasa).
• side_bet_uplift es la proporción esperada de side-betas (si corresponde).
• provider/platform_fee - fix/porcentaje por ronda/apuesta, a veces atado a la moneda.
• bonus_buy_friction es la «fricción» de la mecánica de compra del bono (si el valor es superior al valor justo).

Todos los términos y fuentes se consideran deterministas y están lógicos en el evento de configuración.

7) Efecto del fich en RTP

Bonus Buy: puede cambiar la distribución de resultados; fijar eRTP para el modo buy por separado.
Jackpot: eRTP depende de la acumulación; permita el intervalo eRTP, pero mantenga los puntos de control (por ejemplo, cuando el grupo crezca cada N% - recuento).
Side Bets/Feature Bets: perfiles RTP individuales; prohibirlas en regiones con restricciones.
Perfil de volatilidad: RTP es el mismo, pero la varianza es diferente; almacene el perfil (low/med/high) junto a la banda.

8) Directorio, inicio y adaptadores

Directory/Read Model: almacenamos 'tRTP _ band', 'eRTP _ range', 'label', banderas fich.
Game Launch: cuando se inicia una sesión, el adaptador comprueba la banda permitida para el contexto; prohíbe el inicio si es incompatible.
Eventos Round: en los eventos 'Round. Started/Resulted 'añadir' rtp _ context' (variant_id, banda, flags) es simplificar la auditoría y la métrica.

9) Monitoreo, SLO y deriva

• 'rRTP _ window _ daily/weekly' es el retorno real a través de las ventanas.
• `rounds_count`, `stake_sum`, `win_sum`, `jackpot_contrib`.
• `deviation_bps = rRTP - tRTP` и `rRTP - eRTP`.
• 'bonus _ buy _ share', 'side _ bet _ share' - para entender la causa de la deriva.
• 'jackpot _ level' y frecuencia de activación.

10) Anti-Abuse y protección

Anomalías: ráfagas bruscas de ganancias, secuencias de compra de características → verificación por dispositivo/cuenta/IP/segmento.
Directivas de límite: deshabilitar temporalmente bonus buy/side bets en caso de anomalías.
Vendor Fid: comprobar la probabilidad de resultados fijos con el feed de referencia del proveedor.
Sampling de rugido manual: por juegos de alta dispersión y frecuentes quejas.

11) Cumplimiento y transparencia

Jurisdicciones: lista de bandas permitidas y etiquetado obligatorio (por ejemplo, visualización de advertencias de RTP/edad).
Certificación/ID build: almacena el enlace al informe, la versión math profile.
Reporting: emite informes regulatorios con 'tRTP', 'eRTP', 'rRTP' y eventos de cambio.
UI/Contenido: En la tarjeta del juego, la etiqueta RTP correcta y las notas (si eRTP depende del jackpot).

12) Lanzamientos canarios y A/B

Canarias: incluye una nueva banda del 5 al 10% del tráfico en una jurisdicción → sigue 'rRTP', 'rounds _ count', quejas.
A/B: compare la conversión/compromiso/ARPU con diferentes bandas de manera empresarial, no solo por RTP.
Autocorrección: cuando rRTP sale por los umbrales críticos, revierte la configuración.

13) Auditoría y gestión de cambios

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"
}

Mantener un registro inmutable facilita la resolución de disputas y el cumplimiento.

14) Pruebas

Pruebas de contrato: validez del esquema, presencia de impagos, lógica deny/allow.
Property-based: 'eRTP' no va más allá de un marco razonable para cualquier combinación de fichas.
Responder: ejecutar rondas históricas encima de la nueva configuración (fuera de línea) → comprobar los informes.
Chaos: reinicios del adaptador, Lage Jackpot Fide, saltos de banderas fichas.
Conjunto de oro: conjunto de juegos/variantes con cálculos de referencia eRTP.

15) Playbooks (runbooks)

1. rRTP salió por debajo de tRTP en la semana

Comprobar la muestra, la proporción de bonus buy/side bets, la relevancia del jackpot y el feed.
Desactivar los fichajes controvertidos (bandera), notificar al proveedor, habilitar el registro reforzado.
Cambiar de banda/variante temporalmente si es necesario.

2. Quejas de jugadores por «RTP deshonesto»

Dar 'as _ of' a la configuración, ID build, rRTP semanal y método de cálculo.
Comprobar el segmento del jugador en los límites/límites/juego responsable.

3. No coincidencia de las marcas de IU

Comparar 'rtp _ label' con la configuración del contexto, retroceder el escaparate, ejecutar la validación e2e.

4. Error del bote

Desactivar uplift/etiquetas, fijar la cuenta de separate, mantener al jugador informado sobre el estado.

16) Errores típicos

Mezclar tRTP y eRTP: mostrar la teoría donde la práctica depende del jackpot/fich.
La ausencia de impagos → el juego se inicia con un contexto «agujereado».
Configuración «por proveedor en general» sin especificar las opciones/jurisdicciones.
No hay umbrales de muestreo → alertas falsas por rRTP en datos pequeños.
Los cambios sin auditoría y los canarios → incidencias a la vez en todos los mercados.
Ignorar comisiones/fees en eRTP → discrepancia entre expectativas y hechos.

17) Lista de verificación antes de la venta

• Cada Variant tiene un certificado/ID y un tRTP fijo.
• Se especifica un default_band para cada combinación (tenant/region/channel).
• Calculado por eRTP (jackpot, fiches, fees) y pasa tolerancias.
• Las etiquetas RTP y los requisitos de las jurisdicciones se reflejan correctamente en IU.
• Se incluye el monitoreo de rRTP/eRTP y los umbrales de muestreo; alertas personalizadas.
• Plantillas de Canarias para nuevas bandas; autocartera.
• Auditoría de cambios y exportación de informes para el regulador.
• Playbucks a la deriva, ganancia controvertida, fracaso del bote.
• Pruebas: contrato/umbral/propiedad/réplica.

El modelo de configuración de RTP no es un «porcentaje en la tarjeta del juego», sino un sistema de gestión de riesgo y confianza. La clara jerarquía de las reglas, el cálculo determinista del eRTP, la observancia del rRTP, los lanzamientos canarios y las rigurosas auditorías convierten el polémico tema en un proceso de ingeniería predecible - conveniente para el producto, comprensible para los jugadores y seguro para el cumplimiento.