Consent Mode v2 è il framework di Google che trasmette i segnali di consenso dell’utente (ad_storage, analytics_storage, ad_user_data, ad_personalization) a Google Analytics 4, Google Ads e agli altri tag Google, permettendo la modellazione statistica delle conversioni quando il consenso viene negato. Verifica prima di tutto se il tuo CMP è certificato da Google, poi imposta lo stato di consenso predefinito (default consent) prima che qualsiasi tag Google si carichi, via gtag.js o Google Tag Manager. Scegli la modalità Basic se vuoi bloccare i tag fino all’interazione, oppure Advanced se vuoi mantenere visibilità statistica anche sugli utenti che negano il consenso.
In breve:
- Se il tuo CMP non è certificato da Google, alcune funzioni di modellazione e remarketing nello Spazio Economico Europeo risultano limitate o disabilitate.
- Nella modalità Advanced, Google può stimare le conversioni aggregando dati anche da utenti che rifiutano il consenso, recuperando fino al 70% dei dati di conversione.
- È fondamentale impostare lo stato di consenso predefinito prima che i tag Google si carichino, evitando che partano con consenso “implicitamente concesso”.
- La scelta tra modalità Basic e Advanced dipende dal tasso di rifiuto del consenso e dall’importanza del remarketing per le campagne, oltre alla capacità tecnica di gestire configurazioni più complesse.
- La modellazione delle conversioni richiede almeno sette giorni di raccolta dati continui e volumi sufficienti per offrire risultati affidabili e comparabili.
Indice
- Che cos’è Consent Mode v2 e cosa cambia per advertising e analytics
- I quattro segnali di consenso: cosa fanno davvero
- Basic o Advanced: quale modalità scegliere
- Come inizializzare e aggiornare il consenso con gtag.js e GTM
- Perché serve un CMP certificato e come integrarlo
- Come testare e convalidare l’implementazione
- Errori comuni e come risolverli
- SPA, server-side tagging e template personalizzati
- Prospettiva Hhype: come approcciamo un progetto di questo tipo
- Un audit tecnico e l’implementazione completa di Consent Mode v2
- Risorse ufficiali e guide consigliate
- Fonti
- Domande frequenti
Che cos’è Consent Mode v2 e cosa cambia per advertising e analytics
La versione precedente di Consent Mode gestiva solo due segnali: ad_storage e analytics_storage. Bastavano a dire a Google se l’utente aveva accettato cookie pubblicitari e cookie analitici, ma non distinguevano tra raccolta dati e utilizzo di quei dati per la personalizzazione degli annunci.
Consent Mode v2 introduce due parametri che riscrivono le regole del gioco: ad_user_data e ad_personalization. Il primo segnala se puoi inviare dati utente a Google per finalità pubblicitarie, il secondo se puoi usarli per personalizzare gli annunci, incluso il remarketing. I parametri della v1 restano attivi e continuano a lavorare insieme ai nuovi segnali.
Il cambiamento non è cosmetico. Google richiede l’uso di Consent Mode v2 tramite un CMP certificato per chi pubblica annunci nello Spazio Economico Europeo: senza questi segnali attivi, le funzioni di remarketing e conversion tracking risultano limitate, e in alcuni casi disabilitate del tutto per gli account che operano su quel mercato.
Sul fronte reporting, l’impatto si vede soprattutto nella qualità dei dati che alimentano il tracciamento delle conversioni pubblicitarie. Con Consent Mode v1, un utente che rifiutava i cookie diventava semplicemente invisibile: nessun dato, nessuna stima, un buco nel funnel. Con la v2, e in particolare con la modalità Advanced, Google può:
- Ricevere segnali aggregati anche da utenti che hanno negato il consenso.
- Applicare modelli statistici per stimare le conversioni mancanti.
- Restituire report di Google Ads e GA4 più vicini alla realtà del traffico effettivo.
- Mantenere la segmentazione di base delle campagne anche con tassi di rifiuto del consenso elevati.
Il risultato pratico è che chi ha un tasso di rifiuto consenso alto (comune in settori come turismo, finanza o e-commerce con pubblico europeo) recupera parte della visibilità che la privacy normativa gli aveva sottratto.
I quattro segnali di consenso: cosa fanno davvero
Ogni segnale di consenso controlla un comportamento tecnico specifico, e capire la mappatura con i servizi Google è il primo passo per non commettere errori di configurazione.
ad_storage regola se Google Ads può scrivere e leggere cookie legati alla pubblicità sul dispositivo dell’utente. Senza questo consenso, niente cookie di conversione, niente frequency capping basato su cookie.
analytics_storage fa lo stesso lavoro ma per Google Analytics 4: controlla se GA4 può salvare identificatori lato client per tracciare sessioni e comportamento sul sito. Negato questo segnale, GA4 passa automaticamente alla modellazione cookieless.
ad_user_data determina se puoi inviare dati personali dell’utente a Google per scopi pubblicitari, indipendentemente dal fatto che tu usi cookie o no. È il segnale che copre l’invio di dati come email hashate o identificatori lato server.
ad_personalization stabilisce se quei dati possono alimentare il remarketing e la personalizzazione degli annunci. Puoi avere ad_user_data concesso ma ad_personalization negato: in quel caso Google riceve i dati ma non li usa per costruire liste di remarketing.
La mappatura operativa è questa:
- GA4 dipende principalmente da analytics_storage.
- Google Ads (tracking conversioni base) dipende da ad_storage e ad_user_data.
- Remarketing e audience personalizzate dipendono da ad_personalization.
Uno scenario frequente: un utente accetta l’analytics ma rifiuta l’advertising. In questo caso GA4 continua a raccogliere dati comportamentali completi, mentre Google Ads riceve solo segnali aggregati e non può costruire un profilo per il remarketing di quell’utente. Il contrario succede quando l’utente accetta solo advertising: Google Ads può modellare le conversioni, ma GA4 perde granularità sui percorsi di navigazione.
Basic o Advanced: quale modalità scegliere
La scelta tra le due modalità dipende da quanto sei disposto a rinunciare in termini di dati grezzi in cambio di semplicità di implementazione.
Nella modalità Basic, i tag Google restano completamente bloccati fino a quando l’utente non interagisce con il banner del CMP. Nessuna richiesta parte prima del consenso esplicito. È il comportamento più semplice da implementare, ma anche il più penalizzante sui report: chi non risponde al banner, o lo chiude senza scegliere, semplicemente non genera alcun dato.
Nella modalità Advanced, i tag si caricano subito con lo stato predefinito impostato su “denied”, ma continuano a inviare dei cookieless ping, richieste anonime senza identificatori persistenti che Google usa per alimentare i suoi modelli statistici. Questa modalità richiede un’implementazione più attenta, ma consente a Google di applicare tecniche di modellazione delle conversioni che, secondo alcune analisi di settore, possono recuperare fino al 70% dei dati di conversione altrimenti persi in scenari con tassi di rifiuto consenso elevati.
Per scegliere, segui questa logica:
- Se il tuo sito ha traffico basso o un tasso di consenso storicamente alto (sopra 80%), la Basic è spesso sufficiente. Il margine di recupero dati con Advanced sarebbe marginale.
- Se dipendi fortemente da campagne di remarketing o hai un pubblico europeo con tassi di rifiuto elevati, l’Advanced diventa quasi obbligatoria per non perdere visibilità sulle performance.
- Se il tuo team tecnico ha risorse limitate per gestire cookieless ping e debugging aggiuntivo, valuta se partire con Basic e migrare più avanti.
Un consiglio: non scegliere Advanced solo perché “recupera più dati”. Se il CMP non è configurato bene, i cookieless ping possono generare rumore statistico che confonde più che aiutare. Prima stabilizza l’implementazione base, poi valuta l’upgrade.
Vale la pena ricordare che l’Advanced non serve a identificare gli utenti che hanno rifiutato: la modellazione lavora su dati aggregati, non su singoli profili. È statistica, non elusione del consenso.
Come inizializzare e aggiornare il consenso con gtag.js e GTM
L’ordine di esecuzione è la parte che manda in crisi più implementazioni. Lo stato di default del consenso deve essere impostato prima che qualsiasi altro tag Google venga caricato in pagina. Se il tag di Google Ads o GA4 parte prima che tu abbia dichiarato lo stato predefinito, quei tag assumono un consenso “granted” implicito, cosa che vanifica l’intera implementazione e può generare violazioni di policy.

