Attribuzione cookieless spiegata: cosa funziona ancora nel 2026

Lo stack di attribuzione marketing che la maggior parte dei team ha costruito tra il 2012 e il 2019 dipendeva da due cose: un cookie di terze parti rilasciato dalla piattaforma pubblicitaria sulla landing page e un pixel del browser che si attivava sulla pagina di conversione e si abbinava a quel cookie. Entrambe le metà di quella coppia sono ora degradate. Nessuna delle due si riprenderà.

Questo post non è un lamento per il cookie. È una mappa di ciò che funziona effettivamente nel 2026 - quali percorsi di attribuzione sono sopravvissuti, quali sono stati commercializzati come soluzioni senza essere effettivamente soluzioni e come appare in pratica uno stack funzionante per team che eseguono acquisizione a pagamento nel traffico UE.

TL;DR#

• L'ITP 2.3 di Apple, Enhanced Tracking Protection di Firefox e l'attuale phase-out dei cookie di terze parti di Chrome insieme significano che il 60-70% del traffico web UE ora blocca o limita severamente i cookie di terze parti per impostazione predefinita.
• Due percorsi di attribuzione funzionano ancora: identificatori lato server passati attraverso un click ID e impianto di cookie first-party tramite una catena di redirect che il tuo dominio controlla.
• Cookieless non significa senza consenso. La Direttiva ePrivacy 2002/58/EC e il GDPR richiedono ancora il consenso per analytics non essenziali, indipendentemente dal meccanismo di storage.
• Lo stitching probabilistico tramite fingerprint non è un fallback conforme nell'UE; il matching deterministico tramite hash dell'email combinato con un click ID lato server è l'unico approccio che regge sia all'accuratezza che allo scrutinio normativo.

Cosa è cambiato: una breve timeline#

Safari ha iniziato a limitare i cookie di terze parti nel 2017 con ITP 1.0. Le restrizioni si sono intensificate rapidamente. ITP 2.3, rilasciato a settembre 2019, ha limitato la durata dei cookie first-party impostati da script a sette giorni, e a ventiquattro ore quando la catena di referral includeva un tracker cross-site noto. Quel solo cambiamento ha rotto l'handoff standard click-ID-to-cookie su cui si basavano la maggior parte dei vendor di attribuzione.

Enhanced Tracking Protection di Firefox ha rilasciato Total Cookie Protection a tutti gli utenti nel 2022, partizionando ogni cookie di terze parti per top-level site. Un cookie impostato da pixel.example.com sulla tua pagina di checkout e sulla pagina di checkout del tuo concorrente sono ora due cookie completamente separati - la correlazione cross-site è sparita per costruzione.

La timeline di Chrome è cambiata più volte da quando Google l'ha annunciata nel 2019. La posizione attuale, documentata sul sito Privacy Sandbox (consultato il 2026-05-12), ha la deprecazione che procede per un sottoinsieme di utenti con un rollout completo ancora in corso. Indipendentemente dalla data finale di Chrome, il quadro UE è già stabilito: Safari e Firefox insieme rappresentano la maggior parte del traffico mobile e desktop attento alla privacy nei mercati UE. Le strategie di attribuzione che richiedono cookie di terze parti sono già rotte per una grande fetta del tuo pubblico europeo.

L'effetto combinato misurato attraverso tipici account di performance marketing UE: l'attribuzione del pixel lato browser sta sottocontando le conversioni del 25-45% a seconda del mix di traffico, con verticali iOS-heavy (moda, bellezza, app, servizi in abbonamento) all'estremo superiore di quella gamma.

I due percorsi di attribuzione sopravvissuti#

Percorso 1: identificatori lato server#

Il meccanismo centrale è semplice. Quando un utente clicca il tuo annuncio, la piattaforma pubblicitaria aggiunge un identificatore di click all'URL della landing page - fbclid per Meta, gclid per Google, e così via. Quell'identificatore esiste nell'URL, non in un cookie, quindi ITP e la partizione dei cookie non lo toccano.

