Google Consent Mode v2 è il meccanismo con cui il tuo sito comunica ai tag di Google che cosa ha scelto il visitatore sui cookie. Non è un banner, non è una legge e non sostituisce l'informativa: è un insieme di parametri, quattro dei quali obbligatori, che viaggiano dal tuo strumento di raccolta del consenso verso Google Analytics 4, Google Ads e le altre tag della piattaforma.

La versione 2 richiede quattro parametri, due dei quali dedicati ai dati pubblicitari, e senza quei segnali le funzioni di personalizzazione e di misurazione degli annunci non sono disponibili per gli utenti dello Spazio economico europeo. Detto in modo pratico: il consenso raccolto deve arrivare integro allo strato di attivazione, e questo è esattamente il punto in cui una CMP fa la differenza tra un banner decorativo e una misurazione che regge.

Consent Mode è un'API di consenso. Il tuo sito dichiara uno stato iniziale per ciascun parametro, poi aggiorna quello stato quando la persona interagisce con il banner, e i tag di Google adattano il proprio comportamento a quello che leggono. Senza questo passaggio, i tag continuano a lavorare come se nessuno avesse mai espresso una scelta.

Il malinteso più diffuso è pensare che Consent Mode raccolga il consenso. Non lo fa. La raccolta resta in capo al titolare del trattamento e passa dal banner, dall'informativa e dalla registrazione della scelta. Consent Mode è il traduttore che porta quella decisione dentro l'ecosistema Google in un formato che i tag sanno leggere.

La documentazione ufficiale di Google descrive questo strato come il modo per adeguare il comportamento dei tag in base al consenso dell'utente, prima ancora che le richieste vengano inviate. Puoi verificarlo nella pagina di riferimento del Consent Mode, da tenere aperta accanto a questa guida.

L'approccio storico, in Italia molto comune, era semplice: blocco tutti gli script di terze parti finché l'utente non accetta. Funziona dal punto di vista del blocco preventivo, ma introduce un effetto collaterale documentato da Google. Se impedisci ai tag di Google di caricarsi fino all'interazione col banner, Google non riesce a verificare le scelte di consenso dell'utente e questo può portare a perdita di dati.

Il punto non è scegliere tra conformità e misurazione. Il punto è capire che sono due catene distinte che devono combaciare: la prima decide se un cookie può essere scritto, la seconda decide che cosa i tag fanno con quella informazione. Consent Mode serve alla seconda.

Se usi Google Analytics 4, Google Ads, il tag di conversione, il remarketing o il Google Tag Manager, ti riguarda. Se il tuo sito vive di traffico organico e non fa investimento pubblicitario, l'urgenza è minore, ma la parte analytics resta rilevante per la qualità dei report.

E se gestisci un e-commerce o generi lead con campagne a pagamento, questo è uno dei pochi argomenti tecnici in cui una configurazione sbagliata si vede subito nel conto economico, non solo in un audit.

Le funzionalità di personalizzazione degli annunci e di misurazione richiedono i segnali di consenso per gli utenti dello Spazio economico europeo. La base di questo obbligo non è una norma europea: è la EU user consent policy di Google, cioè una condizione contrattuale che accetti quando usi i suoi prodotti.

Senza quei segnali si perdono la personalizzazione degli annunci, il remarketing e le soluzioni di pubblico. Gli utenti privi di consenso smettono di entrare nei pubblici usati dai prodotti pubblicitari collegati. È una degradazione progressiva delle funzionalità, non un interruttore che spegne tutto in una notte.

Il rischio concreto, quindi, è la perdita di alcune funzioni di personalizzazione e di misurazione: è questo che conviene spiegare a una direzione commerciale quando si definisce la priorità del lavoro.

In Italia il consenso ai cookie è disciplinato dall'articolo 122 del Codice privacy e dalle linee guida del Garante. Consent Mode è invece un requisito di Google. Il primo ti espone a un procedimento dell'autorità, il secondo alla perdita di funzionalità di misurazione.

Un sito può essere impeccabile sul piano tecnico verso Google e avere un banner cookie che non rispetta le regole del Garante. Il contrario è altrettanto possibile. Torneremo su questo punto perché è il nodo che genera più errori nelle aziende italiane.

Il framework prevede sette parametri di consenso, e ciascuno accetta solo due valori: granted oppure denied. Non esistono stati intermedi, non esiste un valore neutro, non esiste il silenzio. Se non dichiari nulla, il comportamento non è definito da te e questo è già un problema.

I quattro richiesti dalla versione 2 sono ad_storage, ad_user_data, ad_personalization e analytics_storage. Gli altri tre esistono nel framework ma non fanno parte dei quattro della versione 2. Puoi dichiararli per completezza, tenendo presente che servono a funzioni diverse da quelle pubblicitarie e di misurazione.