Con gtag.js direttamente in pagina
Il pattern corretto prevede tre passaggi in sequenza:
- Caricare la libreria gtag.js.
- Chiamare
gtag('consent', 'default', {...})con tutti e quattro i parametri impostati su “denied” (o sui valori di default che vuoi applicare prima dell’interazione dell’utente). - Solo dopo, caricare i tag di configurazione per GA4 e Google Ads.
Quando l’utente interagisce con il banner del CMP e fa una scelta, chiami gtag('consent', 'update', {...}) con i nuovi valori. Google applica retroattivamente lo stato aggiornato a tutte le richieste successive, non a quelle già inviate.
Con Google Tag Manager
Il pattern in GTM segue la stessa logica ma sposta la configurazione nei tag e nelle impostazioni del container. I passaggi tipici sono:
- Attivare la panoramica dei consensi (Consent Overview) nel container GTM, opzione che abilita i controlli integrati.
- Configurare un tag “Consent Default” che si attiva sull’evento di inizializzazione del container, prima di tutti gli altri tag.
- Usare le Consent Settings integrate su ogni tag Google (GA4, conversion tracking di Google Ads) per dichiarare quali segnali di consenso sono richiesti prima che quel tag possa attivarsi.
- Collegare il tag “Consent Update” all’evento generato dal CMP quando l’utente fa la sua scelta.
La guida pratica di CookieHub descrive passo per passo come abilitare questa panoramica e collegare correttamente i trigger, un riferimento utile se stai configurando il container per la prima volta.
Un punto spesso sottovalutato: usare template GTM sandboxed (pubblicati nella galleria dei template della community o costruiti internamente) è preferibile rispetto a scrivere script HTML personalizzati direttamente in un tag “HTML personalizzato”. I template sandboxed dichiarano permessi espliciti (come “Access Consent State” e “Write Consent State”), passano attraverso un processo di revisione dei permessi, e riducono il rischio che uno script mal scritto interferisca con lo stato di consenso globale del container. La documentazione tecnica sui template personalizzati raccomanda proprio questo approccio per chi costruisce logiche di consenso su misura.
- Dichiara sempre i permessi minimi necessari nel template, non quelli massimi disponibili.
- Evita tag HTML personalizzati per l’inizializzazione del consenso: sono difficili da mantenere e da controllare in fase di audit.
- Documenta l’ordine dei trigger nel container, specialmente se più persone lavorano sullo stesso GTM.
Un consiglio: aggiungi sempre un campo wait_for_update nella configurazione del consenso predefinito, con un valore realistico (500 millisecondi è un punto di partenza comune). Questo dice a Google di aspettare che il CMP si sincronizzi prima di considerare la scelta dell’utente come definitiva, evitando che i tag partano con lo stato sbagliato per una manciata di millisecondi.
Perché serve un CMP certificato e come integrarlo
Google non modella le conversioni per chiunque installi un banner cookie. La modellazione nello Spazio Economico Europeo richiede un CMP certificato da Google, un requisito che filtra chi trasmette i segnali in modo tecnicamente corretto da chi si limita a mostrare un popup senza integrazione reale.
Il CMP certificato deve trasmettere in modo sincrono i quattro segnali di consenso e ogni loro aggiornamento, in un formato che Google Tag Manager e gtag.js possano leggere immediatamente. Non basta che il banner “esista”: deve parlare la lingua tecnica che Consent Mode si aspetta.
Per verificare se il tuo provider è certificato:
- Controlla la dashboard del CMP: i provider certificati, come consentmanager, indicano lo stato di certificazione direttamente nel pannello di configurazione o nella documentazione ufficiale.
- Consulta la lista pubblica dei CMP certificati fornita da Google nella sua documentazione per sviluppatori.
- Verifica che l’integrazione supporti sia gtag.js che Google Tag Manager, dato che Google richiede compatibilità con entrambi gli ambienti.
Una checklist rapida per l’integrazione end to end:
- Il banner del CMP si carica prima di qualsiasi altro script di terze parti sulla pagina.
- I segnali di default vengono impostati correttamente al primo caricamento, prima dell’interazione.
- La scelta dell’utente genera un evento che GTM (o gtag.js) intercetta e traduce in un aggiornamento di consenso.
- I cambi di stato successivi (l’utente che torna e modifica le preferenze) vengono propagati correttamente senza richiedere un refresh della pagina.
Come testare e convalidare l’implementazione
Testare Consent Mode v2 non è opzionale: un’implementazione che sembra funzionare visivamente (il banner appare, l’utente clicca) può comunque avere segnali sbagliati che passano inosservati senza un controllo tecnico.
Segui questa sequenza:
- Apri GTM Preview e naviga il sito rifiutando tutti i consensi. Controlla nella console del container che il tag “Consent Default” si attivi come primo evento.
- Accetta tutti i consensi e verifica che l’evento “Consent Update” si attivi correttamente e che i tag GA4/Ads passino da uno stato “denied” a “granted”.
- Apri gli strumenti per sviluppatori del browser, filtra le richieste di rete per il dominio
google-analytics.comogoogleads.g.doubleclick.net, e controlla il parametrogcs(Google Consent Signals) nelle richieste inviate: deve riflettere lo stato reale scelto dall’utente. - Usa Tag Assistant per confermare che i tag Google riconoscano correttamente lo stato di consenso e non generino errori di configurazione.
- Verifica la presenza dei cookieless ping quando il consenso è negato in modalità Advanced: dovresti vedere richieste di rete anche senza consenso attivo, ma senza cookie identificativi allegati.
Sulla modellazione delle conversioni, i tempi non sono immediati. Per attivare la modellazione specifica dell’inserzionista, più precisa del modello generale di settore, Google richiede almeno sette giorni di dati consecutivi e soglie minime di volume, tipicamente centinaia di click pubblicitari al giorno, prima che l’uplift nei report diventi visibile e stabile.
Dopo il rollout, monitora in particolare: il tasso di consenso per canale di acquisizione, la variazione delle conversioni riportate in Google Ads rispetto al periodo pre implementazione, e la coerenza tra i dati di GA4 e quelli di Google Ads, che dopo l’attivazione della modellazione dovrebbero convergere maggiormente.
Errori comuni e come risolverli
Il problema più frequente è la race condition: il CMP non ha ancora comunicato la scelta dell’utente, ma i tag Google si attivano comunque assumendo un consenso di default che magari non corrisponde alla realtà. La causa quasi sempre è un wait_for_update assente o troppo basso rispetto al tempo di caricamento reale del CMP. Alza il valore a 500 millisecondi come punto di partenza e misura se il problema persiste con il tuo CMP specifico.
Un secondo errore riguarda la console del browser che si riempie di avvisi quando ad_storage è impostato su “denied” ma i tag continuano a tentare operazioni sui cookie. La soluzione è impostare ads_data_redaction su true nei tag interessati: questo dice esplicitamente ai tag Google di non tentare letture o scritture di cookie non autorizzate, eliminando l’errore alla radice invece di ignorarlo.
Terzo problema, tipico di chi lavora con template GTM personalizzati: permessi sandbox mancanti. Se il template non dichiara esplicitamente “Access Consent State” nelle sue impostazioni di sicurezza, non potrà leggere lo stato attuale del consenso, e la logica condizionale al suo interno smetterà semplicemente di funzionare senza un errore evidente.
- Controlla sempre i permessi dichiarati nella scheda “Permissions” del template prima di pubblicarlo.
- Aggiungi logging temporaneo (variabili di debug in GTM) per verificare quale stato di consenso il template riceve realmente in ogni sessione di test.
- Ripeti il test dopo ogni modifica al container: una configurazione che funzionava ieri può rompersi con un aggiornamento non collegato al consenso.
Un consiglio: tieni un registro delle versioni del container GTM legate a modifiche del consenso. Quando una metrica crolla improvvisamente, la prima domanda da farti è se qualcuno ha toccato la configurazione di consenso, non se è cambiato l’algoritmo di Google Ads.
SPA, server-side tagging e template personalizzati
Le applicazioni a pagina singola (SPA, incluse quelle costruite in React) complicano l’inizializzazione del consenso perché il ciclo di vita della pagina non coincide con un caricamento tradizionale. Lo stato di consenso deve essere impostato al primo render, e ogni cambio di rotta virtuale che attiva nuovi tag deve rispettare lo stesso stato senza richiedere un reload completo del container GTM.
Il pattern più solido è centralizzare la gestione del consenso in un unico punto dell’applicazione (spesso un context o uno store globale) e propagare gli aggiornamenti a GTM tramite dataLayer.push ogni volta che l’utente modifica le preferenze, senza duplicare la logica di inizializzazione a ogni cambio di componente.
Con il server-side tagging tramite un container Google Tag Manager server side, la gestione del consenso cambia forma: i segnali vengono ricevuti dal client e trasmessi al server, che decide quali dati inoltrare a GA4 e Google Ads. Questo approccio riduce il carico sul browser dell’utente e permette un controllo più granulare su cosa viene effettivamente inviato a terze parti, ma richiede una configurazione aggiuntiva per assicurarsi che il consenso venga rispettato anche lato server, non solo lato client.
Per un template GTM personalizzato in questi contesti avanzati:
- Dichiara i permessi sandbox minimi necessari e documenta perché servono.
- Gestisci il
wait_for_updateanche negli scenari server side, dove la latenza di rete tra client e server introduce ulteriori variabili di tempo. - Testa la latenza complessiva: ogni livello aggiuntivo (client, container server side, endpoint Google) somma millisecondi che possono diventare secondi percepibili su connessioni lente.
- Evita di duplicare la logica di consenso tra client e server: mantieni un’unica fonte di verità.
Prospettiva Hhype: come approcciamo un progetto di questo tipo
Il metodo che applichiamo in Hhype segue tre fasi: audit tecnico dell’implementazione esistente, correzione o costruzione dell’architettura di consenso su GTM, e monitoraggio dei report nelle settimane successive per verificare che la modellazione stia effettivamente recuperando dati.
L’audit iniziale è quasi sempre la fase che rivela i problemi più seri: container con tag duplicati, CMP non certificati installati per motivi estetici, template HTML personalizzati che nessuno in azienda sa più spiegare. Risolvere questi problemi prima di parlare di ottimizzazione delle campagne è quello che distingue un’implementazione che regge nel tempo da una che si rompe al primo aggiornamento di Google.
Abbiamo applicato logiche simili su progetti che spaziano dal turismo al branding, come Dolche, dove l’affidabilità del tracciamento pubblicitario è parte integrante della strategia di advertising e personalizzazione messa in campo.
Esternalizzare questa parte tecnica ha senso quando il team interno ha competenze di marketing ma non di sviluppo, o quando semplicemente manca il tempo per stare dietro ai continui aggiornamenti delle policy Google. Il valore che ci si aspetta non è solo “il banner funziona”, ma report pubblicitari che tornano ad avere senso.
— Hhype
Un audit tecnico e l’implementazione completa di Consent Mode v2
Se hai letto fin qui probabilmente hai già capito che sistemare Consent Mode v2 bene non è un lavoro di un pomeriggio: tocca il container GTM, il CMP, i tag pubblicitari e, se usi un’architettura server side, anche l’infrastruttura backend. Offriamo un percorso guidato che parte da un audit tecnico reale del tuo container e finisce con un sistema che i tuoi report possono davvero usare.

