Tillde
Menu
ServiziConsulenzaAcademyProdottiChi siamoLavora con noiBlogContattiContattaci

[ Article ]

ITP Safari e ad blocker: perché il 20-30% delle conversioni Shopify sparisce davvero (e come recuperarle)

Su 7 milioni di eventi tracciati in 10 giorni, Stape ha trovato che il 20,71% andava perso — il 30,67% per gli acquisti. Ecco come funziona e come recuperarli con CAPI.

·Mattia Minafò
itp safariad blockermeta capishopify trackingconversioni perseserver-side tracking

Nel primo articolo di questa serie ho scritto che il divario tra Meta e GA4 non è quasi mai una perdita di dati reale — è quasi sempre una differenza di modelli di attribuzione.

Questo articolo parla dell’eccezione.

Esiste una categoria di conversioni che sparisce davvero. Non perché Meta e GA4 usino finestre diverse, ma perché il segnale viene bloccato fisicamente prima di arrivare da nessuna parte. Safari ITP spegne i cookie del tuo pixel entro 7 giorni. Gli ad blocker tagliano la richiesta prima che parta. Il risultato: un acquisto reale che non entra né in Meta né in GA4 — semplicemente non esiste come dato.

Stape ha misurato questo su 10 giorni di traffico reale, con oltre 7 milioni di richieste. Il 20,71% degli eventi era sparito. Per gli acquisti: 30,67%. Non un problema di attribuzione. Una perdita netta di segnale.

Per capire la differenza tra perdita di segnale e differenza di attribuzione, leggi Il tuo pixel Meta non mente.

In sintesi

  • In un test empirico su 7.032.096 richieste, Stape ha trovato che il tracking lato server recuperava il 20,71% di eventi altrimenti persi — il 30,67% specificamente per gli acquisti (Stape.io, aggiornato luglio 2025).
  • Safari limita a 7 giorni tutti i cookie impostati via JavaScript, inclusi _fbp e _fbc del pixel Meta. Safari vale il 24,07% del market share mobile mondiale in giugno 2026 (StatCounter, giugno 2026).
  • Il 13 gennaio 2026, Shopify ha cambiato la modalità predefinita di tutti i pixel App a “Ottimizzata” — una modifica silenziosa che ha ridotto la raccolta dati per molti store senza notifica esplicita (Shopify Changelog, gennaio 2026).

ITP (Intelligent Tracking Prevention) è il sistema di Apple che blocca i cookie usati per il tracking pubblicitario. La versione attiva oggi su ogni iPhone e Mac è ITP 2.1, introdotta con iOS 12 nel 2018: tutti i cookie impostati via JavaScript — inclusi _fbp e _fbc del pixel Meta, e _ga di Google Analytics — scadono automaticamente dopo 7 giorni.

Il meccanismo concreto: un utente clicca sul tuo annuncio Meta da iPhone, aggiunge al carrello, poi si ferma. Torna 9 giorni dopo e compra. Il cookie _fbp è già scaduto. Il pixel Meta non ha più il segnale per attribuire quell’acquisto alla campagna che ha innescato tutto. In GA4 quell’ordine arriva come “direct”. In Meta non arriva come conversione.

Durata massima dei cookie di conversione (_fbp, _ga) Fonte: WebKit ITP spec, Firefox ETP, Google Cookie Policy, Stape.io (2026) Safari (ITP 2.1+) iOS, macOS 7 giorni Firefox (ETP) Enhanced Tracking Prot. 30 giorni Chrome first-party cookie 400 giorni Server-side (CAPI) Set-Cookie header HTTP Nessun limite
I cookie impostati via JavaScript (come il pixel Meta) sono soggetti al cap ITP. Il tracking lato server usa Set-Cookie header HTTP — immune a ITP. Fonte: WebKit ITP spec (2018–2026), Stape.io

Safari vale il 24,07% del market share mobile mondiale in giugno 2026, il 54,69% negli Stati Uniti, e il 32,11% in Europa (StatCounter Global Stats, giugno 2026). Significa che in media 1 acquirente mobile su 4 globalmente non può essere attribuito dopo il settimo giorno dal click — indipendentemente dalla qualità del setup.

Con Safari 26, rilasciato il 15 settembre 2025, Apple ha attivato di default l’Advanced Fingerprinting Protection per tutte le sessioni di navigazione — non solo quella privata. L’AFP blocca i parametri gclid e fbclid nei redirect. I parametri UTM standard non sono ancora bloccati, ma la direzione è chiara (Stape.io, “iOS 26 Safari Advanced Fingerprinting Protection”, agosto 2025).

