Iubenda + GTM: integrare il consent banner senza buchi

Su un cliente con 180k sessioni/mese, dopo aver corretto l'integrazione Iubenda + GTM + Consent Mode v2, ho visto l'audience "Tutti gli utenti" su Google Ads passare da 47k a 71k visitatori identificati nel mese successivo. Non era un aumento di traffico: era smettere di buttare nel cestino i visitatori che davano il consenso ma il cui consenso non veniva propagato correttamente ai tag pubblicitari.

Il problema è quasi sempre lo stesso: i tutorial generici di Iubenda funzionano bene su un container GTM pulito e su Consent Mode v1. Con la v2 e con il livello di personalizzazione che serve in produzione, servono pochi accorgimenti aggiuntivi.

L'architettura: chi fa cosa

Per chiarezza, separiamo i ruoli:

Componente	Responsabilità
Iubenda CS	Mostra il banner, raccoglie il consenso, salva preferenze in cookie `_iub_cs-*`
Iubenda → dataLayer	Pubblica gli eventi `iubenda_consent_given` e `iubenda_consent_rejected`
GTM Consent Mode	Riceve segnali, gestisce defaults e updates verso Google
Tag GTM	Sparano o si bloccano in base al consenso
Google (GA4, Ads)	Reagisce ai segnali (`ad_storage`, `ad_user_data`, ecc.)

Il pasticcio nasce quando questi cinque componenti hanno aspettative non allineate.

Su Iubenda Console, abilita le seguenti opzioni nella Cookie Solution:

Tag Manager mode: attiva l'integrazione "Per chi ha attivo Google Tag Manager". Questo fa sì che Iubenda non esegua direttamente nessuno script di terze parti: pubblica solo eventi nel dataLayer.
Per-category consent: abilita la modalità "categorie" (Necessari, Funzionalità, Esperienza, Misurazione, Marketing). Ti serviranno per il mapping al Consent Mode.
Google Consent Mode: attiva l'integrazione nativa Google Consent Mode v2 nelle preferenze avanzate. Questa è la parte che molti dimenticano.

Il codice da inserire nel <head> è quello standard di Iubenda CS, da prendere dalla loro console. Importante: deve essere il primo script del <head>, prima ancora del container GTM. Se è dopo, GTM parte con i defaults sbagliati e ti tocca aggiornarli a stato avvenuto, generando race condition.

Dentro GTM, hai bisogno di un Custom Template che gestisca il Consent Mode. Le opzioni:

Template community gratuito "Consent Mode V2" (autori vari su Template Gallery)
Template custom che hai scritto tu (più controllo, vedi Consent Mode v2 template GTM)
Integrazione nativa Iubenda via Tag Iubenda official (più semplice ma meno flessibile)

Indipendentemente da quale scegli, il template deve fare due cose:

Esegue al boot del container, in Consent Initialization - All Pages trigger:

const consentDefaults = {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'functionality_storage': 'granted',
  'security_storage': 'granted',
  'wait_for_update': 500
};

setDefaultConsentState(consentDefaults);

Nota: wait_for_update: 500 dice a Google "aspetta 500ms prima di assumere che il default sia definitivo". È il margine per ricevere l'aggiornamento di Iubenda quando l'utente già ha consenso salvato.

Trigger su iubenda_consent_given o iubenda_consent_rejected. Tag che legge le preferenze e aggiorna:

const iubPrefs = {{DLV - iubenda - preferences}};  // variabile DataLayer

const update = {
  'ad_storage': iubPrefs.purposes['5'] ? 'granted' : 'denied',         // Marketing
  'analytics_storage': iubPrefs.purposes['4'] ? 'granted' : 'denied',  // Misurazione
  'ad_user_data': iubPrefs.purposes['5'] ? 'granted' : 'denied',       // Marketing
  'ad_personalization': iubPrefs.purposes['5'] ? 'granted' : 'denied'  // Marketing
};

updateConsentState(update);

La mappatura purposes['5'] viene dalla categorizzazione di Iubenda. Su Iubenda Console verifica che le tue categorie corrispondano a:

1: Necessari
2: Funzionalità
3: Esperienza
4: Misurazione
5: Marketing

Se hai customizzato le categorie, devi aggiornare lo script.

Il bug più frequente: ad_user_data legato a purpose 4

Vedo questo errore in 8 audit su 10 sui clienti italiani che usano Iubenda. Il banner ha "Misurazione" e "Marketing" come categorie separate, ma il template mappa ad_user_data su analytics_storage (Misurazione) invece che su ad_storage (Marketing).

Conseguenza: l'utente che concede solo "Misurazione" ma rifiuta "Marketing" vede il segnale ad_user_data settato a granted, e questo manda inutilmente dati first-party a Google Ads. Tecnicamente possibile sanzione, anche se la prassi è ancora poco enforced.

Mappatura corretta:

analytics_storage ← Misurazione (purpose 4)
ad_storage ← Marketing (purpose 5)
ad_user_data ← Marketing (purpose 5)
ad_personalization ← Marketing (purpose 5)

ad_user_data e ad_personalization sono segnali introdotti dal DMA EU: vanno trattati come Marketing, non Misurazione.

La race condition silenziosa

Su pagine pesanti (ecommerce con product gallery, landing con video hero), il banner Iubenda a volte renderizza dopo che GTM ha già caricato. Sequence problematica:

Pagina inizia a caricare
GTM si carica, setta i defaults (denied)
Pagina renderizza, l'utente è già in cookie pool "denied"
Banner Iubenda compare 800ms dopo, l'utente accetta tutto
GTM aggiorna lo state a "granted"

Il problema: tra il punto 2 e il punto 5, qualsiasi tag con trigger "Initialization - All Pages" o "All Pages" è già partito con consenso denied. GA4, se configurato male, ha già perso il page_view iniziale di quella sessione.

Soluzione: wait_for_update del Consent Mode (vedi sopra) deve essere abbastanza alto (500ms minimo, 1000ms su siti pesanti) per dare a Iubenda il tempo di comunicare la preferenza pre-esistente. E i tag che dipendono dal consenso vanno triggered su "Window Loaded" o "DOM Ready" + check consent, non su "Consent Initialization".

Verificare che funzioni

Dopo il setup, tre verifiche obbligatorie:

Test 1: refresh con consenso già dato

L'utente apre il sito, accetta tutto via banner. Chiude. Riapre il sito.