Il percorso include un audit completo dell’implementazione attuale, la costruzione o correzione dei template necessari per gestire correttamente default e update del consenso, l’integrazione con un CMP certificato quando manca o non è configurato a norma, e un ciclo di test end to end prima del rilascio in produzione. Dopo il lancio, vengono monitorati i primi report per verificare che la modellazione delle conversioni stia effettivamente recuperando dati.
Il primo passo è una richiesta di preventivo tramite la pagina principale di Hhype, dove puoi descrivere la situazione attuale del tuo tracciamento e ricevere una valutazione su tempi e interventi necessari. Se il progetto richiede anche una revisione della strategia pubblicitaria complessiva, puoi approfondire i nostri servizi di consulenza marketing strategico per PMI.
Risorse ufficiali e guide consigliate
Per verificare o approfondire ogni aspetto trattato, queste fonti restano il riferimento più solido:
- La documentazione ufficiale di Google per sviluppatori sui CMP, che descrive i requisiti tecnici di integrazione e i criteri di certificazione.
- La guida pratica di CookieHub alla configurazione di Consent Mode v2, utile per chi configura per la prima volta il container GTM.
- Le indicazioni tecniche di consentmanager sui requisiti per gli inserzionisti nello SEE, con dettagli sulla certificazione CMP.
- La documentazione su template GTM personalizzati di Nova Tools, per chi costruisce logiche di consenso su misura.
Per il debugging quotidiano, gli strumenti indispensabili restano Google Tag Assistant, la modalità Preview di GTM e la scheda di rete della console del browser per controllare i parametri gcs inviati nelle richieste.
Fonti
- Consent Mode for CMP providers | Google Developers
- Guida alla configurazione di Google Consent Mode V2 (2026) | CookieHub
- Consent Mode v2: Template GTM Personalizzato | Nova Tools
- Google Consent Mode v2 | consentmanager
Domande frequenti
Che cos’è la Consent Mode v2 di Google?
È il framework che trasmette a Google Analytics 4, Google Ads e agli altri tag Google i segnali di consenso dell’utente su quattro parametri: ad_storage, analytics_storage, ad_user_data e ad_personalization, permettendo la modellazione statistica delle conversioni quando il consenso è negato.
Cosa cambia rispetto alla Consent Mode v1?
La v1 gestiva solo ad_storage e analytics_storage; la v2 aggiunge ad_user_data e ad_personalization, richiesti da Google per attivare il remarketing, il conversion tracking e la modellazione avanzata nello Spazio Economico Europeo.
Devo usare la modalità Basic o Advanced?
Scegli Basic se hai un tasso di consenso già alto e vuoi un’implementazione semplice; scegli Advanced se dipendi da remarketing o campagne europee con tassi di rifiuto significativi, perché recupera dati tramite modellazione statistica.
Serve davvero un CMP certificato?
Sì: senza un CMP certificato da Google, la modellazione delle conversioni nello Spazio Economico Europeo non si attiva e alcune funzioni pubblicitarie, come il remarketing, risultano limitate.
Come posso testare se l’implementazione è corretta?
Usa GTM Preview per verificare l’ordine di attivazione dei tag, Tag Assistant per confermare la lettura dello stato di consenso, e controlla il parametro gcs nelle richieste di rete verso i domini Google.
Quanto tempo serve prima di vedere l’effetto della modellazione?
Google richiede tipicamente almeno sette giorni di dati continui e soglie minime di volume pubblicitario prima che la modellazione specifica dell’inserzionista produca un uplift stabile nei report.