Article
ITP Safari, ad blocker e il pixel messo in pausa da Shopify: cosa si perde davvero
Tre cause di perdita vengono quasi sempre messe nello stesso paragrafo e pesano in modo molto diverso. Una è grossa, una è più piccola di come viene raccontata, e la terza è arrivata il 13 gennaio 2026.
Tre cause di perdita vengono quasi sempre messe nello stesso paragrafo, e pesano in modo molto diverso. Una è grossa e nota, una è più piccola di come viene raccontata, e la terza è arrivata il 13 gennaio 2026 senza che nessuno la annunciasse ai negozianti. Questa guida le separa e dice quanto se ne recupera davvero.
Categoria: implementazione · 12 minuti di lettura · Mattia Minafò · aggiornato al 18 agosto 2026
Di cosa parliamo
Hai letto che ITP e gli ad blocker ti fanno perdere il 20 o 30% delle conversioni, hai messo il canale server, e non sai dire quanto hai recuperato davvero né dove sia finito il resto.
Le domande a cui questa guida risponde: quanto pesa ciascuna delle tre cause, quanto ne recupera il canale server, e cosa resta fuori comunque.
Nell’ordine: cosa fa ITP ai cookie e da quando, quanto pesano davvero gli ad blocker, cosa è cambiato su Shopify a gennaio, quanto si recupera secondo il fornitore e secondo le nostre misure, il limite che non viene mai scritto, e la checklist.
Metodo e limite. Il comportamento di Safari è verificato sul blog di WebKit, il cambio di Shopify sul changelog ufficiale, entrambi al 18 agosto 2026. I numeri sui progetti vengono da audit nostri, con finestra dichiarata. Non è una guida al debug del tuo setup.
Nel testo trovi tre etichette. Documentazione quando la fonte è ufficiale, misurato da noi quando il numero viene da un nostro audit, raccomandazione quando è un giudizio professionale e non un fatto.
Indice
- Cosa fa davvero ITP ai tuoi cookie, e da quando
- Perché il cookie scritto dal server non dura per forza di più
- Quanto pesano gli ad blocker, che è meno di come viene raccontato
- Il pixel che Shopify ha messo in pausa il 13 gennaio 2026
- Quanto si recupera, secondo chi lo vende e secondo noi
- Il limite che non viene mai scritto
- La checklist
Cosa fa davvero ITP ai tuoi cookie, e da quando
Le date circolano sbagliate, e sbagliano di versione oltre che di anno.
Documentazione. Il cap di sette giorni sui cookie persistenti scritti da JavaScript arriva con ITP 2.1, il 21 febbraio 2019, non con Safari 12 nel 2018. WebKit scrive che «all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry». I cookie di sessione restano fuori.
Poi la restrizione si è allargata tre volte.
| Quando | Cosa è cambiato | Cosa colpisce |
|---|---|---|
| Febbraio 2019 | Cap a 7 giorni sui cookie scritti da JavaScript | _fbp, _ga e qualunque cookie impostato dal browser |
| Novembre 2020 | Cap a 7 giorni sui cookie scritti da risposte HTTP con CNAME cloaking | Il sottodominio di tagging che punta al fornitore |
| 2022 | Cap a 7 giorni sulle risposte da indirizzi IP di terze parti | Il container ospitato altrove |
| Settembre 2025 | Protezione avanzata dal fingerprinting attiva di default | Identificativi di clic rimossi in alcuni percorsi di redirect |
Raccomandazione. Le tre righe centrali contano più della prima, e sono quelle che quasi nessuno cita. Il paragrafo dopo spiega perché.
Perché il cookie scritto dal server non dura per forza di più
Si legge quasi ovunque che il cookie impostato dal server via header HTTP non è soggetto al limite, e che quindi torna a durare mesi. È vero solo a una condizione, e la condizione non è avere un container.
Documentazione. Dal 12 novembre 2020 WebKit limita a sette giorni anche i cookie scritti in risposte HTTP quando il sottodominio risolve, tramite CNAME, verso un dominio diverso dal tuo. Dal 2022 la stessa cosa vale quando l’indirizzo IP di risposta è di terze parti.
La soglia è documentata: il cookie sopravvive se l’indirizzo del sottodominio corrisponde a quello del sito almeno per metà, cioè i primi 16 bit su IPv4 e i primi 64 su IPv6. Sotto quella soglia, sette giorni.
Questo vuol dire che il sottodominio di tagging fa due lavori diversi, e quasi tutti ne comprano uno solo credendo di averli entrambi.
| Cosa vuoi ottenere | Basta il sottodominio via CNAME | Cosa serve davvero |
|---|---|---|
| Non farti bloccare dagli ad blocker basati su liste di domini | Sì | Niente altro |
| Far durare il cookie oltre i sette giorni su Safari | No | Percorso sullo stesso dominio, oppure instradamento del traffico sul tuo indirizzo |
Raccomandazione. Confronta l’indirizzo a cui risolve il tuo sottodominio di tagging con quello del tuo sito. Se i primi due blocchi non coincidono, il cookie che stai scrivendo dal server su Safari vive sette giorni come prima, e nessun pannello te lo dirà.
Quanto pesano gli ad blocker, che è meno di come viene raccontato
Il numero che gira è che il 29,5% degli utenti internet nel mondo usa un ad blocker. È una rilevazione reale, ed è la cosa sbagliata da usare per stimare la tua perdita.
Due ragioni. La prima è che misura gli utenti internet globali, non i visitatori di un negozio che vende un prodotto specifico in un mercato specifico. La seconda, più importante, è che avere un ad blocker installato non equivale a perdere l’evento: dipende da quali liste sono attive e da quale richiesta stai facendo.
Un dato utile viene dal fornitore che ha più interesse a farlo sembrare grande. Nella sua analisi sul recupero degli eventi, la quota attribuita esplicitamente agli ad blocker è del 3,29%, contro un recupero totale intorno al 20%. Il resto è tracking prevention, cioè soprattutto Safari.
Raccomandazione. Tratta gli ad blocker come una causa minore e verificabile, non come metà del problema. Il peso vero, sui negozi che abbiamo misurato, sta nella composizione del traffico, che è la cosa da guardare per prima.
Misurato da noi. Su uno store Shopify, nella finestra 8 luglio / 4 agosto 2026, il traffico era per il 64% Safari e per il 27% browser interno di Instagram su Android, insieme oltre il 90%. Sono i due ambienti dove il canale browser perde di più, e non somigliano a nessuna media pubblicata.
Le quote globali di Safari che trovi in giro oscillano fra il 19% e il 26% a seconda della fonte e di cosa viene contato. È esattamente la ragione per cui vanno ignorate: la percentuale che ti riguarda è nel tuo rapporto sulla tecnologia, e la puoi leggere in due minuti.
Il pixel che Shopify ha messo in pausa il 13 gennaio 2026
Questa è la causa meno conosciuta delle tre, ed è l’unica che si risolve con un clic.
Documentazione. Il 13 gennaio 2026 Shopify ha cambiato l’impostazione predefinita degli App Pixel da “Always on” a “Optimized”. In quella modalità Shopify osserva nel tempo il traffico in ingresso, le vendite, le impostazioni del negozio e quelle delle campagne, e mette in pausa la condivisione dei dati verso un pixel quando non rileva segnali per giorni o settimane, riattivandola quando i segnali tornano.
Due precisazioni che cambiano cosa devi andare a guardare.
Riguarda solo gli App Pixel. I Custom Pixel non sono toccati e continuano a funzionare come prima, senza nessun algoritmo di ottimizzazione sopra.
Non è un meccanismo per visitatore e non riguarda il consenso. Non è che Shopify riduce il dato quando un visitatore arriva senza parametri o da sessione privata. È una decisione presa sul pixel nel suo insieme, sulla base di quanto quel pixel sembra portare risultati, e la ragione dichiarata è evitare di condividere dati con strumenti inattivi.
La differenza è pratica. Se cerchi il sintomo sbagliato, vai a controllare i parametri delle campagne. Il sintomo giusto è un pixel che smette di ricevere dati per un periodo e poi ricomincia, senza che nessuno abbia toccato niente.
Raccomandazione. Vai su Impostazioni, Customer Events, e controlla in che modalità sono i tuoi App Pixel. Se un pixel è in “Optimized” e per te è critico, puoi riportarlo a “Always on”. Fallo sapendo che l’impostazione predefinita esisteva per una ragione, e che il consenso resta un vincolo a monte in ogni caso.
Quanto si recupera, secondo chi lo vende e secondo noi
Il numero del fornitore. L’analisi più citata su questo argomento riporta un recupero del 20,71% degli eventi e del 30,67% sui soli acquisti, su circa sette milioni di richieste in dieci giorni. È un dato reale, ed è pubblicato da chi vende il servizio che quel dato giustifica. I casi di successo che lo accompagnano sono selezionati dalla stessa fonte.
La nostra misura indipendente. Sullo stesso tipo di confronto, su un negozio Shopify nella finestra 8 luglio / 4 agosto 2026, abbiamo contato gli eventi che esistono solo sul canale server e non su quello browser. Il contributo netto è di 1.774 eventi, il 23,9% del segnale complessivo e il 31,7% sulle sole visualizzazioni prodotto. Nel dettaglio, visualizzazioni di pagina 4.025 contro 3.327, più 21%. Visualizzazioni prodotto 3.389 contro 2.316, più 46%.
Che una misura nostra e una del fornitore cadano a tre punti di distanza non conferma la cifra. Stabilisce l’ordine di grandezza, ed è già molto: si recupera qualcosa attorno a un quarto del segnale, non la metà.
Quanto varia da negozio a negozio. Su questo l’onestà migliore l’abbiamo sentita da un partner tecnico in call: ci sono store dove con il consenso gestito correttamente si perde intorno al 20%, altri dove si arriva al 35%, altri ancora peggio, e il numero esatto in anticipo non si può dare. Su due nostri negozi senza gestione del consenso la perdita sugli acquisti si attestava intorno all’8% e al 19%, quindi molto sotto le medie che circolano.
Raccomandazione. Non usare un numero pubblicato per decidere. Usalo per sapere se il tuo, una volta misurato, è dentro o fuori scala.
Il limite che non viene mai scritto
Il canale server protegge l’evento dal browser. Non lo protegge da quello che manca prima del browser.
Misurato da noi. Su uno store Shopify entrambi i canali erano attivi, browser e server, e il canale server portava quasi il 24% di segnale in più. Nella stessa finestra gli eventi di acquisto registrati erano zero.
La causa non era il tracciamento. Confrontando il registro ordini con le piattaforme, il 62% del fatturato del periodo non risultava attribuito ad alcuna sorgente, e su dodici mesi solo il 55% degli ordini reali aveva il percorso utente valorizzato. Era Shopify a non riuscire ad associare l’ordine a una sessione di navigazione.
Mancando quell’aggancio a monte, il canale server non ha materia prima da proteggere. Recupera benissimo le visualizzazioni e non salva l’acquisto, perché anche lui dipende dalla sessione che la piattaforma riconosce.
Sullo stesso negozio, su 92 ordini in dodici mesi, un solo ordine riportava parametri di tracciamento della campagna. Nessun canale server corregge quello.
Raccomandazione. Prima di comprare infrastruttura, confronta il registro ordini con le piattaforme su 90 giorni. Se la distanza è larga, il problema sta a monte e l’infrastruttura non lo tocca.
La checklist
Prima di spendere
- Quota Safari e browser in-app letta nel tuo rapporto sulla tecnologia, non stimata da una media
- Registro ordini confrontato con le piattaforme su 90 giorni
- Parametri di tracciamento verificati sui link delle campagne attive
- Modalità degli App Pixel controllata in Customer Events
Dopo aver messo il canale server
- Indirizzo IP del sottodominio di tagging confrontato con quello del sito
- Scadenza del cookie controllata su un iPhone reale, oltre i sette giorni
- Deduplica misurata, con identificativo condiviso presente su tutti gli eventi
- Copertura dell’identificativo del clic pubblicitario, che sotto il 30 o 40% è un allarme
- Contributo netto del canale server calcolato sugli eventi che esistono solo lì
- Confronto con il registro ordini rifatto dopo il rilascio, sulla stessa finestra di prima
In sintesi
Le tre cause pesano in modo diverso. Safari è la più grossa, gli ad blocker molto meno di come vengono raccontati, e la modalità dei pixel su Shopify è quella che costa meno da sistemare.
Il canale server recupera una quota reale, attorno a un quarto del segnale sui negozi con molto traffico da Safari e da app. Quello che non recupera è l’ordine che la piattaforma non ha mai collegato a una visita, e quella verifica viene prima di tutte le altre.
Fonti
- WebKit, Intelligent Tracking Prevention 2.1, 21 febbraio 2019, recuperato il 18 agosto 2026
- WebKit, CNAME Cloaking and Web Privacy, 12 novembre 2020, recuperato il 18 agosto 2026
- Shopify Changelog, New default setting for pixel data sharing, 13 gennaio 2026, recuperato il 18 agosto 2026
- Shopify Help Center, App pixels, recuperato il 18 agosto 2026
- Google Developers, Introduction to server-side tagging, recuperato il 18 agosto 2026
- Stape, Safari ITP guide, recuperato il 18 agosto 2026, fornitore di hosting per container di tagging
- Stape, analisi sul recupero eventi lato server, luglio 2025, fornitore interessato
- Backlinko, Ad blocker users statistics, su dati DataReportal, recuperato il 18 agosto 2026
- Misurazioni interne su audit di store Shopify, finestre dichiarate nel testo
Il primo passo
Apri l’amministrazione del tuo negozio, vai su Impostazioni e poi su Customer Events, e guarda in che modalità sono i tuoi App Pixel. Se trovi “Optimized” su un pixel che per te conta, hai appena trovato la causa più economica delle tre.
È una verifica da un minuto. Le altre due richiedono di misurare, e ne parliamo volentieri.
Contenuti verificati sulla documentazione ufficiale al 18 agosto 2026. Le regole di Safari e le impostazioni di Shopify cambiano spesso, se leggi molto dopo questa data ricontrolla i link.