Cum funcționează urmărirea S2S și posturile

1) Ce este S2S și de ce este necesar

S2S (server-to-server) de urmărire este schimbul de evenimente între serverele sursei de trafic (redirector/tracker/rețea) și serverele operatorului (cazinou), fără dependență de cookie-uri de browser și blocări.

Postback - o cerere HTTP de ieșire cu un eveniment (reg/KYC/FTD/2nd_dep/...) din backend-ul expeditorului la URL-ul destinatarului.

Avantaje:

Datele nu se pierd din cauza adblock/ITP/moduri private.
Acuratețe mai mare a atribuirii și a calității facturării.
Puteți transfera în siguranță suma/moneda și steaguri de serviciu.

2) Lanțul și rolurile de bază

1. Faceți clic pe: utilizatorul face clic pe anunțul pe → redirectorul creează un 'click _ id' și înregistrează parametrii (utm, geo, dispozitiv, sub_id).

2. Redirecționare: utilizatorul merge la aterizarea operatorului, "click _ id' este împins la URL-ul sau criptat.

3. Înregistrarea/CCM/depozite apar la operator.

4. Postback-uri: serverul operatorului trimite 'înregistrare', 'kyc _ approved', 'deposit _ success' etc. evenimente la tracker, legându-le la originalul 'click _ id'.

5. BI/Raportare: agregați evenimente în secțiunile UTM/creative/geo/device, luați în considerare CPA/ROAS/LTV.

Schema de text:


Anunțul  Faceți clic pe  [Redirectorul dvs. generează ]  LP/App
↑             │
└──────── Postback (S2S) ─┘

3) Identificatori de evenimente și legături

click_id (obligatoriu) - ID unic al primei atingeri; cheie de atribuire.

event_id (galben) - ID unic al fiecărui eveniment (pentru idempotență).

user_id/ account_id (en-gros) - ID-ul jucătorului pe partea operatorului (transmis numai către S2S).

session_id (en-gros) - pentru parsarea UX/viteză.

aff_sub/campaign/ creative_id - secțiuni pentru analiză.

Regula: click_id este creat de tine; operatorul de pe partea sa stochează cartografierea 'click _ id ↔ user/account'.

4) Câmpurile evenimentului: compoziție minimă

4. 1. Înregistrare

json
{
"eveniment": "înregistrare", " " : " " : " ": "geo": "BR", "dispozitiv": "android", " :" ip ":" 203 ". 0. 113. 7”, „ua”: „Mozilla/5. 0", "semnătură": "hmac_sha256 (sarcină utilă)"
}

4. 2. KYC aprobat

json
{
„eveniment”: „ ” „ :”  „ :”  „” : „ ”    „,” semnătură „:”..
}

4. 3. Depozit (FTD/Repetare)

json
{
"eveniment": " " " :"  " :"  ":"  ":" sumă ": 100. 00, "valută": "USD", "is_ftd": adevărat ", payment_method": "card'    pix    crypto    portofel "," ts_event": "2025-10-21T15:12:31Z," "semnătură": "..
}

Câmpurile obligatorii sunt 'event', 'event _ id',' click _ id', 'ts _ event' (UTC), 'signature'.

Câmpurile valutare sunt întotdeauna împreună cu 'valută' (ISO-4217) și ca numere, nu șiruri.

5) Securitate: Semnături și acces

Подпись (HMAC-SHA256): 'semnătură = HMAC (secret, canonical_payload)'; canoniza ordinea câmpului → validare stabilă.

Jetoane de scurtă durată (JWT/opac) la nivel de autorizare: TTL 5-15 minute.

Idempotence: Repetați POST cu același 'event _ id' ar trebui să dea' 200 OK 'fără o dublă.

IP allow-list și mTLS (dacă este posibil) pe prod.

Limitarea ratei: Protejați punctul final de „explozii” și roboți.

Interzicerea redirecționărilor HTTP din criteriul final postbeck; numai răspunsuri directe.

6) Fiabilitate: Retrase, cozi și ordine

Coadă (Kafka/RabbitMQ/SQS) între recepția evenimentului și procesarea raportului - pentru a nu pierde date la vârfuri.

Retrai cu pauză exponențială și jitter backoff; limita de încercări și DLQ (coadă de litere moarte).

Comanda este opțională, dar este de dorit să aveți 'ts _ event' pentru sortare în BI.

Jurnalele de cerere/răspuns (fără date sensibile), corelarea prin 'event _ id'.

7) fusuri orare, valută și consistență

Toate timbrele de timp în UTC ('2025-10-21T15: 12: 31Z').

În rapoarte, specificați fusul orar al proiectului, dar stocați evenimentele în UTC.

Stocați sumele în moneda tranzacției și duplicați-le în moneda raportului printr-un curs fiabil (data-time-based FX).

8) Deduplicarea și regulile de afaceri

event_id idempotency: Repetați → „deja prelucrate”.

Eliminarea duplicatelor prin (click_id + tip de eveniment + ts-fereastră) ca mecanism de rezervă.

Reguli de valabilitate FTD: depozit minim, nici un bonus „zero” reaprovizionare; Fix în contract.

Chargeback/Rambursarea sunt evenimente separate „cu venituri negative” pentru un NGR onest.

9) Confidențialitate și conformitate

Nu treceți PII la URL și față; S2S este un loc pentru domenii sensibile.

Stocați consimțământul (analytics/ads) și versiunea acestora.

Minimizați câmpurile: numai ceea ce este necesar pentru atribuire și facturare.

