Tracking S2S (Server-to-Server): Guida Tecnica al Postback nell’Affiliate Marketing iGaming

Il tracking S2S (server-to-server) attribuisce una conversione di affiliazione facendo comunicare direttamente il server dell’operatore e quello del network, senza passare dal browser dell’utente: l’operatore invia un postback con l’identificativo di click, il tipo di evento e il valore, e il network accredita la commissione all’affiliato corretto. È il meccanismo che ha sostituito il tracciamento via cookie proprio nel momento in cui i cookie di terze parti sono diventati inaffidabili — un problema strutturale per un network che deve liquidare correttamente CPA e RevShare, i due modelli di pagamento verificati nel mercato italiano nei range 80-200€ e 25-45%.

Per un affiliato la domanda non è se il tracking S2S sia tecnico — lo è — ma se le sue conversioni vengono accreditate correttamente. Un click perso per un cookie bloccato o un cambio di dispositivo tra click e deposito è un mancato guadagno che, moltiplicato su tutto il traffico, pesa più di quanto sembri da un singolo caso isolato.

Cosa troverai in questa guida:

• Perché il tracciamento via cookie ha smesso di reggere e come funziona un postback S2S, passo per passo
• Una matrice di confronto tra cookie tracking e S2S su cinque dimensioni operative, e la differenza con il pixel di conversione
• I parametri di un postback, dal nucleo minimo a quelli opzionali
• Come validare un postback per evitare falsificazioni, gli errori più comuni da evitare e cosa dice il GDPR in materia

Dal cookie tracking al postback: perché è cambiato tutto

Fino a pochi anni fa il tracciamento standard dell’affiliate marketing funzionava così: l’utente clicca il link dell’affiliato, il browser riceve un cookie di terze parti che memorizza l’identificativo dell’affiliato, l’utente si sposta sul sito del bookmaker e, quando deposita, uno script legge quel cookie e comunica al network chi ha portato la conversione. Il meccanismo funzionava finché il browser conservava il cookie senza interferenze.

Il problema è arrivato in due ondate. La prima è la restrizione tecnica dei browser: Safari con Intelligent Tracking Prevention (ITP) ha iniziato a cancellare i cookie di terze parti dopo pochi giorni, Firefox li blocca di default, e anche Chrome ha progressivamente ridotto la finestra di vita dei cookie non di prima parte. Un click che genera una conversione tre settimane dopo, tempo plausibile per un giocatore che valuta prima di depositare, rischia di arrivare con il cookie già scaduto: la conversione avviene, ma l’attribuzione si perde. La seconda ondata è comportamentale: sempre più utenti passano dal dispositivo su cui hanno cliccato (spesso mobile, arrivando da un contenuto social o da un articolo) a un altro dispositivo per completare la registrazione — un cookie salvato sul primo browser non esiste sul secondo, quindi l’attribuzione multi-device semplicemente non esiste nel modello a cookie.

Per un network che deve liquidare correttamente CPA fisso o percentuali RevShare, questo non è un dettaglio tecnico astratto: è denaro che non viene attribuito a chi ha davvero portato il giocatore. Il tracking S2S nasce come risposta diretta a questo problema, spostando il punto di attribuzione dal browser dell’utente — che il network non controlla — ai server di operatore e network, che il network controlla e può verificare.

Il meccanismo: dal click al postback

Il flusso, semplificato, attraversa quattro passaggi. L’utente clicca il link dell’affiliato: a questo punto network o operatore generano un click_id univoco e lo salvano lato server, non in un cookie del browser. L’utente prosegue sul dominio del bookmaker — si registra, deposita, gioca — e il click_id lo accompagna nei parametri del redirect e nei sistemi interni dell’operatore, non nel browser. Quando si verifica l’evento tracciato, il server del bookmaker chiama in autonomia un URL di postback del network: è una chiamata server-to-server, invisibile all’utente e indipendente dal suo browser. Il network riceve il click_id, lo abbina al click originario e accredita la conversione all’affiliato corretto.