Qui nasce metà dei problemi di implementazione. Le categorie che mostri all'utente nel banner (tecnici, statistici, di profilazione) non hanno una corrispondenza automatica con i parametri di Google. Sei tu che devi definire la mappatura, e quella mappatura deve riflettere quello che hai scritto nell'informativa.

Una mappatura ragionevole per un sito italiano tipico associa la categoria statistica a analytics_storage e la categoria di profilazione o marketing a ad_storage, ad_user_data e ad_personalization insieme. Se separi il marketing in due sottocategorie, devi decidere quale governa quale parametro e documentarlo.

L'errore da evitare è la mappatura implicita, quella che nessuno ha scritto e che vive solo nella configurazione di un tag manager. Quando arriva una richiesta di accesso o un chiarimento dell'autorità, la coerenza tra informativa, banner e segnali inviati è esattamente ciò che devi poter dimostrare.

Esistono due modi di implementare Consent Mode e la scelta cambia il comportamento del sito in modo visibile. Non è una preferenza estetica: è una decisione che riguarda che cosa parte dal browser dell'utente prima che lui abbia deciso qualcosa.

Nella modalità base i tag di Google restano bloccati finché l'utente non interagisce con il banner, e nessun dato viene trasmesso a Google prima di quel momento. Se l'utente nega, nessun dato viene trasferito. La modellazione delle conversioni, in questo scenario, si appoggia a un modello generale e non a un modello specifico dell'inserzionista.

Qui torna l'avvertenza vista sopra, e conviene tenerla in mente invece di considerarla risolta: bloccare i tag fino all'interazione è esattamente lo scenario in cui Google dice di non riuscire a verificare le scelte dell'utente, con possibile perdita di dati. La modalità base non elimina quell'effetto, lo accetta in cambio di un comportamento più semplice da spiegare e da difendere.

Nella modalità avanzata i tag si caricano già all'ingresso, inizializzati con gli stati predefiniti su denied, e inviano ping senza cookie mentre il consenso resta negato. Dopo il consenso passano alla misurazione completa. Secondo la documentazione, è la modalità che permette una modellazione specifica dell'inserzionista invece di un modello generale.

| Modellazione | Modello generale | Modello specifico dell'inserzionista |
| Complessità di implementazione | Minore | Maggiore |

La scelta tra le due modalità dipende da come è costruito il consenso a monte, non da una preferenza tecnica. Se vuoi un confronto sul tuo caso, AdOpt lavora esattamente su questo punto di raccordo.

Se la tua priorità assoluta è che nulla parta verso Google prima di una scelta esplicita, la modalità base è la risposta più semplice da spiegare e da difendere. Il prezzo è una perdita di segnale e una modellazione meno precisa, perché Google non dispone di dati sul comportamento aggregato del tuo sito.

Se invece la misurazione è centrale per il business e hai un volume di traffico significativo, la modalità avanzata offre risultati migliori sul fronte dei report. In quel caso però la valutazione va fatta con il consulente legale dell'azienda, perché l'invio di un ping prima della scelta merita un'analisi del caso concreto.

Quello che non cambia tra le due modalità è la necessità di un banner corretto, di un'informativa completa e di una prova della scelta effettuata. Consent Mode non ti esonera da nulla di tutto questo, e su questo punto la guida al GDPR in Italia resta il riferimento da tenere aperto accanto alla documentazione tecnica.

Questa è la sezione che risolve la maggior parte delle discussioni interne, perché la documentazione di Google descrive comportamenti specifici e verificabili. Vale la pena leggerli con attenzione, uno per uno, invece di affidarsi a riassunti di seconda mano.

Con ad_storage impostato su denied accadono tre cose. Nessun nuovo cookie pubblicitario viene scritto. Le richieste passano attraverso un dominio diverso, per evitare i cookie di terze parti impostati in precedenza. E l'URL completo della pagina viene raccolto, il che significa che può includere informazioni sul clic sull'annuncio presenti nei parametri.

Quell'ultimo punto merita una riga in più, perché sfugge quasi sempre. Se la tua pagina di destinazione riceve parametri di campagna nell'URL, quei parametri fanno parte dell'URL raccolto anche a consenso negato. Non è una scappatoia nascosta: è un comportamento documentato che devi conoscere quando descrivi i trattamenti nella tua informativa.

Con analytics_storage impostato su denied il comportamento è diverso. Vengono inviati ping senza cookie ad Analytics, e nessun cookie di Analytics di prima parte viene letto o scritto sul dispositivo.

