L'attribuzione cookieless funziona se smetti di chiedere al browser di ricordare il click. Registra il click su un server, porta un identificatore nell'URL, salvalo nel tuo record d'ordine e invia la conversione da server a server. Tutto il resto è degradato o legalmente rischioso nell'UE. Vale per i cookie di terze parti, per i cookie impostati da script che scadono in pochi giorni e per il fingerprinting.
Lo stack che la maggior parte dei team ha costruito tra il 2012 e il 2019 dipendeva da un cookie di terze parti piazzato sulla landing page e da un pixel che lo abbinava sulla pagina di conversione. Per le basi del termine, vedi che cos'è l'attribuzione di marketing. Questo articolo è una mappa di ciò che sopravvive, di ciò che Elido copre oggi e di dove serve il tuo back-end.
TL;DR
- Safari limita i cookie e lo storage scritti da script a 7 giorni di inattività, e a 24 ore per i cookie creati su una landing page con link decorato. Chrome consente ancora i cookie di terze parti, con scelta dell'utente. Considerali inaffidabili in entrambi i casi.
- Due percorsi reggono: un click ID o link ID passato al tuo record d'ordine e inviato da server a server, e i cookie first-party impostati dal server.
- Cookieless non significa senza consenso. L'articolo 5(3) della ePrivacy arriva fino a fingerprinting e local storage, e il GDPR richiede comunque una base giuridica per il trattamento lato server.
- Elido registra i click lato server e collega i ricavi di Stripe e Shopify ai link. Non genera ancora click ID né inoltra conversioni alle piattaforme pubblicitarie.
Cosa è cambiato nei browser
Tre fonti danno il quadro attuale, tutte consultate il 2026-10-24.
La pagina di tracking prevention di WebKit dice che Safari elimina i cookie creati in JavaScript, e altri storage scrivibili da script, dopo 7 giorni senza interazione dell'utente con il sito. Dice anche che, quando nell'URL della landing viene rilevato un click ID, la scadenza dei cookie creati in JavaScript su quella pagina è limitata a 24 ore. ITP 2.3, pubblicato il 23 settembre 2019, ha esteso limiti simili ad altri dati scrivibili da script. I cookie impostati in un header di risposta HTTP dal tuo host first-party non sono limitati da queste regole. L'eccezione è un host di terze parti mascherato, come un sottodominio nascosto tramite CNAME o IP, dove WebKit limita la scadenza a 7 giorni.
Firefox partiziona i cookie di terze parti per sito di primo livello tramite Total Cookie Protection. Un cookie impostato da un tracker sul tuo checkout e su quello di un concorrente diventa due cookie distinti.
Chrome non ha mai completato l'eliminazione. Il 22 aprile 2025 Google ha annunciato che non avrebbe introdotto un avviso autonomo per i cookie di terze parti e che gli utenti continuano a scegliere nelle impostazioni. Il blog Privacy Sandbox aggiunge che alcune tecnologie di Privacy Sandbox vengono dismesse. Quindi la domanda pratica non è più "quando muoiono i cookie" ma "quale quota del mio pubblico li blocca", e non posso darti una percentuale onesta valida per tutta l'UE. Controlla le tue analytics per browser.
Un'altra affermazione che vedrai nelle presentazioni dei vendor: che la Link Tracking Protection di Safari rimuova click ID come fbclid o gclid nella navigazione privata e in Mail. La pagina di tracking prevention di WebKit non lo menzionava quando l'ho consultata, quindi qui non ripeto un elenco di parametri. Testa le tue landing page in quei contesti prima di contare sulla sopravvivenza di un click ID.
I due percorsi che funzionano ancora
Entrambi partono dallo stesso fatto: un server vede il click prima che si applichino le regole di storage del browser.
Percorso 1: identificatori lato server
Quando un utente clicca un annuncio, la piattaforma aggiunge un click identifier all'URL della landing, come fbclid per Meta o gclid per Google. L'identificatore vive nell'URL, quindi il partizionamento dei cookie non lo tocca. La tua landing page lo legge e lo salva nel carrello o nell'ordine. Quando l'ordine viene pagato, il tuo back-end lo legge dall'ordine e invia la conversione all'API lato server della piattaforma, come la Conversions API di Meta o il GA4 Measurement Protocol.
La deduplicazione conta se mantieni anche il pixel del browser. La documentazione di Meta dice che l'eventID del Pixel deve corrispondere all'event_id della Conversions API, con lo stesso nome evento, e che i duplicati ricevuti entro 48 ore vengono scartati. Per gli acquisti usa l'ID dell'ordine. Per sapere quali campi cliente vanno sottoposti a hash, leggi la pagina di Meta sui parametri di informazione del cliente; non ho verificato quelle regole per questo articolo.
I punti deboli sono reali. Cancellare i cookie fa perdere un ID salvato in un cookie. Una conversione su un altro dispositivo non ha alcun collegamento a meno che la persona non sia loggata. Il click ID può anche sparire prima che la landing page lo veda.
Percorso 2: un redirect che controlli
Un redirect sul tuo dominio è un evento lato server. Quando qualcuno clicca un link breve con brand, l'host del redirect può scrivere subito un record del click, con timestamp, referrer e user agent, invece di aspettare che si attivi un tag al caricamento della pagina. Se imposti anche un cookie, impostalo nell'header Set-Cookie su un host first-party. Così eviti i limiti di 7 giorni e 24 ore per i cookie scritti da script visti sopra.
Un pixel non può replicarlo. È anche il punto in cui finisce l'attuale ambito di Elido.
Cosa fa Elido oggi, verificato nel codice
Ho controllato nei servizi ogni affermazione che questo articolo faceva in precedenza. Ecco il risultato.
| Funzionalità | Stato |
|---|---|
| Log dei click lato server scritto quando viene servito il redirect | Sì |
Inoltro dei click a GA4 (evento link_click), Mixpanel, Klaviyo, Brevo e Datadog | Sì, integrazioni per workspace |
| Eventi Meta e TikTok lato server al click | No |
Ordini Stripe e Shopify abbinati a un link tramite elido_link_id | Sì |
| Ricavi per link, campagna, giorno e piattaforma | Sì |
ID elido_click aggiunto all'URL di destinazione | No |
| Cookie first-party impostato dal redirect | No |
API pubblica delle conversioni (POST /v1/conversions) | No |
Inoltro delle conversioni a Meta CAPI o GA4 con hash e event_id | No |
La versione onesta di "un link breve come superficie di attribuzione" è più limitata di quanto dicesse questo articolo in passato. Il redirect ti dà un record del click e report per link. Per chiudere il cerchio sui ricavi, metti l'ID del link nell'ordine: elido_link_id nei metadati di Stripe, oppure un attributo nota elido_link_id su un carrello Shopify. Quando arriva il webhook dell'ordine, Elido attribuisce i ricavi a quel link. Tutto ciò che va oltre, come fare l'hash di un'email e chiamare l'API di Meta, oggi è codice nel tuo back-end. Per come è costruita quella distribuzione, vedi il tracciamento server-side delle conversioni tramite link brevi e, per l'angolo specifico di Safari, l'attribuzione dei click dopo Safari ITP. La pagina della funzionalità di tracciamento conversioni descrive il lato dashboard.
Identity stitching: cosa funziona e cosa no
Gli ID lato server coprono il caso comune. Una persona, un dispositivo, una sessione, nessun parametro rimosso. Il resto richiede un identificatore che la persona ti ha dato.
Il matching deterministico funziona. Se qualcuno effettua il login o inserisce un'email in un qualsiasi momento, puoi inviare un'email con hash insieme alla conversione come segnale di abbinamento. L'hash deve seguire le regole di normalizzazione della piattaforma, quindi leggi la pagina del vendor prima di implementarlo.
Il fingerprinting probabilistico è il ripiego sbagliato nell'UE. Combina dimensioni dello schermo, font, fuso orario, output del canvas e segnali simili in un identificatore senza cookie. Se serva il consenso è una questione legale, e l'articolo 5(3) della Direttiva ePrivacy si applica all'accesso a informazioni sul dispositivo dell'utente, non solo ai cookie. La pagina EUR-Lex non si è caricata per me il 2026-10-24, quindi parafraso dall'ambito noto della Direttiva e non la cito. Non nomino nemmeno decisioni di specifiche autorità. I browser orientati alla privacy continuano a ridurre l'entropia su cui questi metodi si basano. L'accuratezza cala proprio dove serve di più.
Il cross-device è il vuoto che non puoi colmare lato server. Un click su un telefono e un acquisto su un portatile si collegano solo se la persona si identifica su entrambi.
Il consenso si applica ancora
"Nessun cookie, nessun consenso" è un fraintendimento comune. L'articolo 5(3) riguarda il dispositivo, quindi qualsiasi archiviazione o accesso lì richiede consenso, a meno che non sia strettamente necessario. Un cookie impostato per le analytics non è strettamente necessario solo perché è first-party.
Il trattamento lato server cambia dove fluiscono i dati. Ad blocker e partizionamento non lo toccano, e controlli tu ciò che esce dal tuo back-end. Richiede comunque una base giuridica GDPR ai sensi dell'articolo 6, di solito il legittimo interesse per le analytics a livello di campagna dopo una valutazione, e più difficile per la profilazione a livello individuale. La guida GDPR per gli accorciatori di URL copre gli articoli 6, 28 e 30, e il consenso ai cookie per i link brevi copre la questione del banner.
Sulla gestione degli IP, Elido tronca l'IP del visitatore all'edge (IPv4 a /24, IPv6 a /48) prima che il click venga memorizzato. Paese, regione, città e coordinate approssimative vengono ricavati prima e conservati con il click, e viene memorizzato lo user agent completo, quindi tratta la riga del click come dato personale. Se la minimizzazione conta per il tuo DPA, chiedi per iscritto la conservazione e la gestione degli IP attuali.
A cosa rinunci
L'attribuzione lato server recupera la maggior parte del segnale perso, non tutto.
Identità cross-device. Persa a meno che la persona non faccia il login.
Attribuzione view-through. Dipende dalla piattaforma pubblicitaria che abbina un'impression a una conversione successiva attraverso il proprio device graph. Aspettati numeri più rumorosi dei report basati sui click.
Finestre di lookback lunghe. Ogni piattaforma stabilisce le proprie finestre di attribuzione, e possono essere più corte dei 28 o 90 giorni che alcuni team usavano con i cookie. Controlla la finestra attuale di ogni piattaforma su cui fai report. Abbonamenti e cicli B2B perdono di più.
Multi-touch per utenti anonimi. Senza un identity graph ripieghi sull'ultimo click. L'email con hash degli utenti loggati ti permette di ricostruire le sequenze per quella fetta di pubblico, usando i modelli basati su regole adatti ai tuoi dati.
Uno stack pratico
Per un team che porta traffico a pagamento nell'UE, questo è ciò che costruirei con quello che esiste oggi.
- Link brevi con brand per email, SMS, QR code e post organici. Ottieni subito un record del click lato server e report per link. Tieni gli annunci puntati sull'URL della landing stessa: Elido scarta i parametri di query aggiunti a un link breve, quindi il
fbclidogcliddi un annuncio non sopravviverebbe al redirect (l'inoltro è pianificato, non ancora disponibile). - Cattura il click ID della piattaforma sulla landing (
fbclid,gclid) e scrivilo nel carrello o nell'ordine. Verifica che sopravviva su iOS Mail e nelle schede private prima di fidartene. - Metti
elido_link_idnei metadati di Stripe o negli attributi nota di Shopify così i ricavi vengono riportati per link senza alcun cookie. - Invia gli acquisti da server a server dal tuo back-end a Meta e GA4, con l'ID dell'ordine come chiave di deduplicazione.
- Fai l'hash dell'email per gli utenti loggati per coprire il cross-device e colmare i vuoti dove manca il click ID.
- Importa le conversioni offline in batch per cicli B2B o di abbonamento lunghi, usando l'API offline della piattaforma.
Niente di tutto questo richiede una CDP. Richiede un log dei click di cui ti fidi, un identificatore nel tuo ordine e un back-end che parli con le piattaforme pubblicitarie.
Correlati sul blog
Domande frequenti
Che cos'è l'attribuzione cookieless?
L'attribuzione cookieless collega una conversione al click o alla campagna che l'ha generata senza basarsi su un cookie di terze parti. In pratica significa un log dei click lato server, un click ID o link ID portato nell'URL e poi salvato nel tuo record d'ordine, e chiamate server-to-server verso le piattaforme pubblicitarie. Recupera la maggior parte di ciò che i pixel del browser perdono, ma non i percorsi cross-device né le finestre di lookback lunghe.
I cookie di terze parti sono spariti da Chrome?
No. Il 22 aprile 2025 Google ha dichiarato che non avrebbe introdotto un nuovo avviso autonomo per i cookie di terze parti in Chrome e che gli utenti continuano a scegliere nelle impostazioni di privacy di Chrome (blog Privacy Sandbox, consultato il 2026-10-24). Safari e Firefox li limitano già per impostazione predefinita, quindi l'attribuzione basata su di essi è inaffidabile per una larga parte del tuo traffico a prescindere da Chrome.
Rinunciare ai cookie elimina la necessità del consenso nell'UE?
No. L'articolo 5(3) della Direttiva ePrivacy riguarda l'archiviazione o l'accesso a informazioni sul dispositivo dell'utente, non solo i cookie, quindi rientrano anche fingerprinting e local storage. Un trattamento puramente lato server è fuori dall'articolo 5(3) ma richiede comunque una base giuridica GDPR. Chiedi al tuo consulente legale quale caso si applica alla tua configurazione.
Un cookie first-party impostato dal mio server è al sicuro dai limiti di Safari?
Per lo più sì. La pagina WebKit sulla tracking prevention dice che i cookie e lo storage creati in JavaScript vengono eliminati dopo 7 giorni senza interazione dell'utente, e che un cookie impostato da script su una landing page con link decorato dura 24 ore. I cookie impostati in un header di risposta HTTP sul tuo host first-party non sono limitati da queste regole, con l'eccezione degli host di terze parti mascherati, che hanno un limite di 7 giorni.
Un accorciatore di URL può fare attribuzione cookieless?
Può fornire la prima metà: un record del click lato server scritto quando viene servito il redirect, prima che entri in azione qualunque funzione di privacy del browser, più report per link e per campagna. Elido abbina inoltre gli ordini Stripe e Shopify a un link tramite un valore elido_link_id che inserisci nei metadati dell'ordine. Non genera ancora click ID né inoltra conversioni a Meta o GA4, quindi quei passaggi restano nel tuo back-end.
Che cosa non può recuperare l'attribuzione cookieless?
I percorsi cross-device in cui la persona non si identifica mai, le conversioni view-through che dipendono dal device graph della piattaforma pubblicitaria e i click più vecchi della finestra di lookback della piattaforma. L'email con hash degli utenti loggati colma in parte il vuoto. Per i visitatori anonimi, l'ultimo click è il tetto massimo.
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Senza registrazione. Crea un account gratuito per 50 link al mese.