Consent Mode v2 in Italia: guida pratica per e-commerce (2026)

Dal marzo 2024 Google richiede Consent Mode v2 per le campagne advertising. Come implementarlo bene in un e-commerce italiano, senza comprare un CMP.

Felice Carotenuto 8 min Per e-commerce

Se hai un e-commerce italiano, dal marzo 2024 Consent Mode v2 non è più opzionale. Senza, Google Ads non è più in grado di usare i dati granulari per il bidding, e in pratica la tua performance peggiora — anche se tu non te ne accorgi subito. Questa guida è il modo in cui lo implemento sui siti dei miei clienti, senza ricorrere a una CMP a pagamento, mantenendo il controllo completo del banner e restando pienamente GDPR compliant.

Non è una guida generica al Consent Mode. È la procedura pratica, testata su decine di e-commerce italiani (Shopify, WooCommerce, Magento, headless), con i dettagli che le documentazioni ufficiali Google lasciano fuori.

Il Consent Mode è il meccanismo con cui Google riceve un segnale sul consenso dell’utente ai cookie, e di conseguenza modula cosa fare: salvare l’identificativo del visitatore, usare i dati per il bidding, fare remarketing. Fino alla v1 c’erano due segnali: ad_storage e analytics_storage. Dalla v2, attiva dal 6 marzo 2024, se ne aggiungono due:

  • ad_user_data — consenso all’invio dei dati utente (email hashed, phone hashed) a Google per matching.
  • ad_personalization — consenso all’uso dei dati per personalization (remarketing, audience).

Senza questi due segnali settati esplicitamente, dal marzo 2024 le campagne di remarketing Google Ads si disattivano progressivamente per gli utenti SEE (Spazio Economico Europeo). Non è una minaccia generica: Google Ads stessa inizia a mostrare warning in UI se non li riceve.

I 4 segnali che devi impostare

In ogni pagina del tuo sito, prima di qualsiasi tag Google, devi inviare un gtag('consent', 'default', {...}) con i 4 segnali su denied:

<head> del sito — prima di GTM 
<script>
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }

gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  functionality_storage: 'granted',
  security_storage: 'granted',
  wait_for_update: 500
});

gtag('set', 'url_passthrough', true);
gtag('set', 'ads_data_redaction', true);
</script>

Cosa fa ogni riga:

  • ad_storage: denied — niente cookie pubblicitari fino a consenso.
  • analytics_storage: denied — niente cookie analytics fino a consenso; GA4 invia ping anonimi modellati.
  • ad_user_data: denied — Google non riceve dati utente per matching (email, phone hashed) prima del consenso.
  • ad_personalization: denied — niente remarketing o audience prima del consenso.
  • functionality_storage: granted — cookie tecnici sempre attivi (lingua, tema, carrello), coerenti con il parere del Garante del maggio 2014.
  • security_storage: granted — cookie di sicurezza (anti-CSRF, rate limiting) sempre attivi.
  • wait_for_update: 500 — aspetta fino a 500ms un eventuale aggiornamento di consenso prima di partire con le richieste. Se entro 500ms arriva un gtag('consent', 'update', ...), i tag si adattano.

La guida pratica step-by-step

Dopo aver impostato il default, servono 4 passi:

1. Caricare questo snippet PRIMA di GTM

Fondamentale: il gtag('consent', 'default', ...) deve essere eseguito nel browser prima che parta il container GTM. Altrimenti i tag Google che il container carica non sanno quali segnali di consenso usare e considerano tutto granted (perché è il loro default interno).

Ordine corretto nel <head>:

  1. gtag('consent', 'default', ...) (lo script qui sopra)
  2. gtag('set', 'url_passthrough', true) e ads_data_redaction (subito dopo, stesso script)
  3. Container GTM (<script>(function(w,d,s,l,i){...})(...)</script>)

Sul sito di questo stesso blog (felicecarotenuto.com) vedrai esattamente questa sequenza nel sorgente.

2. Mostrare il banner di consenso

