Pruebas A/B de las reglas de puntuación

Ganar puntos es el corazón de cualquier gamificación. De cómo se cuentan exactamente los puntos depende el comportamiento de los jugadores, la estructura de participación y la economía (ARPPU, bonus-bones). A continuación, una receta práctica para probar de forma válida la nueva regla de las gafas y asegurarse de que el crecimiento de las métricas sea real y no un artefacto.

1) Qué estamos probando exactamente

Ejemplos de reglas:

Por la cantidad de apuestas: 1 punto por cada 1 € de apuesta.
Por multiplicador win/bet: puntos = ⌊ multiplicador × k ⌋, con una gota por apuesta.
Híbrido: puntos por turno + busto por «serie» (N giros seguidos), gotas por minuto/hora.
Misiones: puntos de fix para realizar tareas (T1...Tn) con creciente complejidad.

Hipótesis (ejemplo): «El modelo «multiplicador + cap» aumentará la tasa de participation_net y compleción sin empeorar la Net ARPPU (después de premios/bonificaciones) «.

2) Unidad experimental y aleatorización

Unidad: usuario (no sesión, no dispositivo).

Distribución: hash estático (user_id → bucket) con sales fijas; cuotas 50/50 o 33/33/33 para A/B/C.

Estratificación (recomendado): payer-status (nuevo pago/re-pago/no pago), plataforma, geo.

Sticky-assignment: el usuario siempre ve la misma regla durante la prueba.

Validación de SRM (Sample Ratio Mismatch): verifique diariamente las partes reales de los grupos con las esperadas (chi-cuadrado). SRM: señal de fuga de tráfico, filtración errónea, errores.

3) Métricas y «embudo de gafas»

Actividad y participación

Reach: la parte que vio el evento.

Participation_gross: entrada/elegible.

Participation_net: comenzó el progreso/elegible.

Completion: completado/comenzado.

Calidad y dinero

ΔDAU/WAU и stickiness (DAU/WAU).

Avg Bets per Session, Avg Bet Size.

ARPPU (net) = ARPPU − (Prize + Bonus Cost per payer).

Avg Deposit, Paying Share.

Net Uplift: (ingresos adicionales) − (premios + bonificaciones + operativas + fugas).

Gardereyly

Quejas/Soporte para 1.000 usuarios, rechazos de KYC, patrones de apuestas anormales, banderas RG (límites, autoexclusión).

4) Duración, estacionalidad y novedad

Un mínimo de 2 ciclos de negocios completos (por ejemplo, 2 semanas para capturar un fin de semana).

Tenga en cuenta novelty-effect: el estallido de las primeras 48-72 h. Fijar y analizar por fases (D0-D2, D3-D7, D8 +).

No cruzar con grandes promociones, o planificar un «ruido igual» por grupos.

5) Potencia y volumen de la muestra (ejemplo de cálculo)

Objetivo: detectar la diferencia de Δ según el promedio de «puntos por usuario» (o Net ARPPU).

Fórmula para la prueba t de dos sonrisas (igual en grupos):

[
n_{\text{na grupo}} =\frac {2, (z_{1-\alpha/2}+z_{1-\beta}) ^ 2 ,\sigma ^ 2} {\Delta ^ 2}
]

Ejemplo: queremos capturar Δ = 5 puntos, σ = 120, α = 0.05 (bidireccional), 80% de potencia (β = 0.2).

(z_{1-α/2}=1{,}96), (z_{1-β}=0{,}84) → suma de 2,8 → cuadrado de 7,84.

(\sigma^2 = 14,400).

(n =\frac {2\times 7 {,} 84\times 14.400} {25 }\approx\frac {225,792} {25 }\approx 9,032) por grupo.

💡 Total: ~ 9.100 usuarios por grupo (con margen de rechazo y antifraude).

6) Reducción de la varianza: hacemos la prueba «más barata»

CUPED: ajuste de regresión en covariables de pre-prueba (por ejemplo, puntos/apuestas durante la semana pasada).

