La risposta onesta è che non esiste una percentuale valida per il tuo sito: la quota di eventi che sparisce varia talmente tanto per pubblico, device, browser e tipo di tag che l’unico numero su cui puoi prendere decisioni è quello che misuri sul tuo dominio.
Nel resto dell’articolo trovi tre cose: come separare le perdite che quasi tutti sommano in un’unica cifra sbagliata, un protocollo di misurazione replicabile in una settimana con strumenti che hai già, e una stima onesta di quanto il tracciamento server-side recupera davvero e quanto invece resta perso comunque.
Un avvertimento preliminare sulle cifre che girano. Quando leggi che una certa quota di utenti usa un ad blocker, stai leggendo una misura di diffusione delle estensioni, di solito su campioni internazionali e su pubblici specifici. Non è la stessa cosa delle sessioni mancanti in GA4, che a loro volta non sono le conversioni mancanti in Google Ads. Tre numeri diversi, che nascono da popolazioni diverse e che nessuno converte l’uno nell’altro. Qui c’è la mia opinione netta: usare una media di settore per decidere se investire in infrastruttura di tracciamento è un errore professionale, non una scorciatoia accettabile. Serve a decidere se vale la pena misurare, mai a decidere un budget.
Tre perdite diverse che finiscono in un unico numero
Quando un cliente ti dice "perdiamo il 30% dei dati per colpa degli ad blocker", nove volte su dieci sta sommando fenomeni che hanno cause, sintomi e rimedi completamente diversi.
Il blocco dei contenuti. Le filter list impediscono il download di gtm.js o gtag.js, oppure bloccano la chiamata di rete verso i domini di raccolta. Succede con le estensioni del browser, ma anche con browser che filtrano di default, con resolver DNS filtranti installati sul router di casa e con i firewall delle reti aziendali. Sintomo tipico: la pagina viene servita dal tuo server, ma in analytics non compare nessuna pageview. L’evento non nasce proprio.
Il consenso negato o tardivo. L’utente rifiuta, oppure la CMP si carica in ritardo e l’evento parte in stato denied, oppure non parte affatto perché l’utente ha già cliccato su un link. Qui il dato manca per una scelta legittima, e nessuna tecnologia deve aggirarla. Sintomo tipico: la perdita si concentra sul primo evento della sessione e cambia bruscamente quando modifichi il banner.
L’erosione dell’identità. Le protezioni antitracciamento di Safari e Firefox accorciano la vita dei cookie first-party impostati via JavaScript. L’hit arriva, l’evento viene registrato, ma l’utente risulta nuovo a ogni visita. Non perdi volume: perdi attribuzione, pubblici di remarketing e finestre di conversione. È la causa più sottovalutata perché nei report di traffico non si vede.
A queste si aggiungono le perdite banali ma reali: uscita dalla pagina prima dell’invio del beacon, errori JavaScript che interrompono l’esecuzione dello script, browser interni alle app social con comportamenti propri, prefetch e prerendering che gonfiano le richieste senza generare eventi.
La distinzione non è accademica. Il server-side agisce in modo forte sulla prima causa e sulla terza, perché sposta la raccolta su un dominio tuo e consente di impostare cookie lato server con durata piena. Sulla seconda non fa nulla, e non deve farlo. Se la tua perdita è per tre quarti consenso negato, spendere in infrastruttura prima di sistemare la CMP significa pagare per un problema che non hai. Se vuoi capire dove si collocano i due modelli prima di decidere, parti dalla differenza tra tracciamento client-side e server-side.
Come misurare la tua quota in una settimana
Tre misure indipendenti. Nessuna è perfetta da sola, ma incrociate ti danno un intervallo difendibile.
Metodo 1 — la sorgente non bloccabile. Prendi gli ordini del gestionale o i lead nel CRM e confrontali con le conversioni registrate in GA4 nello stesso intervallo. È la misura più solida perché il back-office non si può bloccare dal browser. Condizioni: almeno due settimane piene, meglio quattro; stessa definizione di evento (ordine confermato contro ordine creato: non sono la stessa cosa); stesso fuso orario, perché GA4 e il gestionale spesso non ce l’hanno uguale; esclusione di ordini duplicati, test, ordini telefonici e inserimenti manuali dell’assistenza. Il delta che ottieni è la tua perdita sulle conversioni, la metrica che conta per le campagne.
Metodo 2 — log del server contro pageview. Conta le richieste HTML nei log del server o della CDN e confrontale con le pageview misurate. Qui serve pulizia: escludi bot dichiarati, crawler, monitoraggi di uptime, richieste di prefetch e prerender, redirect. Il delta residuo contiene insieme blocco dei contenuti e consenso negato, quindi da solo non ti dice quale dei due pesa. Ti dà però un tetto massimo alla perdita sul traffico, utile per verificare che il Metodo 1 non stia misurando un problema diverso.
Metodo 3 — il beacon di controllo. Serve a isolare il blocco puro. Pubblica un endpoint sul tuo dominio, su un percorso neutro: niente parole come analytics, track, pixel, collect, tag, stats. Fallo chiamare da uno script inline che incrementa un contatore anonimo, senza cookie, senza identificatori, senza parametri che descrivano l’utente. Confronta quel contatore con le pageview del tag standard sullo stesso periodo. La differenza tra i due è, con buona approssimazione, la quota bloccata a monte, perché un endpoint anonimo e non riconoscibile sopravvive alle filter list. Verifica con il tuo DPO che la raccolta resti fuori dal perimetro del consenso: se aggiungi dettagli identificativi, non lo è più.
Poi segmenta, perché il numero aggregato è quasi inutile. Spacca il risultato per browser, device, sorgente di traffico, area geografica e fascia oraria. È lì che scopri le cose interessanti: il desktop da ricerca organica che perde il doppio del mobile da social, la campagna su un pubblico tecnico che perde molto più della newsletter, il picco serale che non esiste nei report perché chi naviga da casa ha un DNS filtrante sul router.
Il risultato finale è una frazione semplice: eventi misurati diviso eventi reali di riferimento. Il reciproco è il tuo fattore di correzione temporaneo, quello che applichi ai report mentre decidi cosa fare. Scrivilo su un foglio insieme al metodo usato, al periodo, ai segmenti e alle esclusioni, e rivedilo ogni trimestre. Un fattore di correzione senza le sue assunzioni accanto diventa, nel giro di sei mesi, una leggenda aziendale.
Che ordine di grandezza aspettarti
Non ti darò intervalli percentuali, perché ogni cifra che leggi in giro senza campione, paese, anno e definizione di "utente che blocca" è aria fritta travestita da dato. Quello che posso darti sono le direzioni in cui il tuo numero si muove.
La perdita per blocco cresce con il grado di competenza tecnica del pubblico e con la quota di traffico desktop. Siti di software, gaming, hardware, finanza fai-da-te e privacy stanno all’estremo alto. Pubblici generalisti, target senior, e-commerce di largo consumo stanno all’estremo basso. Il traffico mobile proveniente dai browser interni alle app social perde poco per blocco e molto di più per consenso e per erosione dell’identità, perché quelle sessioni sono corte e spesso ripartono da zero.
Sul Manifest V3 di Chrome vale la pena essere chiari: il cambio di architettura delle estensioni ha modificato il modo in cui i blocchi vengono dichiarati, non ha eliminato il filtraggio. Le liste continuano a funzionare, parte degli utenti più attenti si è spostata su browser che bloccano di default, e il filtraggio a livello DNS — che avviene fuori dal browser — non è toccato in alcun modo. Chi ha archiviato il problema nel 2024 pensando che si risolvesse da solo si ritroverà a rifare i conti.
Un’ultima cosa sul perché questo numero conta davvero. Gli algoritmi di offerta automatica imparano dalle conversioni che ricevono. Se la perdita non è uniforme, e non lo è quasi mai, il sistema non sottostima soltanto i risultati: li sottostima più su alcuni segmenti che su altri, e sposta budget verso i canali che si lasciano tracciare meglio. Il danno non è il report che non torna, è il budget allocato male per mesi. Il tema è trattato nel dettaglio negli articoli su performance pubblicitarie, Google Ads e ROAS.
Quanto recupera il server-side e cosa fare lunedì
Il server-side recupera le chiamate di raccolta spostate su un sottodominio tuo che non compare nelle filter list, le integrazioni server-to-server con le piattaforme pubblicitarie e i cookie impostati dal server con durata piena, che sopravvivono alle restrizioni applicate a quelli scritti via JavaScript. Su questi tre fronti il recupero è concreto e misurabile con lo stesso protocollo che hai usato prima.
Cosa non recupera, e qui serve onestà. Se a essere bloccato è il caricamento del contenitore lato client, il server non riceve nulla: nessun evento parte, non c’è niente da inoltrare. Per questo il loader va servito dal tuo dominio e da un percorso tuo, altrimenti hai pagato infrastruttura per un problema che resta a monte. Allo stesso modo, un sottodominio chiamato track., tag. o analytics. finisce nelle liste in poco tempo e vanifica il lavoro: la scelta del nome e del percorso conta quanto la configurazione, e trovi i criteri nella guida su come configurare un dominio personalizzato per il container server.
Sul consenso, nessun recupero. Il server-side convive con Consent Mode e con la modellazione delle conversioni, ma non scavalca una scelta dell’utente. Chi ti promette il contrario ti sta vendendo un problema legale.
L’ordine delle cose da fare, dal costo più basso al più alto: sistema i tempi di caricamento della CMP e gli eventi che partono prima che il consenso sia disponibile; correggi gli eventi fragili che si perdono all’uscita dalla pagina; metti in piedi un Data Layer coerente e documentato, perché un container server alimentato da dati sporchi produce dati sporchi più velocemente; solo dopo valuta loader first-party, container server e integrazioni via API di conversione. Per capire se il tuo caso rientra tra quelli in cui l’investimento ha senso, le condizioni sono elencate nell’articolo su quando conviene davvero implementare il server-side.
Dopo l’intervento, rimisura con lo stesso metodo, sugli stessi segmenti e su una finestra di durata comparabile. Avrai un prima/dopo difendibile. E quando lo presenti, usa le parole giuste: hai recuperato dati, non hai generato vendite. Le vendite in più arrivano eventualmente dopo, da decisioni di budget prese su numeri che finalmente corrispondono alla realtà.