Al primo accesso, l’utente deve vedere un banner che gli permette di scegliere fra Accetta tutto, Solo necessari, Personalizza. Tre pulsanti minimo — due (accetta/rifiuta) non sono sufficienti per il Garante italiano: serve un’opzione di granularità. Personalmente non faccio mai “accetta tutto” come unico pulsante evidente: è anti-pattern e non passa un audit serio.

Il banner deve rispettare queste regole:

  • Nessun cookie di tracking piazzato prima dell’interazione utente (tranne tecnici).
  • Negazione altrettanto facile dell’accettazione — stesso livello visuale, stessa area.
  • Nessuna opzione pre-spuntata nel pannello “Personalizza”.
  • Persistenza della scelta (io uso localStorage con chiave dedicata, no cookie).

Quando l’utente fa clic su una delle tre scelte, il banner deve chiamare gtag('consent', 'update', ...):

banner onclick handler (esempio) 
// Quando l'utente accetta tutto
gtag('consent', 'update', {
ad_storage: 'granted',
ad_user_data: 'granted',
ad_personalization: 'granted',
analytics_storage: 'granted',
});

// Quando l'utente rifiuta tutto tranne il necessario
gtag('consent', 'update', {
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
});

// Salva la scelta per le visite successive
localStorage.setItem('fc_consent_v1', JSON.stringify({
choice: 'all',
categories: { /* ... */ },
updatedAt: new Date().toISOString()
}));

// Push evento in dataLayer per logica GTM
dataLayer.push({ event: 'consent_update', choice: 'all' });

Da notare due cose importanti:

  • gtag('consent', 'update', ...) va chiamata prima di qualsiasi eventuale reinvio di eventi. Il consent update cambia il comportamento di tutti i tag caricati, incluso il GTM container, i pixel Meta, ecc.
  • Il dataLayer.push({ event: 'consent_update' }) è quello che io uso in GTM per dire ai tag analytics di rifare certe operazioni (es. re-firing di page_view con i cookie ora accettati). Se non lo fai, perdi la page view della prima visita.

4. Riapplicare il consenso alle visite successive

Al secondo accesso, prima di mostrare nuovamente il banner, controlla se c’è già una scelta salvata e se sì, riemetti il gtag('consent', 'update', ...) coerente:

onload di pagine successive alla prima 
const stored = localStorage.getItem('fc_consent_v1');
if (stored) {
const { categories } = JSON.parse(stored);
gtag('consent', 'update', {
  ad_storage: categories.ad_storage ? 'granted' : 'denied',
  ad_user_data: categories.ad_user_data ? 'granted' : 'denied',
  ad_personalization: categories.ad_personalization ? 'granted' : 'denied',
  analytics_storage: categories.analytics_storage ? 'granted' : 'denied',
});
// Nessun banner
} else {
showBanner();
}

Questo va eseguito il prima possibile nel caricamento pagina — tipicamente nel blocco <script> dopo il default consent, prima del container GTM.

Perché url_passthrough e ads_data_redaction sono obbligatori

Due impostazioni spesso ignorate ma fondamentali:

url_passthrough: true fa sì che GA4 propaghi identificatori di campagna (es. gclid) attraverso la navigazione del sito, senza usare cookie. Se non lo attivi, su utenti che rifiutano i cookie le campagne Google Ads non possono collegare la conversione al click — anche in modalità modellata.

ads_data_redaction: true fa sì che quando ad_storage è denied, gli URL inviati a Google per le conversioni non contengano dati potenzialmente identificativi (come l’ID click). È un livello di compliance aggiuntivo che Google stessa raccomanda.

Personalmente li tengo sempre attivi, anche dopo il consenso. Non hanno effetti collaterali negativi se l’utente ha accettato e aggiungono un ulteriore livello di privacy.

I ping anonimi modellati: cosa raccolgono davvero

