Verifica tecnica del banner cookie: blocca gli script non essenziali? 7 errori

Il pulsante «Rifiuta» non dimostra che il tracciamento si fermi davvero. Una guida pratica alla verifica del banner con Network, Application, Consent Mode e test ripetuti.

Lei apre il sito in un nuovo profilo del browser, preme «Rifiuta» e vede scomparire l’avviso sui cookie; dall’esterno sembra tutto a posto, ma è proprio qui che comincia la verifica tecnica del banner cookie: prima del clic era già partita una richiesta verso una piattaforma pubblicitaria, la risposta aveva tentato di impostare un identificatore rimasto nello spazio di archiviazione del browser e, dopo il rifiuto, i tag hanno ricevuto lo stato di consenso corretto? Il pulsante è soltanto il quadro comandi, e il controllo deve accertare che sotto siano davvero collegati i cavi, perché la CMP potrebbe non avere ancora impostato lo stato predefinito quando il gestore dei tag attiva già il primo tag.

L’ispezione visiva del banner o il segno di spunta verde di uno scanner automatico non dicono che cosa sia accaduto nei primi secondi di caricamento, né rivelano quale script abbia provocato l’azione, quale stato del consenso fosse disponibile in quel momento o se lo stato finale visibile corrisponda all’intera sequenza degli eventi precedenti. Per questo mettiamo sulla stessa linea temporale il comportamento del sito prima della scelta, dopo il rifiuto di tutte le categorie non essenziali, dopo il consenso e dopo la sua successiva revoca, valutando in ciascuno stato le richieste di rete, le intestazioni delle risposte, i cookie, localStorage e gli altri sistemi di archiviazione, la sequenza dei segnali di consenso e l’iniziatore della singola azione. Soltanto questo confronto distingue una configurazione corretta da un banner che si limita a chiudersi.

Questo è un articolo tecnico, non un parere legale individuale: mostra come raccogliere fatti verificabili e come evitare conclusioni che le prove non giustificano. Se il sito usa Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, video incorporati, una finestra di chat o altri strumenti di terze parti, l’elenco dei cookie visibile in una sola schermata è soltanto una parte del quadro; la domanda decisiva, quindi, non è «il banner è installato?», ma «che cosa fa il sito in ogni momento della scelta dell’utente?».

Che cosa comprende la verifica tecnica del banner cookie — e che cosa non dimostra

L’audit esamina la catena tecnica del consenso dalla prima richiesta della pagina fino al cambio di stato successivo alla scelta dell’utente, ma non può valutarla guardando soltanto lo stato finale, perché la sequenza iniziale di caricamento potrebbe avere già avviato un’azione che la successiva chiusura del banner non annulla. Il perimetro comprende l’ordine di caricamento degli script, le connessioni di rete, i cookie e gli altri sistemi di archiviazione, i segnali della CMP, ossia la piattaforma di gestione del consenso, la configurazione di Google Consent Mode, il funzionamento delle categorie e la possibilità di modificare in seguito la scelta; il risultato è un insieme di prove sul funzionamento di cookie e tracciamento, non un certificato che attesta la piena correttezza giuridica di ogni trattamento di dati personali dell’organizzazione.

Sul piano giuridico occorre distinguere due livelli collegati tra loro: l’articolo 5, paragrafo 3, della direttiva ePrivacy riguarda l’archiviazione di informazioni nell’apparecchiatura terminale dell’utente e l’accesso a informazioni già archiviate, e questo perimetro tecnico non si limita ai file che contengono la parola «cookie» nel nome. Il GDPR diventa rilevante quando vengono trattati dati personali e stabilisce inoltre i requisiti di validità del consenso e i principi della revoca; la verifica tecnica relativa a un quadro normativo, quindi, non sostituisce la valutazione giuridica richiesta dall’altro. Nel report di audit indichiamo separatamente i due livelli, affinché un fatto tecnico osservato non venga presentato come una conclusione giuridica più ampia.

