Analyse des anomalies et des corrélations

1) Pourquoi est-ce iGaming

• Détecte tôt les écarts (avant que les KPI et les revenus ne tombent dans les rapports).
• Distingue les échecs de la saisonnalité/actions/tournois.
• Trouve les causes profondes (RCA) au lieu de « traiter les symptômes ».
• Respecte la vie privée et l'éthique (RG/AML) sans distribuer de PII.

2) Typologie des anomalies

Point (point) : Un seul pic/échec (par exemple, spike erreurs PSP).
Série (collective) : séquence de valeurs atypiques (dégradation longue).
Contextuel (contextual) : normal la nuit, anormal le jour (dépend du contexte : heure/pays/canal).
Changement de mode/tendance (changement de point) : niveau, variance, saisonnalité ont changé radicalement.
Structurel : sursaut de passes/doublons, schema drift.
Causalité : le changement de nœud voisin (PSP/fournisseur) a « renversé » notre gamme.

3) Préparation des données et contexte

Calendrier et saisonnalité : Week-end/vacances/tournois/promotions → lignes de base séparées.
Couches d'agrégation : 1-min/5-min/heure, par pays/marque/fournisseur/appareil.
Normalisation : per-capita (par joueur/session), par heure du jour, par FX.
Fiches horaires : rolling mean/std, EWMA, lags, jour de la semaine, « minutes à cut-off ».
Qualité : filtrer les événements tardifs/dupliqués, éliminer les erreurs timezone.

4) Techniques de détection (du simple au hybride)

Statistiques et séries chronologiques

Robust z-score (médiane/IQR), EWMA, décomposition STL (trend/seasonal/remain).
CUSUM/ADWIN - sont sensibles au décalage moyenne/variance.
Points de changement (par exemple PELT/BOCPD) : nous fixons les points de changement de mode.
Prophet/ETS - prévision + corridor de confiance → émissions hors intervalle.

Multidimensionnel/dense

Isolation Forest, LOF, One-Class SVM - quand il y a beaucoup de caractéristiques (PSP, géo, canal, device).
Autoencoder (reconstruction/erreur) pour les modèles complexes.

Flux en ligne

Fenêtres glissantes, sketches quantiles, EWMA + hystérésis ; comptage des données watermarks et late.
« Dual-thresholds » (entrée/sortie de l'anomalie) pour supprimer le drebezer.

Hybride

Règles de domaine (SLO-conscientes) + statistiques/ML → ci-dessus précision et explication.

5) Qualité de détection : Comment mesurer

Precision/Recall/F1 sur les incidents signalés.
ATTD (Average Time To Detect) et TTR (temps avant la normalisation).
Durée bias : amende pour « flashing » (entrées/sorties fréquentes de l'anomalie).
Métriques d'affaires ex post : « combien de tours/dépôts ont été sauvés », « combien de P1 ont été évités ».
Stabilité : proportion de fausses alarmes supprimées ; p95 « nuits tranquilles ».

6) Corrélation, causalité et pièges

Corrélation ≠ causalité : un conducteur commun (action/down externe) peut « conduire » les deux métriques.
Corrélation partielle (conditionnelle), Information mutuelle (MI) - lorsque les liens ne sont pas linéaires.
Granger causality (causalité temporelle) - une série aide à prédire l'autre.
DAG/discovery causal (avec vérification prédictive) - hypothèses sur la direction de l'influence.
Paradox de Simpson : les agrégats « mentent » sans stratification (pays/canal/appareil).
Leakage : les signes contenant les informations futures donnent des raisons fausses.

7) Root-Cause Analysis (RCA)

Graphique de dépendance : fournisseurs de jeux → lobby → paris → paiements/PSP → KPI.
Scan par mesure : qui est « cassé » ? (pays, marque, fournisseur, mode de paiement, OS).
Groupes de contraste : où il y a ou non anomalie → risque relatif/odds ratio.
Shapley/Feature attribution pour les modèles multidimensionnels d'anomalies.
Scénarios « si » : Déconnecte le segment suspect - KPI est-il rétabli ?

8) Réduction du bruit et priorité

Hystérésis : « 3 fenêtres sur 5 sont cassées » pour confirmation.
Seuils dynamiques : baseline ± k· σ, quantile 5/95, profils saisonniers.
Regroupement : un incident par « fournisseur A » au lieu de 300 alerts par jeu.
SLO-conscience : alertim seulement si SLO/seuil d'affaires sont touchés.
Suppressions : N alerts pour un maximum de T minutes par ensemble de labels.

9) Convoyeur : en ligne et hors ligne

En ligne : Flink/Spark Streaming/CEP - fenêtres minutes, watermarks, déduplication, idempotence.
Hors ligne : bagatelles pour une année d'histoire, injection d'incidents « synthétiques », comparaison des candidats.
ModelOps : inversion des règles/modèles (MAJOR/MINEUR/PATCH), shadow/canary et rollback pour les règles.

10) Vie privée, éthique, conformité

