Analisi delle anomalie e delle correlazioni

1) Perché questo iGaming

• Rileva presto le deviazioni (prima che KPI e i ricavi scendano nei rapporti).
• Differenzia i guasti da stagionalità/azioni/tornei.
• Trova la causa primaria (RCA) invece di «trattare i sintomi».
• Rispetta la privacy e l'etica (RG/AML) senza distribuire PII.

2) Tipologia di anomalie

Punti (point) - Picco singolo/fallimento (ad esempio, spike errori PSP).
Di serie - Sequenza di valori non comuni (degrado prolungato).
Contestuale - Normale di notte, anomala di giorno (dipende dal contesto: ora/paese/canale).
Cambio di modalità/trend (change-point) - Il livello, la dispersione e la stagionalità sono cambiati drasticamente.
Struttura: aumento di omissioni/duplicati, schema draft.
Causa-effetto: la modifica del sito adiacente (PSP/provider) ha «spezzato» la nostra fila.

3) Elaborazione dei dati e contesto

Calendario e stagionalità: fine settimana/festività/tornei/promozioni → linee di base separate.
Livelli di aggregazione: 1-min/5-min/h, paese/marchio/provider/dispositivo.
Normalizzazione: per-capita (per giocatore/sessione), ora del giorno, FX.
Phicky time: rolling mean/std, EWMA, lagi, giorno della settimana, «minuti a cut-off».
Qualità: filtriamo gli eventi/duplicati in ritardo, eliminiamo gli errori timezone.

4) Metodi di rilevamento (da semplice a ibrido)

Statistiche e righe temporali

Robust-score (mediana/IQR), EWMA, decomposizione STL (trend/seasonal/remain).
CUSUM/ADWIN - Sensibili allo spostamento della media/dispersione.
Change-point (ad esempio PELT/BOCPD) - Fissa i punti di cambio di modalità.
Prophet/ETS - previsione + corridoio di fiducia per le emissioni fuori intervallo.

Multitasking/densità

Isolation Forest, LOF, One-Class SVM - quando molti segni (PSP, geo, canale, device).
Autoencoder (ricostruzione/errore) per pattern complessi.

Flussi online

Finestre che scivolano, sketch quantili, EWMA + isteresi; contabilità di watermarks e late data.
Dual-thresholds (ingresso/uscita dell'anomalia) per sopprimere il drebising.

Ibrido

Le regole di dominio (SLO-consapevoli) + statistiche/ML sono più accurate e spiegabili.

5) Rilevamento di qualità: come misurare

Precision/Recall/F1 per gli incidenti segnati.
ATTD (Average Time To Detect) e TTR (tempo fino alla normalizzazione).
Duration bias - Multa lampeggiante (frequenti ingressi/uscite da anomalie).
Ex post metriche aziendali: «quanti round/depositi salvati», «quanti P1 hanno impedito».
Stability: percentuale di false allarmi soppressi; «notti tranquille».

6) Correlazione, causalità e trappole

Correlazione causale: il driver generico (azione/down esterno) può «guidare» entrambe le metriche.
Partial correlation (condizionale), Mutual Information (MI) - Quando le relazioni non sono lineari.
Granger causality - una serie aiuta a prevedere l'altra.
DAG/causal discovery (con controllo predittivo) è un'ipotesi di direzione d'influenza.
Simpson's paradox - Le unità mentono senza stratificazione (paese/canale/dispositivo).
Leakage - I segni che contengono informazioni future forniscono falsi motivi.

7) Root-Cause Analysis (RCA)

di Dipendenze: provider di giochi nella lobby dei tassi di pagamento PSP/KPI.
Scan, chi si è rotto? (paese, marchio, provider, metodo di pagamento, sistema operativo).
Gruppi di contrasto: se l'anomalia è o meno un rischio relativo/odds ratio.
Shapley/Feature utente per modelli multi-dimensioni di anomalie.
Script se - Disattiva il segmento sospetto - KPI viene ripristinato?

8) Rumore e priorità

Isteresi, «Le 3 delle finestre sono state 5 ate».
Soglie dinamiche: baseline © k· , quantile 5/95, profili stagionali.
Un incidente sul provider A, invece di 300 di gioco.
La consapevolezza SLO è alerticabile solo se si colpisce la soglia SLO/Business.
Supressi: N alert per un massimo di T minuti per set labels.

9) Catena di montaggio online e offline

Online: Flink/Spark Streaming/CEP - finestre minuti, watermarks, deduplicazione, idampotenza.
Battistest per un anno di storia, iniezione di incidenti «sintetici», confronto tra candidati.
ModelOps: versioning delle regole/modelli (MAJOR/MINORE/PATCH), shadow/canary e rollback per le regole.