Il Garante per la protezione dei dati personali chiarisce che gli strumenti non tecnici possono essere attivati soltanto dopo aver acquisito il consenso; un rifiuto privo di effetti, quindi, non costituisce una scelta effettiva. Neppure, però, l’etichetta di categoria «necessario» prova qualcosa da sola. L’eccezione per ciò che è strettamente necessario va interpretata in modo restrittivo: la singola operazione deve servire a trasmettere una comunicazione o a erogare un servizio della società dell’informazione esplicitamente richiesto dall’utente, non essere semplicemente utile all’analisi, al marketing o alle esigenze interne del titolare del sito; chi svolge l’audit deve quindi collegare l’operazione alla funzione che la rende necessaria e verificare, nello stesso tempo, che nella medesima categoria non sia nascosta una finalità del tutto diversa, non giustificata dalla funzione richiesta dall’utente.

L’espressione di ricerca «audit GDPR del sito web», nel nostro servizio, indica esclusivamente il perimetro di cookie, tracciamento e gestione del consenso, perché restano fuori le basi giuridiche degli altri trattamenti, le richieste degli interessati, i contratti e la governance interna. Il nostro servizio di audit dei cookie e del tracciamento fornisce i fatti tecnici con cui un avvocato o uno specialista della protezione dei dati può valutare in modo fondato proprio questa parte del sito, ma la conformità al GDPR non è un interruttore che uno scanner tecnico possa accendere per tutta l’organizzazione. Questo confine non è un modo per sottrarsi alla responsabilità: dichiara con precisione che cosa dimostra il report e quali questioni devono ancora essere valutate al di fuori dell’audit tecnico.

Come ottenere prove, non soltanto il risultato di uno scanner

Un buon test comincia con un profilo pulito del browser, privo di consensi salvati in precedenza, di cookie del sito e di richieste generate da estensioni; prima di qualsiasi clic si attiva il registro Network, si controlla la sezione Application e si documenta lo stato iniziale. La stessa sequenza di azioni viene poi ripetuta dopo il rifiuto, dopo il consenso e dopo la revoca, partendo ogni volta da uno stato documentato e conservando l’intero registro, perché altrimenti la scelta di ieri può sembrare un errore del banner di oggi oppure, al contrario, nascondere il problema reale.

Una voce nel pannello Network dimostra che il browser ha tentato di contattare un indirizzo preciso e permette di vedere l’iniziatore, lo stato, le intestazioni della richiesta e della risposta e le informazioni inviate, ma non prova ancora che un cookie sia stato memorizzato. L’intestazione di risposta Set-Cookie mostra che il server ha tentato di impostarlo; il browser può tuttavia bloccarlo, mentre JavaScript può scrivere in document.cookie o in localStorage senza quell’intestazione; il risultato effettivo va quindi controllato nella sezione Application e nessuno di questi elementi, da solo, sostituisce gli altri. Una richiesta visibile verso un dominio di analisi prova un tentativo di flusso di dati, non dimostra automaticamente che un cookie analitico sia stato impostato con successo o che il server abbia ricevuto uno specifico insieme di dati personali.

Per ogni rilievo annotiamo l’URL e il percorso dell’utente sottoposti a test, l’ora, il contesto del dispositivo e del browser, lo stato di consenso scelto, l’iniziatore e la destinazione della richiesta, l’esito dell’invio e le modifiche nello spazio di archiviazione, così da poter ripetere esattamente lo stesso test dopo la correzione. Una scansione automatica offre un ampio inventario iniziale, ma non percorre tutti i menu, le fasi di acquisto, le aree di accesso, le versioni linguistiche o le integrazioni caricate dinamicamente, né può stabilire con sicurezza la finalità partendo soltanto dal nome di un file o di un dominio; per questo le facciamo seguire da scenari manuali e da un confronto con i referenti interni degli strumenti. Chiediamo chi abbia introdotto lo strumento, per quale finalità, in quale contenitore di tag risieda e a quale segnale di consenso debba obbedire, in modo da collegare il rilievo tecnico alla configurazione prevista. Una prova senza contesto è soltanto uno screenshot; un contesto senza prova è soltanto una promessa.