Capsule citabile: ITP Safari limita a 7 giorni tutti i cookie impostati via JavaScript — tra cui _fbp e _fbc del pixel Meta — su qualsiasi iPhone o Mac da Safari 12 in poi (2018). Safari detiene il 24,07% del market share mobile mondiale in giugno 2026 (StatCounter, giugno 2026). Un acquirente mobile su quattro globalmente non può essere attribuito a una campagna Meta dopo il settimo giorno dall’ultimo click, indipendentemente dalla qualità del pixel installato.

Per approfondire FBP e match rate Meta, vedi Il tuo pixel Meta non mente.

Gli ad blocker bloccano il pixel prima che parta

ITP riduce la qualità del dato nel tempo — i cookie scadono. Gli ad blocker fanno qualcosa di più radicale: bloccano la richiesta prima ancora che parta.

Lucchetto dorato posato sopra la tastiera di un laptop, che rappresenta il blocco del tracking da parte degli ad blocker

uBlock Origin, Brave’s built-in blocker, Ghostery, AdBlock Plus — tutti riconoscono le richieste al dominio connect.facebook.net e le tagliano a livello di rete. Il pixel Meta non viene scaricato. Nessun evento viene inviato. Google Tag Manager con il pixel lato browser subisce lo stesso trattamento: la richiesta a www.googletagmanager.com viene bloccata prima di partire.

In marzo 2026, il 29,5% degli utenti internet globali usava un ad blocker — circa 912 milioni di persone (Backlinko / DataReportal Digital 2026 Report, marzo 2026). Il tasso varia per segmento di pubblico: per un ecommerce generalista, tipicamente il 5-15% dei visitatori ha un ad blocker attivo; per store con audience tech o giovane, si può arrivare al 20-40% (Kissmetrics / Sleek Analytics, dati eyeo/Statista 2025).

La distinzione pratica: ITP riduce la qualità dei dati nel tempo. Gli ad blocker riducono immediatamente la quantità degli eventi. Meta CAPI bypassa entrambi — la richiesta parte dal tuo server, non dal browser dell’utente.

Capsule citabile: Gli ad blocker bloccano il pixel Meta a livello di rete prima ancora che la richiesta parta dal browser. In marzo 2026, il 29,5% degli utenti internet globali usava un ad blocker (Backlinko / DataReportal Digital 2026, marzo 2026). Stape ha quantificato il contributo specifico degli ad blocker in un test empirico su 7 milioni di richieste: il 3,29% degli eventi totali era attribuibile al blocco browser — separato e cumulativo rispetto al 20,71% totale di eventi persi per ITP e tracking prevention complessiva (Stape.io, luglio 2025).

Il cambiamento silenzioso di Shopify del 13 gennaio 2026

Smartphone con schermata di impostazioni privacy e condivisione dati, che mostra opzioni di controllo del tracking

Questa è la parte che molti store owner italiani non sanno ancora.

Il 13 gennaio 2026, Shopify ha cambiato la modalità predefinita di tutti i pixel App — incluso il pixel Meta installato tramite l’integrazione ufficiale Shopify — da “Standard” a “Ottimizzata” (Shopify Changelog, “New default setting for pixel data sharing”, 13 gennaio 2026).

In modalità “Ottimizzata”, Shopify riduce automaticamente la quantità di dati inviati dal pixel quando non rileva segnali di attribuzione. Se un visitatore arriva senza UTM, senza click ID, da sessione privata, o da un browser con ITP attivo, Shopify può limitare il dato inviato per gestire la conformità con le policy di Apple e GDPR. Non c’è stata una notifica esplicita agli store owner.

I pixel personalizzati installati direttamente via GTM e le configurazioni Meta CAPI lato server non sono stati toccati da questa modifica. Ma se usi il pixel Meta tramite l’app ufficiale Shopify e non hai controllato le impostazioni da gennaio, quella modalità predefinita ha probabilmente ridotto i tuoi eventi — senza che tu lo sapessi.

Come verificarlo: Shopify Admin → Impostazioni → Customer Events. Cerca il pixel Meta. Se mostra “Ottimizzata”, puoi cambiarlo in “Sempre attiva” se sei GDPR-conforme e hai un Consent Mode correttamente configurato.