Un ping senza cookie è una richiesta che non porta con sé un identificatore persistente scritto sul dispositivo. Non permette di ricostruire la sequenza di visite di una persona nel tempo, perché manca proprio l'elemento che rende possibile quel collegamento.

È un segnale povero per definizione, e questo è il motivo per cui Google lo usa in aggregato dentro un modello statistico. Chiamarlo "conversione" è impreciso e crea aspettative sbagliate in chi legge i report. Chiamarlo "dato personale zero" sarebbe altrettanto impreciso: la valutazione va fatta caso per caso, guardando che cosa contiene la richiesta nella tua specifica configurazione.

Se stai mettendo ordine in questa catena e vuoi capire dove il tuo setup perde pezzi, un occhio esterno accorcia molto i tempi. Puoi vedere come lavora AdOpt sulla parte di raccolta e trasmissione del consenso e capire se l'impostazione attuale regge.

La modellazione è la risposta di Google alla perdita di dati causata dal consenso negato. L'idea è ricostruire statisticamente i comportamenti che non si possono osservare, partendo da quelli osservabili degli utenti che hanno acconsentito e dai segnali aggregati di chi non lo ha fatto.

Ci sono due meccanismi distinti che vengono spesso confusi. La modellazione delle conversioni riguarda i prodotti pubblicitari e stima le conversioni non osservabili. Il behavioral modeling riguarda Google Analytics 4 e stima il comportamento degli utenti nei report, come utenti e sessioni.

La distinzione conta perché i requisiti sono diversi e perché la modellazione non è un interruttore che accendi. È una funzione che si attiva quando ci sono le condizioni, e se le condizioni non ci sono i tuoi report restano semplicemente incompleti.

La modellazione produce stime, e le stime hanno un margine di errore che non compare nell'interfaccia con la stessa evidenza dei numeri osservati.

Un dato modellato è utile per capire una tendenza e per confrontare periodi. È meno utile quando devi prendere una decisione su un numero puntuale, per esempio il valore esatto delle conversioni di una singola campagna in una singola settimana. Sapere quale dei due casi stai guardando è una competenza di misurazione, non di privacy.

Qui i numeri esistono e sono pubblici, quindi non c'è motivo di andare a intuito. La documentazione di Google indica due soglie che devono essere soddisfatte insieme perché il behavioral modeling possa attivarsi su una proprietà.

La prima soglia riguarda gli eventi senza consenso: almeno 1.000 eventi al giorno con analytics_storage impostato su denied per almeno 7 giorni. La seconda riguarda gli utenti con consenso: almeno 1.000 utenti giornalieri che inviano eventi con lo stato granted in almeno 7 dei 28 giorni precedenti.

Due precisazioni importanti, entrambe documentate. Raggiungere la soglia non garantisce l'idoneità, e l'addestramento del modello può richiedere più di 7 giorni. Trovi le condizioni esatte nella documentazione sul behavioral modeling.

Anche quando è attiva, la modellazione non copre tutto. Secondo la documentazione non si applica ai pubblici, a User explorer, alle esplorazioni di coorte e di durata di vita, ai segmenti con sequenza, ai rapporti di conservazione, alle metriche predittive e all'esportazione verso BigQuery.

È un elenco che vale la pena stampare e appendere accanto al monitor, perché spiega decine di discrepanze apparentemente inspiegabili tra report. Se un numero non torna, la prima domanda da farsi è se quella superficie riceve dati modellati oppure no.

Per una proprietà con traffico modesto quelle soglie possono non essere raggiunte. In quel caso la modellazione non entra in funzione e i dati senza consenso restano mancanti nei report. Non è un difetto dell'implementazione: è il funzionamento previsto.

Un punto da chiarire bene: con la modalità avanzata le conversioni non continuano a essere inviate normalmente anche senza consenso.

Quello che viene inviato con il consenso negato è un segnale senza cookie, aggregato, usato per la modellazione statistica. Non è una conversione osservata, non è attribuibile a una persona identificata e non alimenta i pubblici come farebbe un dato raccolto con consenso.

La differenza è sostanziale su tre piani. Sul piano tecnico, manca l'identificatore che permette di collegare eventi nel tempo. Sul piano dei report, il numero che vedi è una stima e non un conteggio. Sul piano delle funzionalità, la personalizzazione degli annunci e il remarketing non funzionano su quegli utenti.

Leggere male questo punto porta a due decisioni sbagliate in fila. La prima è rilassarsi sulla qualità del banner, pensando che il dato arrivi comunque. La seconda è pianificare investimento pubblicitario su numeri che interpreta come osservati quando sono modellati.