1. Gli script non essenziali partono prima della scelta dell’utente

Un errore critico di sequenza si verifica quando il banner della CMP compare rapidamente, ma il tag di analisi o pubblicitario è già partito: l’utente sta ancora leggendo il testo dei pulsanti mentre il browser ha già contattato una terza parte o registrato un identificatore. Su questo punto l’indicazione del Garante è netta: i cookie non essenziali non devono essere attivati prima del consenso; la verifica tecnica parte quindi dal primo caricamento del documento, non dal momento in cui chi svolge l’audit riesce a trovare e premere «Rifiuta».

Nell’ambiente Google Tag Manager, una causa frequente è l’ordine errato degli eventi, perché lo stato di consenso predefinito deve essere impostato prima dei tag, mediante l’attivatore Inizializzazione del consenso o un’altra soluzione che garantisca lo stesso ordine, e l’aggiornamento va inviato soltanto dopo l’azione dell’utente. Se lo stato predefinito arriva troppo tardi, per un breve momento il tag può vedere uno stato non definito o salvato in precedenza e attivarsi; un banner che si chiude più in fretta non risolve questo problema di sincronizzazione, che dipende dall’ordine di esecuzione, non dall’animazione.

Nell’audit, la frase «i cookie vengono caricati prima del consenso» deve essere scomposta con maggiore precisione: potrebbe essere stato caricato lo script, eseguita una richiesta di rete, inviata una misurazione senza cookie, effettuato un tentativo di impostare Set-Cookie oppure memorizzato davvero un identificatore, e ogni azione ha un diverso valore probatorio. Con Consent Mode in modalità Advanced, alcuni tag Google possono caricarsi con l’accesso allo spazio di archiviazione negato e inviare segnali senza cookie; la sola presenza dello script, quindi, non basta a concludere né che vi sia una violazione né che vi sia conformità.

La correzione comincia da una mappa degli strumenti e da un unico modello chiaro degli stati: quali tag possono funzionare senza una scelta, quali richiedono una categoria precisa e quale evento aggiorna lo stato. Dopo la modifica della configurazione, il test viene ripetuto in un profilo pulito conservando il registro Network e osservando con particolare attenzione le prime richieste e i loro iniziatori; se l’errore compare soltanto a volte, in genere rivela un problema di sincronizzazione tra la CMP, il contenitore di tag e il codice del sito, che va eliminato correggendo l’ordine di caricamento invece di essere nascosto con un banner visivamente più rapido.

2. «Rifiuta» cambia l’interfaccia, ma non il flusso di dati

Il pulsante può chiudere il banner, mostrare la scelta come disattivata e perfino salvare il valore «denied», mentre i tag di terze parti continuano a funzionare come prima; il test del rifiuto, quindi, non consiste nel controllare se una scritta sia scomparsa, ma nel confrontare due stati. Prima e dopo il rifiuto di tutte le categorie non essenziali registriamo le richieste e lo spazio di archiviazione, poi verifichiamo che i tag interessati non ricevano un evento di attivazione, che non compaiano nuovi identificatori e che le visualizzazioni successive mantengano il rifiuto. Una sessione precedente può falsare facilmente questo test: se ieri è stato prestato il consenso, oggi la pagina può caricarsi prima con lo stato di ieri e recepire «Rifiuta» soltanto dopo, quando la prima richiesta è già partita. Anche la cancellazione manuale dei cookie tra un passaggio e l’altro produce una pulizia artificiale e non verifica il vero meccanismo di revoca; il rifiuto iniziale e la revoca successiva sono perciò scenari distinti: il primo parte senza una decisione, il secondo da un consenso prestato consapevolmente, e i loro risultati non vanno confusi in un unico screenshot.

