Quando il banner cookie cambia e nessuno te lo dice

Il cookie banner monitoring consiste nel tenere traccia di quale consent management platform (CMP) gira su un sito, verificare che sopravviva a ogni deploy e controllare che i tag di marketing si comportino ancora correttamente rispetto al consenso. Se il banner sparisce, il sito inizia a scrivere cookie di tracciamento senza chiedere niente a nessuno, e questo è un problema di GDPR; se cambia, GA4 e Meta Pixel possono smettere di caricarsi mentre ogni pagina sembra in perfetta salute.

Nessuna pagina restituisce un 404 e nessun controllo di uptime diventa rosso. Di solito il primo indizio è un grafico delle conversioni che, qualche settimana dopo, non torna più.

Chi mette mano al banner, e perché nessuno ti avvisa

Il consenso sta a cavallo tra reparti diversi. Il legale si occupa della cookie policy e spesso del contratto con la CMP. Uno sviluppatore gestisce il plugin o lo script nell'<head>. Il marketing gestisce i tag che ne dipendono. Il risultato finale non è di nessuno, quindi le modifiche nascono da motivi sensati per un team e non arrivano mai agli altri.

Qualche esempio tipico. Uno sviluppatore installa Complianz o CookieYes su un sito WordPress che aveva già un sistema di consenso. Il legale sposta l'account da Cookiebot a OneTrust e lo archivia come pratica contrattuale. Un aggiornamento del tema o del CMS elimina lo snippet che caricava la CMP. Qualcuno rinomina le categorie di consenso e un tag finisce in una categoria che nessun visitatore attiva mai. Oppure il banner era stato disattivato in staging per comodità durante i test, e quell'impostazione arriva in produzione con la release.

Ognuno di questi casi è un esempio da manuale di modifica SEO silenziosa, solo che il danno colpisce analytics e compliance invece del posizionamento.

Cosa fa un cambio di CMP a GA4 e Meta Pixel

La maggior parte delle CMP blocca gli script prima del consenso, riconoscendo gli URL degli script oppure assegnando i tag a delle categorie. Una CMP nuova non sa nulla delle eccezioni configurate su quella vecchia, quindi un tag che prima si caricava dopo "Accetta" può non caricarsi più. Google Tag Manager è presente, il container parte, e il tag GA4 al suo interno resta bloccato.

Con Google Consent Mode v2 il guasto è ancora più difficile da notare. La pagina imposta un default con gtag('consent', 'default', {...}), e il banner dovrebbe chiamare gtag('consent', 'update', {...}) quando il visitatore accetta. Se il nuovo banner non invia mai quell'update, analytics_storage e ad_storage restano su denied. GA4 continua a ricevere hit, ma sono ping senza cookie, e i report si riempiono di dati modellati al posto delle sessioni osservate. Nel tab Network lo vedi dalla richiesta /g/collect: il parametro gcs vale G100 quando entrambi i tipi di storage sono negati e G111 quando sono entrambi concessi.

Il guasto opposto sembra una buona notizia. Se il banner scompare del tutto, i tag partono per chiunque e le sessioni in GA4 schizzano verso l'alto. Quel salto è un problema di compliance, non crescita.

Un disallineamento tra le categorie colpisce soprattutto l'advertising. Quando il Meta Pixel sta dietro una categoria "marketing" che il nuovo banner nasconde in una seconda schermata, le campagne continuano a spendere mentre le conversioni smettono di essere attribuite.

Cosa dovrebbe succedere in ogni stato del consenso

Stato	GA4 / GTM	Meta Pixel	Cookie che dovresti vedere
Prima di qualsiasi scelta	Bloccato, oppure Consent Mode con default denied	Non caricato	Nessun _ga, nessun _fbp
Dopo Accetta	gtag.js si carica, /g/collect con gcs=G111	fbevents.js si carica	_ga, _ga_<ID>, _fbp
Dopo Rifiuta	Nessun hit, oppure solo hit senza cookie	Non caricato	Nessun _ga, nessun _fbp

Come verificare il consenso a mano

1. Apri una nuova finestra in incognito. Una scelta di consenso salvata da una visita precedente nasconderebbe il problema.
2. Carica la homepage e annota quale CMP mostra il banner. Cookiebot, Iubenda, OneTrust, CookieYes e Complianz hanno markup e URL degli script riconoscibili.
3. Apri i DevTools, vai su Network e filtra per collect, gtag e fbevents. Controlla anche Application > Cookies.
4. Clicca Accetta e verifica che compaiano le richieste e i cookie indicati nella tabella. Controlla che il measurement ID nella richiesta (tid=G-...) sia ancora quello del cliente.
5. Ripeti in una nuova finestra in incognito, questa volta cliccando Rifiuta.
6. Fai lo stesso su ogni template che conta, senza saltare la thank you page o la conferma d'ordine, perché è lì che partono i tag di conversione.

Servono circa dieci minuti per sito. Una volta si può fare, ma dopo ogni release su trenta siti di clienti non è realistico.

Il cookie banner monitoring in Deltio, e dove si ferma

Deltio controlla una volta al giorno la homepage di ogni sito, registra quale CMP è presente e ti avvisa su Slack e via email quando il provider compare, sparisce o cambia. Nello stesso ciclo giornaliero verifica GA4, GTM e Meta Pixel sulle pagine monitorate e segnala un tag sparito o con l'ID cambiato. Un cambio di banner e un pixel mancante emergono quindi nello stesso posto, lo stesso giorno.

Non valuta se la configurazione del consenso è adeguata dal punto di vista legale e non fa l'inventario dei cookie scritti dal sito. Ti dice cosa c'è sulla pagina e cosa è cambiato rispetto al controllo precedente. Per il resto di un sito cliente, vedi la checklist di monitoraggio per agenzie e la guida su come monitorare i siti dei clienti per rilevare modifiche.

Un buon punto di partenza è il cliente in cui legale, sviluppatore e marketing non sono mai stati nella stessa call. Puoi aggiungere quel sito con la prova di 14 giorni.