Tracking pre-consenso: cos'è e perché le autorità lo trattano come una violazione

Il tracking pre-consenso è una categoria di rilevamento del nostro scanner. Si attiva quando, tra l'inizio di un nuovo caricamento di pagina e il momento in cui l'utente compie un'azione qualsiasi sul banner di consenso, il browser invia una o più richieste di rete che trasportano identificatori, contengono payload analitici non essenziali o impostano cookie non essenziali.

È il difetto più frequente che rileviamo. Nella nostra scansione di 97.000 siti dell'UE, la maggior parte delle classificazioni ad alto rischio è stata determinata dal tracking pre-consenso, non dall'assenza di banner né da pulsanti di rifiuto difettosi.

Cosa cerca lo scanner

Il rilevatore osserva la rete dal momento in cui il browser emette la richiesta del documento fino a uno di tre eventi:

1. L'utente fa clic su un pulsante del banner di consenso (accetta, rifiuta, impostazioni).
2. Viene scritto un cookie o una voce di localStorage misurabile relativi allo stato di consenso.
3. Scade un timeout (8 secondi per impostazione predefinita) senza alcun segnale di consenso.

Ogni richiesta che si attiva in quella finestra viene esaminata in cerca di tre segnali:

• Impronta nota di tracker. Il dominio di destinazione, il percorso della richiesta o il pattern del payload corrispondono a una voce nel nostro database di tracker. Sono inclusi Google Analytics, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, i pixel di conversione di X e molti altri.
• Payload con identificatore. La richiesta trasporta un identificatore client stabile (cookie, hash di fingerprinting o parametro di query che persiste tra le pagine).
• Scrittura di cookie non essenziale. La risposta imposta un cookie che, per classificazione, non è strettamente necessario per il funzionamento del sito.

Uno solo di questi è sufficiente ad attivare il rilevamento. Tutti e tre insieme costituiscono il pattern tipico di un container di Google Tag Manager che si attiva prima del gate di consenso.

Il quadro giuridico, in breve

Non siamo il vostro avvocato. I fatti essenziali:

• GDPR Art. 6(1)(a) richiede una valida base giuridica per il trattamento dei dati personali. Per i tracker non essenziali, è il consenso.
• GDPR Art. 7 stabilisce lo standard di un consenso valido: libero, specifico, informato, inequivocabile e revocabile.
• ePrivacy Directive Art. 5(3) richiede specificamente il consenso prima di archiviare informazioni o accedere a informazioni nelle apparecchiature terminali dell'utente — cioè prima di leggere o scrivere cookie e identificatori analoghi. Se una specifica richiesta di rete pre-consenso si traduca in una violazione dipende dal fatto che essa legga o scriva informazioni sul dispositivo, dal fatto che trasporti identificatori e dal fatto che possa essere giustificata come "strettamente necessaria" — sono le domande che le autorità stanno valutando.

Le trasposizioni nazionali differiscono nei dettagli. Il TTDSG tedesco (ora TDDDG) e la trasposizione francese tramite la Loi Informatique et Libertés, applicata dalla CNIL, hanno prodotto la prassi sanzionatoria più visibile. Le DPAs di tutta l'UE hanno messo in guardia sui pattern di tracking pre-consenso; le specifiche soglie di intervento variano per giurisdizione. Il principio di fondo è ovunque lo stesso: prima il consenso, poi il tracker.

Cosa hanno effettivamente fatto le autorità

Una breve cronologia parziale di decisioni in cui il tracking pre-consenso è stato il rilevamento centrale:

• CNIL contro Google (dicembre 2020): 100 milioni di EUR per aver collocato cookie pubblicitari su google.fr senza consenso preventivo.
• CNIL contro Amazon Europe Core (dicembre 2020): 35 milioni di EUR per lo stesso pattern su amazon.fr.

Non sono i soli casi: sono quelli portanti. Il pattern tra di essi è coerente: l'autorità ha misurato il comportamento di rete e ha trattato la realtà tecnica come dirimente, indipendentemente dal testo delle policy.

Gli script che più spesso ne sono causa

Approssimativamente nell'ordine in cui li vediamo come causa principale di una scansione ad alto rischio:

• Container di Google Tag Manager configurati senza gating del consent mode, oppure con consent mode mal configurato in modo che lo stato predefinito sia "granted".
• Meta Pixel caricato direttamente tramite <script src> invece di essere bloccato dietro una callback di consenso.
• Registrazione delle sessioni di Hotjar avviata prima della chiusura del banner.
• LinkedIn Insight per il retargeting B2B, in particolare su siti di agenzie e SaaS.
• TikTok Pixel sull'e-commerce consumer.
• Implementazioni di analytics first-party che leggono proprietà di navigator o impostano cookie di fingerprinting prima di qualsiasi azione utente.

Il fattore comune non è quasi mai lo script in sé: è il deployment. Ognuno di questi fornitori pubblica un modo documentato per condizionare l'attivazione a un segnale di consenso; tuttavia, le istruzioni di installazione predefinite spesso non lo menzionano.

Come si presenta una scansione pulita

Un sito che supera il nostro controllo pre-consenso fa una di queste cose:

1. Non carica alcun tracking di terze parti finché non viene prestato il consenso. I cookie funzionali (sessione, preferenza di lingua, CSRF) vanno bene.
2. Carica il tag manager in stato "denied", con tutti i tag non essenziali bloccati dietro segnali di consenso espliciti, e aggiorna lo stato tramite Google Consent Mode v2 o un meccanismo equivalente dopo l'azione dell'utente.
3. Carica stub di tracker che non trasmettono identificatori finché non è impostato il flag di consenso.

Nel nostro corpus del primo trimestre 2026 di 97.000 siti UE, il 68% aveva un servizio di tracking attivo prima di qualunque decisione di consenso. La minoranza dei siti che supera il controllo pre-consenso tende a condividere un profilo: la rete nella finestra pre-consenso è dominata dal documento stesso, dai file CSS e dai font e da una favicon — nulla che porti un identificatore via dal dispositivo.

Come correggerlo

La versione onesta: non ci sono scorciatoie. Ogni tag deve essere verificato per stabilire se si attiva prima che il segnale di consenso sia impostato. Passi che funzionano nella pratica:

1. Aprite il sito in un profilo di browser pulito con i dev tools aperti.
2. Filtrate la rete su "terze parti" e ricaricate.
3. Tutto ciò che si attiva prima che facciate clic su un pulsante del banner è un candidato.
4. Per ogni candidato, individuate il loader (di norma un tag script, un trigger del tag manager o uno snippet inline) e condizionatelo al segnale di consenso.
5. Riprovate. Ripetete finché la finestra pre-consenso non è priva di tracker.

Se utilizzate una piattaforma di gestione del consenso, la sua modalità "blocca fino al consenso" è necessaria ma non sufficiente: molti CMP bloccano solo la scrittura del cookie, non la richiesta. L'Article 5(3) della ePrivacy Directive richiede il consenso prima di archiviare informazioni o accedere a informazioni nel dispositivo dell'utente (cookie, local storage, identificatori analoghi). Se una specifica richiesta di rete pre-consenso faccia scattare quell'obbligo dipende da cosa la richiesta legge dal dispositivo o vi scrive — una questione di fatto.

Per un esempio concreto sul vostro dominio, eseguite una scansione e guardate il pannello "rete pre-consenso" del report. Ogni richiesta segnalata viene elencata con il suo stack di iniziatore, così da poterla risalire fino al file sorgente nel vostro codice.