Anche dopo il rifiuto, il sito può eseguire operazioni davvero necessarie per una funzione di sicurezza, del carrello o di altro tipo richiesta esplicitamente dall’utente; sostenere che «qualsiasi richiesta dopo il rifiuto è sbagliata» sarebbe quindi impreciso quanto il segno di spunta verde del banner. Occorre stabilire la finalità, l’iniziatore e l’operazione di archiviazione di ogni connessione rimasta, quindi configurare la CMP affinché il rifiuto aggiorni prima lo stato del consenso e i tag usino i controlli del consenso integrati o esplicitamente definiti; un pulsante funziona quando modifica in modo prevedibile, su più pagine, il flusso di dati a cui è collegato. Se il rifiuto ferma un tag pubblicitario ma conserva un cookie di sessione di prima parte, il risultato può essere quello previsto; se una categoria ne attiva un’altra di nascosto, la configurazione non è affidabile e, dopo la correzione, il rifiuto deve poter essere ripetuto su più pagine senza pulire manualmente lo spazio di archiviazione, ottenendo ogni volta uno stato identico, ripetibile e dimostrabile.

3. Le categorie e l’informativa sui cookie non corrispondono all’inventario reale

Il banner può essere tecnicamente rigoroso e risultare comunque fuorviante se le categorie o l’informativa sui cookie descrivono un altro sito, come accade dopo la copia di un modello, il subentro nella gestione di un contenitore di tag o l’aggiunta di un nuovo strumento senza aggiornare la documentazione. Nell’informativa resta allora un cookie inutilizzato da tempo, mentre non compaiono il lettore video, la finestra di chat o il tag di conversione pubblicitaria, e l’utente compie la scelta sulla base di informazioni incomplete. In questa situazione l’azienda non può spiegare quale destinatario riceva i dati, per quale finalità ciò avvenga e per quanto tempo l’identificatore venga conservato.

Il Garante lega l’informativa sui cookie all’inventario effettivo, nel quale vanno indicati finalità, fornitore o destinatario e periodo di conservazione, non soltanto ciò che il catalogo della CMP ha riconosciuto automaticamente. Un cookie con lo stesso nome può avere impieghi diversi in configurazioni differenti, mentre un identificatore personalizzato di prima parte potrebbe non avere alcuna descrizione in una banca dati pubblica; l’audit collega quindi l’oggetto tecnico alla finalità reale del titolare del sito e allo strumento che lo gestisce. Il compito dell’audit non è ricopiare l’ipotesi del catalogo, ma verificare che configurazione, destinatario e durata corrispondano a ciò che l’azienda usa davvero ed è in grado di spiegare.

L’inventario non finisce nella scheda Cookies: vanno controllati localStorage, sessionStorage, IndexedDB, i pixel e le richieste al server, oltre agli identificatori usati negli URL o nei flussi dei moduli quando partecipano al tracciamento. Le linee guida tecniche dell’EDPB chiariscono che l’ambito di applicazione della direttiva ePrivacy non è legato a una sola tecnologia di archiviazione; un’informativa che promette «non utilizziamo cookie», quindi, non dice ancora se il sito acceda con un altro metodo alle informazioni contenute nell’apparecchiatura terminale o invii segnali di misurazione. L’elenco dei nomi dei cookie è perciò l’inizio dell’inventario, non una panoramica completa delle tecnologie capaci di archiviare, leggere o inviare identificatori.

