Attribuzione dei click dopo l'ITP di Safari: cosa funziona ancora nel 2026

Apple ha rilasciato la prima versione di Intelligent Tracking Prevention a settembre 2017. È stata presentata come una funzionalità di privacy, il che è accurato. È stata anche uno smantellamento sistematico di ogni workaround che l'industria dell'ad tech aveva assemblato da quando l'ecosistema dei cookie di terze parti aveva iniziato a incrinarsi intorno al 2013. Ogni nuova versione di ITP ha chiuso la via di fuga che i marketer avevano trovato nella precedente. Quando l'ITP 2.3 è stato rilasciato nel 2019, la sequenza di chiusure era stata sufficientemente accurata che gli unici percorsi di attribuzione ancora funzionanti in modo affidabile su Safari erano quelli che non avevano mai dipeso dal tracciamento cross-site in primo luogo.

Questo post percorre quella sequenza in ordine di data: cosa ha rotto ogni versione, quale workaround era specificamente progettata per chiudere e dove lascia l'attribuzione nel 2026. Il post companion Attribuzione cookieless spiegata copre il panorama più ampio attraverso i browser; questo è specificamente su Safari e specificamente sul pattern di redirect-chain che sopravvive a tutto questo.

TL;DR#

• ITP 2.0 (2018) ha bloccato tutto l'accesso al third-party storage su domini cross-site, uccidendo il percorso standard di attribuzione del pixel pubblicitario su Safari.
• ITP 2.1 (2019) ha limitato i cookie first-party impostati da JavaScript a 7 giorni, ponendo fine alle finestre di attribuzione annuali impostate tramite tag manager.
• ITP 2.2 e 2.3 hanno strippato i parametri di link decoration e degradato gli header referrer, chiudendo gli ultimi workaround basati su query string.
• Un link breve sul tuo dominio imposta un cookie first-party lato server al momento del redirect - questo è l'unico pattern che sopravvive all'ITP in tutte le sue versioni e ti dà una finestra di attribuzione affidabile di 7 giorni su Safari.

La timeline di ITP: una panoramica versione per versione#

ITP non è arrivato pienamente formato. È stato rilasciato in modo incrementale, con ogni versione che mirava a una classe specifica di workaround che l'industria aveva sviluppato in risposta alla versione precedente. Capire la sequenza è importante perché la forma tecnica di ciò che sopravvive è definita da ciò che è stato chiuso e come.

ITP 1.0 - Settembre 2017. Il primo rilascio ha classificato i domini come "cross-site tracker" in base alla frequenza di rimbalzo e ai segnali di interazione utente. I domini classificati come tracker avevano i loro cookie partizionati - potevano essere impostati, ma letti solo in un contesto cross-site se l'utente aveva interagito direttamente con il dominio del tracker nelle ultime 24 ore. Per un dominio come un pixel di analytics standard a cui gli utenti non navigano mai direttamente, la finestra di 24 ore era un blocco de facto.

ITP 1.1 - Marzo 2018. Gli inserzionisti hanno risposto a 1.0 instradando l'attribuzione attraverso catene di redirect che toccavano il dominio del tracker come first-party landing prima di rimbalzare alla destinazione. Questo dava agli utenti una "visita diretta" al dominio del tracker, che resettava l'orologio di interazione. ITP 1.1 ha identificato questo pattern - noto come bounce tracker - e ha rimosso il credito di interazione che le catene di bounce-redirect generavano. I domini che sembravano esistere unicamente per il pattern di bounce-and-redirect hanno perso il loro status di interazione.

Cosa ha rotto ITP 2.0#

ITP 2.0 è stato rilasciato a settembre 2018. È stata la rottura strutturale. Dove 1.x aveva partizionato i cookie di terze parti, 2.0 è andato oltre: ha rimosso completamente l'accesso al third-party storage per i domini classificati. Cookie, localStorage, IndexedDB, dati cached - tutto è stato bloccato per qualsiasi dominio classificato da ITP come cross-site tracker.

L'effetto pratico sull'ad tech è stato significativo. Il Facebook Pixel, il tag di conversione di Google Ads e la maggior parte dei pixel di retargeting dipendono dalla lettura di un cookie cross-site per legare un click a una conversione. Su Safari dopo ITP 2.0, quella lettura falliva. I report di Meta dell'epoca indicavano un gap del 15-25% nella copertura degli eventi sul traffico Safari - click e conversioni che il pixel vedeva su Chrome o Firefox semplicemente non apparivano dagli utenti Safari.