Apri DevTools → Console
Tipo: dataLayer (deve mostrare l'evento iubenda_consent_given quasi immediato)
Tipo: google_tag_data.ics.getEntry() (mostra stato Consent Mode corrente: tutti granted)
Apri Tag Assistant Companion: verifica che i tag GA4, Google Ads e Meta sparano subito

Test 2: utente che rifiuta

Apri in incognito. Quando arriva il banner, rifiuta tutto.

DevTools → Network: nessuna chiamata a google-analytics.com/g/collect con gcs=G111 (concesso). Devi vedere gcs=G100 (rifiutato) o cookieless ping
Tag Assistant: i tag Meta e LinkedIn devono essere bloccati (in stato "Tag did not fire, consent denied")
GA4 Realtime: dovresti comunque vedere il page_view modellato (cookieless), ma non gli eventi commerciali

Test 3: refresh dopo rifiuto

Stessa sessione, rifiuta tutto, refresh pagina.

DevTools → Console: google_tag_data.ics.getEntry() mostra ancora ad_storage = denied, analytics_storage = denied
Niente cookie _ga (perché analytics_storage è denied)
Iubenda banner NON ricompare (perché il consenso è già stato dato, anche se negativo)

Se uno di questi test fallisce, il setup ha un bug. I bug più frequenti sono mappatura sbagliata delle purposes, defaults troppo permissivi, o tag che ignorano il segnale consent.

Quando passare a server-side Iubenda

L'integrazione Iubenda standard è client-side: il consenso vive nei cookie del browser. Su ecommerce con utenti loggati cross-device (oggi dal mobile, domani dal desktop), questo crea inconsistenze: ogni device ha il suo cookie consenso indipendente.

Iubenda offre anche Consent Database (server-side): il consenso viene salvato lato server associato all'utente loggato, e il banner non si ripresenta sui device dove l'utente è già loggato. Costa di più ma vale la pena se hai >100k utenti registrati.

Sul lato GTM, l'integrazione server-side richiede di leggere lo stato consenso dal backend (via API Iubenda) all'init del container server, e di propagarlo a tutti i tag server. Setup più complesso, ma è il modello giusto per chi prende sul serio la compliance.

Limiti

L'integrazione Iubenda + Consent Mode v2 risolve il "come" della compliance, non il "se". Resta tutto da decidere a monte:

Quale categoria mappare su quale segnale Google (Iubenda non lo fa per te, è policy)
Se mostrare il banner solo agli EU o a tutti (anche se gli US e gli EU hanno regole diverse)
Come gestire il "Reject all" che alcuni regolatori chiedono come default opt-out

La parte tecnica è chiara, la parte legale richiede DPO o consulente privacy. Non sono cose che si decidono guardando GTM.

E il modeling Google Consent Mode v2 ha bisogno di volume: con meno di 1000 conversioni/giorno il modeling non parte e perdi le conversioni rifiutate definitivamente. Su business piccoli, il discorso si sposta su come massimizzare il consent rate (UX del banner) invece che su come recuperare cookieless.

Domande che ricevo più spesso

FAQ

Iubenda è meglio di Cookiebot o OneTrust per Consent Mode v2?

Per il mercato italiano e PMI Iubenda è più conveniente e ha integrazione GTM nativa. Cookiebot ha categorizzazioni un filo più strict, OneTrust è enterprise. Tecnicamente, con la mappatura corretta, tutti e tre fanno lo stesso lavoro: la differenza è UX banner, prezzo e supporto.

Devo per forza usare il template ufficiale Iubenda di GTM?

No. Il template ufficiale è comodo per partire ma è una scatola nera: non vedi il codice e non puoi modificare la mappatura purposes-segnali. Su progetti dove serve controllo (ecommerce, B2B con dati sensibili), un template custom dà più garanzie. Vedi la guida dedicata al Consent Mode v2 con template GTM custom.

Il Consent Mode v2 modeling funziona davvero?

Sì, ma serve volume. Google richiede minimo 1000 click annuncio e 100 conversioni negli ultimi 7 giorni per attivare il modeling per campagna. Sotto, le conversioni rifiutate sono perse definitivamente. Su business piccoli conviene massimizzare il consent rate del banner anziché contare sul modeling.

Cosa succede se l'utente clicca 'X' sul banner senza scegliere?

Dipende dalla configurazione Iubenda. Per default, in EU il banner non scompare finché non c'è una scelta esplicita (per essere conformi al DMA). Se hai abilitato 'continua navigazione = accettazione', sappi che il Garante italiano lo considera consenso non valido dal 2024.

Funziona anche se ho un sito multilingua con dominio diverso per paese?

Sì, ma ogni dominio ha il suo cookie consenso indipendente: l'utente che cambia da .it a .fr vede di nuovo il banner. Per evitarlo, serve l'integrazione Consent Database server-side di Iubenda (paid) che propaga il consenso cross-domain via login utente.

Prossimi passi

Se il tuo banner Iubenda esiste ma sospetti che la mappatura sia sbagliata, parti da un audit tracking GA4 che include il check del Consent Mode v2 e del flusso completo Iubenda → GTM → Google. Per chi ha bisogno di andare oltre lo standard, il template GTM custom è descritto in Consent Mode v2 template GTM.

Se il fine ultimo è recuperare conversioni perse dalle scelte di consenso (e dagli ad-blocker), il passo successivo sono le Enhanced Conversions e il GTM Server-Side. Quel tre layer (consent banner + GTM client-side + GTM server-side + EC) è la combo che fa la differenza vera nel 2026.

Iubenda + GTM: integrare il consent banner senza buchi

L'architettura: chi fa cosa

Setup del banner Iubenda

Il bug più frequente: ad_user_data legato a purpose 4

La race condition silenziosa