Zero-PII en dattes et alerts ; jetons au lieu d'identifiants.
RG/AML : canaux et accès séparés ; redaction du texte.
Bias : vérifiez la dispersion des mesures sensibles (pays/méthode/appareil) - ne transformez pas une anomalie en discrimination.
Legal Hold/DSAR : stockage de l'historique des détections/solutions - WORM logs.

11) Case iGaming (modèles prêts à l'emploi)

Paiements/PSP

Détection : 'success _ rate _ deposits _ 5m ↓' ci-dessous baseline_28d 3 σ, confirmation 3/5 fenêtres → P1.
RCA : coupe selon 'psp, country, method' ; vérification des files d'attente/retraits.

Fournisseurs de jeux

Détection : 'rounds _ per _ min' du fournisseur A <60 % de la rolling_quantile (0. 1) pour 28d → P1.
Action : masquer les secrets des jeux A, avertir le fournisseur, changer de lobby.

RG

Détection : 'high _ risk _ share' ↑ à> 3 pp pour 10 min dans la marque B → P2.
RCA : campagnes/bonus, surtension de nouveaux appareils, géo-décalage.

Antifrod

Détection : 'chargeback _ rate _ 60m> μ + 3 σ'Et 'new _ device _ share ↑' → P1.
Action : resserrer le scoring/limites de retrait.

12) Artefacts et modèles

12. 1 règles YAML (en ligne)

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 hors ligne-baktest

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 Passeport d'incident RCA

Incident : drop rounds @ provider A

Période : 2025-11-01 18 : 10-18 : 35 (Europe/Kyiv)

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

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

Contrargents : payments OK, PSP OK, FX/stats normaux

Actions : hide tiles, contact fournisseur, bannière de statut

Résultat : récupération @ 18:34 ; pertes évitées X

13) Mesures du succès du processus

Precision/Recall/F1 sur les incidents P1/P2 (marquage par les propriétaires de domaine).
ATTD/MTR en minutes (médiane/p90).
Noise↓ : − X % des alarmes « fausses nocturnes », ≤ Y alerts/poste.
RCA-time : médiane du temps jusqu'à la cause première.
Business saved : évaluation des dépôts/rondes en attente.
Coverage : ≥ 95 % des voies critiques sous surveillance.

14) Processus et RACI

Domain Owners (R) - règles/lignes de base/marquage des incidents.
Data Platform/Observability (R) - moteur de détection, stockage, SLO.
ML Lead (R) - modèles d'anomalies, étalonnage, fairness.
SRE/SecOps (R) - intégration avec SOAR/PagerDuty, incidents.
CDO/DPO (A) - Politique de confidentialité/éthique, Zero-PII.
Product/Finance (C) - seuils de SLO et priorités d'affaires.

15) Feuille de route pour la mise en œuvre

0-30 jours (MVP)

1. Chemins critiques : payments, game_rounds, freshness ingest.
2. Lignes de base par heure/jour et dimensions clés (pays/marque/psp/fournisseur).
3. Détecteurs simples : EWMA/robuste z-score + hystérésis.
4. Chaînes Alert et 3 runbook 'a (paiements/jeux/DQ).
5. Les bâtards pour 3-6 mois de l'histoire ; marquage des incidents.

30-90 jours

1. Changements de points, quantiles seasonaux, séries multimodales.
2. Isolation Forest/LOF pour les cas multidimensionnels ; mode shadow.
3. Graphique RCA des dépendances et attribut semi-automatique.
4. Seuils conscients de SLO ; suppression/grouping; tickets avec remplissage automatique.

3-6 mois

1. Champion-Challenger des règles/modèles ; Auto-tuning des seuils.
2. Intégrations externes (fournisseurs/PSP) avec webhooks signés.
3. Rapports sur « la contribution des alerts à MTTR/recettes » ; les séances trimestrielles d'hygiène.
4. Expériences causales pour des corrélations controversées (A/B, Granger, variables instrumentales).

16) Anti-modèles

Seuil « par œil » commun à tous les pays/heures/canaux.
Ignorer la saisonnalité/les actions → la « tempête » des fausses alertes.
Il n'y a pas de backtest ou d'incident - rien à optimiser.
Chercher des corrélations sans stratification/partial corr → de fausses raisons.
Logs/alerts avec PII, captures d'écran dans les canaux partagés.
Règles « éternelles » sans révision et sans propriétaire.

17) Sections connexes

Alertes des flux de données, pratiques DataOps, API analytiques et métriques, Audit et versionalité, MLOps : exploitation des modèles, Contrôle d'accès, Sécurité et cryptage, Politiques de stockage, Réduction des biais.

Résultat

L'analyse des anomalies et des corrélations n'est pas une « magie ML », mais un système d'ingénierie : contexte et saisonnalité corrects, règles et modèles hybrides, métriques de qualité strictes et gérées par RCA. Dans iGaming, un tel système réduit MTTR, protège les revenus et maintient la confiance des joueurs et des régulateurs - sans violation de la vie privée.