La soluzione pratica è un registro centrale che consenta di mantenere aggiornati la classificazione della CMP, la tabella tecnica dell’informativa e gli scenari di audit, indicando per ogni voce il responsabile interno dello strumento, il fornitore, la finalità, lo stato di consenso che ne determina l’attivazione, il sistema di archiviazione usato, il destinatario e la durata. L’aggiunta di un nuovo tag non è più soltanto un intervento nel contenitore di Google Tag Manager, ma una modifica controllata che, prima della pubblicazione, impone di aggiornare le informazioni fornite all’utente e i casi di test. Dopo la modifica, lo stesso registro offre un punto di partenza per ripetere la prova e indica chi, all’interno dell’azienda, è responsabile di correggere la non conformità.

4. Una richiesta nel pannello Network viene scambiata per la prova di un cookie

Vedere un dominio di analisi nel pannello Network è un rilievo importante, ma non permette da solo di concludere che «è stato impostato un cookie»: la voce prova un tentativo di connessione e mostra ciò che il browser ha aggiunto all’URL, alle intestazioni o al contenuto della richiesta, mentre una richiesta fallita, bloccata o annullata non equivale a dati ricevuti con successo dal server. Per la parte relativa ai cookie occorre controllare l’eventuale presenza di Cookie nell’intestazione della richiesta e di Set-Cookie nella risposta, verificare se il browser ne abbia bloccato l’applicazione e accertare se il cookie sia stato effettivamente salvato nello spazio di archiviazione. Una richiesta può essere bloccata o annullata prima che il server riceva i dati, e questo limite della prova deve emergere anche nella formulazione del rilievo, senza fondere in una sola affermazione il tentativo di connessione, l’esito dell’invio e la memorizzazione.

Nemmeno la conclusione opposta è sicura: una richiesta senza cookie può contenere lo stato del consenso e altri parametri, mentre il sito può usare un identificatore memorizzato in localStorage, un parametro URL o un altro metodo tecnico; l’assenza di un cookie non rende automaticamente la connessione anonima o priva di informazioni. A sua volta, Set-Cookie è un’istruzione del server al browser, non la garanzia che la voce sia stata salvata, perché il browser può rifiutarla a causa del dominio, degli attributi di sicurezza, delle restrizioni sui cookie di terze parti o di un’altra regola; un cookie proprietario impostato da JavaScript può invece comparire senza quell’intestazione di risposta. DevTools mostra anche i motivi del blocco, quindi la presenza di Set-Cookie va letta insieme alla decisione del browser e allo stato effettivo in Application. Se nella scheda Cookies non compare una nuova riga, non concludiamo che il segnale fosse «privo di dati», ma controlliamo URL, intestazioni, parametri e altri sistemi di archiviazione.

Il metodo più sicuro riunisce tre viste sulla stessa linea temporale — che cosa ha provocato la richiesta, che cosa il server ha chiesto di fare e che cosa è poi rimasto davvero memorizzato in quello specifico profilo del browser — e il report di audit nomina deliberatamente soltanto ciò che è stato dimostrato. Scriviamo «prima della scelta è stata inviata una richiesta al dominio X», «nella risposta è stato rilevato un tentativo di impostare un cookie» oppure «dopo il rifiuto, in Application era ancora presente l’identificatore Y», perché uno sviluppatore può ripetere questi passaggi, un giurista vede i limiti del fatto tecnico e il risultato può essere confrontato in modo oggettivo dopo la correzione. Non deduciamo da un solo screenshot l’intera catena del trattamento dei dati, perché lo screenshot può dimostrare soltanto l’azione, lo stato e il momento specifici che documenta.

5. La revoca del consenso è nascosta o tecnicamente incompleta

Il consenso non è un clic compiuto una volta per tutte e poi dimenticato dal sito: l’articolo 7, paragrafo 3, del GDPR riconosce all’interessato il diritto di revocare il proprio consenso in qualsiasi momento e stabilisce che il consenso sia revocato con la stessa facilità con cui è accordato, principio che anche il Garante traduce in indicazioni pratiche. Se il consenso può essere prestato nella prima schermata della home page, ma per revocarlo occorre cercare una sottosezione dell’informativa sulla privacy, scrivere un’email o cancellare i dati dalle impostazioni del browser, il meccanismo non è accessibile in condizioni equivalenti; una soluzione consueta è mantenere nel footer un link permanente per rivedere le scelte sui cookie. Ne controlliamo la reperibilità da ogni pagina e anche quando il banner non è più visibile, perché è proprio allora che l’utente cerca di cambiare la decisione precedente.