La tua landing page legge il click ID dall'URL e lo scrive in un cookie first-party sul tuo dominio, o lo passa al carrello e infine al record dell'ordine. Quando l'utente converte, il tuo back-end legge il click ID dall'ordine e invia la conversione server-to-server all'API di conversione della piattaforma pubblicitaria - Meta Conversions API, GA4 Measurement Protocol, endpoint di eventi server-side di Mixpanel.

Questo percorso funziona perché non tocca mai i cookie di terze parti. Il click ID è nella query string URL al momento dell'atterraggio. Il tuo cookie first-party sul tuo dominio non è limitato da ITP nello stesso modo dei cookie di terze parti (anche se è soggetto al cap di 7 giorni sui cookie impostati da script se la catena di referral è sospetta - di più su questo sotto). L'evento di conversione fluisce server-to-server, interamente fuori dal browser.

I punti deboli sono reali. Se l'utente cancella i cookie tra atterraggio e conversione, il click ID è sparito. Se la conversione avviene su un dispositivo diverso, non c'è link cross-device a meno che non si abbia un utente loggato con un indirizzo email noto. E iOS 17 ha introdotto la Link Tracking Protection in Private Browsing e Mail, che strippa parametri di click ID noti dagli URL - fbclid, gclid, msclkid sono nella lista di strip. Un utente che arriva tramite l'app Mail con la link tracking protection attiva non porterà affatto il click ID nel tuo sito.

Percorso 2: catena di redirect first-party#

Il secondo percorso sopravvissuto usa un redirect che controlli come superficie di attribuzione. Invece del click ID della piattaforma pubblicitaria, generi il tuo identificatore persistente al momento del redirect sul tuo dominio.

Quando un utente clicca un link sul tuo dominio - sia un link breve, un redirect di landing di campagna o un deep link brandizzato - l'handler di redirect sul tuo edge gira prima che si applichino le restrizioni di privacy del browser. Può:

1. Impostare un cookie first-party con un click ID generato dal server sul tuo dominio.
2. Aggiungere il click ID come parametro URL all'URL di destinazione.
3. Loggare l'evento di click lato server con il contesto tecnico completo (IP, user-agent, referrer, timestamp) al momento del click piuttosto che al momento del caricamento della pagina.

Poiché questo è il tuo dominio e il tuo cookie lato server, si trova al di fuori delle restrizioni dei cookie di terze parti che ITP prende di mira. Il cookie è impostato dal tuo server tramite un header di risposta Set-Cookie sulla risposta di redirect - i cookie impostati dal server non sono soggetti al cap ITP di 7 giorni che si applica alle scritture document.cookie da JavaScript.

Questa è la superficie di attribuzione che un accorciatore di URL fornisce che un pixel del browser non può. Il redirect si risolve sul dominio dell'accorciatore. Se quel dominio è il tuo dominio brandizzato, il tuo click ID è first-party, impostato dal server e architetturalmente posizionato prima che qualsiasi restrizione di privacy lato browser venga eseguita.

Come un link breve diventa la superficie di attribuzione#

Il flusso di redirect funziona così. L'URL di destinazione del tuo annuncio è un link breve brandizzato - per esempio, go.acme.example/summer-sale. L'utente clicca. La richiesta di redirect raggiunge l'handler edge di Elido, che:

• Cerca l'URL di destinazione.
• Genera un identificatore elido_click e logga l'evento di click lato server.
• Imposta un first-party Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 sulla risposta di redirect.
• Aggiunge ?elido_click=<id> all'URL di destinazione prima di inoltrare.

La pagina di destinazione riceve il click ID nella query string. Il tuo tag manager o codice del tema lo legge e lo memorizza nel record del carrello o dell'ordine. Quando avviene la conversione, fai POST su POST /v1/conversions con il click ID e i dettagli dell'ordine - Elido gestisce l'hashing SHA-256 degli identificatori dei clienti e il fan-out lato server a Meta CAPI, GA4 Measurement Protocol e Mixpanel.

Il click ID non ha mai vissuto in un cookie di terze parti. Era impostato dal server, first-party, loggato prima che il layer di privacy del browser avesse la possibilità di interferire. Per la meccanica completa del passo di inoltro lato server, tracciamento server-side delle conversioni tramite link brevi copre la deduplicazione, i requisiti di hashing e le semantiche di retry in dettaglio.