10) Privacy, etica, compilazione

Zero-PII in ficce e alert; token al posto degli identificatori.
RG/AML: canali e accessibilità separati; redaction del testo.
Bias: controlla la variazione in misura sensibile (paese/metodo/dispositivo) - Non trasformare l'anomalia in discriminazione.
Legale Hold/DSAR - Loga WORM.

11) Case iGaming (modelli finiti)

Pagamenti/PSP

Rilevamento: 'success _ rate _ deposits _ 5m ' sotto baseline _ 28d su 3 , conferma 3/5 finestre P1.
RCA: taglio dì psp, country, method "; Controlla le code/retrai.

Provider di giochi

Rilevamento: 'rounds _ per _ min'del provider A <60% di rolling _ quantile (0. 1) per 28d P1.
L'azione è nascondere i timer dei giochi A, avvisare il provider, cambiare la lobby.

RG

Rilevamento: «high _ risk _ share» per> 3 p per 10 min nel marchio B-P2.
RCA: campagne/bonus, nuovi dispositivi in espansione, geo-spostamento.

Antifrode

Rilevamento: 'chargeback _ rate _ 60m> + 3 E' new _ device _ share ' P1.
Azione: rigidificare lo screening/i limiti di output.

12) Manufatti e modelli

12. 1 regole YAML (online)

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 battistest

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 Passaporto RCA-incidente

Incidente: drop rounds @ provider A

Periodo 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%`

Contrasti: payments OK, PSP OK, FX/stats normali

Azioni: hide tiles, contatto provider, striscione di stato

Risultato: ripristino @ 18:34; Perdita evitata X

13) Metriche di successo del processo

Precision/Recall/F1 per incidenti P1/P2 (mappatura dei proprietari dei domini).
ATTD/MTTR in minuti (mediana/p90).
X% di «false» allarmi notturni.
RCA-time - Tempo medio fino alla root cause.
Business saved - valutazione dei depositi/round detenuti.
Coverage: ≥ il 95% dei percorsi critici sotto osservazione.

14) Processi e RACI

Domain Owners (R) - regole/linee base/marcatura incidenti.
Data Platform/Observability (R) - Motore di rilevamento, storage, SLO.
ML Lead (R) - Modelli di anomalie, calibrazione, fairness.
SRE/SecOps (R) - integrazione con i SOAR/PagerDuty, incidenti.
CDO/DPO (A) - Politica di privacy/etica, Zero-PII.
Product/Finance (C) - soglie SLO e priorità aziendali.

15) Road map di implementazione

0-30 giorni (MVP)

1. Percorsi critici: payments, game _ rounds, freshness ingest.
2. Linee base per orologio/giorno e misure chiave (paese/marchio/psp/provider).
3. Rilevatori semplici: EWMA/robust z-score + isteresi.
4. Canali di alert e 3 runbook 'a (pagamenti/giochi/DQ).
5. Bectesti a 3-6 mete di storia; Rilevamento degli incidenti.

30-90 giorni

1. Change-point, seasonal quantiles, file multimodali.
2. Isolation Forest/LOF per valigette multi-dimensioni; modalità shadow.
3. Il grafico RCA delle dipendenze e l'attributo semiautomatico.
4. Soglie SLO-consapevoli; suppression/grouping; Ticket con completamento automatico.

3-6 mesi

1. Campione-Challenger regole/modelli l'auto-tuning delle soglie.
2. Integrazioni esterne (provider/PSP) con webhoop firmati.
3. Report «contributo degli alert a MTTR/ricavato»; Sessione di igiene trimestrale.
4. Esperimenti Causal per correlazioni controverse (A/B, Grander, variabili utensili).

16) Anti-pattern

La soglia dell'occhio è comune a tutti i paesi/ore/canali.
Ignorando la stagionalità/le azioni della bufera di falsi alert.
Niente battistesti, niente segni di incidenti, niente da ottimizzare.
La ricerca di correlazioni senza stratificazione/partial corr è un falso motivo.
Loghi/alert con PII, screenshot nei canali comuni.
Regole «eterne» senza revisione né proprietario.

17) Sezioni correlate

Alert da flussi di dati, EP, API di analisi e metriche, Verifiche e versioni, MLOs: utilizzo dei modelli, Controllo degli accessi, Sicurezza e crittografia, Criteri di storage, Riduzione dei pregiudizi.

Totale

L'analisi delle anomalie e delle correlazioni non è una magia ML, ma un sistema ingegneristico: un contesto corretto e stagionale, un ibrido di regole e modelli, metriche di qualità rigorose e un RCA controllato. Nel iGaming, questo sistema riduce MTTR, protegge i ricavi e mantiene la fiducia degli attori e dei regolatori - senza violazioni della privacy.