Il test tecnico parte da un consenso prestato consapevolmente e da tag realmente attivati; in seguito, chi svolge l’audit apre la gestione delle preferenze, revoca le categorie non essenziali e continua a navigare nel sito senza simulare un nuovo inizio cancellando manualmente lo spazio di archiviazione. Va verificato che la CMP invii lo stato aggiornato e che i tag lo ricevano, che non inizino nuovi flussi di dati basati sul consenso e che cosa accada agli identificatori memorizzati localmente, perché così si scopre un pulsante che salva la nuova scelta senza comunicarla ai tag già caricati. Nello stesso tempo registriamo la sequenza degli eventi di aggiornamento, per distinguere una scelta salvata correttamente da una situazione in cui il tag che dipende da quello stato riceve l’aggiornamento troppo tardi o non lo riceve affatto.

La revoca opera per il futuro e da sola non riscrive il passato né cancella tutti i dati trattati lecitamente in precedenza; deve quindi interrompere il successivo trattamento fondato su quel consenso, mentre conservare o eliminare i dati già ricevuti dal server può richiedere una valutazione distinta. Nel report di audit separiamo perciò l’interruzione dei futuri flussi di dati dalla questione della conservazione dei dati precedenti, senza promettere che un cambio tecnico delle preferenze risolva entrambe. La correzione deve unire l’interfaccia all’integrazione: il link deve essere reperibile da ogni pagina, la CMP deve mostrare lo stato attuale, la modifica deve raggiungere ogni tag interessato e il test deve essere ripetuto con più combinazioni di categorie, perché «rifiuta tutto» può funzionare mentre la disattivazione del solo interruttore della categoria marketing non produce alcun effetto. Anche la cancellazione degli identificatori dal browser va valutata in base alla loro funzione, non promessa come se un clic nella CMP potesse ripulire automaticamente il sistema di ogni terza parte.

6. Si confondono le modalità Basic e Advanced o si promettono dati modellati

Le modalità di base (Basic) e avanzata (Advanced) di Consent Mode non sono due versioni grafiche dello stesso interruttore: nella modalità di base i tag Google non vengono caricati prima del consenso e fino ad allora Google non riceve i dati di misurazione di quei tag; dopo il consenso, i tag possono cominciare la misurazione ordinaria. Nella modalità avanzata, i tag si caricano con l’accesso allo spazio di archiviazione inizialmente negato e, finché il consenso non viene prestato, possono inviare misurazioni senza cookie; questa modalità non va quindi descritta come uno stato in cui «non viene inviato nulla», né quella di base come una configurazione analitica automaticamente peggiore. La differenza sta nel comportamento effettivo dei tag prima della scelta, non nell’aspetto del banner o nel nome di un’impostazione.

La scelta deve basarsi sulla valutazione giuridica dell’azienda e sulle sue esigenze di analisi, non sull’idea che il nome di un prodotto Google risolva da solo i requisiti ePrivacy o del GDPR. La documentazione di Google sulla modalità di consenso distingue il blocco dei tag nella modalità di base dalle misurazioni senza cookie nella modalità avanzata, ma durante l’audit verifichiamo la configurazione reale: se gli stati predefiniti entrano in vigore prima dei tag, quale aggiornamento viene inviato dopo il clic e quali richieste compaiono davvero in ogni stato. Il nome commerciale di una modalità non è una conclusione giuridica; nel report descriviamo quindi il flusso verificato e la configurazione scelta dall’azienda, senza attribuirle un’etichetta automatica di conformità.

