GH GambleHub

Telemetria e raccolta eventi

1) Assegnazione e principi

Obiettivi:
  • Flusso unico e prevedibile di eventi per analisti, antifrode, RG, compilation e ML.
  • Traccia completa (user/pression/sollest/trace) e riproducibilità.
  • Ridurre al minimo il PI e soddisfare i requisiti di privacy.

Принципы: schema-first, privacy-by-design, idempotency-by-default, observability-by-default, cost-aware.

2) Tassonomia degli eventi

Pagamenti: 'payment'. deposit`, `payment. withdrawal`, `payment. chargeback`.
Giochi: 'game. session_start/stop`, `game. bet`, `game. payout`, `bonus. applied`.
Personalizzato: 'auth. login`, `profile. update`, `kyc. status_changed`, `rg. limit_set`.
Sala operatoria: 'api. request`, `error. exception`, `release. deploy`, `feature. flag_changed`.
Compagine: 'aml. alert_opened`, `sanctions. screened`, `dsar. requested`.

Ogni tipo ha un proprietario (domain owner), uno schema e un SLO di freschezza.

3) Schemi e contratti

Campi obbligatori (minimo):
  • `event_time` (UTC), `event_type`, `schema_version`, `event_id` (UUID/ULID),
  • `trace_id`/`span_id`, `request_id`, `user. pseudo_id`, `session_id`,
`source` (clientserverprovider), `market` (jurisdiction), `labels.`.
Esempio (JSON):
json
{
"event_id": "01HFY1S93R8X",
"event_time": "2025-11-01T18:45:12. 387Z",
"event_type": "game. bet",
"schema_version": "1. 4. 0",
"user": {"pseudo_id": "p-7a2e", "age_band": "25-34", "country": "EE"},
"session": {"id": "s-2233", "device_id": "d-9af0"},
"game": {"id": "G-BookOfX", "provider": "StudioA", "stake": {"value": 2. 00, "currency": "EUR"}},
"ctx": {"ip": "198. 51. 100. 10", "trace_id": "f4c2...", "request_id": "req-7f91"},
"labels": {"market": "EE", "affiliate": "A-77"}
}

Evoluzione degli schemi: versioni semantiche backward-compatibile - Aggiungiamo campi nullabili; breaking: solo in una nuova versione ('/v2 ') con un periodo di doppia scrittura.

4) Strumenti: dove e come

4. 1 Client (Web/Mobile/Desktop)

Telemetria SDK con buffer locale, invio batch, retrai esponenziali.
Eventi auto: visite, clic, visibilità blocchi, web-vitals (TTFB, LCP, CLS), errori JS.
Identificatori: "device _ id" (sostenibile ma privato), "sessions _ id" (aggiornato), "user. pseudo_id`.
Protezione da «rumore»: Dedotto da «event _ id», trottling, client-side sampling.

4. 2 Server/backend

Gli imballaggi di logger/tracker (OpenTelemetry) → l'emit degli eventi di dominio.
È obbligatorio scorrere «trace _ id» da edge/gateway a tutti i servizi downstream.
Pattern Outbox per la pubblicazione transazionale degli eventi di dominio.

4. 3 Provider/terzi

Connettori (PSP/KYC/Studio) normalizzati agli host Adattatori di versione.
Firma/verifica integrità payload, perimetro di cronologia (ingest audit).

5) OpenTelemetry (OTel)

Trade: ogni richiesta riceve «trace _ id»; Collegare i loghi/eventi attraverso trace _ id/' span _ id '.
Logi: usiamo gli OTEL Logs/convertitori; etichette dell'ambiente 'service. name`, `deployment. env`.
Metriche: RPS/latency/error-rate per servizi, metriche aziendali (GGR, conversione).
Raccoglitore: un unico punto di ricezione/buffer/esportazione in Kafka/HTTP/grafic. pila.

6) Identificatori e correlazione

«event _ id» è l'unicità e l'idimpotenza.
`user. pseudo _ id "è un alias stabile (mupping separato e limitato).
sessione _ id, richiest _ id, trace _ id, device _ id sono obbligatori per un'analisi completa.
Coerenza ID a livello di gateway API e SDK.

7) Semilibertà e controllo del volume

Regole: per-event-type, per-market, per carico dinamico (adattivo).
Gli eventi accuratamente filmati - pagamenti/compliance/incidenti - non sono seminati.
Eventi analitici: è consentito 10-50% con pesi regolatori nelle vetrine.
Server-side downsampling - Valido per le metriche high-frequency.

8) Privacy e compliance

Ridurre al minimo il PII: toccare PAN/BAN/email; Codice IP-geo/ASN a ingest.
Regionalizzazione: invia agli engest-endpoint regionali (EEA/UK/BR).
DSAR/RTBF - Supporto per la dissimulazione selettiva delle proiezioni il registro delle transazioni legali.
Criteri di conservazione: tempi per tipo (analisi più brevi, regolatori più lunghi) Legal Hold.

9) Trasporti e buffering