C'è poi un terzo effetto, più insidioso. Se in azienda si diffonde l'idea che il consenso non incida sulla misurazione, sparisce l'incentivo a lavorare sul tasso di accettazione e sulla chiarezza dell'informativa. E quello è il lavoro che dà il ritorno più alto, perché un consenso reale vale più di qualsiasi stima.

La formulazione corretta è semplice e la puoi usare tale e quale nelle riunioni interne. Senza consenso, Google riceve un segnale povero e aggregato che serve a stimare; con il consenso, riceve la misurazione completa. La modalità avanzata riduce il buco, non lo elimina.

L'implementazione ruota attorno a due chiamate. La prima dichiara gli stati predefiniti e deve girare prima che qualsiasi tag scatti. La seconda aggiorna gli stati dopo che l'utente ha compiuto la sua scelta. Ordine e tempistica sono la parte in cui si sbaglia più spesso.

Questo è lo snippet ufficiale per gli stati predefiniti, quello che va eseguito per primo su ogni pagina, prima che qualsiasi libreria di Google entri in azione:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});

Leggiamolo riga per riga. La chiamata gtag('consent', 'default', {...}) comunica al livello dati che stai impostando lo stato iniziale del consenso, non un aggiornamento. Tutto ciò che segue vale finché non arriva un aggiornamento esplicito.

'ad_storage': 'denied' dice ai tag di non scrivere nuovi cookie pubblicitari e di comportarsi come descritto nella sezione precedente, con richieste su un dominio diverso. 'ad_user_data': 'denied' blocca l'invio a Google di dati utente per finalità pubblicitarie. 'ad_personalization': 'denied' esclude quell'utente dalla pubblicità personalizzata e dal remarketing. 'analytics_storage': 'denied' impedisce ad Analytics di impostare, leggere o consultare i propri cookie sul dispositivo.

Impostare tutto su denied come predefinito non è pessimismo tecnico: è l'unico stato iniziale coerente con l'articolo 122 del Codice privacy, che consente l'archiviazione o l'accesso alle informazioni sul dispositivo soltanto dopo il consenso dell'utente informato. Puoi leggere il testo vigente sulla versione consolidata del Codice su Normattiva.

Quando la persona sceglie, aggiorni gli stati corrispondenti alle categorie che ha effettivamente accettato, senza toccare le altre. Questo è lo snippet ufficiale di update, nella versione in cui l'utente ha acconsentito a tutto:

gtag('consent', 'update', {
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'ad_storage': 'granted',
  'analytics_storage': 'granted'
});

La differenza rispetto al primo snippet è il secondo argomento: 'update' invece di 'default'. Da quel momento i tag già caricati cambiano comportamento e quelli in attesa possono scattare. Non serve ricaricare la pagina, ed è proprio questo il vantaggio dell'API.

Attenzione a un dettaglio pratico: nell'aggiornamento invii solo i parametri che l'utente ha effettivamente concesso. Se accetta le statistiche e rifiuta il marketing, aggiorni analytics_storage su granted e lasci gli altri tre su denied. Uno snippet copiato con tutti i valori su granted per ogni scelta è un errore che vanifica l'intera catena.

Il default deve girare prima di qualunque tag, quindi va posizionato il più in alto possibile nel documento, prima del caricamento della libreria di Google. Se gira dopo, alcune tag avranno già agito senza istruzioni e nessun aggiornamento successivo potrà annullare ciò che è già partito.

L'update gira nel momento in cui la scelta dell'utente è definita, tipicamente nel callback del banner. Se il visitatore ha già scelto in una visita precedente e la preferenza è memorizzata, l'update va eseguito subito al caricamento, immediatamente dopo il default, senza mostrare di nuovo il banner.

Oltre agli stati di consenso esistono quattro parametri di controllo che governano il comportamento della catena. Conoscerli è la differenza tra un'implementazione che funziona in laboratorio e una che funziona su un sito reale con latenza, cache e visitatori impazienti.

wait_for_update è un valore in millisecondi che controlla quanto tempo attendere prima che i dati vengano inviati, per dare tempo alla CMP di risolvere lo stato. Serve nei casi in cui la lettura della preferenza salvata è asincrona e rischia di arrivare dopo il primo invio.

region permette di definire stati predefiniti solo per i visitatori di determinate aree, indicate con il codice ISO 3166-2. È lo strumento con cui applichi il regime europeo a chi arriva dall'Europa senza imporre lo stesso trattamento a tutto il traffico mondiale.

ads_data_redaction, quando impostato su true, oscura gli identificatori pubblicitari nelle richieste mentre ad_storage resta su denied. È una misura aggiuntiva che riduce ciò che viaggia nel periodo in cui il consenso non c'è.