«Senza cookie» non significa «senza informazioni», quindi nel report il nome di un segnale non può sostituire la valutazione del suo contenuto e della sua finalità. Nel pannello Network vanno esaminati la destinazione, i parametri, lo stato del consenso e l’iniziatore, mentre Google Tag Assistant o gli strumenti di debug di Consent Mode aiutano a controllare gli stati predefiniti e quelli aggiornati; le due viste si completano, perché la prima rivela il flusso di dati del singolo tentativo e la seconda la logica della configurazione. Se non coincidono, non si dà ragione alla schermata più gradevole: occorre trovare il punto in cui il comando che imposta lo stato predefinito o l’evento di aggiornamento non ha raggiunto il tag nell’ordine previsto.

Neppure i dati modellati sono un risultato garantito dall’attivazione della modalità avanzata, perché la creazione di modelli di comportamento in Google Analytics 4 dipende dai requisiti fissati da Google per la proprietà, il volume e la qualità dei dati, e la funzione può non essere disponibile o scomparire se tali requisiti non sono più soddisfatti. La creazione di modelli non ricostruisce le sessioni dei singoli utenti che hanno rifiutato; nell’offerta promettiamo quindi una configurazione corretta e una sequenza verificabile dei segnali, non una quantità determinata di dati modellati, che dipende dal sistema di Google e dall’idoneità della proprietà interessata. Il risultato dell’audit è pertanto una configurazione riproducibile e una verifica dei segnali, non una promessa sulla quantità di dati che il fornitore del servizio non controlla.

7. Il test si ferma alla prima pagina e al primo giorno

La home page copre raramente l’intero inventario del tracciamento: un tag video può caricarsi soltanto dopo aver premuto «Riproduci»; l’integrazione di una mappa può attivarsi soltanto nella pagina dei contatti; un tag di conversione pubblicitaria può partire dopo l’invio di un modulo; lo strumento di pagamento può comparire nell’ultimo passaggio del carrello; uno script di chat o personalizzazione può caricarsi dopo un certo intervallo. Chi svolge l’audit aprendo un solo URL, aspettando pochi secondi e chiudendo lo scanner può redigere un report tecnicamente corretto per quella vista e, nello stesso tempo, pericolosamente incompleto per il sito nel suo insieme. Ciascuno di questi stati va riprodotto attraverso l’azione che lo attiva davvero, senza presumere che l’inventario della home page rappresenti automaticamente tutti i modelli e i percorsi degli utenti.

Costruiamo gli scenari sui percorsi reali degli utenti e sui modelli del sito, includendo una pagina pubblica, un articolo, il modulo di contatto, l’area account, il processo di acquisto, i contenuti incorporati e ogni versione rilevante per lingua o regione; controlliamo anche il layout mobile, nel quale i pulsanti della CMP possono sovrapporsi o il link alle preferenze diventare irraggiungibile, benché sul desktop tutto funzioni. Una scansione automatica amplia la copertura, mentre uno scenario manuale riproduce gli stati che un robot privo di account, clic o dati inseriti non vedrà mai. Le versioni linguistiche e regionali, come il layout mobile, non sono duplicati decorativi quando modificano il caricamento delle integrazioni o le opzioni disponibili per l’utente.

Un audit una tantum non copre i cambiamenti successivi: un nuovo tag di marketing, un modello modificato della CMP o un contenitore di Google Tag Manager importato possono compromettere una sequenza prima corretta senza produrre modifiche visibili nel banner; ogni nuovo strumento richiede perciò un test prima della pubblicazione e un confronto successivo. È una disciplina che conviene prevedere già nel contratto di realizzazione del sito, come abbiamo spiegato nell’articolo sui 10 errori da evitare nella realizzazione di un sito web; nel nostro processo di audit effettuiamo una nuova scansione a 30 e 180 giorni dall’implementazione, usando gli stessi scenari e campi di prova per verificare se la correzione resti efficace nel normale lavoro di pubblicazione e se siano comparsi nuovi strumenti o scostamenti di configurazione. La prima scadenza mostra se l’implementazione ha retto al lavoro quotidiano, la seconda intercetta i cambiamenti successivi; a ogni ripetizione confrontiamo la singola richiesta, lo spazio di archiviazione e lo stato del consenso con il rilievo iniziale, senza limitarci all’impressione che «adesso sembri andare meglio».