Per la questione più ampia di come ITP degrada specificamente l'attribuzione dei click e cosa fa al riguardo la catena di redirect del link breve, attribuzione dei click dopo l'ITP di Safari è il companion operativo a questo post.

Stitching dell'identità: cosa funziona e cosa no#

I click ID lato server risolvono il problema dell'attribuzione per gli utenti che cliccano un link e convertono nella stessa sessione del browser sullo stesso dispositivo, senza cancellare i cookie, senza che la link tracking protection strippi il parametro. Questo copre comunque la maggior parte delle conversioni e-commerce. Ma non copre tutto, e gli approcci che i team usano per colmare il gap rimanente variano significativamente sia in accuratezza che in esposizione legale.

Il matching deterministico funziona. Se l'utente è loggato, o fornisce il suo indirizzo email in qualsiasi punto del funnel (cattura email, iscrizione newsletter, checkout), puoi fare hash di quell'indirizzo email con SHA-256 e includerlo nell'evento di conversione. Meta CAPI, GA4 e Mixpanel accettano tutti l'email hashata come segnale di matching insieme o al posto di un click ID. Il tasso di match per il traffico con email nota è alto - Meta riporta internamente tassi di match sopra il 90% quando è presente un'email normalizzata e hashata. Questo è il principale meccanismo di stitching che sopravvive intatto alla deprecazione dei cookie.

L'accoppiamento di deduplicazione conta qui. Ogni evento di conversione ha bisogno di un event_id (per Meta) o transaction_id (per GA4) che sia identico tra il pixel lato browser e l'invio lato server. Senza di esso, entrambi gli eventi vengono ingeriti e la conversione viene conteggiata due volte. L'ID dell'ordine è la chiave di dedup standard per gli eventi di acquisto.

Il fingerprinting probabilistico non funziona - e non è legale nell'UE. Il fingerprinting del browser assembla un identificatore unico dalla combinazione di risoluzione dello schermo, font installati, fuso orario, user-agent, fingerprint di rendering canvas e segnali simili. L'identificatore è probabilistico - assegna un match ad alta confidenza tra due eventi senza un cookie condiviso o login. Alcuni vendor di attribuzione lo offrono come soluzione di "misurazione cookieless".

Nell'UE, questo approccio ha un problema legale specifico. La Direttiva ePrivacy 2002/58/EC, Articolo 5(3), richiede il consenso per l'accesso o lo storage di informazioni sull'apparecchiatura terminale di un utente. La posizione dell'EDPB, ripetuta in diverse decisioni delle autorità di vigilanza dal 2022, è che il fingerprinting rientra nell'ambito dell'Articolo 5(3) indipendentemente dal fatto che l'identificatore sia tecnicamente un "cookie". La DSB austriaca, la CNIL francese e il Garante italiano hanno emesso ciascuno azioni di enforcement sul fingerprinting senza consenso. L'affermazione "non usiamo cookie, usiamo fingerprinting" non è un argomento di compliance; è l'argomento che invita un controllo più stretto.

Anche al di fuori dell'esposizione legale, il fingerprinting probabilistico degrada in accuratezza man mano che l'entropia del browser diminuisce. I browser moderni focalizzati sulla privacy abbassano attivamente l'entropia normalizzando l'output canvas e limitando la risoluzione delle API di temporizzazione. La qualità del segnale cala precisamente nella popolazione - attenta alla privacy, iOS-heavy - dove hai più bisogno di misurazione accurata.

Lo stitching cross-device tramite CRM è il gap rimanente. Per utenti che convertono su un dispositivo diverso da quello su cui hanno cliccato, il matching deterministico tramite email è l'unico approccio che funziona. Se l'utente è loggato su entrambi i dispositivi, l'ID utente è il link. Se non lo è, il click ID sul dispositivo A e la conversione sul dispositivo B non possono essere connessi senza che l'utente fornisca volontariamente un identificatore (email, telefono) che puoi hashare e abbinare. Questo gap non può essere chiuso lato server. È un vero limite di attribuzione nel mondo cookieless.

L'overlay di compliance#