Il blocco dello storage non era limitato ai cookie. Gli script che cercavano di persistere identificatori in localStorage sotto un dominio classificato come tracker, o di usare i Service Worker per la persistenza, erano ugualmente bloccati. L'intento di 2.0 era rendere il layer di third-party storage strutturalmente non disponibile per scopi di tracciamento, non solo rompere una tecnica specifica.

Cosa ha rotto ITP 2.1#

Se 2.0 ha ucciso l'attribuzione di terze parti, ITP 2.1 (Marzo 2019) ha mirato al workaround cresciuto in risposta ad esso: attribuzione tramite cookie first-party via injection di tag manager.

La logica era valida. Se il pixel di terze parti era bloccato, potevi comunque persistere l'attribuzione scrivendo un cookie first-party sul dominio dell'inserzionista tramite JavaScript - tipicamente iniettato da un tag manager come GTM. Il cookie era first-party e quindi non soggetto alle restrizioni di third-party storage di ITP. Molti team erano passati a finestre di attribuzione annuali impostate in questo modo, ragionando che una scrittura first-party document.cookie fosse sicura.

ITP 2.1 ha limitato tutti i cookie impostati tramite document.cookie - indipendentemente dallo status first-party o third-party - a un massimo di 7 giorni. Il limite si applicava specificamente ai cookie impostati da script; i cookie impostati tramite l'header di risposta HTTP Set-Cookie non erano interessati da 2.1. La distinzione è precisa e conseguente: document.cookie = "..." in JavaScript è limitato a 7 giorni. Set-Cookie: ...; Max-Age=31536000 da una risposta del server no.

La vittima immediata fu il setup di attribuzione basato su GTM. GTM scrive cookie attraverso JavaScript sulla pagina. Quei cookie, indipendentemente dalla loro scadenza dichiarata, ora scadevano in 7 giorni su Safari. Un utente che cliccava un link di campagna un martedì e convertiva il mercoledì successivo era fuori dalla finestra di attribuzione. La finestra di attribuzione annuale con cookie first-party a cui i team erano migrati dopo ITP 2.0 era sparita.

Cosa ha rotto ITP 2.2#

ITP 2.2 ha stretto due aree. Primo, ha ridotto il cap sui cookie JavaScript a 24 ore nel caso specifico in cui la pagina di destinazione era collegata da un dominio che ITP aveva classificato come cross-site tracker. Se un utente cliccava un link dalla pagina di un dominio classificato, i cookie first-party sul sito di destinazione impostati tramite JavaScript erano limitati a 24 ore - non 7 giorni. Il cap di 7 giorni rimaneva per percorsi referrer non tracciati, ma il cap di 24 ore si applicava quando la catena di click includeva un dominio classificato.

Secondo, e notato più ampiamente, ITP 2.2 ha introdotto limiti sulla link decoration. Le piattaforme pubblicitarie e gli strumenti di analytics avevano sviluppato un pattern di aggiungere identificatori di attribuzione come parametri di query agli URL di destinazione - gclid per Google Ads, fbclid per Meta, msclkid per Microsoft Advertising. In determinate condizioni, se il dominio di linking era classificato come tracker, ITP iniziava a strippare quei parametri prima che la pagina caricasse o a limitare i cookie che potevano essere impostati in risposta alla loro presenza.

Questo era un attacco diretto al percorso di attribuzione basato su gclid a cui i team erano passati dopo 2.0 e 2.1. Il ragionamento era esplicito: Apple considerava il tracciamento utente basato su parametri di query equivalente in impatto sulla privacy al tracciamento basato su cookie, e dovevano applicarsi le stesse restrizioni.

Cosa ha rotto ITP 2.3#

ITP 2.3 (Settembre 2019) ha chiuso due gap rimanenti.

