Synchronisation des données analytiques

1) Pourquoi l'écosystème synchronise l'analyse

Le réseau regroupe les opérateurs, les studios/RGS, les affiliés, les PSP/APM, les fournisseurs KYC/AML et les médias. Pour voir une seule image (vortex de CR→FTD→ARPU/LTV, RG/conformité, SLO de transport, finance/RevShare), l'écosystème a besoin d'une synchronisation canonique, opportune et prouvable des données entre les chaînes et les vitrines - sans « deux vérités », avec une histoire claire de changement et de contrôle des coûts.

2) Ontologie et contrats de données

Сущности: `eventId`, `traceId`, `participantId`, `role` (operator/studio/affiliate/psp/kyc/stream), `jurisdiction`, `brandId`, `campaignId`, `apmRouteId`, `gameId`, `tableId`, `currency`, `schemaVersion`, `formulaVersion`.

• `click`, `session_start`, `registration`, `kyc_status`, `deposit`, `ftd`, `bet/spin`, `reward_granted`, `withdrawal`, `postback_sent/received`, `rg_guardrail_hit`, `stream_sli`.

• schémas dans Schema Registry (semver, compatibilité des champs) ;
• propriétaires, fenêtres d'agrégation, SLA de fraîcheur et d'exhaustivité ;
• la politique d'erreur (nullable/stop), les annuaires (devises, locals, profils RTP).

Metric Store : versions des formules (GGR/NetRev/CR/ARPU/LTV, facteurs K), leurs propriétaires et la date d'entrée en vigueur - la formule est toujours prise en compte dans le rapport.

3) Sémantique temporelle et fenêtres

Event Time vs Processing Time : les agrégations doivent être basées sur l'heure de l'événement et non sur le traitement.
Watermarks : pour contrôler les événements « tardifs » ; une politique de prépresse (par exemple, T + 24h).
Fenêtres : glissières/calendaires, avec recalculage lors des dogmes.
Retard comme métrique : 'ingest _ lag' et 'publish _ lag' sont publiés pour chaque vitrine.

4) Modes de transport et de synchronisation

1. CDC/streaming (temps réel) :

Bus d'événements (EDA), lot par 'traceId/participantId' ;

« une seule fois au sens du terme » par l'idempotence des consommateurs et des corps ;

topics supervisés : événements bruts, normalisés, agrégats/oracles.

2. Batch/microbatch :

Décharges incrémentielles avec pagination de curseur (curseurs temporaires/logs) ;

formats : Parquet/Avro avec schéma ; les manifestes des partis.

3. API/webhooks :

'/vN/events 'avec les curseurs et' Idempotency-Key ';

Webhooks signés (JWS/HMAC), registre de replay, backoff + jitter.

4. Asset-sink :

guides/locals/catalogues de jeux comme des gangs versionnés (hashi, TTL).

5) Idempotence, dedup et événements tardifs

Idempotency-Key et hachage du corps sur les chemins critiques (paiements/postbacks).
Déduplication : fenêtre ± 5 minutes/par watermark ; stockage des hachages « visibles ».
Événements tardifs : politique d'upsert/recalculage ; changelog vitrine.
Exactly-once par sens d'affaires : nous n'exigeons pas la « magie du courtier », nous exigeons l'idempotence des consommateurs et la déterminisme des régimes.

6) Harmonisation de l'attribution et des formules

Attribution : la règle de la touche de dernière chose avec des fenêtres sur les canaux/juridictions, cross device - seulement à travers les tokens (pas de PDn cru).
Formules métriques : chaque entrée fait référence à « formulaVersion » ; Les modifications MAJOR sont publiées sous la forme d'événements 'data _ formula _ change'.
Backfill selon les règles : lorsque vous changez de formule, une double publication (ancienne/nouvelle) est autorisée pendant la période de transition (frozen-period).

7) Qualité des données : SLI/SLO et tests de conformation

• Fraîcheur (publish_lag p95),
• Exhaustivité (proportion d'événements vs référence),
• Unicité (proportion de doublons),
• Cohérence (monnaie/local/ID),
• Précision (montants de contrôle/oracles),
• Linéarité de l'heure (événements tardifs dans le couloir).

• publish_lag p95 ≤ 1-5 s (panneaux d'exploitation), ≤ 15 min (fin. agrégats) ;
• exhaustivité ≥ 99. 5 % en T + 15 min, ≥ 99. 9 % en T + 24h ;
• doublons ≤ 0. 1‰; divergence avec l'oracle ≤ 0. 1–0. 3%.

Tests de conformité : schémas, champs obligatoires, guides, signatures de webhooks, déchargement de curseurs sans laissez-passer.

8) Lineage, audit et oracles

Lineage : de la vitrine/dashboard aux ensembles primaires (schémas/versions/propriétaires).
Audit WORM : journaux de schémas/formules/clés/exceptions immuables.
Oracles (résumés signés) : GGR/NetRev/SLO/RG avec 'formulaVersion', 'hash (inputs)', 'kid', 'traceId' est la source de vérité pour les factures et les appels.
Paquets d'essai : SLA 60-90 s pour les incidents P1/P2.

9) Confidentialité, localisation et sécurité