Una domanda che mi fanno sempre i clienti preoccupati del Garante: “Ma quindi Google riceve comunque qualcosa anche se l’utente rifiuta?”. Sì, ma con limitazioni precise:

  • Nessun client ID (quindi niente sessione ricostruibile).
  • Nessun IP completo (Google anonimizza prima dell’invio).
  • Nessun user ID di nessun tipo.
  • Solo metriche aggregate: page view count, session count, event count.

Google usa questi ping per alimentare modelli statistici che restituiscono una stima aggregata di metriche come conversioni e utenti. Sulla base di ciò che dice il EDPB e il Garante italiano, questi ping non costituiscono trattamento di dati personali ai sensi del GDPR, perché non è possibile identificare la persona. Ma la cosa è grigia e l’interpretazione può cambiare — motivo in più per avere un banner fatto bene e un’informativa completa.

Cosa pensa il Garante italiano (stato dell’arte 2026)

La posizione del Garante si è progressivamente chiarita:

  1. Cookie tecnici sempre attivi — ok senza consenso, posizione ferma dal 2014.
  2. Scroll come accettazione — non valido, rimosso dalle linee guida del 2021.
  3. Legitimate interest per analytics — non accettabile se i cookie sono identificativi. Serve consenso o anonimizzazione forte.
  4. Ping modellati di Google — al momento accettati, purché l’informativa lo dichiari in modo trasparente.
  5. Design del banner — la negazione deve essere facile almeno quanto l’accettazione. Dark pattern (solo pulsante accetta ben visibile, rifiuta nascosto in un link testuale) = sanzionabili.

Nei miei setup rispetto tutti e 5 i punti, e nella cookie policy descrivo esplicitamente il ruolo dei ping modellati.

Errori comuni che vedo spesso

Per chiudere, i 5 errori più frequenti nelle implementazioni che mi ritrovo ad auditare:

  1. Default consent assente o in ordine sbagliato — il gtag('consent', 'default', ...) va eseguito prima del container GTM, non dopo.
  2. wait_for_update troppo basso o assente — con 0ms o con valori inferiori a 500ms, alcuni tag possono partire prima che arrivi il consent update.
  3. Solo 2 segnali aggiornati (v1 style) — dimenticano ad_user_data e ad_personalization. Conseguenza: Google Ads continua a essere in “partial consent mode”.
  4. Cookie banner che non aggiorna davvero — il click mostra il toast ma il gtag('consent', 'update', ...) non viene mai chiamato. L’ho visto su siti che usano CMP mal configurate.
  5. Accetta tutto = anche functionality_storage — non ha senso, quel segnale non controlla mai niente di rilevante. Mantenere separate le categorie effettive del banner dai 6 segnali Google è la strategia giusta.

Checklist finale

Prima di pubblicare un sito con Consent Mode v2, questi sono i check che faccio sempre:

  • gtag('consent', 'default', ...) presente nel <head>, prima di GTM.
  • Tutti e 4 i segnali v2 impostati su denied.
  • functionality_storage e security_storage su granted.
  • url_passthrough: true e ads_data_redaction: true sempre attivi.
  • wait_for_update: 500.
  • Banner con 3 pulsanti (Accetta tutto / Solo necessari / Personalizza).
  • Persistenza in localStorage e re-apply al load successivo.
  • Evento consent_update in dataLayer con choice all | necessary | custom.
  • Cookie policy che descrive i ping modellati.
  • Test in Tag Assistant: Consent signals corretti prima e dopo choice.
  • Test in Google Ads UI: nessun warning su consenso mancante.

Se vuoi che ti aiuti con il tuo specifico setup, scrivimi un brief o fissa una call. Ho anche un servizio dedicato al Consent Mode v2 e al cookie banner se preferisci affidarmi l’implementazione completa.

#Consent Mode v2#GDPR#Cookie Banner#GTM#Ecommerce

Hai un progetto su questo tema?

Se hai letto fin qui, probabilmente stai lavorando su qualcosa che assomiglia a questo. Se vuoi farmi qualche domanda — anche solo per sapere se sono la persona giusta per te — la call è gratuita.

Fissa una call Scrivimi un brief