Come funziona il tracking S2S e i postback

1) Cos'è S2S e perché è necessario

Il tracking S2S (server-to-server) è uno scambio di eventi tra i server sorgente del traffico (il tuo riduttore/tracciatore/rete) e quelli dell'operatore (casinò), senza dipendere dai browser e dai blocchi.

Postbeck - La richiesta HTTP in uscita con l'evento (reg/KYC/FTD/2nd _ dep/...) dal backend del mittente all'URL del destinatario.

Vantaggi:

I dati non vengono persi a causa di adblock/ITP/modalità private.
Maggiore accuratezza di attribuzione e qualità di billing.
È possibile trasferire in modo sicuro la somma/valuta e le bandiere di servizio.

2) Catena e ruoli di base

1. Click: l'utente fa clic sulla pubblicità per creare click _ id e logica i parametri (utm, geo, device, sub _ id).

2. Readyrect: l'utente va al landing dell'operatore, 'click _ id' è stato inserito nell'URL o crittografato.

3. Registrazione/CUS/depositi avvengono presso l'operatore.

4. Postback: il server dell'operatore invia al tuo localizzatore gli eventi «registration», «kyc _ approved», «deposit _ success» e così via, associandoli all'originale «click _ id».

5. BI/Report: si aggregano eventi per taglio UTM/Creat/geo/device, si pensa CPA/ROAS/LTV.

Schema di testo:


Ad  Click  [Il tuo rettore genera click _ id]  LP/App  ( /KYC/FTD al fianco dell'operatore)
↑             │
└──────── Postback (S2S) ─┘

3) ID e relazione eventi

click _ id ( .) - ID univoco del primo tocco Chiave di assegnazione.

event _ id (desiderato) è l'ID univoco di ogni evento (per l'idempotenza).

user _ id/account _ id (opz.) è l'ID del giocatore dal lato dell'operatore (trasmesso solo a S2S).

sessione _ id (opz.) - per scansioni UX/velocità.

af _ sub/campaign/creative _ id - tagli per gli analisti.

La regola viene creata da te. l'operatore sul suo lato memorizza il mapping'click _ id n'user/account '.

4) Campi eventi: composizione minima

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": "..."
}

I campi obbligatori sono «event», «event _ id», «click _ id», «ts _ event» (UTC), «signature».

I campi contanti sono sempre insieme a «currency» (ISO-4217) e come numeri, non righe.

5) Sicurezza: firme e accesso

Подпись (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; canonizzare l'ordine dei campi per un controllo stabile.

TTL (JWT/opache) a livello di autorizzazione (TTL 5-15 minuti).

Idampotenza: un POST ripetuto con lo stesso «event _ id» deve dare «200 OK» senza ripresa.

IP allow-list e mTLS (se possibile) in vendita.

Rate limiting - Proteggi l'endpoint dai «burst» e dai bot.

Vietare i rediretti HTTP dall'endpoint postback; Solo risposte dirette.

6) Affidabilità: retrai, code e ordine

Coda (Kafka/RabbitMQ/SQS) tra la ricezione dell'evento e l'elaborazione dei rapporti - per non perdere dati ai picchi.

Retrai con pausa esponenziale e backoff-jitter; limite di tentativi e DLQ (dead-letter queue).

L'ordine non è obbligatorio, ma è preferibile avere «ts _ event» da ordinare in BI.

7) Zone temporali, valuta e consistenza

Tutte le etichette di tempo in UTC ('2025-10-21T15: 12: 31Z').

Nei report, specificare il timezone del progetto, ma memorizzare gli eventi in UTC.

Gli importi vengono memorizzati nella valuta della transazione e duplicati nella valuta del rapporto attraverso un tasso di cambio sicuro (data-time-based FX).

8) Deduplicazione e regole aziendali

Idampotenza event _ id: ripetizione «già elaborata».

Deduplicazione per (click _ id + tipo di evento + ts-finestra) come meccanismo di riserva.

Regole di validità FTD: deposito minimo, senza sovraccarico bonus «zero»; Lo fissi nel contratto.

Chargeback/Refund sono eventi individuali di «reddito negativo» per un NGR onesto.

9) Privacy e compilazione

Non passare il PII all'URL e al fronte; S2S è la posizione per i campi sensibili.

Conservare il consent/consenso (analytics/ads) e versionarli.

Minimizzare i campi: solo ciò che si desidera per l'assegnazione e il biling.