url_passthrough, quando impostato su true, propaga le informazioni sul clic sull'annuncio e sulla sessione tramite parametri di URL nel momento in cui i cookie sono negati. Aiuta l'attribuzione, e va valutato con attenzione perché sposta informazione dentro l'URL.

La tentazione è ovvia: applico il default restrittivo solo all'Europa e lascio il resto libero. Tecnicamente si può fare, ed è previsto dalla stessa documentazione di Google. Prima di farlo, però, considera due cose.

La prima è che il rilevamento dell'area geografica non è infallibile e un visitatore italiano dietro una connessione instradata altrove può ricevere il default sbagliato. La seconda è che una configurazione differenziata è più difficile da spiegare e da dimostrare quando qualcuno chiede conto delle tue scelte.

Molte aziende italiane, alla fine, scelgono di applicare il default restrittivo a tutti. È una decisione che costa un po' di segnale e compra molta semplicità, e la guida ufficiale all'implementazione del consenso contiene tutti gli elementi per valutare l'alternativa.

Con Google Tag Manager la logica non cambia, cambia il punto in cui la scrivi. Nella sezione di amministrazione del container esistono impostazioni di consenso dedicate, e la documentazione prevede l'uso di un modello di una CMP che dichiari gli stati al posto tuo.

Il passo per passo, con gli errori più comuni, è nella guida a Google Tag Manager e GDPR.

Il flusso corretto ha quattro passaggi. Imposti gli stati predefiniti su denied in un tag che scatta con priorità massima all'inizializzazione del container. Dichiari per ogni tag di quali parametri ha bisogno. Fai in modo che la CMP invii l'aggiornamento quando l'utente sceglie. Verifichi in anteprima che ogni tag scatti solo con lo stato atteso.

La parte più trascurata è la seconda. In molti container i tag di terze parti non dichiarano alcun requisito di consenso, quindi scattano sempre, indipendentemente da quello che l'utente ha deciso. Consent Mode governa i tag di Google, non il pixel di un social network o lo script di una chat, e questo confine è la fonte di parecchie non conformità silenziose.

Se questa parte del lavoro ti sta costando più tempo di quanto valga, vale la pena guardare i piani disponibili e capire quale livello di automazione ti toglie il problema dalle mani.

Il vantaggio di centralizzare la dichiarazione nel container è che non dipendi dalla correttezza di ogni singolo tag inserito a mano nel tempo. Lo svantaggio è che una configurazione sbagliata sbaglia per tutti insieme, quindi vale la pena verificarla come descritto più avanti.

Attenzione però al doppio blocco. Se blocchi il container e in più blocchi gli script con un altro strumento, rischi di produrre uno stato in cui nessun segnale arriva mai a Google, con la perdita di dati che la documentazione stessa segnala. Una sola catena di controllo, ben progettata, funziona meglio di tre catene sovrapposte.

Per un sito costruito su un CMS con molti plugin, la mappatura completa dei tag richiede una revisione manuale, e una piattaforma di gestione del consenso pensata per lavorare accanto al tag manager riduce sensibilmente il tempo necessario.

Questa è la sezione che, in Italia, fa la differenza tra un'implementazione che passa un controllo e una che no. Consent Mode è un requisito contrattuale di Google. Le linee guida cookie sono un provvedimento dell'autorità italiana. Rispettare il primo non ti mette a norma con il secondo, e viceversa.

Le linee guida sono il provvedimento n. 231 del 10 giugno 2021, doc. web n. 9677876, pubblicato nella Gazzetta Ufficiale n. 163 del 9 luglio 2021, con un termine di adeguamento di sei mesi dalla pubblicazione in Gazzetta. Il fondamento normativo resta l'articolo 122 del Codice privacy, che subordina l'archiviazione e l'accesso alle informazioni sul dispositivo al consenso dell'utente informato.

Quello che le linee guida chiedono riguarda il banner e l'informativa, non i segnali verso Google. Il primo livello del banner deve contenere cinque elementi: l'avviso che chiudere con la X mantiene le impostazioni predefinite, l'informazione sintetica sui cookie tecnici e, se presenti, di profilazione con le relative finalità, il link all'informativa estesa, il comando per acconsentire a tutti i cookie e il link all'area delle scelte granulari per finalità e per terzo.

Il primo scenario è il sito con Consent Mode perfetto e banner illegittimo. I quattro parametri partono con denied, l'aggiornamento è impeccabile, i report sono puliti. Il banner però non ha la X con evidenza grafica pari a quella degli altri comandi negoziali, oppure usa colori e dimensioni che spingono verso l'accettazione. Le linee guida chiedono esplicitamente l'utilizzo di comandi e di caratteri di uguali dimensioni, enfasi e colori.