L'inquadramento di "attribuzione cookieless" può ingannare le persone facendole pensare che poiché nessun cookie viene impostato, non è richiesto consenso. Non è quello che dice la legge.

La Direttiva ePrivacy 2002/58/EC, Articolo 5(3), si applica a qualsiasi storage o accesso di informazioni sull'apparecchiatura terminale di un utente - non solo cookie. Un cookie first-party impostato per scopi di analytics richiede lo stesso consenso di un cookie di terze parti impostato per scopi di tracciamento, se quel cookie non è essenziale. Il cookie click ID impostato dal server descritto sopra è analytics-adjacent; può o non può richiedere consenso a seconda della valutazione del tuo titolare dello scopo e dell'implementazione nazionale applicabile della Direttiva.

Quello che fa l'approccio lato server - e questo è il suo vero vantaggio di compliance - è spostare l'elaborazione fuori dal dispositivo dell'utente e sul server. Il log degli eventi di click, l'inoltro dell'evento di conversione, lo stitch dell'identità: questi avvengono nel tuo back-end e nel back-end di Elido, non in uno script del browser. Ciò significa che gli ad blocker non li intercettano, le funzionalità di privacy del browser non li partizionano e la postura di minimizzazione dei dati è controllabile da te piuttosto che dipendente da ciò che un tag di terze parti decide di inviare.

La questione della base giuridica GDPR è separata dalla questione ePrivacy. Anche con l'attribuzione lato server, hai bisogno di una base giuridica sotto l'Articolo 6 GDPR per elaborare dati di click su soggetti UE identificabili. Per gli analytics a livello di campagna, la maggior parte dei titolari basa questo sull'interesse legittimo sotto l'Articolo 6(1)(f) dopo una Valutazione di Interesse Legittimo. Per il profiling a livello individuale o il retargeting, la base è più difficile. Il cornerstone GDPR per accorciatori di URL copre l'analisi degli Articoli 6, 28 e 30 in dettaglio; il riassunto qui è che cookieless ≠ senza consenso, e l'overlay di compliance non scompare perché è cambiato il meccanismo di storage.

I default degli eventi di click di Elido riflettono una postura di minimizzazione dei dati: gli IP sono troncati a /24 (IPv4) prima di essere persistiti, le stringhe user-agent complete sono analizzate e scartate. I dati a piena risoluzione sono disponibili per workspace se il tuo caso d'uso lo richiede, ma il default è l'impostazione conservativa. Quello conta per la conversazione di addendum DPA con i tuoi acquirenti. Per più su quella conversazione, solutions/marketers copre i punti di contatto procurement per team di marketing.

Cosa rinunci#

L'onesta contabilità conta. L'attribuzione cookieless lato server recupera la maggior parte del segnale perso al degrado lato browser, ma non recupera tutto.

Identità cross-device in tempo reale. Come notato sopra: se un utente clicca su mobile e converte su desktop senza un evento di login che collega i due, l'attribuzione è persa. Non c'è alcuna soluzione lato server conforme per questo. Il gap è strutturale.

Attribuzione view-through precisa. L'attribuzione view-through - accreditare una campagna per una conversione che ha seguito un'impressione di annuncio, non un click - richiede che la piattaforma pubblicitaria abbia abbinato l'utente attraverso entrambi gli eventi. Le API di conversione lato server gestiscono bene l'attribuzione basata su click; view-through dipende dal grafo cross-device della piattaforma stessa, che si degrada in proporzione alla perdita di segnale. Aspettati che il reporting view-through sia più rumoroso e meno affidabile dei numeri basati su click.

Finestre di lookback lunghe. La maggior parte degli endpoint API di conversione lato server impone un cap di lookback su quanto indietro nel tempo un click può essere attribuito a una conversione. Il lookback standard di Meta CAPI è 7 giorni per click-through. Il Measurement Protocol di GA4 ha una finestra di attribuzione che varia per canale. Questi cap sono più brevi delle finestre di 28 giorni o 90 giorni che alcuni team usavano nel mondo basato su cookie. I prodotti in abbonamento e gli acquisti considerati con cicli di ricerca lunghi vedranno più conversioni cadere fuori dalla finestra attribuibile.

