Architecture des liens de référence

1) Pourquoi l'écosystème a-t-il des liens de référence

• la prévisibilité de l'attribution et des paiements ;
• la vitesse de mise à l'échelle des partenaires ;
• Sécurité/Privacy (PII-minimisation, RG-guardrails) ;
• l'économie (honnête split, Cost-to-Serve, ROI des canaux).

2) Modèles de liens de référence

2. 1 Par profondeur

Niveau unique (L1) : récompense du référent principal pour l'événement cible (FTD/dépôt/activation de la mission).
Multi-niveaux (L2 +) : les parts de paiement montent dans l'arbre de référence ; une limite par niveau/caps/commissions s'applique.
Hybride : L1 fix + petite « fine queue » selon L2.

2. 2 Par porteur d'influence

Affiliation/médias (réseaux, pub, streamers).
User-to-User (codes de référence/liens des joueurs).
Co-brand/B2B (marques/opérateurs partenaires, transitions croisées).

2. 3 Par topologie d'échange

Hub & Spoke : Un seul centre d'attribution et de post-back - une conformation plus facile.
Mesh (fédération) : liens directs entre les chaînes - exige une stricte canonique des événements et des signatures.
Layer-to-Layer : médias → offer → paiements/KUS → jeu (domaines et passerelles clairs).

3) Ontologie et identifiants

3. 1 entités clés

`referrerId`, `referralId`, `playerId` (псевдоним), `affiliateId`, `campaignId`, `offerId`, `routeId`, `operatorId`, `providerId`, `traceId`.

3. 2 Connectivité et intimité

PII est stocké dans les zones de coffre-fort, dans l'échange - seulement les tokens/pseudonymes.
Lien entre le clic et l'événement : 'traceId' va du clic/link à l'enregistrement/dépôt/jeu.
TTL/expiry pour les tokens de refcode ; protection contre le bandage des dispositifs.

4) Modèle d'événement et contrats de données

4. 1 Ensemble minimal d'événements

`ref_click`, `deep_link_open`, `session_start`, `registration`, `kyc_status`, `deposit`, `ftd`, `bet/spin`, `mission_progress`, `reward_granted`, `ref_postback_received`, `fraud_signal`.

4. 2 Exigences relatives aux événements

Versions sémantiques des schémas (Schema Registry), champs obligatoires et valeurs valides.
Idempotence via 'eventId' + fenêtre de déduplication (± 5 min).
Fuseaux horaires - UTC/ISO-8601, tous les montants et devises avec 'currency'.

5) Protocoles : Liens, Diplinks, SmartLink, Postbacks

5. 1 Génération de liens ref

Paramètres : 'rid' (référent), 'cid' (campagne), 'oid' (offer), 'sub1.. sub5', 'utm _', 'traceId'.
Signature des paramètres (JWS/HMAC), TTL, protection contre la substitution ('kid', 'timestamp').

5. 2 SmartLink/Deep Link

SmartLink redirige par géo/juridiction/périphérique/état des itinéraires de paiement SLO.
Deep Link mène à un jeu/location/mission spécifique (vérification de la disponibilité par région/licence).

5. 3 Post-Becky (S2S)

Les webhooks signés sont : 'signature', 'eventId', 'timestamp', 'rid/cid/oid', 'traceId'.
Retrai avec gitter et backoff ; un registre de replay ; déchargement en curseur de l'histoire.

6) Attribution et conflits

6. 1 Règles d'attribution

Last eligible touch avec fenêtres à travers les juridictions et les canaux.
Stitching cross-device via des tokens/fingerrints cohérents (sans PII brut).
Avec des itinéraires en plusieurs étapes - le poids des contributions (voir les split ci-dessous).

6. 2 Résolution des conflits

Priorité du renvoi direct de l'utilisateur sur le clic média si la fenêtre L1 est active.
Frod/non-valide : marques "disputed', cold de paiement avant la reconnaissance.

7) Antifrod et qualité du trafic de référence

Signaux : ferme d'appareils, CTR/CR non naturels, cycles rapides de clics/enregistrements, non-correspondance géo/ASN, brand-bidding, trafic de stimulation sous forme de contenu.
Actions : Auto-refroidissement, pause link/offer, rappel de clés, blacklist de sites, refonte de référence.
Qualité Scorecard : LTV/FTD, rétention, chargeback/bonus-abuse, précision/actualité des postbacks.

8) Calcul des paiements et split

8. 1 Modèles de base

CPA/CPL (fix par événement, par exemple FTD/inscription).
RevShare (part Net Revenue par fenêtre).
Hybride (fix + proportion).
Split à plusieurs niveaux (L1/L2... avec caps/seuils).

8. 2 Formules (simplifiées)

[
share_i=\frac{W_i \cdot Q_i}{\sum_j W_j \cdot Q_j}
]

où (W_i) est le poids de l'étape (L1> L2... ou selon le modèle de contribution du canal), (Q_i) est un facteur de qualité (SLI de livraison, précision des postbacks, absence de frod/drapeaux RG).

[
payout_i = share_i \times (Base\ Reward \ \text{или} \ Net\ Revenue \times rate) \times Adjustments
]

« Adjustments » : crédits/pénalités pour SLO, retenues pour cas controversés, RG/corrections de sanctions.

8. 3 Restrictions et caps

Limites trimestrielles/mensuelles ; paiement minimum ; hold sur la rumeur des événements controversés ; tranches par juridiction et statut de paiement.