Il secondo scenario è il sito con banner esemplare e Consent Mode assente. La raccolta del consenso è corretta, la registrazione della scelta esiste, l'informativa è completa. Solo che la scelta non viaggia verso i tag: il banner blocca gli script e Google non riceve alcun segnale. Il risultato è conformità sul piano dell'autorità e perdita di funzionalità sul piano contrattuale.

Il punto della tesi di AdOpt è esattamente qui. Il valore non sta nell'estetica del banner, sta nel fatto che la scelta dell'utente arrivi integra allo strato di attivazione e che ne resti una prova verificabile. Un consenso raccolto e mai trasmesso è lavoro sprecato due volte.

Ci sono tre indicazioni che incidono direttamente sul modo in cui progetti la catena tecnica. La prima riguarda lo scroll: secondo il Garante il semplice scroll down del cursore di pagina è inadatto in sé alla raccolta di un idoneo consenso all'installazione e all'utilizzo di cookie di profilazione, e può essere solo un componente di un processo più articolato e registrabile.

La seconda riguarda la chiusura dal comando X, posizionata di regola, e secondo prassi consolidata, in alto a destra e all'interno del banner: chiudere da lì comporta il permanere delle impostazioni di default, cioè nessun cookie non tecnico installato. Tradotto nella catena tecnica, la chiusura dalla X non deve generare un aggiornamento con valori granted.

La terza è il punto più frainteso del mercato italiano. I sei mesi citati nelle linee guida non sono la durata di validità del consenso: sono l'intervallo minimo dopo il quale puoi tornare a chiedere il consenso a chi si è già espresso.

Il testo è esplicito: la scelta dovrà essere debitamente registrata e la prestazione del consenso non più nuovamente sollecitata. Le eccezioni sono tre: quando mutino significativamente le condizioni del trattamento, quando sia tecnicamente impossibile sapere se l'utente si è già espresso, o quando siano trascorsi almeno sei mesi dalla precedente presentazione del banner.

Chi legge male questo punto costruisce un sistema che riprogramma il banner ogni sei mesi come se il consenso scadesse. Se ti interessa il dettaglio di come queste regole vengono applicate e con quali conseguenze, cosa fa il Garante e come funzionano le sanzioni chiarisce il quadro procedurale.

Questa confusione costa tempo e soldi a molte aziende italiane, quindi vale la pena separare i due casi con la massima chiarezza possibile. L'obbligo di usare una CMP certificata da Google e integrata con lo IAB Transparency and Consent Framework riguarda i publisher, non tutti.

Per i publisher che monetizzano con AdSense, Ad Manager o AdMob, il requisito è in vigore nello Spazio economico europeo dal 16 gennaio 2024. Se il tuo modello di business è vendere spazi pubblicitari sul tuo sito o nella tua app con questi prodotti, la certificazione e l'integrazione TCF ti riguardano.

Per gli inserzionisti, cioè per chi usa Google Ads e Google Analytics 4 per promuovere la propria attività, il requisito è diverso: inviare i segnali del Consent Mode v2. Non è richiesto l'uso di una CMP certificata TCF. È una differenza sostanziale che cambia il perimetro del progetto.

Un e-commerce che investe in Google Ads e misura con GA4 è un inserzionista. Per lui un'integrazione TCF completa non è un requisito.

Un editore online che vive di pubblicità programmatica è nella situazione opposta e ha bisogno esattamente di quel livello. Confondere i due profili porta a scegliere lo strumento sbagliato, e la differenza tra una CMP e uno script che mostra un avviso è il primo filtro da applicare in questa valutazione.

Esistono anche casi ibridi, per esempio un sito editoriale che vende abbonamenti e insieme monetizza con la pubblicità. In quelle situazioni la valutazione va fatta prodotto per prodotto, perché il requisito segue lo strumento usato e non la categoria commerciale dell'azienda.

Con analytics_storage su denied i report di GA4 cambiano aspetto in modi che vale la pena anticipare, perché la prima reazione di chi li guarda è pensare che qualcosa si sia rotto. Non si è rotto niente: stai vedendo l'effetto del consenso sulla misurazione.

La metrica che si comporta in modo più sorprendente è il conteggio degli utenti. Senza un cookie di Analytics, non esiste un identificatore che permetta di riconoscere la stessa persona in due visite diverse, quindi due visite della stessa persona non si riconoscono come tali. Gli eventi, invece, continuano ad arrivare come ping senza cookie.

L'attribuzione delle sorgenti di traffico è l'altra area che si degrada. La ricostruzione del percorso che ha portato alla conversione dipende dalla continuità dell'identificatore, e quando quella continuità manca il percorso che ha portato alla conversione diventa più difficile da ricostruire.