Dominio dell'ultimo click. Senza un grafo di identità multi-touch, l'attribuzione lato server default a ultimo click - il click ID più recente nella catena ottiene il credito. Per campagne di brand awareness che guidano conversioni assistite per un lungo periodo, l'attribuzione lato server ultimo click sottovaluterà sistematicamente la spesa upper-funnel. La mitigazione è lo stitching CRM tramite hash dell'email: se l'email di ogni utente loggato è su ogni evento di conversione, puoi ricostruire una sequenza multi-touch per la porzione loggata del tuo pubblico. Per gli utenti anonimi, ultimo click è il tetto.

Uno stack pratico#

Dati i vincoli sopra, ecco lo stack di attribuzione che funziona per un team di performance marketing che esegue traffico UE nel 2026.

Click ID di link breve come punto di ingresso. Tutte le destinazioni di annuncio sono link brevi brandizzati sul tuo dominio. Il redirect imposta un cookie first-party lato server e aggiunge il click ID all'URL di destinazione. Questo ti dà un identificatore persistente, impostato dal server, che sopravvive a ITP e alla partizione dei cookie per la sessione.

Plumbing di carrello e ordine. Il click ID viene scritto su un attributo del carrello al caricamento della pagina (dal parametro URL o dal cookie first-party). Alla creazione dell'ordine, il click ID è sugli attributi personalizzati dell'ordine. Questo è l'handoff durevole - una volta che il click ID è sull'ordine, non scade.

CAPI lato server a Meta. All'ordine pagato, il tuo back-end (o la funzionalità di inoltro delle conversioni) fa POST a Meta CAPI con il click ID, l'email hashata SHA-256 e gli identificatori fbc/fbp dai cookie first-party. L'event_id è l'ID dell'ordine, abbinando il pixel lato browser. Meta deduplica entro la finestra di matching di 48 ore.

Measurement Protocol lato server a GA4. Simultaneamente, un evento server-side GA4 viene inviato con transaction_id uguale all'ID dell'ordine. Il client_id è il valore del cookie GA4 _ga se disponibile, il click ID come fallback. GA4 deduplica su transaction_id entro la finestra di sessione.

Stitch CRM tramite hash dell'email. Per qualsiasi conversione in cui manca il click ID (organico, diretto, brand search), l'indirizzo email hashato è il segnale di attribuzione. Questo popola il segmento "utente noto" della tua attribuzione e supporta la ricostruzione multi-touch di base per i clienti loggati.

Import di conversioni offline per lookback lungo. Per prodotti in abbonamento o pipeline B2B dove la conversione avviene settimane dopo il click, l'import di conversioni offline tramite l'API batch della piattaforma (Conversions API offline events di Meta, conversioni offline di Google Ads) ti permette di inviare eventi di attribuzione oltre la finestra di lookback in tempo reale. La chiave di match è ancora email hashata o telefono; la finestra temporale è estesa. Questo non risolve l'attribuzione anonima a ciclo lungo, ma chiude il loop per la porzione del tuo pubblico che ha fornito un indirizzo email.

Lo stack sopra non richiede un CDP. Richiede un accorciatore di URL che genera e persiste click ID lato server, un back-end che fa il plumbing del click ID fino all'ordine e un layer di inoltro delle conversioni che gestisce l'hashing e il fan-out API. Per l'implementazione tecnica del layer di fan-out, tracciamento server-side delle conversioni tramite link brevi ha le forme di payload, la meccanica di deduplicazione e le semantiche di retry. Per dove questo si inserisce in un flusso di lavoro UTM di campagna completo, vedi solutions/marketers.

La versione di questo stack che non funziona: una che si basa sul grafo cross-device della piattaforma pubblicitaria stessa per la risoluzione dell'identità, spera che gli utenti iOS abbiano App Tracking Transparency abilitata in un modo che beneficia la tua misurazione, o usa fingerprinting probabilistico per colmare i gap. Il primo è fuori dal tuo controllo. Il secondo è velleitario. Il terzo è una responsabilità di compliance nell'UE.

Lavora con ciò che regge.