Capsule citabile: Il 13 gennaio 2026, Shopify ha cambiato la modalità predefinita di tutti i pixel App a “Ottimizzata”, riducendo automaticamente il dato inviato in assenza di segnali di attribuzione (Shopify Changelog, gennaio 2026). Store con audience UE elevata, visitatori da sessioni private, o annunci Meta senza UTM sono i più esposti. I pixel personalizzati via GTM e le configurazioni CAPI lato server non sono stati modificati.

Per Consent Mode e setup server-side su Shopify, leggi GA4 server-side: quando conviene e come implementarlo.

Quante conversioni stai perdendo? I dati empirici

Fino ad ora ho descritto il meccanismo. Adesso parliamo di numeri reali.

Il riferimento più solido che ho trovato è uno studio empirico di Stape.io su 10 giorni di traffico reale con 7.032.096 richieste totali, aggiornato a luglio 2025 (Stape.io, “Twenty percent of data recovered from tracking prevention”, luglio 2025).

Quota di eventi persi recuperata dal tracking lato server Studio empirico: 7.032.096 richieste, 10 giorni — Stape.io (luglio 2025) Purchase (acquisto) 30,67% Tutti gli eventi (media totale) 20,71% Add to Cart 20,48% Ad-blocker (segnale eliminato) 3,29% Percentuale di eventi recuperati dal tracking lato server vs setup solo client-side
Fonte: Stape.io, "Twenty percent of data recovered from tracking prevention", 7.032.096 richieste, 10 giorni, aggiornato luglio 2025

Il numero da tenere a mente è il 30,67% sugli acquisti. È l’evento che conta per l’ottimizzazione delle campagne Meta — il segnale su cui l’algoritmo di Meta ottimizza le bid, trova i lookalike, e valuta le creative. Perdere il 30% di quel segnale significa che Meta sta ottimizzando su dati parziali.

Tre retailer danesi documentati nel caso studio di Stape di aprile 2026 hanno visto risultati coerenti: Helm ha raggiunto il 100% di tracciamento degli ordini, Special-Butikken +55% di conversioni attribuite, Bolighuset +56% di ricavi dopo il passaggio al tracking lato server (Stape.io, “Retail data transformation — server-side case study”, aprile 2026).

Capsule citabile: In un test empirico su 7.032.096 richieste distribuite su 10 giorni, Stape ha quantificato che il tracking lato server recuperava il 20,71% di eventi altrimenti persi per ITP e tracking prevention. Per gli eventi Purchase — quelli critici per l’ottimizzazione delle campagne Meta — la quota recuperata saliva al 30,67% (Stape.io, “Twenty percent of data recovered from tracking prevention”, luglio 2025). Il 3,29% aggiuntivo era attribuibile specificamente al blocco da ad blocker.

Come recuperarle: Meta CAPI e il tracking lato server

La soluzione tecnica per ITP e ad blocker è la stessa: spostare l’invio degli eventi dal browser al server.

Laptop con dashboard di analytics aperta su tavolo di vetro, che mostra grafici di recupero delle conversioni dopo l’implementazione del tracking server-side

Meta CAPI (Conversions API) opera lato server: quando avviene un acquisto su Shopify, il server invia l’evento direttamente a Meta — senza passare dal browser, senza essere bloccato da ITP, senza essere intercettato dagli ad blocker. Il cookie _fbp impostato tramite Set-Cookie header HTTP (non JavaScript) non è soggetto al cap ITP di 7 giorni.

In aprile 2026, Meta ha riportato che gli advertiser che usano CAPI registrano in media il 17,8% di costo per risultato inferiore rispetto a chi usa solo il pixel client-side (Meta for Business, Conversions API case studies, aprile 2026). Il SignalBridge Server-Side Tracking Benchmark Report 2026 stima un recupero del 20-35% di eventi Meta attribuiti aggiuntivi rispetto al solo pixel (SignalBridge, 2026).

Checklist pratica per Shopify:

  1. Verifica l’EMQ: Events Manager → seleziona il dataset → “Qualità della corrispondenza eventi”. Sotto 6.0 = urgente. Sopra 8.0 = ottimo.

  2. Controlla la modalità pixel: Admin → Impostazioni → Customer Events. Se il pixel Meta è in modalità “Ottimizzata”, valuta il passaggio a “Sempre attiva” in base alla tua configurazione GDPR.

  3. Abilita CAPI lato server: tramite l’integrazione nativa Shopify + Meta, o via Google Tag Manager Server-Side su Stape. La deduplicazione via event_id univoco è obbligatoria — senza, ogni evento viene contato due volte.

  4. Imposta _fbp tramite cookie first-party HTTP: il cookie deve essere scritto dal tuo server tramite Set-Cookie header, non da JavaScript. Questo rimuove il cap ITP di 7 giorni e migliora il match rate.

  5. Aggiungi UTM su tutti gli annunci Meta: i parametri UTM non sono bloccati da Safari 26 AFP. Non recuperano il segnale server-side, ma aiutano GA4 ad attribuire correttamente il traffico.