Che cosa riceve con un audit tecnico di cookie e tracciamento

Il primo risultato dell’audit è un inventario verificato di cookie, sistemi di archiviazione, tag e richieste a terze parti, nel quale ogni rilievo è collegato a una pagina, a un’azione dell’utente e a uno stato del consenso; accanto compaiono la prova e il suo limite: una voce Network, un tentativo di Set-Cookie, un cookie davvero presente in Application, una voce di localStorage o un evento della CMP. Lo sviluppatore riceve così un errore riproducibile, non una nota vaga come «sistemare il GDPR», mentre chi è responsabile della privacy vede quali fatti richiedano ancora una decisione giuridica. Per ogni rilievo resta inoltre la procedura per ripetere il test, così dopo l’implementazione si possono riprodurre esattamente la stessa pagina e la stessa scelta, controllando la medesima richiesta e il relativo risultato nello spazio di archiviazione.

La seconda parte è l’implementazione: sistemiamo le categorie della CMP e la sequenza degli stati predefiniti e degli aggiornamenti in Google Tag Manager, configuriamo i controlli del consenso per Google Analytics 4, Google Ads, Meta Pixel e gli altri strumenti e prepariamo i testi della dichiarazione sui cookie e dell’informativa sulla privacy. Scegliamo la modalità di base (Basic) o avanzata (Advanced) di Consent Mode in base alla Sua valutazione giuridica e alle Sue esigenze di analisi, senza presentare Advanced come l’opzione giusta in ogni caso né promettere dati modellati quando la specifica proprietà Google Analytics 4 non soddisfa le condizioni previste. Verifichiamo il risultato dell’implementazione negli stessi stati di consenso in cui è stato registrato il rilievo iniziale, così da fondare la modifica della configurazione su prove confrontabili.

Il prezzo del servizio è a partire da 800 € e il lavoro richiede 1–4 settimane, a seconda delle dimensioni del sito, del numero di lingue e modelli, della complessità della CMP e dei contenitori di tag e del numero di integrazioni necessarie. Prima di iniziare distinguiamo con chiarezza, nel prezzo e nel calendario, le evidenze dell’audit, le correzioni tecniche e le questioni che devono essere decise dall’avvocato o dallo specialista della protezione dei dati dell’azienda; a 30 e 180 giorni ripetiamo la scansione sugli scenari stabiliti. Prezzo e scadenza si riferiscono così a un perimetro tecnico definito, non alla promessa indeterminata di sistemare l’intera protezione dei dati dell’azienda.

Se Le serve un «audit GDPR del sito web», concordiamo anzitutto sul fatto che qui l’espressione indica il perimetro di cookie, tracciamento, CMP e Consent Mode, non una verifica completa della conformità al GDPR dell’intera organizzazione; promettiamo quindi soltanto ciò che possiamo dimostrare tecnicamente: il comportamento del sito prima della scelta, dopo il rifiuto, dopo il consenso e dopo la revoca, i segnali inviati agli strumenti e i punti in cui la prova non basta ancora a una conclusione giuridica. Questa distinzione consente di chiudere il lavoro tecnico con un risultato verificabile e affidare le questioni giuridiche a chi risponde del trattamento più ampio dei dati personali. Può richiedere un audit dei cookie e del tracciamento inviandoci l’indirizzo del sito e il nome della CMP o del gestore dei tag che utilizza.