Comment fonctionne le S2S tracking et post-Becky

1) Qu'est-ce qu'un S2S et pourquoi il est nécessaire

Le suivi des S2S (server-to-server) est l'échange d'événements entre les serveurs source de trafic (votre redirecteur/tracker/réseau) et les serveurs de l'opérateur (casino), sans dépendre des cookies du navigateur et des verrous.

Post-back est une requête HTTP sortante avec un événement (reg/KYC/FTD/2nd_dep/...) depuis le backend de l'expéditeur vers l'URL du destinataire.

Avantages :

Les données ne sont pas perdues en raison des modes adblock/ITP/private.
La précision d'attribution et la qualité de facturation sont améliorées.
Vous pouvez transférer en toute sécurité le montant/devise et les drapeaux de service.

2) Chaîne de base et rôles

1. Click : l'utilisateur clique sur la publicité → votre redirecteur crée 'click _ id' et enregistre les paramètres (utm, geo, device, sub_id).

2. Redirect : l'utilisateur va sur le landing de l'opérateur, 'click _ id'est lancé dans l'URL ou crypté.

3. L'enregistrement/le CUS/les dépôts se font auprès de l'opérateur.

4. Post-Becky : le serveur de l'opérateur envoie à votre tracker les événements 'registration', 'kyc _ approved', 'deposit _ success', etc. en les liant à l'original 'click _ id'.

5. BI/Reporting : vous agrégez les événements par coupes UTM/creative/geo/device, comptez CPA/ROAS/LTV.

Schéma de texte :


Ad → Click → [Votre redirecteur : génère des click_id] → LP/App → (Reg/KYC/FTD côté opérateur)
↑             │
└──────── Postback (S2S) ─┘

3) Identifiants et communication d'événements

click_id (iz.ru.) - ID unique du premier toucher ; la clé d'attribution.

event_id (désiré) - l'ID unique de chaque événement (pour l'idempotence).

user_id/ account_id (opz.) - ID du joueur du côté de l'opérateur (transmis uniquement en S2S).

session_id (opz.) - pour les débits UX/vitesse.

aff_sub/campagne/ creative_id - coupes pour l'analyse.

Règle : Le click_id est créé chez vous ; l'opérateur de son côté stocke le mapping 'click _ id ↔ user/account'.

4) Champs d'événements : composition minimale

4. 1. Registration

json
{
"event": "registration",  "event_id": "reg_8f9...",  "click_id": "clk_123...",  "account_id": "u_456...",  "geo": "BR",  "device": "android",  "ts_event": "2025-10-21T14:54:12Z",  "ip": "203. 0. 113. 7",  "ua": "Mozilla/5. 0",  "signature": "hmac_sha256(payload)"
}

4. 2. KYC Approved

json
{
"event": "kyc_approved",  "event_id": "kyc_b21...",  "click_id": "clk_123...",  "account_id": "u_456...",  "ts_event": "2025-10-21T15:10:05Z",  "kyc_level": "basic    full",  "signature": "..."
}

4. 3. Deposit (FTD/Repeat)

json
{
"event": "deposit_success",  "event_id": "dep_9aa...",  "click_id": "clk_123...",  "account_id": "u_456...",  "amount": 100. 00,  "currency": "USD",  "is_ftd": true,  "payment_method": "card    pix    crypto    wallet",  "ts_event": "2025-10-21T15:12:31Z",  "signature": "..."
}

Champs obligatoires : 'event', 'event _ id', 'click _ id', 'ts _ event' (UTC), 'signature'.

Les champs monétaires sont toujours associés à 'currency' (ISO-4217) et en tant que nombres, pas de chaîne.

5) Sécurité : Signatures et accès

Подпись (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; Canoniser l'ordre des champs → une vérification stable.

Jetons à courte durée de vie (JWT/opaque) au niveau de l'autorisation : TTL 5-15 minutes.

Idempotence : un POST répété avec le même 'event _ id' doit donner '200 OK'sans prise.

IP allow-list et mTLS (si possible) sur la vente.

Limite de taux : protéger l'endpoint des « burst » et des bots.

L'interdiction du redirect HTTP avec l'endpoint post-bec ; seulement des réponses directes.

6) Fiabilité : Retraits, files d'attente et ordre

La file d'attente (Kafka/RabbitMQ/SQS) entre la réception de l'événement et le traitement des rapports - pour ne pas perdre de données pendant les pics.

Retrai avec pause exponentielle et backoff-jitter ; limite de tentative et DLQ (dead-letter queue).

L'ordre n'est pas obligatoire, mais il est souhaitable d'avoir « ts _ event » pour le tri en BI.

Logs de requête/réponse (pas de données sensibles), corrélation par 'event _ id'.

7) Zones temporaires, monnaie et consistance

Tous les horodateurs en UTC ('2025-10-21T15 : 12 : 31Z').

Dans les rapports, indiquez la timezone du projet, mais stockez les événements dans UTC.

Conservez les montants dans la devise de transaction et doublez dans la devise du rapport via un taux de change fiable (date-time-FX).

8) Déduplication et règles commerciales

Idempotence par event_id : répétition → « déjà traitée ».

Déduplication par (click_id + type d'événement + ts-fenêtre) en tant que mécanisme de secours.

Règles de validation FTD : dépôt minimum, pas de « zéro » bonus de recharge ; fixez dans le contrat.

Chargeback/Refund sont des événements distincts de « revenus négatifs » pour un NGR honnête.

9) Confidentialité et conformité