Covariables: bandera de pago, transformación de registro de rotación, actividad, plataforma, geo.

Clustering de errores: a nivel de usuario (sesiones repetidas en el interior).

7) Interferencia y «estrechos»

La regla de puntos no solo puede afectar a los participantes de la prueba:

La comparación social (tabla de liderazgo en general) → «spillover».
Jackpots compartidos/misiones conjuntas → efecto cruzado.

Soluciones:

Líderes separados por grupos o normalización oculta de puntos.
Aleatorización de clústeres por clústeres de tráfico/geo (más caro pero más limpio).
Protocolo PER (ITT) + análisis sensibles.

8) Reglas antifraude y capas

Cualquier cambio en las gafas estimula la optimización: microestaciones, producción de botes, «granjas de gafas».

Protecciones mínimas:

Una tapa de puntos por minuto/hora/día y por una apuesta.
Mínima volatilidad de las apuestas (prohibición de secuencias «perfectas»).
Detección de fingerprints sin cabeza/repetitivos, proxy.
Verificación diferida de grandes premios + KYC.
Analítica: compara «puntos/apuestas» y «puntos/min» de distribución, busca colas.

9) Eventos y esquema de datos (mínimo)

Eventos:

`session_start {user_id, ts, platform}`
`event_view {user_id, event_id, ts}`
`event_join {user_id, event_id, ts}`
`points_awarded {user_id, event_id, rule_id, amount, source, ts}`
`mission_progress {user_id, mission_id, step, value, ts}`
`mission_complete {user_id, mission_id, ts}`
`bet {user_id, game_id, bet, win, ts}`
`deposit {user_id, amount, ts}`

Manuales:

`rules {rule_id, name, params, caps_minute, caps_hour, caps_day, version}`
`assignments {user_id, test_id, group, assigned_at}`

10) SQL-sketches para análisis

Verificación SRM (distribución por grupos):

sql
SELECT group, COUNT() AS users
FROM assignments
WHERE test_id =:test
GROUP BY group;
-- a continuación, el ji-cuadrado contra las proporciones esperadas

Participación/Completion por grupo:

sql
WITH eligible AS (
SELECT user_id FROM users
WHERE last_active_at >=:start - INTERVAL '14 day'
), joined AS (
SELECT DISTINCT user_id FROM event_join
WHERE event_id =:event AND ts BETWEEN:start AND:end
), started AS (
SELECT DISTINCT user_id FROM mission_progress
WHERE ts BETWEEN:start AND:end AND mission_id IN (:missions)
), completed AS (
SELECT DISTINCT user_id FROM mission_complete
WHERE ts BETWEEN:start AND:end AND mission_id IN (:missions)
)
SELECT a. group,  COUNT(DISTINCT j. user_id)::float/COUNT(DISTINCT e. user_id) AS participation_gross,  COUNT(DISTINCT s. user_id)::float/COUNT(DISTINCT e. user_id) AS participation_net,  COUNT(DISTINCT c. user_id)::float/NULLIF(COUNT(DISTINCT s. user_id),0) AS completion
FROM eligible e
JOIN assignments a USING (user_id)
LEFT JOIN joined j USING (user_id)
LEFT JOIN started s USING (user_id)
LEFT JOIN completed c USING (user_id)
WHERE a. test_id =:test
GROUP BY a. group;

Net ARPPU y el valor de los premios/bonos:

sql
WITH payors AS (
SELECT DISTINCT user_id FROM payments
WHERE ts BETWEEN:start AND:end
), rev AS (
SELECT user_id, SUM(ggr) AS ggr
FROM revenue
WHERE ts BETWEEN:start AND:end
GROUP BY user_id
), costs AS (
SELECT user_id, SUM(prize + bonus) AS cost
FROM promo_costs
WHERE ts BETWEEN:start AND:end
GROUP BY user_id
)
SELECT a. group,  AVG(COALESCE(r. ggr,0) - COALESCE(c. cost,0)) FILTER (WHERE p. user_id IS NOT NULL) AS net_arppu
FROM assignments a
LEFT JOIN payors p USING (user_id)
LEFT JOIN rev r USING (user_id)
LEFT JOIN costs c USING (user_id)
WHERE a. test_id =:test
GROUP BY a. group;

