Análisis de anomalías y correlaciones

1) Por qué es iGaming

• Detecta las desviaciones temprano (antes de que los KPI y los ingresos caigan en los informes).
• Distingue fallas de estacionalidad/promociones/torneos.
• Encuentra las causas de origen (RCA) en lugar de «tratar los síntomas».
• Respeta la privacidad y la ética (RG/AML) sin repartir PII.

2) Tipología de anomalías

Punto (point): pico/fallo unitario (por ejemplo, spike errores PSP).
Serie (collective): secuencia de valores atípicos (degradación prolongada).
Contextual (contextual): normal por la noche, anormal por el día (depende del contexto: hora/país/canal).
Cambio de modo/tendencia (change-point): el nivel, la varianza, la estacionalidad han cambiado drásticamente.
Estructural: salto de pases/duplicados, schema drift.
Causal: el cambio de nodo adyacente (PSP/proveedor) ha «revertido» nuestra serie.

3) Preparación de datos y contexto

Calendario y estacionalidad: fines de semana/vacaciones/torneos/promociones → líneas base separadas.
Capas de agregación: 1-min/5-min/hora, por país/marca/proveedor/dispositivo.
Normalización: per-capita (por jugador/sesión), según la hora del día, por FX.
Fichi del tiempo: rolling mean/std, EWMA, lags, día de la semana, «minutos a cut-off».
Calidad: filtramos eventos/duplicados tardíos, eliminamos errores de timezone.

4) Técnicas de detección (de simple a híbrido)

Estadísticas y series cronológicas

Robust z-score (mediana/IQR), EWMA, descomposición STL (trend/seasonal/remain).
CUSUM/ADWIN - sensibles al cambio de media/varianza.
Puntos de cambio (por ejemplo, PELT/BOCPD): fijamos los puntos de cambio de modo.
Prophet/ETS - pronóstico + corredor de confianza → emisiones fuera de intervalo.

Multidimensional/densual

Bosque de Isolación, LOF, Uno-Clase SVM - cuando hay muchas características (PSP, geo, canal, dispositivo).
Autoencoder (reconstrucción/error) para patrones complejos.

Flujos en

Ventanas deslizantes, sketches cuantiles, EWMA + histéresis; contabilidad de watermarks y datos late.
«Dual-thresholds» (entrada/salida de la anomalía) para suprimir el drebezg.

Híbrido

Reglas de dominio (SLO-consciente) + estadísticas/ML → mayor precisión y explicabilidad.

5) Calidad de detección: cómo medir

Precision/Recall/F1 por incidentes marcados.
ATTD y TTR (tiempo antes de la normalización).
Duration bias: penalización por «parpadeo» (entradas/salidas frecuentes de la anomalía).
Métricas de negocio ex-post: «cuántas rondas/depósitos se han salvado», «cuántos P1 se han impedido».
Estabilidad: proporción de falsas alarmas suprimidas; p95 «noches tranquilas».

6) Correlación, causalidad y trampas

Correlación ≠ causalidad: un controlador común (promoción/down externo) puede «liderar» ambas métricas.
Correlación parcial (condicional), Información mutua (MI) - cuando las conexiones no son lineales.
Causalidad Granger (causalidad temporal) - una serie ayuda a predecir la otra.
El descubrimiento DAG/causal (con verificación predictiva) son hipótesis sobre la dirección de la influencia.
Paradox de Simpson: unidades «mentiras» sin estratificación (país/canal/dispositivo).
Leakage: los signos que contienen información futura dan razones falsas.

7) Root-Cause Analysis (RCA)

Gráfico de dependencia: proveedores de juegos → lobby → apuestas → pagos/PSP → KPI.
Scan por dimensiones: ¿quién se ha «roto»? (país, marca, proveedor, método de pago, SO).
Grupos de contraste: donde hay/no anomalía → riesgo relativo/odds ratio.
Atribución Shapley/Feature para modelos multidimensionales de anomalías.
Scripts de «qué si»: deshabilita el segmento sospechoso: ¿se está recuperando el KPI?

8) Cancelación de ruido y priorización

Histéresis: «3 de las 5 ventanas están rotas» para confirmar.
Umbrales dinámicos: baseline ± k· σ, cuantil 5/95, perfiles estacionales.
Agrupación: un incidente en el «proveedor A» en lugar de 300 alertas por juego.
SLO-mindfulness: alertis sólo si el SLO/umbral de negocio está afectado.
Supresas: N alertas en un máximo de T minutos por juego de labels.

9) Transportador: en línea y fuera de línea

En línea: Flink/Spark Streaming/CEP - ventanas de minutos, watermarks, deduplicación, idempotencia.
Offline: Backtests para un año de historia, inyección de incidentes «sintéticos», comparación de candidatos.
ModelOps: versionando reglas/modelos (MAJOR/MINOR/PATCH), shadow/canary y rollback para reglas.

10) Privacidad, ética, cumplimiento

Cero-PII en fichas y alertas; tokens en lugar de identificadores.
RG/AML: canales y accesos separados; redacción de texto.
Bias: compruebe la dispersión en las mediciones sensibles (país/método/dispositivo) - no convierta la anomalía en discriminación.
Legal Hold/DSAR: almacenamiento del historial de detección/solución - registro WORM.

11) Casos de iGaming (plantillas terminadas)

Pagos/PSP