Modificare regolarmente i criteri di retensione dei logi.

10) Web2App e la realtà mobile

Per le applicazioni, collegare «click _ id» a «install _ id» sul lato MMP/SDK.

Quando non c'è un ID di rilevamento (privacy) - usa una partita probabile + regole server, e S2S rimane la verità per il biling.

11) Monitoraggio e SLA

Metriche:

Postbecchi di successo/errore (%/min), p95 latency, percentuale di retrai, percentuale di duplicati.
Variazione degli eventi tra le parti (operatore vs tracker) al giorno.
Ritardo di spedizione (ingestion lag) e inattività oraria.

SLA (esempio):

La ricezione postbeek è disponibile al 99. 5 %/mes.
Ritardo medio fino alla scrittura in DWH di 60 secondi; p95 risposta API da 500 ms.
I dati di Rassincron> 3% sono obbligatori per 5 giorni lavorativi.

12) Assegno fogli

12. 1. Assegno prima dell'avvio

Redattrice con generazione click _ id e loghi.
Endpoint postbeek: TLS, HMAC, JWT, IP allow-list, idempotency.
Gli schemi payload e l'ordine canonico dei campi sono documentati.
Code + DLQ, retrai, alert per errori/ritardi.
UTC-Time, ISO-valuta, regole FTD/Refund/Conformeback.
Test in sandbox con la fissazione dei fogli di riferimento.

12. 2. Assegno operativo (ogni settimana)

Contrassegnare l'operatore per numero di eventi e importi.
Analisi di duplicati ed eventi «persi» Un controllo dei retroscena.
Controllare chiavi/token, tempi di vita e rotazione.
Visualizzare gli incidenti e regolare le regole.

13) Errori frequenti e come evitarli

1. Nessuna idempotency per le riprese FTD nei retrai. Digitare «event _ id» e l'archivio «seen».

2. Fuso orario diverso «nuotato» D0/D1.

3. Valori stringa/virgola per errori di parsing.

4. La firma «grezzo» della JSON si rompe dall'ordine delle chiavi.

5. Nessun DLQ/Retrai ha perso eventi nei chip. + backoff + alert.

6. L'autenticazione è . Foglio di lavoro HMAC + JWT + mTLS/IP.

7. L'assenza di regole FTD ha → le controversie di →.

14) Esempi di richieste e risposte

14. 1. POST/postback (operatore tracciatore)


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" }

Risposta:


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

Invio ripetuto con lo stesso «event _ id»:


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

14. 2. Errore di firma


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

15) Incidenti e smistamenti

Sintomo: l'operatore FTD = 120, lei 117.

Piano:

1. Incrocia l'intervallo di tempo (UTC) e le valute.

2. Carica i fogli crudi in «event _ id »/« click _ id».

3. Ricerca rifiutata a causa della firma/TTL token/idampotenza.

4. Comprimere gli eventi «bloccati» dalla DLQ, gli atti di riconciliazione.

16) Piano di implementazione

0-30 giorni - MVP tracciato

Avvia il rettore con'click _ id 'e i loghi.

Implementare la ricezione di HMAC, JWT, idempotency, code, DLQ, alert.

Alzare la sandbox, controllare lo script di rig/FTD completo con gli importi di prova.

Documentare gli schemi e la canonizzazione dei campi.

31-60 giorni - Qualità e scala

Abilita eventi di cassa e contabilità a due voci (txn & report).

Configura il monitoraggio di p95 latency, soluzioni temporanee e retrai.

Firmare SLA/procedure di incidenti; Aggiungeback/refund eventi.

In BI assemblare le vetrine: coorti FTD, Payback, D7/D30 ARPU.

61-90 giorni - Sostenibilità e verifica

Immettere la rotazione di segreti/certificati, test di tolleranza.

Eseguire test di carico e esercitazioni di emergenza (coda/database).

Formalizza le playbook di crocevia e il controllo trimestrale dei diagrammi/regole FTD.

17) Totale

Il tracking S2S è una «spina dorsale» di equa attribuzione e bollo: click _ id come chiave primaria, postbecchi protetti, idompotenza, retrai e rigida igiene temporale/valuta. Aggiungi regole trasparenti per la validità FTD, gli eventi chargeback e il monitoraggio maturo, e ottieni un sistema affidabile in cui ogni conversione viene confermata dal server e corrisponde ai rapporti fino a un centesimo.