Minimisation des PII : Tokenization de 'playerId', interdiction des PDn dans les logs/vitrines, désintoxication uniquement dans les zones de coffre-fort.
Localisation : cartes des juridictions (où nous stockons/traitons les classes de données).
Zero Trust : mTLS, jetons à courte durée de vie, egress-allow-list, rotation de clé/JWKS.
ABAC/ReBAC/SoD : accès « vu le mien et convenu » ; « je mesure ≠ influence ≠ je change ».

10) Reconnaissance et calculs financiers

[
NetRev = GGR - BonusCost - Jackpot/PoolShare - PaymentFees - Chargebacks - Tax/Levy - FraudLosses
]

• déchargement de curseurs, « aigles » (unités signées), montants de contrôle ;
• les statuts de la facture, les actes de divergence et l'analyse des SLA ;
• Les règles FX, les NET7/14/30, les holds et les clau-backs.

11) Gestion du coût de synchronisation

Politiques de cardinalité : interdiction de 'userId '/URL brute dans les labels ; « routeId/campagneId » est autorisé.
Downsampling/roll-ups: 1с→1м→5м; Les données RAW sont courtes, les agrégats sont plus longs.
Samples adaptatifs : pourcentage de base + priorité pour les erreurs/chemins lents/nouvelles versions.
SLO-first : nous ne collectons que ce qui soutient les solutions (SLO/Finance/RG).

12) Dashboards de synchronisation

Data Sync Aperçu : publish_lag, completeness, duplicates, late ratio, schema drift, erreurs de conformation.
Attribution Santé : actualité des postbacks, fenêtres de dedup, cas controversés.
Finances/Oracle : divergence des agrégats avec les oracles, statuts des factures.
Carte de jurisprudence : localisation/flux PDn, conformité DPA/DPIA.

13) Opérations, incidents, RCA

Alerts : burn-rate par fraîcheur/complétude, dérive des schémas, surtension des doublons.
Salle de guerre : playbooks prêts pour pneus/webhooks/CDC/vitrine ; boutons stop pour les agrégations/formules.
RCA "sans recherche coupable" : факт→гипотеза→эксперимент→вывод→действие; post-mortem SLO.

14) Anti-modèles

« Deux vérités » par métriques/formules et dates d'entrée.
Offset-pagination de l'histoire sous charge (curseurs uniquement).
PDn brut dans les loges/vitrines ; pas de tokénisation.
Zoo des post-backs sans signature et idempotence → prises/trous.
Mélange Event/Processing Time dans les agrégations.
Il n'y a pas de politique d'événements tardifs.
Négociation manuelle (Excel/déchargement manuel) au lieu des oracles.
Un grand tableau unique avec une cardinalité illimitée des labels.

15) Chèques-feuilles

Conception

• Ontologie, Schema Registry, propriétaires, manuels.
• Metric Store с `formulaVersion` и frozen-period для MAJOR.
• Sémantique temporelle (event time, watermarks), politique des événements tardifs.
• Transport : EDA/CDC, API/webhooks avec signatures, curseurs, idempotence.
• Données de qualité SLI/SLO, tests de conformité, alertes.
• Privacy/Localization (DPIA/DPA), Zero Trust, ABAC/ReBAC/SoD.
• Oracles et règles de reconnaissance.

Démarrage

• Bac à sable et pneus/vitrines de charge/chaos.
• Synchronisation canarienne 1%→5%→25%→50%→100 % avec les guardrails.
• Dashboards publish_lag/completeness/duplicates/drift.
• Documentation des formules et dates d'entrée ; release-notes `data_formula_change`.

Exploitation

• Rapport hebdomadaire du DQ ; révision du SLO/guardrails.
• Chainjlogs mensuels de schémas/formules/accès.
• DR/xaoc régulier pour le courtier/ingestors/vitrines.

16) Feuille de route pour la maturité

v1 (Fondation) : circuits uniques, CDC/batch de base, curseurs, DQ-SLI, reconnaissance manuelle.
v2 (Intégration) : watermarks et politiques des événements tardifs, oracles, dashboards de synchronisation, auto-retrai avec jitter.
v3 (Automation) : surveillance prédictive de la fraîcheur/complétude, reconnaissance intelligente, auto-réindexation, sampling adaptatif.
v4 (Networked Governance) : échange intercanal d'oracles/signaux de qualité, règles de formule DAO et trésorerie transparente.

17) Les métriques du succès

Qualité des données : publish_lag p95, completeness %, duplicate ‰, late %, schema drift rate.
Uniformité : proportion de rapports avec 'formulaVersion' enregistré, nombre MAJOR sans incident.
Finances : divergence avec les oracles, proportion d'auto-reconnaissance, controverse <X %.
Opérations : incidents de synchronisation MTTD/MTTR, proportion d'auto-stops/rollbacks.
Conformité : 0 fuites PDn, vérification DPIA/DPA réussie, disponibilité des logs WORM 100 %.
Économie de l'observabilité : Cost-to-Sync sur rps/event, respect de la cardinalité.

Résumé succinct

La synchronisation des données analytiques n'est pas une copie de tables, mais un protocole de confiance et de temps : canonique des schémas et des formules, event-time avec watermarks, curseurs et idempotence, dedup et événements tardifs, DQ-SLO et oracles, confidentialité et localisation. En suivant ce cadre, l'écosystème obtient une analyse unique, fraîche et éprouvée - la base de solutions rapides, de calculs honnêtes et de croissance évolutive du réseau.