Il primo era il downgrading del referrer sulla navigazione cross-site. Dove le versioni precedenti si erano concentrate sullo storage e sui parametri di link, 2.3 ha affrontato l'header referrer - il valore Referer che una pagina riceve quando un utente naviga ad essa da un altro sito. Per navigazioni cross-site da domini classificati, ITP 2.3 ha degradato il referrer a solo origine: https://classified-domain.com/ invece del completo https://classified-domain.com/path?campaign=spring&source=email. Il path e la query string, che spesso contenevano il contesto di attribuzione, venivano strippati.

Il secondo cambiamento ha esteso la logica di capping dello storage. Oltre al cap di 7 giorni sui cookie JavaScript, ITP 2.3 ha applicato un cap sullo storage dopo un singolo click cross-site da un dominio classificato: tutto lo storage lato client sul sito di destinazione - cookie, localStorage, IndexedDB - era soggetto al capping. L'intento era chiudere una classe di pattern di attribuzione stateful in cui il semplice atto di essere collegati da un dominio classificato avrebbe avviato un countdown sulla capacità della destinazione di persistere dati.

Insieme, 2.2 e 2.3 hanno chiuso le tre vie principali che i team avevano usato dopo 2.0 e 2.1: parametri di link decoration, attribuzione basata su referrer e accumulazione di storage attraverso catene di click cross-site.

Cosa sopravvive#

La sequenza di ITP era metodica, ma mirava al tracciamento cross-site. I pattern che sopravvivono sono quelli che sono genuinamente first-party - dove i dati di attribuzione vengono catturati sul tuo dominio, impostati dal tuo server, e non passano mai attraverso lo storage di un dominio di terze parti.

Cookie first-party impostati dal server. Il cap sui cookie di ITP 2.1 si applica alle scritture document.cookie tramite JavaScript. I cookie impostati da un server tramite l'header di risposta HTTP Set-Cookie mantengono la loro scadenza dichiarata. Il vincolo chiave è che il cookie deve essere impostato sul dominio che il server controlla.

Inoltro eventi lato server. Se l'identificatore di click viene catturato al momento del redirect e memorizzato lato server, la lookup di attribuzione al momento della conversione è un'operazione server-to-server. Nessun cookie del browser deve sopravvivere 7 giorni; il click ID è nel tuo database. Questa è l'architettura dietro il tracciamento server-side delle conversioni e l'approccio che Meta CAPI, GA4 Measurement Protocol e TikTok Events API sono tutti progettati per supportare.

Matching deterministico tramite email o telefono hashati. Quando un utente è autenticato o ha inviato un indirizzo email, la conversione può essere abbinata al click originale tramite hash dell'email piuttosto che tramite identità del cookie. Questo percorso è indipendente da ITP interamente - non si è mai basato sullo storage del browser. La limitazione è la copertura: funziona solo per utenti che si sono identificati entro la finestra di attribuzione.

Il contesto tecnico completo per questi pattern è in Attribuzione cookieless spiegata.

Il pattern di redirect del link breve#

I link brevi sul tuo dominio - non su un dominio di accorciatore condiviso - ti danno il percorso di cookie server-set in una forma che funziona naturalmente con il traffico di campagna.

Il meccanismo è semplice. Quando un utente clicca un link di campagna che punta a go.acme.example/spring26, la richiesta colpisce un handler edge su go.acme.example. L'handler edge cattura l'evento di click, genera un click ID e imposta un header Set-Cookie sulla risposta di redirect - un cookie first-party server-set su acme.example. Emette poi il 302 all'URL di destinazione con il click ID aggiunto come parametro di query.

Poiché il cookie è impostato tramite Set-Cookie dal server al momento del redirect, il cap JavaScript di 7 giorni di ITP 2.1 non si applica. Il cookie mantiene qualsiasi scadenza il server abbia impostato. Su Safari, con ITP 2.3 pienamente attivo, un cookie server-set su go.acme.example sopravvive per l'intera finestra configurata. Impostiamo una scadenza di 7 giorni per impostazione predefinita in Elido perché corrisponde comunque al vincolo più restrittivo di ITP per i cookie impostati da JS, e il cookie server-set tiene per tutti i 7 giorni.

La pagina di destinazione poi legge il click ID dal cookie o dal parametro di query (qualsiasi sia disponibile), lo scrive negli attributi del carrello o dell'ordine, e l'evento di conversione lo porta server-side al momento dell'acquisto. Nessun dominio cross-site è coinvolto. Il cookie è sul tuo dominio. La lookup di attribuzione è un'operazione lato server. ITP non ha nulla da bloccare.