Revizuiți în mod regulat politicile de păstrare a jurnalului.

10) realități Web2App și mobile

Pentru aplicații, legați 'click _ id' ↔' install _ id' pe partea MMP/SDK.

Atunci când nu există nici un ID determinist (confidențialitate iOS) - utilizați un meci probabilistic + reguli de server, și S2S rămâne „adevărul” pentru facturare.

11) Monitorizarea și SLA

Măsurători:

Postback-uri reuşite/eronate (%/min), latenţă p95, proporţia de retribuiri, proporţia de duplicate.
Discrepanța dintre părți (operator vs tracker) pe zi.
Întârzierea livrării (întârzierea ingestiei) și „eșecurile” cu ora.

SLA (exemplu):

Disponibilitate recepție postback ≥ 99. 5 %/lună
Întârzierea medie înainte de a scrie la DWH ≤ de 60 de secunde; răspuns API p95 ≤ 500ms.
Desincronizarea datelor> 3% → reconcilierea obligatorie a jurnalelor brute în termen de 5 zile lucrătoare.

12) Liste de verificare

12. 1. Verificare tehnică înainte de lansare

Redirector cu generație click_id și jurnale.
Postback endpoint: TLS, HMAC, JWT, IP allow-list, idempotency.
Schemele de sarcină utilă și ordinea canonică a câmpului sunt documentate.
Cozi + DLQs, Retrase, Eroare/Întârziere Alerte.
Ora UTC, moneda ISO, regulile FTD/Rambursare/Chargeback.
Rulează în sandbox cu busteni de referință de fixare.

12. 2. Verificarea funcționării (în fiecare săptămână)

Reconcilierea „operatorului ↔ tracker” cu volumul evenimentelor și sumelor.
Analiza duplicatelor și evenimentelor „pierdute”; auditul retroactivelor.
Verifică cheile/jetoanele, durata de viață și rotația.
Vizualizați incidentele și ajustați regulile.

13) Greșeli frecvente și cum să le evitați

1. Nu există idempotență → duplicate FTD în Retrays. → Introduceți 'event _ id' și stocați „seen”.

2. Diferite fusuri orare → D0/D1 „plutite”. → Întotdeauna UTC în jurnalul de evenimente.

3. Sume de șir/virgulă → erori de parsare. → Treceți numere cu o perioadă și o monedă ISO.

4. Semnătura de pe → „crud” JSON se rupe din ordinea cheilor →.

5. Fără DLQ/Retrăiri → Pierderea evenimentelor pe Microsobes. → Coadă + backoff + Alerte.

6. Autentificare slabă → postback-uri false. → lista HMAC + JWT + mTLS/IP.

7. Lipsa regulilor FTD → litigiile de facturare →.

14) Cereri de probă și răspunsuri

14. 1. POST/postback (operator → tracker)


POST/postback HTTP/1. 1
Tip de conținut: aplicație/json
Autorizatie: Purtator eyJhbGciOi...
Semnătura X: sha256 = ab12...

{"eveniment": "depunere _ succes", "eveniment _ id':" rep _ 9aa "," click_id":"clk_123,""account_id":"u_456, "" sumă ": 100. 00, "valută": "USD", "is _ ftd': true," ts_event":"2025-10-21T15:12:31Z "}

Răspuns:


200 OK
{„status”:” ok”, „idempotent”: false}

Retrimite cu același 'event _ id':


200 OK
{„status”:” ok”, „idempotent”: true}

14. 2. Eroare de semnătură


403 Interzis
{„error „: „signature _ invalid”, „hint „:” check canonical order”}

15) Incidente și parsare

Simptom: operatorul are DTF = 120, aveți 117.

Plan:

1. Reconcilierea intervalului de timp (UTC) și a valutelor.

2. Descărcarea jurnalelor brute prin 'event _ id'/' click _ id'.

3. Căutați jetonul respins/idempotența din cauza semnăturii/TTL.

4. Livrarea suplimentară a evenimentelor „blocate” din DLQ, acte de reconciliere.

16) Planul 30-60-90 de implementare

0-30 zile - Circuit MVP

Lansați redirectorul cu 'click _ id' și jurnale.

Implementați recepția postback-urilor: HMAC, JWT, idempotency, cozi, DLQ, alerte.

Ridicați cutia de nisip, executați scriptul reg/FTD end-to-end cu sume de testare.

Scheme de câmp de documente și canonizare.

31-60 zile - Calitate și scară

Includeți evenimente monetare și contabilitate cu valută dublă (txn și raport).

Configurați monitorizarea latenței p95, a discrepanțelor și a retroactivelor.

Semnarea procedurilor SLA/incident; adăugați evenimente de chargeback/rambursare.

În BI, colectați vitrine: FTD, Payback D7/D30 cohorte ARPU.

61-90 zile - Sustenabilitate si audit

Introduceți rotația secretelor/certificatelor, testele de toleranță la erori.

Efectuați teste de sarcină și „burghie de urgență” (picătură de coadă/DB).

Formalizați cărțile de joc de reconciliere și auditul trimestrial al schemelor/normelor FTD.

17) Linia de jos

urmărirea S2S este „coloana vertebrală” a atribuirii și facturării oneste: click_id ca cheie primară, postback-uri protejate, idempotență, retrăiri și igiena strictă a timpului/monedei. Adăugați la aceste reguli de valabilitate FTD transparente, evenimente de încărcare și monitorizare matură - și veți obține un sistem fiabil în care fiecare conversie este confirmată de server și converge în rapoarte la un cent.