La regola pratica è confrontare periodi omogenei e diffidare dei confronti che attraversano un cambio di configurazione. Se hai attivato Consent Mode a metà mese, il confronto con il mese precedente non misura il tuo marketing: misura il tuo setup tecnico.

La seconda regola è tenere sotto controllo il tasso di consenso come metrica di business a pieno titolo. È il moltiplicatore che agisce su tutto il resto, e migliorarlo con un banner chiaro e leggibile vale più di qualsiasi affinamento del modello. Chi lavora bene sull'informativa e sulla trasparenza raccoglie più consenso reale, e su questo la lettura pratica degli obblighi del GDPR in Italia aiuta a impostare il messaggio giusto.

Ci sono due modifiche documentate da Google che conviene mettere in agenda adesso, perché toccano la configurazione e non solo i report. Sono cambiamenti dichiarati dalla piattaforma, non ipotesi normative.

La prima ha una data precisa: dal 15 giugno 2026 Google Analytics inizia a usare il Consent Mode, all'interno di Google Ads, come controllo unico dei dati. L'impostazione Google Signals smette di controllare la raccolta di cookie e identificatori di Google Ads e passa a servire soltanto per associare i dati degli utenti che hanno effettuato l'accesso nei rapporti.

La seconda è prevista nel corso del 2026 senza una data definita. Il modello dei controlli a livelli per la personalizzazione degli annunci esce di scena e il parametro ad_personalization passa a controllare in via esclusiva quell'utilizzo nelle proprietà collegate a Google Ads.

Che cosa significa nella pratica per un'azienda italiana. Significa che il peso della configurazione si sposta sempre più sui segnali di consenso e sempre meno sulle impostazioni di prodotto. Chi ha una catena solida oggi non deve fare nulla di drammatico; chi si appoggia a impostazioni interne di GA4 per governare la raccolta dovrà rivederle.

Dopo aver visto molti setup, gli errori si ripetono con una regolarità quasi noiosa. Elencarli serve a risparmiare settimane di diagnosi, perché ognuno di questi produce sintomi che sembrano indicare cause completamente diverse.

• Il default che gira dopo il caricamento dei tag, quindi senza alcun effetto reale sul comportamento iniziale.
• L'update che invia tutti i quattro parametri su granted anche quando l'utente ha accettato solo le statistiche.
• Il blocco totale degli script sommato al Consent Mode, che produce l'assenza di qualsiasi segnale e la perdita di dati segnalata dalla documentazione.
• La chiusura dalla X del banner trattata come accettazione, in contrasto diretto con le linee guida del Garante.
• I tag di terze parti nel container senza requisiti di consenso dichiarati, che scattano indipendentemente dalla scelta.
• La preferenza già espressa in una visita precedente che non viene riapplicata all'inizializzazione, con il banner che ricompare a ogni pagina.
• La mappatura tra categorie del banner e parametri di Google mai scritta da nessuna parte, quindi impossibile da verificare o da dimostrare.
• Il wait_for_update assente su siti in cui la lettura della preferenza salvata è asincrona, con i primi eventi inviati con lo stato sbagliato.

Il più costoso di tutti, in termini di rischio, è il quarto: la X trattata come consenso. È in contrasto diretto con le linee guida, che prevedono che chiudere dalla X comporti il permanere delle impostazioni di default. Se devi correggere una cosa sola questa settimana, correggi quella e sistema in parallelo il banner secondo le indicazioni del Garante.

Verificare è la parte che quasi nessuno fa, ed è l'unica che ti dice se hai finito il lavoro. Servono venti minuti e gli strumenti già presenti nel browser. Queste sono le verifiche in ordine, da eseguire su una sessione pulita, senza estensioni che blocchino gli script.

1. Apri il sito in una finestra anonima con la scheda di rete degli strumenti per sviluppatori già attiva, prima di interagire con il banner.
2. Filtra le richieste verso i domini di Google e osserva che cosa parte prima di qualsiasi scelta: in modalità base non dovresti vedere richieste di misurazione, in modalità avanzata dovresti vedere ping senza cookie.
3. Guarda se le richieste verso Google riportano lo stato del consenso e annota che cosa indicano in quel momento.
4. Ripeti la lettura subito dopo aver accettato, e verifica che le richieste cambino in coerenza con la scelta appena compiuta.
5. Ripeti la stessa sequenza rifiutando tutto, poi accettando solo le statistiche, e controlla che gli stati riflettano ogni combinazione senza scorciatoie.
6. Apri la scheda delle applicazioni e controlla quali cookie risultano scritti in ciascuno dei tre scenari, confrontandoli con quanto dichiarato nell'informativa.
7. Usa la modalità di anteprima di Google Tag Manager e guarda, tag per tag, se è stato attivato o sospeso e con quale stato di consenso.
8. Ricarica la pagina dopo aver scelto e verifica che la preferenza venga riapplicata all'inizializzazione, senza che il banner ricompaia.
9. Ripeti tutto su mobile, perché il comportamento del banner e i tempi di caricamento cambiano abbastanza da produrre risultati diversi.
10. Annota le evidenze con data e configurazione: è la prova che ti serve quando qualcuno, tra sei mesi, chiederà come funzionava la catena in quel periodo.