Questo è il motivo per cui il supporto del dominio personalizzato su un link breve è importante per l'attribuzione: non solo per il branding ma per la classificazione first-party del cookie. Un dominio di accorciatore condiviso come bit.ly o short.io è un'origine diversa dal tuo sito web. Un cookie impostato su bit.ly è un cookie di terze parti su acme.example; ITP 2.0 lo blocca. Un cookie impostato su go.acme.example è first-party; nulla in ITP lo tocca. La pagina solutions/marketers copre il flusso di attribuzione di campagna end to end.

Per il contesto GDPR più profondo su quali dati di click un accorciatore può lecitamente elaborare e come configurare la minimizzazione dei dati sullo schema degli eventi di click, vedi GDPR per accorciatori di URL.

Cosa ancora non funziona#

L'onestà è più economica che vendere troppo una soluzione parziale.

Attribuzione view-through cross-domain. Se un utente vede un annuncio su publisher.example senza cliccare e successivamente converte su advertiser.example, non c'è percorso ITP-safe per quell'attribuzione. View-through richiede intrinsecamente un segnale cross-site dall'impressione alla conversione. Safari la blocca, e gli approcci di inoltro lato server sopra sono iniziati dal click - richiedono che il click imposti il cookie first-party o scriva il click ID.

Stitching in tempo reale per utenti non autenticati. Se un utente converte senza mai effettuare login o inviare un indirizzo email, l'unico identificatore disponibile è il click ID dal cookie o parametro di query. Se il cookie è scaduto (oltre i 7 giorni dopo il primo click, o 24 ore se si applica il cap più stretto di 2.2), lo stitch è perso. Lo storage server-side del click ID risolve questo per le conversioni entro la finestra. Non lo risolve per le conversioni che arrivano dopo la chiusura della finestra.

Finestre di attribuzione più lunghe di 7 giorni su Safari per first-touch. Se il tuo business ha un ciclo di acquisto misurato in settimane o mesi - comune in SaaS B2B, e-commerce ad alto valore, servizi finanziari - la finestra di 7 giorni sui cookie first-party Safari significa che una frazione sostanziale di conversioni non sarà attribuibile al loro click originario. Per questi modelli di business, il percorso deterministico tramite hash dell'email è l'unica opzione; l'attribuzione probabilistica su Safari non è abbastanza affidabile per agire.

Fingerprinting come sostituto. Canvas fingerprinting, audio fingerprinting ed enumerazione dei font sono workaround che cercano di ri-identificare gli utenti tra sessioni senza cookie. Apple si è esplicitamente mossa per ridurre la superficie di fingerprinting in Safari. Le note di rilascio ITP 2.3 fanno riferimento a "ulteriore protezione contro altre forme di tracciamento cross-site," e la direzione è continuata in ogni rilascio Safari successivo. Il fingerprinting comporta anche un rischio legale materiale sotto l'Articolo 6 GDPR, come esplorato in GDPR per accorciatori di URL. Non è un sostituto praticabile per i pattern descritti sopra.

Punto di partenza pratico#

Il pattern di redirect funziona. Configura un dominio personalizzato sul tuo workspace di link breve (go.yourdomain.example), instrada il traffico di campagna attraverso di esso e configura la pagina di destinazione per leggere il parametro di query elido_click o il cookie first-party e scriverlo negli attributi dell'ordine o del carrello prima che l'utente converta. Poi instrada le conversioni lato server alle piattaforme pubblicitarie tramite la API delle conversioni. La finestra di 7 giorni copre la maggior parte dei percorsi click-to-conversion per la maggior parte dei tipi di campagna.

Per il setup di inoltro delle conversioni - Meta CAPI, GA4 Measurement Protocol, le semantiche di retry e la forma di deduplicazione - il tracciamento server-side delle conversioni è il companion tecnico a questo post. Per la superficie di prodotto, le funzionalità di tracciamento delle conversioni è il punto di partenza.

ITP non ha ucciso l'attribuzione. Ha ucciso un'architettura specifica di attribuzione - quella costruita su storage persistente cross-site e accumulazione indiscriminata di dati attraverso domini che non controlli. L'architettura che l'ha sostituita è più difendibile, non meno.