La differenza rispetto al tracciamento via cookie sta tutta qui: nel modello a cookie, l’attribuzione dipende da un file che il browser dell’utente conserva e restituisce; nel modello S2S, l’attribuzione dipende da un identificativo che i server si scambiano direttamente, a prescindere da cosa succeda nel browser nel frattempo.

In pratica, una chiamata di postback assomiglia a una richiesta HTTP GET verso un endpoint del network, con i dati passati come parametri di query. Una struttura tipica è del tipo:

https://track.esempio-network.it/postback?click_id={click_id}&event=ftd&amount=50&currency=EUR

Il segnaposto {click_id} viene sostituito dal sistema dell’operatore con il valore ricevuto al momento del click; event indica il tipo di conversione (in questo esempio ftd, first time deposit); amount e currency trasportano il valore economico dell’evento, se previsto dal contratto di affiliazione. Questa è una struttura illustrativa a scopo didattico: il formato esatto dei parametri varia da network a network e va sempre verificato nella documentazione tecnica specifica prima di un’integrazione reale.

Un dettaglio spesso trascurato è la differenza tra postback sincrono e asincrono. Nel modello sincrono, il server dell’operatore attende la risposta del network prima di proseguire — utile per confermare in tempo reale che la conversione sia stata registrata, ma rischioso se il network risponde con lentezza, perché può rallentare l’esperienza dell’utente sull’operatore. Nel modello asincrono, più diffuso, l’operatore invia il postback e prosegue senza attendere una risposta immediata, verificando in un secondo momento — tramite log o dashboard — che il network abbia ricevuto e processato correttamente ogni evento.

Perché conta nello scenario cookieless

Il tracciamento via cookie di terze parti perde l’attribuzione in tre situazioni ricorrenti: quando il browser blocca i cookie di terze parti, quando l’utente passa da un dispositivo all’altro tra il click e la conversione, quando l’utente naviga in modalità privata. Il tracking S2S non dipende da nessuna di queste condizioni, perché l’identificativo di click non vive nel browser: vive nei server di network e operatore, e viene scambiato direttamente tra loro al momento dell’evento.

Postback S2S vs pixel di conversione: non sono la stessa cosa

Un errore concettuale diffuso è confondere il postback S2S con il pixel di conversione installato sulla pagina di ringraziamento dell’operatore. Il pixel è uno script che si carica nel browser dell’utente quando raggiunge una pagina specifica (tipicamente dopo un deposito) e da lì invia una chiamata al network: funziona finché il browser esegue correttamente lo script, ma resta comunque un meccanismo lato client, soggetto a blocker pubblicitari, estensioni privacy e agli stessi limiti di affidabilità multi-dispositivo del cookie tracking, anche se non dipende direttamente da un cookie.

Il postback S2S, al contrario, non passa mai dal browser dell’utente: è il server dell’operatore a contattare direttamente il server del network, indipendentemente da cosa succeda nel browser in quel momento — se l’utente ha chiuso la scheda, se ha un blocker attivo, se sta navigando in modalità privata. Per questo, quando un network offre entrambe le opzioni, il postback S2S è generalmente la scelta più robusta per eventi ad alto valore economico come il primo deposito, mentre il pixel può restare utile per eventi secondari a basso rischio di perdita, come una semplice visualizzazione di pagina.

Cookie tracking vs S2S: matrice di confronto

Dimensione	Cookie tracking	Tracking S2S
Dipendenza dal browser	Alta — richiede che il cookie resti leggibile	Nessuna — l’attribuzione avviene lato server
Resistenza al blocco cookie / ITP	Bassa	Alta
Affidabilità multi-dispositivo	Bassa — si perde cambiando device	Alta — il click_id non dipende dal device
Complessità di implementazione	Bassa lato operatore	Richiede integrazione tecnica lato operatore
Chi lo implementa	Spesso già presente nei CMS/piattaforme standard	Operatore o piattaforma di tracking del network