L'ultimo punto è quello che distingue un'azienda organizzata da una che si affida alla memoria delle persone. La registrazione di ciò che il visitatore ha scelto, e la possibilità di ricostruirla, è parte integrante dell'obbligo di dimostrare il consenso e non un vezzo documentale.

A questo punto la funzione di una piattaforma di gestione del consenso dovrebbe essere chiara, e non ha molto a che vedere con il disegno del banner. Serve a fare quattro cose in modo affidabile e ripetibile, ogni giorno, su tutte le pagine.

• Raccogliere la scelta con un'interfaccia coerente con le linee guida, compresa la parità grafica tra i comandi.
• Registrare la scelta in modo verificabile, con una traccia che permetta di dimostrare che cosa è stato scelto e quando.
• Trasmettere lo stato allo strato di attivazione con gli stati predefiniti e gli aggiornamenti nell'ordine corretto.
• Riapplicare la preferenza alle visite successive, senza tornare a chiedere ciò che è già stato deciso.

Il quarto punto è quello che fa la differenza percepita dall'utente e, insieme, quello che tiene il tuo sito lontano dalla riproposizione eccessiva del banner censurata dalle linee guida. Un visitatore a cui si chiede la stessa cosa a ogni pagina non sta esprimendo una scelta libera, sta cercando di liberarsi di un ostacolo.

Il lavoro di AdOpt si concentra proprio su questo tratto della catena, quello che va dalla scelta della persona fino al segnale che arriva ai tag, con la prova di quello che è successo. Se vuoi capire quale livello serve al tuo caso, i piani disponibili partono da scenari molto diversi tra loro.

Una precisazione onesta per chiudere la sezione: nessuno strumento sostituisce la valutazione legale del tuo caso concreto. La tecnologia risolve la parte ripetibile, la parte specifica va discussa con il consulente legale dell'azienda, che conosce i tuoi trattamenti e le tue finalità.

• Che cos'è una CMP e perché ti serve
• Come mettere il banner cookie a norma secondo il Garante

No. Non è previsto da alcuna norma italiana o europea. È un requisito contrattuale di Google: le funzioni di personalizzazione e misurazione degli annunci richiedono i segnali di consenso per gli utenti dello Spazio economico europeo. Gli obblighi di legge sui cookie restano l'articolo 122 del Codice privacy, il GDPR e le linee guida del Garante, che riguardano banner e informativa.

No, sono due cose separate. Consent Mode governa che cosa i tag di Google fanno con la scelta dell'utente, mentre le linee guida del Garante disciplinano come quella scelta viene chiesta e registrata. Un sito può avere segnali perfetti e un banner non conforme, per esempio se la X non ha parità grafica con gli altri comandi o se chiuderla viene trattato come accettazione.

Nella modalità base i tag restano bloccati fino all'interazione con il banner e nessun dato viene trasmesso prima; se l'utente nega, nulla viene trasferito. Nella modalità avanzata i tag si caricano subito con gli stati su denied e inviano ping senza cookie finché il consenso manca. La modalità avanzata consente una modellazione specifica dell'inserzionista, la base si appoggia a un modello generale.

No, e questa è la confusione più diffusa. Senza consenso viene inviato un segnale senza cookie, aggregato, usato per la modellazione statistica: non è una conversione osservata e non alimenta pubblici, remarketing o personalizzazione. I numeri che vedi nei report sono stime, quindi utili per leggere tendenze e molto meno affidabili per decisioni su singoli valori puntuali.

Molto probabilmente non raggiungi le soglie documentate. Il behavioral modeling in Google Analytics 4 richiede almeno 1.000 eventi al giorno con analytics_storage su denied per almeno 7 giorni e almeno 1.000 utenti giornalieri con stato granted in almeno 7 dei 28 giorni precedenti. Raggiungere le soglie non garantisce l'idoneità e l'addestramento del modello può richiedere più di 7 giorni.

---

Il consenso che raccogli sul tuo sito arriva davvero ai tag di Google, o si ferma al banner?

Prenota una conversazione con il nostro team e vediamo insieme dove la catena perde pezzi.