9) Sécurité, vie privée et RG

Zero Trust : mTLS pour les S2S, jetons à courte durée de vie, egress-allow-list.
Minimisation des PII : dans le trafic ref, seulement les tokens/pseudonymes ; la désintoxication est stricte dans les zones de sécurité.
RG-guardrails : limites d'intensité par segment vulnérable ; les disclaimeurs obligatoires ; interdiction des offers dans les régions interdites.
DPA/DPIA et localisation : stockage et manutention par juridiction, interdiction des exportations transfrontalières de DPn hors réglementation.

10) Dashboards et observabilité

10. 1 Barre de références/affiliations

Clics, inscriptions, KYC, FTD, dépôts, CR/ARPU/LTV, statuts post-BEC, split et paiements anticipés, caps/quotas.

10. 2 Panneau Écosystème

Carte des liens (referrer→referal), cohortes, proportion de sujets controversés, foles RG/sanctions, TDMT par incident, contribution des canaux/chaînes.

10. 3 SLO

Livraison des posts ≥ 99. 9 % (p95 ≤ 1-2 s), pneus lag ≤ 200-500 ms, panneaux de rendu p95 ≤ 1. 5–2. 0 s, couverture de trace ≥ 95 % des chemins.

11) Governance и RACI

12) Processus opérationnels

12. 1 Onbording referer

KYP/KYB, sources de trafic, juridictions, hyde de marque, accord RG.
Délivrance de clés/API/webhooks ; le bac à sable et les tests de conformité des signatures/idempotence.

12. 2 Modifications/releases

Changez-calendar (fenêtres vertes/jaunes/rouges), inclusions progressives (1%→5%→25%→100 %), guardrails et auto-rollback.

12. 3 Incidents/war-room

P1/P2, boutons stop (trafic/offer/route), SLA sur la piste 60-90 s, RCA « pas de recherche de coupables ».

12. 4 Récupération et paiements

Déchargement de curseurs, rapprochement des événements hachés, actes/factures, NET7/14/30, retenues (frod/chargbecky/bonus-abyse), cours FX.

13) Intégration avec le reste des couches de l'écosystème

Paiements/ARM : quotas et cut-over dans la dégradation des CR/P95.
KYC/AML : pass-rate et SLA des étapes ; fast-track pour les bas-fonds.
Contenu/missions : diplômes pour les jeux/tournois avec test RTP/volatilité et restrictions régionales.
Analytique/ML : modèles propensity, classement des offers, signaux antifrod.

14) Anti-modèles

« Zoo Postback » : différents formats/signatures/fenêtres → prises, pertes, controverses.
Offset-pagination de l'historique des événements sous charge → trous/doublons (curseurs uniquement).
Retrai sans jitter/limites → tempêtes et doubles charges.
PII dans les événements ref → fuites et violations.
Les résidus à plusieurs niveaux illimités → l'économie toxique, l'impossibilité de contrôler.
Un seul SPOF-redirect sans N + 1/santé-flip.
Aucune traceId → attribution ne peut être prouvée.

15) Chèques-feuilles

15. 1 Conception

• Ontology et Schema Registry (versions, champs obligatoires).
• Contrats de sous-titrage (JWS/HMAC), fenêtre de déduplication.
• Générateur SmartLink/Deep Link, TTL et protection des paramètres.
• Attribution : règle, fenêtres, priorités des conflits, stitching cross-device.
• Modèles de paiement et de split, caps/limites, retenues.
• Zero Trust, Tokenization, DPIA/DPA, RG-guardrails.
• Dashboards/scorecards et SLO, alertes et salle de guerre.

15. 2 Démarrage

• Bac à sable/conformation, épreuve et rapprochement.
• Sortie progressive, auto-rollback.
• La reconnaissance et la facture pipline sont configurées.

15. 3 Exploitation

• Scorecards hebdomadaires de qualité et SLO.
• Je revois les cas controversés/holding.
• ACR périodiques et mise à jour des règles.

16) Feuille de route pour la maturité

v1 (Fondation) : Canon unique des événements/postbacks, SmartLink, modèle L1, dashboards de base.
v2 (Intégration) : repères croisés, répliques de curseurs, paiements hybrides, scorecards et auto-refroidissement.
v3 (Automation) : ML-classement des offers, paiements prédictifs cut-over/CUS, auto-guardrails par SLI/RG.
v4 (Networked) : attribution fédérale entre les réseaux, missions collectives/tournois, règles de split DAO.

17) Les métriques du succès

Entreprise : uplift FTD/ARPU/LTV des canaux de réf, SAS/retour sur investissement, part de sources de qualité.
Qualité : précision/actualité des postbacks, controverse <X %, holds/charjbacks.
Technique : p95 radiés et postbacks, pneus lag, MTTR par incident.
Conformité/RG : incidents PDn = 0, conformité avec les juridictions, déclencheurs RG/1k actifs.
Économie : Cost-to-Serve (per rps/txn/event), crédits/penalti, ROI des canaux.

Résumé succinct

L'architecture des liens de référence est la norme des identifiants et des événements, SmartLink/diplinks et des postbacks signés, l'attribution honnête, la confidentialité stricte et RG, ainsi que l'économie transparente et l'observation. Construisez des canons et des SLO, automatisez les guardrails et la reconstitution - et le circuit de référence deviendra la base évolutive, sûre et rentable de l'ensemble de l'écosystème.