Client → Edge: HTTPS (HTTP/2/3), 'POST/telemetry/batch' (fino a 100 eventi).
Edge → Shina: Kafka/Redpanda con partitina'user '. pseudo_id`/`tenant_id`.
Formati: JSON (ingest), Avro/Protobuf (in pneumatico), Parket (in lake).
Affidabilità: retrai con jitter, DLQ, poison-pill isolamento.

Specifica batch (semplificata):
json
{
"sdk": {"name":"igsdk-js","version":"2. 7. 1"},
"sent_at": "2025-11-01T18:45:12. 500Z",
"events": [ {... }, {... } ]
}

10) Affidabilità e idepotenza

Client-generated 'event _ id' + deadup server per '(event _ id, source)'.
Outbox nei servizi, Exactly-Once-semantica nei flussi (keyed state + dedupe).
Ordine all'interno della chiave: partizionamento per user/sessions.
Controllo orario: NTP/PTP, deriva valida (ad esempio, ≤ 200 ms), 'received _ at'sul server.

11) Qualità della telemetria (TQ) e SLO

Completeness: ≥ 99. 5% degli eventi di tipo critico per T.
Freshness: p95 ritardo di consegna fino a Silver 15 min.
Correctness: schemi validi 99. 9%, drop-rate < 0. 1%.
Trace coverage - Percentuale di query con 'trace _ id' 98%.
Cost/GB: budget di destinazione per ingest/storage per domini.

12) Osservabilità e dashboard

Widget minimi:
  • Lega ingest (p50/p95) per fonte e regione.
  • Completeness per tipo di evento e mercato.
  • Errori di convalida diagrammi/oversized-payloads.
  • Mappa delle versioni SDK e percentuale di clienti obsoleti.
  • Correlazione web-vitals con conversione/guasto.

13) SDK client: requisiti

Footprint leggero, buffer offline, inizializzazione ritardata.
Impostazioni: sampling, max batch size, max queue age, privacy-moda (no-PII).
Protezione: firma del pacchetto/anti-tamper, rivestimento delle chiavi.
Aggiornamento: flag feature per disattivare gli eventi rumorosi.

14) Livello e protezione Edge

Rate limit, WAF, schema validation, compressione (gzip/br).
Token bucket per cliente; anti-replay ('richiest _ id', TTL).
Ritiro di IP e UA: normalizzazione/arricchimento fuori dal payload grezzo.

15) Integrazione con la catena di montaggio dati

Bronze - payload crudi irreversibili-aggiuntivi (per forensica).
Tabelle normalizzate con deduplicazione/arricchimento.
Gold: vetrine per BI/AML/RG/prodotto.
Linage tra eventi e rapporti; versioni delle trasformazioni.

16) Analisi della qualità del cliente

Coefficiente «clienti silenziosi» (nessun evento in N ore).
Anomalie «tempesta» (mass duplicata/burst).
Quota di SDK obsoleti su versioni e piattaforme.

17) Processi e RACI

R: Data Platform (ingest/bus/validatori), App Teams (strumenti SDK).
A: Head of Data/Architecture.
C: Compliance/DPO (PII/retention), SRE (SLO/incidenti).
I: BI/Marketing/Rischio/Prodotto.

18) Road map di implementazione

MVP (2-4 settimane):

1. Tassonomia eventi v1 + schemi JSON per 6-8 tipi.

2. SDK (Web/Android/iOS) с batch и sampling; Edge `/telemetry/batch`.

3. Livello Kafka + Bronze; Validatori di base e deadup.

4. Dashboard ingest lag/completeness, alert su drop/validatore.

Fase 2 (4-8 settimane):
  • OtTel Collector, correlazione trace; Regolazione silver e regole DQ.
  • Endpoint regionali (EEA/UK), privacy-moda, procedure DSAR/RTBF.
  • Mappa delle versioni SDK, aggiornamenti auto-rollout per anelli.
Fase 3 (8-12 settimane):
  • Exactly-Once nei flussi, Feature Store connettività, fidi antifrode online.
  • Rule-as-Code per diagrammi e validatori, simulazione di modifiche (impact analysis).
  • Ottimizzazione dei costi: adattativo sampling, Z-order/cluster in lake.

19) Scontrino di qualità prima del lancio

  • Sono stati completati i campi di schema obbligatori e i tipi corretti.
  • Sono presenti «trace _ id »/« sollest _ id »/« sessions _ id».
  • SDK supporta batch, retry, sampling.
  • Edge valuta lo schema e limita le dimensioni del payload.
  • Sono attivati i filtri di privacy e la tornizzazione dei campi sensibili.
  • Sono configurati SLO/alert e dashboard.
  • Documentazione dei domini (esempio di evento, owner, SLA).

20) Errori frequenti e come evitarli

Eventi crudi senza schemi - Immettere registry e convalida CI.
Nessuna idempotenza: richiedi «event _ id» e memorizza le finestre di deduplicazione.
Miscelare PII e analisti: separa i mupping, maschera i campi.
Nessun training: inserisci «trace _ id» attraverso il gateway dei servizi di dell'evento.
Volumi non controllati: applica sampling/trrottling e quote budget get.
Global endpoint senza regioni: utilizzare la regionalizzazione e data residency.

21) Glossario (breve)

OpenTelemetry (OTel) è uno standard aperto per trailer/metriche/logi.
Outbox - Pubblicazione transazionale di eventi di dominio.
DLQ - Spunta messaggi.
Sampling - selezionare parte degli eventi per ridurre il volume.
Data Residency - Memorizzazione dei dati nella giurisdizione desiderata.

22) Totale

La telemetria ben progettata è un accordo, non solo un'invio di cassetti ": schemi rigorosi, identificatori coerenti, privacy predefinita, trasporti affidabili, osservabilità e costi convenienti. Seguendo questo articolo, si ottiene un flusso costante di eventi, pronto per analisi, compilation e apprendimento automatico con SLO prevedibile.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.