CUPED (ejemplo):

sql
-- pre_value: puntos/ingresos antes de la prueba; valor: durante la prueba
SELECT group,    AVG(value - theta pre_value) AS cuped_mean
FROM (
SELECT a. group, x.user_id, x.value, x.pre_value,     (SELECT COVAR_SAMP(value, pre_value)/VAR_SAMP(pre_value)
FROM x) AS theta
FROM assignments a
JOIN x ON x.user_id = a. user_id
WHERE a. test_id =:test
) t
GROUP BY group;

11) Efectos privados y heterogeneidad

Compruebe los efectos HET:

Novatos vs core, low-value vs high-value, diferentes plataformas/geo.
A veces, una nueva fórmula de gafas «enciende» la mid-core sin cambiar las ballenas es el resultado deseado.
Realice una preinscripción de segmentos para no atrapar «p-hacking».

12) Trampas frecuentes

1. Una tabla de liderazgo común para todos los grupos → interferencia.

2. Cambiar la estructura de los premios durante la prueba → incomparable.

3. Las gafas de Pharm con microestables → uplift inválido.

4. SRM y «filtros flotantes» en ETL → estimaciones sesgadas.

5. Confiar en el ARPPU «cargado» sin deducir premios/bonificaciones.

6. Parada temprana debido a las fluctuaciones sin estadísticas secuenciales correctas.

13) Bayes vs frecuencia y soluciones sucesivas

Framework: se puede utilizar un enfoque bayesiano (diferencia métrica a posteriori, probabilidad «B mejor que A»), especialmente cuando se monitorea en el tiempo.

Precaución: los banditos para las reglas de puntos son adecuados después de uplift confirmado - en la fase de operación, no en la validación primaria.

14) Juego y cumplimiento responsables

Reglas transparentes y capas: el jugador debe entender cómo gana puntos.

Límites de actividad y depósitos, «pausas» y pistas de RG.

No hay «penalizaciones» ocultas por el estilo de juego.

15) Mini caso (sintético)

Contexto: evento semanal, A = «puntos por 1 € apuesta», B = «puntos por multiplicador win/bet, cap = 50/apuesta».

Tamaño: 2 × 10.000 usuarios, estratificación por estado de pago. SRM - aprox.

Resultados:

Participation_net: A 17,3% → B 22,1% (+4,8 п.п.).
Completion: A 38,9% → B 44,0% (+5,1 п.п.).
Net ARPPU: A 41,2 € → B 43,5 € (+ 2,3 €) con Prize + Bonus per payer ≈ 6,4 € (sin cambios).
Quejas/1k: sin cambios; Banderas de Frod ↓0,3 p.p. a expensas de las gotas.
Conclusión: la regla B es la ganadora; escalamos con la «cola larga» de los premios y guardamos las gotas.

16) Lista de comprobación de inicio A/B por puntos

Unidad = usuario, sticky-assignment, estratificación.
Mandos separados/normalización para eliminar la interferencia.
Gafas claras, señales antibot, KYC a los grandes medallistas.
Pregrabación de hipótesis y métricas (primary/secondary/guardrails).
Plan de potencia y duración, estacionalidad tomada en cuenta.
CUPED/covariables conectados, alertas SRM pipeline.
Дашборд «Reach → Participation → Progress → Completion → Value».
Informe: aumento en el dinero después de los premios/bonos, cola post-efecto.

La regla de puntos es una palanca de comportamiento. La prueba A/B correctamente diseñada (sin SRM, con antifraude y covariables) permite aumentar la participación, completion y Net ARPPU de forma segura, manteniendo la confianza de los jugadores y la economía de las campañas.