Detección: 'success _ rate _ deposits _ 5m ↓' debajo baseline_28d 3 σ, confirmación de 3/5 ventanas → P1.
RCA: corte por 'psp, país, método'; comprobación de colas/retiros.

Proveedores de juegos

Detección: 'rounds _ per _ min' del proveedor A <60% de rolling_quantile (0. 1) por 28d → P1.
Acción: ocultar los títulos de los juegos A, notificar al proveedor, cambiar el lobby.

RG

Detección: 'high _ risk _ share' ↑ en> 3 p.p. por 10 min en la marca B → P2.
RCA: campañas/bonos, estallido de nuevos dispositivos, geo-cambio.

Antifraude

Detección: 'chargeback _ rate _ 60m> μ + 3 σ' Y 'new _ device _ share ↑' → P1.
Acción: apriete la puntuación/los límites de salida.

12) Artefactos y patrones

12. 1 reglas YAML (en línea)

yaml rule_id: psp_success_drop severity: P1 source: stream:payments. metrics_1m baseline: {type: seasonal_quantile, period: P28D, quantile: 0. 1, by: [hour, dow, country, psp]}
detect:
type: ratio_below value: 0. 6 confirm: {breaches_required: 3, within: PT5M}
labels: {psp: "$psp", country: "$country"}
actions:
- route: pagerduty:payments
- soars: [{name: switch_psp, params: {backup: "PSP_B"}}]
privacy: {pii_in_payload: false}
version: 1. 4. 0

12. 2 Config offline-backtest

yaml dataset: payments_gold period: {from: "2025-07-01", to: "2025-10-31"}
inject_scenarios:
- type: level_shift target: success_rate where: {psp: "PSP_A", country: "EE"}
from: "2025-09-15T12:00Z"
delta: -0. 02 metrics: [precision, recall, f1, attd_sec]

12. 3 pasaporte RCA-incidente

Incidente: drop rounds @ provider A

Período: 2025-11-01 18: 10-18: 35 (Europa/Kyiv)

Root-node: `games. engine. provider_A` (change-point @18:12)

Аффект: `lobby_clicks ↓`, `rounds_per_min ↓ 45%`, `GGR/min ↓ 28%`

Contraargumentos: payments OK, PSP OK, FX/stats normales

Acciones: hide tiles, contacto del proveedor, banner de estado

Resultado: recuperación @ 18:34; pérdidas evitadas por X

13) Métricas del éxito del proceso

Precision/Recall/F1 de incidentes P1/P2 (marcado por los propietarios de los dominios).
ATTD/MTTR en minutos (mediana/p90).
Noise↓: −X% de alarmas «falsas nocturnas», ≤ Y alertas/turno.
RCA-time: la mediana del tiempo hasta la causa raíz.
Business saved: evaluación de depósitos retenidos/rondas.
Coverage: ≥ el 95% de las rutas críticas bajo vigilancia.

14) Procesos y RACI

Domain Owners (R): reglas/líneas base/marcas de incidentes.
Plataforma de datos/Observabilidad (R): motor de detección, almacenamiento, SLO.
ML Lead (R): modelos de anomalías, calibración, fairness.
SRE/SecOps (R) - integración con SOAR/PagerDuty, incidentes.
CDO/DPO (A) - Política de privacidad/ética, Zero-PII.
Product/Finance (C): umbrales de SLO y prioridades empresariales.

15) Hoja de ruta para la implementación

0-30 días (MVP)

1. Rutas críticas: payments, game_rounds, freshness ingest.
2. Líneas de base por reloj/día y mediciones clave (país/marca/psp/proveedor).
3. Detectores simples: EWMA/robust z-score + histéresis.
4. Canales de alertas y 3 runbook 'a (pagos/juegos/DQ).
5. Bektests en 3-6 meses de historia; marcando incidentes.

30-90 días

1. Change-points, seasonal quantiles, series multimodales.
2. Isolation Forest/LOF para casos multidimensionales; modo shadow.
3. Gráfico RCA de dependencias y atribución semiautomática.
4. Umbrales conscientes de SLO; suppression/grouping; tickets autocompletados.

3-6 meses

1. Champion-Challenger reglas/modelos; ajuste automático de los umbrales.
2. Integraciones externas (proveedores/PSP) con webhooks firmados.
3. Informes «contribución de alertas a MTTR/ingresos»; Sesiones trimestrales de higiene.
4. Experimentos causales para correlaciones controvertidas (A/B, Granger, variables instrumentales).

16) Anti-patrones

Umbral «por ojo» común a todos los países/horas/canales.
Ignora la estacionalidad/acciones → la «tormenta» de alertas falsas.
No hay backtests y marcas de incidentes - no hay nada que optimizar.
La búsqueda de correlaciones sin estratificación/corr parcial → razones falsas.
Registros/alertas con PII, capturas de pantalla en canales compartidos.
Reglas «eternas» sin revisión y propietario.

17) Secciones relacionadas

Alertas de flujos de datos, prácticas de DataOps, API de análisis y métricas, Auditoría y versionabilidad, MLOps: explotación de modelos, Control de acceso, Seguridad y cifrado, Políticas de retención de datos, Reducción de sesgos.

El análisis de anomalías y correlaciones no es una «magia ML», sino un sistema de ingeniería: contexto y estacionalidad correctos, un híbrido de reglas y modelos, estrictas métricas de calidad y controlados por RCA. En iGaming, este sistema reduce el MTTR, protege los ingresos y mantiene la confianza de los jugadores y reguladores, sin violar la privacidad.