Ne transférez pas le PII à l'URL et au front ; S2S est un endroit pour les champs sensibles.

Conservez les consents/consentements (analytics/ads) et les versionnez.

Minimisez les champs : juste ce dont vous avez besoin pour l'attribution et la facturation.

Vérifiez régulièrement les politiques de rétention des logs.

10) les Web2App et les réalités mobiles

Pour les applications, liez 'click _ id' ↔' install _ id 'sur le côté MMP/SDK.

Quand il n'y a pas d'ID déterministe (confidentialité iOS) - utilisez le match probabiliste + les règles du serveur, et la S2S reste la « vérité » pour la facturation.

11) Surveillance et SLA

Métriques :

Succès/erreurs post-Becks (%/min), p95 latency, proportion de retraits, proportion de doublons.
Divergence d'événements entre les parties (opérateur vs tracker) par jour.
Retard de livraison (ingestion lag) et « échecs » à l'heure.

SLA (exemple) :

Disponibilité de l'accueil post-BEC ≥ 99. 5 %/mois.
Délai moyen d'écriture dans DWH ≤ 60 secondes ; p95 réponses API ≤ 500 ms.
Dissynchrone de données> 3 % → le rapprochement obligatoire des logs bruts dans les 5 jours ouvrables.

12) Chèques-feuilles

12. 1. T-chèque avant le lancement

Redirecteur avec génération de click_id et loges.
Endpoint postback : TLS, HMAC, JWT, IP allow-list, idempotency.
Les schémas payload's et l'ordre canonique des champs sont documentés.
Files d'attente + DLQ, retraits, alertes sur les erreurs/retards.
Temps UTC, monnaie ISO, règles FTD/Refund/Chargeback.
Lancer dans une sandbox avec fixation des logs de référence.

12. 2. Chèque d'exploitation (chaque semaine)

Rapprochement « opérateur ↔ tracker » en termes d'événements et de montants.
Analyse des doublons et des événements « perdus » ; audit des retras.
Vérification des clés/tokens, durée de vie et rotation.
Afficher les incidents et ajuster les règles.

13) Erreurs fréquentes et comment les éviter

1. Il n'y a pas d'idempotency → de prise FTD pour les retraits. → Entrez 'event _ id' et le stockage « seen ».

2. Différents fuseaux horaires → « flotté » D0/D1. → Toujours UTC dans le journal des événements.

3. Montants de chaîne/virgule → erreurs de parsing. → Passez des nombres avec un point et une monnaie ISO.

4. La signature de JSON « brut » est → cassée par l'ordre des clés. → Faites la canonisation.

5. Il n'y a pas de DLQ/rétroactifs → perte d'événements dans les microsbos. → File d'attente + backoff + alerts.

6. L'authentification faible → les faux post-Becks. → HMAC + JWT + mTLS/feuille IP.

7. L'absence de règles FTD → des conflits de facturation. → Incorporer les définitions dans le contrat.

14) Exemples de demandes et de réponses

14. 1. POST/postback (opérateur → tracker)


POST /postback HTTP/1. 1
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
X-Signature: sha256=ab12...

{ "event":"deposit_success","event_id":"dep_9aa",  "click_id":"clk_123","account_id":"u_456",  "amount":100. 00,"currency":"USD","is_ftd":true,  "ts_event":"2025-10-21T15:12:31Z" }

Réponse :


200 OK
{ "status":"ok", "idempotent": false }

Réessayer avec le même 'event _ id' :


200 OK
{ "status":"ok", "idempotent": true }

14. 2. Erreur de signature


403 Forbidden
{ "error":"signature_invalid", "hint":"check canonical order" }

15) Incidents et analyse

Symptôme : l'opérateur FTD a 120, vous avez 117.

Plan :

1. Rapprochement de la plage de temps (UTC) et des monnaies.

2. Déchargement des logs bruts par 'event _ id '/' click _ id'.

3. Recherche des jetons/idempotentes rejetés en raison de la signature/TTL.

4. Retarder les événements « bloqués » du DLQ, les actes de rapprochement.

16) Plan de mise en œuvre 30-60-90

0-30 jours - boucle MVP

Démarrer le redirecteur avec 'click _ id' et les logs.

Mettre en œuvre la réception des posts : HMAC, JWT, idempotency, file d'attente, DLQ, alertes.

Soulevez la sandbox, chassez le script de bout en bout reg/FTD avec les montants de test.

Documenter les schémas et la canonisation des champs.

31-60 jours - Qualité et échelle

Activer les événements monétaires et le double compte (txn & report).

Configurez la surveillance de la latence, des écarts et des retraits p95.

Signer le SLA/procédures d'incident ; ajouter un événement chargeback/refund.

En BI, assembler des vitrines : cohortes FTD, Payback, D7/D30 ARPU.

61-90 jours - Durabilité et vérification

Entrez la rotation des secrets/certificats, les tests de tolérance aux pannes.

Effectuer des tests de charge et des « exercices d'urgence » (file d'attente/OBD).

Formaliser le rapprochement des pleybooks et l'audit trimestriel des schémas/règles de la DTF.

17) Résultat

Le S2S Tracking est une « crête » d'attribution et de facturation honnête : click_id comme clé primaire, protection post-Bec, idempotence, retrai et hygiène stricte du temps/des monnaies. Ajoutez à cela les règles transparentes de validation FTD, les événements chargeback et la surveillance mature - et vous obtenez un système fiable où chaque conversion est confirmée par le serveur et convergent dans les rapports jusqu'à un centime.