L’errore più comune è dare per buono il banner. Il CMP è installato, le categorie ci sono, il cliente ha firmato: si considera chiusa la pratica. Poi arriva un controllo, oppure una segnalazione, e si scopre che _fbp viene scritto al primo caricamento, prima di qualsiasi clic. Il costo non è teorico: significa riscrivere la configurazione sotto pressione, buttare mesi di dati raccolti in modo non difendibile e — nei casi peggiori — rispondere a un reclamo con zero evidenze documentali da mostrare.
Verificare il consenso non vuol dire leggere la cookie policy. Vuol dire aprire gli strumenti, ricreare tre scenari precisi e scrivere pass o fail accanto a ogni controllo. Qui trovi il protocollo che uso, nell’ordine in cui va eseguito.
Cosa significa "consenso rispettato" a livello tecnico
Ci sono tre livelli che vengono confusi di continuo, e la confusione genera la maggior parte delle non conformità.
Il primo livello è il banner mostrato: l’utente vede la richiesta. È il livello visibile, ed è quello che tutti controllano.
Il secondo è lo stato del consenso trasmesso ai tag: cosa sa Google Tag Manager in quel preciso istante. Un banner perfetto può convivere con un default di Consent Mode mal configurato.
Il terzo è cosa esce davvero dal browser: quali cookie vengono scritti e quali richieste di rete partono. È l’unico livello che conta in sede di contestazione, perché è l’unico osservabile da fuori.
Un sito può essere a posto sui primi due e sbagliato sul terzo. Succede quando un tag custom contiene uno script esterno che si carica da sé, indipendentemente dalle impostazioni di consenso del container.
I tre scenari minimi
Ogni verifica si svolge su tre stati, sempre gli stessi:
- Nessuna scelta: banner aperto, nessun clic. È lo scenario più rivelatore.
- Rifiuto totale: l’utente nega tutto. Qui emergono i tag che ignorano il blocco.
- Accettazione totale: serve come controprova che il tracciamento funzioni davvero quando deve.
Se gestisci categorie separate (statistiche, marketing, personalizzazione), aggiungi un quarto scenario di consenso parziale: accetti solo le statistiche e verifichi che i tag pubblicitari restino fermi.
Cosa è lecito prima della scelta
Prima del clic possono legittimamente partire: i cookie tecnici di sessione, il cookie del CMP che memorizza la scelta, il caricamento del container GTM e del CMP stesso, e i ping di Consent Mode avanzato con stato negato.
Quest’ultimo punto confonde molti. Vedere una richiesta verso google-analytics.com con gcs=G100 non significa che un tag sia partito senza consenso: significa che Consent Mode avanzato sta inviando un segnale privo di identificatori. È una scelta di configurazione, non un errore. Per capire come si imposta la catena completa fino al container server, trovi i dettagli nella guida alla configurazione di Consent Mode v2 server-side.
Il criterio di pass/fail
Per tutto l’articolo vale questa soglia, nello scenario "nessuna scelta" e nello scenario "rifiuto":
- zero cookie non tecnici scritti;
- zero richieste verso domini di terze parti di marketing;
- zero eventi GA4 o Google Ads con identificatori utente.
Tre voci. Se una fallisce, la verifica fallisce.
Preparare l’ambiente: cinque condizioni, non quattro
Metà delle diagnosi sbagliate nasce da un ambiente di test sporco. Prima di aprire qualunque strumento:
Profilo pulito. Finestra in incognito dedicata, o meglio un profilo browser creato apposta. Un profilo con cookie residui ti mostra _ga già presente e ti fa inseguire un problema che non esiste. All’inverso, un consenso già memorizzato ti nasconde il comportamento pre-scelta.
Zero estensioni. Ad-blocker, password manager, estensioni di privacy: bloccano richieste e falsano il risultato in entrambe le direzioni. In incognito disattivale esplicitamente, non fidarti del comportamento predefinito.
Due browser minimo. Uno basato su Chromium e uno fra Safari e Firefox. Le protezioni anti-tracciamento cambiano cosa viene scritto e per quanto tempo, e alcuni CMP si comportano diversamente.
Mobile reale. Non solo emulazione da DevTools. Diversi CMP caricano configurazioni differenti sotto una certa larghezza di viewport, e il banner mobile può avere un pulsante in meno.
Geografia coerente. Le regole di Consent Mode si applicano per area. Se testi da un IP fuori dall’area configurata, vedi comportamenti che i tuoi utenti non vedranno mai.
Ultimo punto, quello che salta sempre: annota le versioni. Versione del container web, versione del container server, versione del CMP, data e ora. Senza questo dato il test non è ripetibile e il verbale non vale niente.
Controllo 1 — La rete: cosa esce davvero
Apri DevTools sulla scheda Network prima di caricare la pagina. Attiva "Preserve log" e "Disable cache". Poi carica l’URL.
Filtri da usare uno alla volta nella barra di ricerca: collect, google-analytics, googletagmanager, doubleclick, facebook, connect, più il tuo dominio di tracciamento server-side se ne hai uno.
Leggere una richiesta GA4
Apri la richiesta verso /g/collect e guarda i parametri in query string:
gcs: lo stato del consenso al momento dell’invio.G100= entrambi i segnali negati,G111= entrambi concessi,G110eG101= stati misti. Leggi le ultime due cifre come analytics_storage e ad_storage.gcd: la codifica estesa che include ad_user_data e ad_personalization.dma: presenza dei segnali richiesti dal Digital Markets Act.npa: se vale 1, la richiesta è non personalizzata.
Se vedi gcs=G111 prima che l’utente abbia cliccato, hai un fail netto: significa che il default è concesso o non è stato impostato affatto.
Controlla anche la presenza del parametro cid o di _ga nel payload: un identificatore persistente inviato a consenso negato è un problema anche se il tag formalmente "rispetta" Consent Mode.
Lecito contro non lecito
La chiamata a googletagmanager.com/gtm.js e quella al CMP sono lecite. Una chiamata a connect.facebook.net con successiva richiesta a facebook.com/tr no. Una chiamata a googleads.g.doubleclick.net con identificatori nemmeno.
Annota per ogni richiesta sospetta: dominio, momento (prima o dopo il clic), stato osservato, azione correttiva. È la riga del tuo verbale.
Controllo 2 — Cookie e storage
Vai su Application. Controlla nell’ordine: Cookies, Local Storage, Session Storage, IndexedDB. Chi guarda solo i cookie si perde gli identificatori messi in localStorage, che sono diventati comuni.
Mappa cosa trovi:
_ga,_ga_XXXXXX,_gid→ richiedono consenso statistiche_gcl_au,_gcl_aw→ marketing_fbp,_fbc→ marketing_uetmsclkid,_uetvid→ marketing- cookie del CMP → tecnico, lecito
FPIDscritto dal container server → va trattato come identificatore soggetto a consenso
Il caso HttpOnly
I cookie scritti lato server con flag HttpOnly non compaiono in document.cookie. Li vedi solo nell’header Set-Cookie della risposta HTTP, nella scheda Headers della richiesta. È esattamente il punto dove si nascondono gli identificatori first-party impostati dal container server, e su cui il controllo manuale salta più spesso. Se vuoi capire come funzionano questi cookie e perché hanno durate diverse, parti dal confronto fra tracciamento client-side e server-side.
La revoca
Qui c’è la lacuna più diffusa. Tutti verificano l’accettazione, quasi nessuno il ritiro.
Accetta tutto, naviga due pagine, poi riapri il banner e revoca. Ricarica. Domande: i cookie di marketing sono stati cancellati? Lo storage è stato ripulito? Partono ancora richieste con identificatori?
La cancellazione non avviene da sola. Alcuni CMP la gestiscono, molti no. Se il tuo non lo fa, serve uno script di cleanup agganciato all’evento di revoca. Senza, un utente che cambia idea continua a essere identificato dai dati già presenti nel suo browser.
Controllo 3 — Lo stato del consenso dentro GTM
Apri l’Anteprima. Per ogni evento nella colonna di sinistra, guarda la scheda Consent.
Trovi due blocchi: On-page Default (lo stato impostato prima del container) e Consent Updates (le modifiche nel tempo). Clicca sugli eventi in sequenza e osserva il momento esatto in cui lo stato cambia. Deve cambiare solo dopo l’interazione con il banner, mai prima.
Bloccato o mai attivato?
Sono due diagnosi opposte che si confondono di continuo.
Nella scheda Tags, un tag che non è partito per mancanza di consenso compare nella sezione dei tag non attivati con l’indicazione esplicita del consenso non concesso. Un tag che non è partito perché il trigger non si è verificato compare semplicemente fra i non attivati, senza quella nota.
La differenza conta: nel primo caso la configurazione funziona. Nel secondo stai guardando un tag che non parte per altri motivi, e che potrebbe partire senza controlli quando il trigger si attiverà davvero.
Il punto che si rompe più spesso
I tag Google hanno il controllo del consenso incorporato. I tag custom HTML e i template di terze parti no: devi impostare manualmente le Additional Consent Checks nella sezione Consent Settings di ogni tag.
Apri ogni tag non-Google del container e verifica questa impostazione, uno per uno. È noioso e non ci sono scorciatoie. Un tag custom con "No additional consent required" che carica uno script di terze parti è una violazione in attesa di essere trovata.
Controllo 4 — Data Layer e sequenza temporale
In console, digita dataLayer e espandi l’array. L’ordine corretto è: comando consent default → eventuali eventi di pagina → consent update dopo il clic.
L’errore classico: il Data Layer contiene un push di evento prima che il default di consenso sia stato impostato. Quando arriva l’update, GTM riprocessa la coda e i tag partono, con l’evento che riporta il contesto della pagina precedente alla scelta.
Incolla questo in console per avere una timeline leggibile:
console.table(window.dataLayer.map(function(e, i) {
return {
i: i,
tipo: Array.isArray(e) ? e[0] : (e.event || '(oggetto)'),
dettaglio: Array.isArray(e) ? e[1] : ''
};
}));
Verifica che il push del CMP arrivi con un nome evento coerente e che le categorie del banner corrispondano uno a uno ai parametri di Consent Mode. Un banner con quattro categorie mappate su due soli parametri è un disallineamento da documentare. Se il Data Layer del tuo sito è disordinato, il problema è a monte: vale la pena rivedere come si struttura un Data Layer prima di proseguire.
Controllo 5 — Lato server: cosa arriva e cosa riparte
Qui si concentra la dimenticanza più frequente. Il container server ha le sue Consent Settings, indipendenti da quelle del container web.
Apri l’Anteprima del container server e ispeziona una richiesta in ingresso. Nella scheda Request, verifica che i parametri di consenso siano arrivati. Se il client web ha trasmesso gcs=G100, il server deve vederlo.
Poi guarda cosa riparte. Per ogni tag server:
- i tag verso piattaforme pubblicitarie devono restare fermi a consenso negato, con Consent Settings configurate esplicitamente;
- i parametri identificativi (email hashate, ID utente, IP completo) non devono essere inoltrati quando manca il consenso, anche se il tag formalmente parte;
- le destinazioni secondarie — CRM, piattaforme di e-mail marketing, webhook interni — sono quasi sempre configurate senza alcun vincolo di consenso. Controllale una per una.
Il server-side non esonera da nulla. Sposta l’elaborazione, non cambia la base giuridica. Chi lo presenta come un modo per aggirare il consenso sta vendendo un problema.
Monitoraggio continuo
Il controllo manuale è una fotografia. Per avere una serie storica, esporta gli eventi verso BigQuery e conta la quota con gcs=G100 sul totale, giorno per giorno. Un salto improvviso dopo una pubblicazione ti dice che qualcosa è cambiato, prima che se ne accorga qualcun altro. La procedura di invio è descritta nella guida su come inviare eventi dal container server a BigQuery.
Controllo 6 — Le piattaforme confermano?
DevTools ti dice cosa è partito. Le piattaforme ti dicono cosa è stato registrato. Servono entrambe.
GA4 DebugView: attiva il debug mode, esegui lo scenario di rifiuto totale. Se compaiono eventi con identificatori utente, hai un fail. Se vedi eventi senza user_pseudo_id persistente, stai guardando il comportamento corretto di Consent Mode avanzato.
Diagnostica GA4: controlla la percentuale di sessioni con dati modellati. Un valore a zero su un sito con banner attivo significa quasi sempre che Consent Mode non è configurato, non che tutti accettano.
Google Ads: nella diagnostica dei tag di conversione, verifica che le conversioni a consenso negato risultino modellate e non osservate. Se a rifiuto espresso una conversione compare come osservata con identificatore, il tag di conversione sta bypassando il blocco.
Una discrepanza fra DevTools e piattaforma non è automaticamente un errore. Latenza di elaborazione, campionamento e modellazione producono scostamenti legittimi. Il fail lo dichiari solo quando vedi un identificatore dove non dovrebbe esserci.
Controllo 7 — Rendere il test ripetibile
Un controllo fatto una volta scade alla prima pubblicazione.
Con Playwright o Puppeteer puoi automatizzare la parte che non cambia: caricare la pagina, intercettare tutte le richieste di rete e far fallire la build se compare un dominio in blacklist prima di qualsiasi interazione. Venti righe di script, e copri lo scenario più rischioso.
Resta manuale l’interazione con il banner: i selettori cambiano a ogni aggiornamento del CMP e un test automatico che li insegue si rompe più di quanto protegga.
Frequenza che consiglio:
- a ogni pubblicazione del container web o server;
- a ogni aggiornamento del CMP;
- a ogni rilascio del sito che tocchi template o header;
- un controllo completo programmato, trimestrale.
L’opinione netta: integrare l’esito nel processo di pubblicazione vale più di qualsiasi documento. Un controllo che dipende dalla memoria di una persona salta alla terza settimana impegnativa. Un controllo che blocca il rilascio non salta mai.
Su un sito con cinque tag e una sola persona che pubblica, il controllo manuale trimestrale basta. Su un e-commerce con più agenzie che toccano lo stesso container, l’automazione non è opzionale.
Il verbale: trasformare il test in prova
Il test senza documento non esiste. Struttura minima:
- data e ora, con fuso;
- URL testati (homepage, scheda prodotto, checkout, pagina legale);
- versione container web, versione container server, versione e nome del CMP;
- browser e dispositivo, area geografica simulata;
- scenario eseguito;
- esito di ciascuno dei 7 controlli, pass o fail, con nota;
- screenshot della scheda Network e della scheda Consent in Anteprima.
I file HAR contengono dati reali di navigazione, a volte token di sessione. Conservali in area ad accesso ristretto, con una scadenza definita, e non allegarli via e-mail.
Il verbale va collegato al registro dei trattamenti e tenuto coerente con la cookie policy: se il documento elenca sei cookie e tu ne trovi nove, l’incoerenza è il primo rilievo che emerge in un controllo. Qui mi fermo: la valutazione giuridica non è il mio mestiere né quello di chi configura tag.
Procedi in autonomia se il container ha pochi tag, nessuno script custom con sorgenti esterne e un CMP standard. Chiedi supporto se trovi tag custom che caricano script di terze parti, un CMP sviluppato internamente, o più container GTM sullo stesso dominio: sono le tre situazioni in cui il consenso si rompe in modi che non si vedono dal pannello del CMP. Altri approfondimenti sul tema li trovi nella sezione dedicata a qualità del dato, Data Layer e consenso.
Domande frequenti
Se vedo una chiamata a google-analytics.com prima dell'accettazione, sto sempre violando il consenso?
No. Con Consent Mode avanzato, Google invia ping senza identificatori anche a consenso negato: li riconosci dal parametro gcs=G100 e dall’assenza di un identificatore utente persistente nel payload. Se invece la stessa richiesta riporta gcs=G111 o contiene il valore del cookie _ga prima di qualsiasi clic, è un fail: il default di consenso non è impostato o è impostato su concesso.
Come capisco se un tag è bloccato dal consenso o semplicemente non è stato attivato da un trigger?
Nell’Anteprima di Google Tag Manager, nella scheda Tags dell’evento, i tag bloccati dal consenso compaiono fra i non attivati con l’indicazione esplicita che il consenso richiesto non è stato concesso. Un tag non attivato dal trigger compare senza quella nota. È una distinzione che cambia la diagnosi: nel primo caso la configurazione funziona, nel secondo il tag potrebbe partire senza controlli quando il trigger si verificherà davvero.
Il tracciamento server-side permette di raccogliere dati anche senza consenso?
No. Spostare l’elaborazione su un container server cambia dove i dati vengono trattati, non la base giuridica che ne consente la raccolta. Il container server riceve comunque i parametri di consenso dal lato client e deve avere le proprie Consent Settings configurate su ogni tag, incluse le destinazioni secondarie come CRM e webhook interni, che sono quelle dimenticate più spesso.
Come verifico che la revoca del consenso funzioni e non solo l'accettazione?
Accetta tutto, naviga due o tre pagine, riapri il banner e revoca. Poi ricarica e controlla in Application se i cookie di marketing sono stati cancellati, se localStorage e IndexedDB sono stati ripuliti e se partono ancora richieste con identificatori. La cancellazione non è automatica: molti CMP non la eseguono e serve uno script di cleanup agganciato all’evento di revoca.