Cookieless tracking: guida S2S postback per affiliate

Il tracking client-side è morto. Non ufficialmente, ma nei fatti: ITP di Safari, Enhanced Tracking Protection di Firefox, Privacy Sandbox di Chrome e il calo del consenso ai cookie hanno ridotto la copertura del pixel classico sotto il 60% in molti verticali. Per una performance publishing company che lavora su CPA, questa perdita si traduce direttamente in fatturato non riconosciuto e advertiser che chiudono i budget.

La risposta è il server-to-server postback (S2S), lo standard che le principali affiliate network e le piattaforme di media buying usano ormai come metodo primario di attribuzione.

Come funziona un postback S2S

A differenza del pixel client-side, che si affida al browser dell'utente per notificare la conversione, il postback S2S è una chiamata HTTP GET generata dal server dell'advertiser verso il server del publisher/network quando avviene la conversione. Il flusso tipico:

1. Il publisher genera un click ID univoco (spesso chiamato clickid, sub1 o transaction_id) e lo passa nell'URL di destinazione. 2. L'advertiser salva quel click ID insieme all'ordine/lead. 3. Alla conversione, il server dell'advertiser chiama l'URL di postback del publisher passando indietro il click ID e i parametri (payout, currency, status). 4. Il publisher riconcilia la conversione senza dipendere da cookie o pixel.

Perché è più affidabile

• Nessuna dipendenza da cookie o localStorage, quindi immune a ITP, Firefox ETP e blocchi consent.
• Attribuzione cross-device: il click ID può essere legato all'account utente dell'advertiser, riconoscendo conversioni che avvengono da un device diverso.
• Nessuna perdita in ambienti in-app o su webview mobili dove i pixel spesso non partono.
• Compliance-friendly: la chiamata avviene server-to-server, senza raccogliere identificatori sul dispositivo.

Best practice implementative

Naming del click ID

Standardizzare il nome del parametro riduce gli errori di integrazione. Consigliamo `clickid` come default, con macro `{clickid}` esposta nell'URL di tracking. Evitare nomi generici come `id` che spesso vengono sovrascritti da altri sistemi.

Deduplicazione

Ogni postback dovrebbe avere un transaction_id univoco. Il server ricevente deve rifiutare (o marcare come duplicato) le chiamate con transaction_id già registrato: questa singola regola elimina la maggior parte delle discrepancie tra publisher e advertiser.

Firma HMAC

Un postback non firmato può essere replicato o falsificato da chiunque scopra l'URL. Aggiungere un HMAC SHA-256 calcolato sui parametri chiave, con chiave condivisa tra advertiser e publisher, è oggi lo standard richiesto dai network più seri.

Status flow

Gestire almeno tre stati: `pending`, `approved`, `rejected`. Un postback iniziale in pending permette di popolare i dashboard in tempo reale, mentre il postback di update finale (dopo il periodo di validation) consolida il payout. Questo pattern riduce del 40-60% le contestazioni tra publisher e advertiser.

Timeout e retry

Il postback deve avere retry con backoff esponenziale (es. 3 tentativi a 1s, 5s, 30s) su risposte non 2xx. Un log persistente delle chiamate fallite è indispensabile per il reconcile mensile.

Errori comuni che vediamo

• Non passare il click ID in landing intermedie: pre-lander, quiz o splash page che perdono i parametri UTM/clickid causano fino al 30% di conversioni non attribuite.
• Postback client-side "mascherati" da S2S: alcune piattaforme chiamano S2S una fetch fatta dal browser. Non lo è.
• Nessun test in staging: ogni nuovo advertiser dovrebbe passare un test end-to-end con un click ID sentinella.

Impatto misurato

Sui verticali dove abbiamo migrato completamente da pixel a S2S negli ultimi 12 mesi, la copertura tracking è passata da una media dell'62% a oltre il 95%, con un aumento diretto del fatturato riconosciuto tra il 18% e il 34% a parità di volume di click.

Il tracking non è più un dettaglio tecnico. È il layer che tiene in piedi l'intera unit economics di un business affiliate.