Capsule citabile: Meta CAPI opera lato server, inviando eventi di conversione da Shopify direttamente a Meta senza passare dal browser — immune a ITP Safari e ad blocker. In aprile 2026, Meta ha riportato il 17,8% di costo per risultato in meno per gli advertiser che usano CAPI rispetto al solo pixel (Meta for Business, aprile 2026). Il SignalBridge Benchmark 2026 stima un recupero aggiuntivo del 20-35% di eventi Meta attribuiti rispetto al setup solo client-side.

Per l’implementazione step-by-step di Meta CAPI su Shopify, vedi GA4 server-side: quando conviene e come implementarlo.

Vuoi sapere quanti eventi stai perdendo?

Se vuoi quantificare il gap nel tuo store — quanti eventi Purchase spariscono prima di arrivare a Meta — il punto di partenza è l’EMQ e i log del container server-side.

Con LayerData vedi in tempo reale gli eventi che arrivano lato server e quelli che mancano, senza dover scavare nelle API di Meta o nei log di Stape.

Se vuoi un audit sul tuo stack, parliamone.

Domande frequenti

ITP blocca anche Google Analytics 4?

Sì. Il cookie _ga è impostato da JavaScript ed è soggetto a ITP 2.1: scade in 7 giorni su Safari. GA4 perde il riconoscimento dei returning visitor che tornano dopo una settimana. La soluzione è impostare _ga tramite Set-Cookie header HTTP lato server, usando il Measurement Protocol di Google o un container sGTM con cookie first-party forzati a 400 giorni. Vedi GA4 server-side.

Meta CAPI sostituisce completamente il pixel client-side?

No — e non dovrebbe. L’approccio corretto è usarli in parallelo, con deduplicazione obbligatoria tramite event_id univoco. Il pixel client-side cattura eventi e micro-interazioni che il server fatica a vedere (scroll, hover, video engagement). CAPI recupera gli eventi bloccati da ITP e ad blocker. Combinati con deduplication, coprono il 90-95% degli eventi reali. Scegliere solo CAPI sarebbe un upgrade incompleto.

Che impatto ha iOS ATT sulla mia pubblicità Meta?

iOS ATT (App Tracking Transparency) entra in gioco per le app — non per il tracking web su Safari. Se un utente usa l’app di Instagram o Facebook e vede il tuo annuncio, ATT determina se Meta può ricevere i dati comportamentali dall’app. Il tasso globale di opt-in è 13,85% per i prompt immediati all’installazione (Singular Q2 2024 via Purchasely, giugno 2025). Per il tracking web su Shopify, il meccanismo rilevante è ITP — non ATT.

Cosa cambia con Safari 26 rispetto a ITP 2.x?

ITP 2.1 (2018) ha introdotto il cap di 7 giorni sui cookie JavaScript — ancora in vigore. Safari 26 (settembre 2025) ha aggiunto l’Advanced Fingerprinting Protection come default per tutte le sessioni: blocca gclid e fbclid nei redirect, ma non i parametri UTM standard. Per Shopify, l’impatto pratico di Safari 26 si aggiunge a ITP — non lo sostituisce. Il fix principale rimane lo stesso: cookie impostati lato server, non via JavaScript.

Conclusione

ITP e ad blocker non sono un problema di attribuzione. Sono una perdita reale di segnale. Un acquisto che avviene su Safari al nono giorno dopo il click semplicemente non esiste come dato — né per Meta, né per GA4. Non è “in un posto diverso”. È sparito.

La buona notizia: il problema è misurabile e risolvibile. Il 30,67% di Purchase events recuperabili (Stape, luglio 2025) e il 17,8% di CPR migliorato (Meta, aprile 2026) sono numeri reali che si traducono in campagne che ottimizzano su dati completi invece di parziali.

Il primo passo è verificare il tuo EMQ. Se sei sotto 7.0, hai trovato il punto di partenza. Per capire come leggerlo nel contesto Shopify, vedi Il tuo pixel Meta non mente.

Fonti

Torna al blog