Il costo del tracking S2S è tutto nella colonna dell’implementazione: richiede che l’operatore esponga un endpoint di postback e che il network gestisca correttamente i click_id in ingresso. Il beneficio è che, una volta implementato, l’attribuzione smette di dipendere da variabili fuori dal controllo di network e affiliato.

Parametri di un postback: dal minimo al completo

Un postback S2S funzionante trasporta come minimo tre informazioni: l’identificativo del click originario (click_id), il tipo di evento tracciato — registrazione, primo deposito o un altro evento definito nel contratto di affiliazione — e, quando l’evento ha un valore economico diretto, l’importo associato. Network e operatori più maturi aggiungono parametri opzionali che migliorano la tracciabilità e la reportistica senza essere strettamente indispensabili al funzionamento di base.

Parametro	Obbligatorio	Funzione
click_id	Sì	Identifica il click originario a cui abbinare la conversione
event	Sì	Tipo di evento tracciato (registrazione, primo deposito, altro evento contrattuale)
amount	Quando l’evento ha valore economico	Importo associato all’evento, base per il calcolo di CPA/RevShare
currency	Consigliato	Valuta dell’importo, utile su network multi-mercato
campaign_id	Opzionale	Identifica la campagna o il sotto-canale dell’affiliato per report più granulari
status	Opzionale	Stato dell’evento (confermato, in verifica, annullato), utile per gestire storni e frodi
signature / token	Fortemente consigliato	Firma del payload per validare l’autenticità del postback (vedi sezione sicurezza)

I primi due parametri (click_id ed event) sono il nucleo minimo che rende il postback verificabile e riconciliabile: senza di essi, il network non ha modo di sapere a quale click e a quale tipo di azione riferire l’evento ricevuto. Tutto il resto migliora la qualità del dato ma non è strutturalmente indispensabile al funzionamento del meccanismo.

Sicurezza: come evitare postback falsificati

Un endpoint di postback esposto pubblicamente è, per definizione, raggiungibile da chiunque conosca l’URL: senza un meccanismo di validazione, nulla impedisce a un terzo di inviare un postback falso e farlo passare per una conversione reale, generando commissioni non dovute o inquinando i dati di performance. Per questo un’integrazione S2S seria non si limita a ricevere i parametri, ma li valida prima di accreditare qualsiasi conversione.

Le pratiche più diffuse per farlo sono tre. La prima è la firma del payload (spesso con HMAC): operatore e network condividono una chiave segreta, l’operatore firma i parametri del postback con quella chiave prima di inviarli, e il network ricalcola la firma al ricevimento per verificare che il payload non sia stato alterato né generato da terzi che non conoscono la chiave. La seconda è il whitelisting degli IP: il network accetta postback solo da un elenco predefinito di indirizzi IP appartenenti ai server dell’operatore, scartando qualunque chiamata proveniente da altre origini. La terza è la verifica di coerenza sul click_id: un postback che referenzia un click_id mai registrato, o già chiuso da una conversione precedente, viene marcato come sospetto e messo in quarantena invece di essere accreditato automaticamente.

Nessuna di queste tre misure, da sola, è a prova di errore: la combinazione di firma del payload e whitelisting degli IP copre la maggior parte degli scenari di abuso realistici in un’integrazione tra operatore e network entrambi in buona fede, che è poi il contesto in cui opera un network di affiliazione regolamentato.

Errori comuni e troubleshooting nell’implementazione

Le integrazioni S2S nuove tendono a fallire in modi ricorrenti, quasi sempre identificabili prima del go-live con un test end-to-end ben condotto:

• Test solo in ambiente di sviluppo: il postback funziona in staging ma non viene mai verificato su un evento reale end-to-end prima del lancio, e un problema di rete o di configurazione emerge solo quando ormai ci sono conversioni reali non accreditate.
• Click_id perso nei redirect: quando il funnel dell’operatore prevede più reindirizzamenti tra pagine diverse, il parametro può non essere propagato correttamente a ogni passaggio, arrivando vuoto o troncato al momento dell’evento.
• Postback duplicati: un retry automatico lato operatore, pensato per gestire timeout di rete, può inviare lo stesso evento più volte se il network non implementa una logica di deduplicazione basata su click_id ed evento.
• Timeout senza retry: l’opposto del problema precedente — se il network non risponde in tempo e l’operatore non ha una logica di nuovo tentativo, l’evento va perso senza che nessuno se ne accorga fino a una riconciliazione manuale.
• Evento diverso da quello contrattuale: il postback parte correttamente ma con un tipo di evento (event) diverso da quello previsto nell’accordo di affiliazione, generando contestazioni sulla commissione dovuta.
• Nessun log consultabile: senza una dashboard o un log dei postback ricevuti, verificare a posteriori se un singolo evento è arrivato o si è perso diventa un lavoro manuale lento, spesso rimandato finché non emerge una discrepanza evidente nei numeri.

Il correttivo comune a tutti questi scenari è lo stesso: verificare l’intera catena su un evento reale prima di considerare l’integrazione conclusa, e mantenere un log consultabile che permetta di riconciliare, in caso di dubbio, cosa è stato inviato e cosa è stato effettivamente ricevuto.

Tracking S2S e GDPR: cosa non deve contenere un postback

Il tracking S2S tratta dati che riguardano persone fisiche identificabili indirettamente tramite il click_id, quindi ricade nel perimetro del GDPR come ogni altro trattamento di dati di tracciamento. La buona pratica, in questo caso, coincide con la sicurezza tecnica: un postback ben progettato trasporta un identificativo tecnico (click_id) e dati di evento (tipo, valore), non dati personali diretti come nome, email o numero di telefono dell’utente. Il click_id collega l’evento al click originario nei sistemi di network e operatore, ma non deve, di per sé, rendere identificabile la persona a chi intercetta il solo payload del postback.

Questo principio di minimizzazione del dato — trasportare solo ciò che serve al calcolo dell’attribuzione, non l’intera identità dell’utente — riduce sia il rischio di conformità sia la superficie di rischio in caso di intercettazione non autorizzata del traffico. Resta comunque responsabilità di operatore e network documentare il trattamento nell’informativa privacy applicabile, anche quando i dati scambiati sono limitati a identificativi tecnici.

Tracking e scelta del network

Il tracking S2S è invisibile all’utente ma decisivo per l’affiliato: un network di affiliazione che gestisce correttamente l’infrastruttura di postback riduce le conversioni perse per motivi puramente tecnici. È uno dei criteri, insieme alle condizioni economiche CPA/RevShare viste nella analisi comparativa dei modelli di pagamento, che vale la pena verificare prima di scegliere con chi lavorare: un network con condizioni economiche competitive ma un’infrastruttura di tracking inaffidabile lascia comunque soldi sul tavolo, solo in una fase diversa del processo.

In pratica, prima di firmare con un network o un programma diretto, ha senso porre domande concrete sull’infrastruttura di tracciamento: se l’attribuzione è basata su S2S o solo su cookie/pixel, quale finestra di attribuzione applica tra click e conversione, se espone log o una dashboard consultabile per riconciliare gli eventi, e come gestisce eventuali dispute su conversioni non accreditate. Sono domande tecniche, ma la risposta determina direttamente quanto delle commissioni maturate arriva davvero all’affiliato. Tipaffiliation gestisce l’attribuzione via postback S2S su tutti gli operatori del network, proprio per ridurre al minimo questo tipo di dispersione.

Il gioco è vietato ai minori di 18 anni e può causare dipendenza patologica.

Articolo redatto dal network editoriale Vector. Vector srl (P.IVA 09532751212) opera nel settore gambling in conformità al Decreto Dignità (D.L. 87/2018) e alle linee guida AGCOM.

Domande frequenti