La Consent Mode v2 ha smesso di essere facoltativa il 06-03-2024. Da quella data, il traffico UE e SEE verso i prodotti pubblicitari di Google ha dovuto trasmettere due nuovi segnali — ad_user_data e ad_personalization — insieme agli originali ad_storage e analytics_storage. Il cambiamento non è stato guidato dal GDPR ma dal Digital Markets Act (Regolamento (UE) 2022/1925), e specificamente dall'Art. 5(2) del DMA, che vieta ai gatekeeper designati di combinare o utilizzare dati personali incrociati tra i servizi senza un consenso esplicito.
Per un abbreviatore di URL che interseca il piano dati del redirect in modi complessi, la situazione è delicata. Un link breve è ciò su cui l'utente ha cliccato; lo stato del consenso sulla landing page decide se il clic può essere attribuito. Questi due eventi accadono su domini diversi, in diversi contenitori di cookie, spesso in sessioni diverse. Il divario tra loro è il luogo in cui risiede ora la maggior parte della perdita di attribuzione.
Questo post è la lettura di un consulente legale operativo sulla conformità riguardo a ciò che è cambiato, cosa significano effettivamente i quattro segnali per un servizio di redirect, dove il recupero server-side è legale secondo le attuali linee guida dell'EDPB e dove non lo è. Gran parte del lavoro di ingegneria per il tracciamento server-side tramite redirect va bene sotto il GDPR; parte di esso non va bene sotto il DMA.
Il DMA, in un paragrafo#
Il Digital Markets Act è diventato applicabile il 07-03-2024. Esso designa i "gatekeeper" — Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft, Booking — e impone loro obblighi ex ante. L'Art. 5(2) del DMA è quello che conta per il tracciamento: un gatekeeper non può trattare i dati personali degli utenti finali di servizi di terze parti per la pubblicità online, né combinare dati personali tra i suoi servizi, senza consenso.
La Consent Mode v2 è il meccanismo di conformità di Google per l'Art. 5(2). I due nuovi segnali — ad_user_data e ad_personalization — permettono al gatekeeper di osservare se l'editore ha ottenuto un consenso conforme all'Art. 5(2) prima che la telemetria dei clic venga utilizzata per la pubblicità o la personalizzazione. Senza questi segnali impostati su granted, i prodotti pubblicitari di Google ripiegano su conversioni aggregate o modellate senza attribuzione per singolo utente.
Il DMA non sostituisce il GDPR. Si aggiunge ad esso. Un titolare del trattamento ha ancora bisogno di una base giuridica ex Art. 6 del GDPR; la Consent Mode v2 aggiunge un secondo cancello che si chiude per i dati pubblicitari instradati tramite gatekeeper anche quando il cancello del GDPR è aperto.
I quattro segnali, in termini semplici#
La Consent Mode v2 invia quattro segnali booleani. Ognuno può essere granted (concesso) o denied (negato). I valori predefiniti possono essere impostati per regione.
ad_storage — il segnale originale della v1. Controlla se i cookie o altri sistemi di archiviazione vengono scritti per scopi pubblicitari. Quando è denied, i tag di Google si attivano senza identificatori; la misurazione delle conversioni degrada ad aggregati modellati senza cookie. Il redirect decide quali UTM e identificatori di clic arrivano sulla pagina, e quelli diventano le chiavi a cui si aggancia il consenso. La documentazione sul consenso della tag-platform è il riferimento canonico per ciò che ogni segnale fa a valle.
ad_user_data — nuovo nella v2. Controlla se i dati utente possono essere inviati a Google per la pubblicità in generale. Questo è il segnale dell'Art. 5(2) del DMA. Quando è denied, il tag non può trasmettere dati utente — inclusi identificatori sottoposti a hash, IP, user-agent — a Google Ads. Il tagging server-side non aggira questo limite; il segnale viaggia con l'evento.
ad_personalization — anch'esso nuovo. Controlla se i dati trasmessi possono essere utilizzati per la pubblicità personalizzata, incluso il remarketing. Una configurazione comune è ad_user_data=granted più ad_personalization=denied, che permette l'attribuzione ma blocca il remarketing.
analytics_storage — controlla se l'archiviazione viene scritta per scopi analitici. Il tag di GA4 rispetta questo segnale; quando è denied, GA4 funziona senza cookie e utilizza la modellazione della consent-mode per ricostruire l'attribuzione a livello aggregato. La modellazione richiede un volume minimo di traffico e un periodo di apprendimento di 7 giorni.
Nessuno dei quattro segnali viene deciso a livello dell'abbreviatore. L'abbreviatore emette il clic; la landing page legge i segnali; il tag sulla landing page decide cosa farne. Il compito dell'abbreviatore è fornire uno stato pulito — UTM preservati, identificatore di clic preservato, redirect veloce — in modo che il banner possa risolversi prima che il tag si attivi.
Cosa va storto nel piano dati del redirect#
Tre modalità di errore si presentano in ogni abbreviatore che prende seriamente il percorso del redirect.
L'identificatore del clic sopravvive ma il segnale di consenso no. Un clic su un annuncio Meta colpisce s.elido.me/abc123?fbclid=… e reindirizza a https://customer.example/landing?fbclid=…. Il fbclid viene preservato. La pagina si carica, appare il banner, l'utente nega il consenso. La CAPI di Meta ha già ricevuto un clic associato a quel fbclid — ma l'utente ha ora negato l'uso pubblicitario. L'abbreviatore non ha fatto nulla di male; il titolare del trattamento ha un problema di deduplicazione della CAPI da risolvere sul proprio endpoint.
L'abbreviatore aggiunge identificatori che la landing page non comprende. Alcuni abbreviatori (il bitly_session di Bitly, il _branch_match_id di Rebrandly) aggiungono parametri specifici del fornitore che necessitano di rimozione o gestione speciale in caso di consenso negato. Elido inoltra solo gli UTM e l'identificatore di clic del cliente stesso.
Lo stato del consenso della landing page è inconoscibile dal punto di osservazione del redirect. L'abbreviatore non può vedere un banner che non si è ancora caricato. Le decisioni di fallback server-side non possono essere condizionate da uno stato di consenso che non esiste ancora. L'unica impostazione predefinita onesta: non attivare alcun evento server-side per scopi pubblicitari al momento del redirect; lasciare che il banner si risolva, quindi lasciare che la pagina o il suo proxy si attivino con lo stato del consenso allegato.
I fornitori che attivano eventi Measurement Protocol o CAPI direttamente dall'edge scommettono che l'utente concederà il consenso. Secondo l'Art. 5(2) del DMA, quella scommessa non spetta a loro. Le Linee guida EDPB 02/2023 sull'ambito tecnico dell'Articolo 5(3) della direttiva ePrivacy hanno sottolineato il punto correlato sull'iniezione di identificatori pre-consenso: si tratta di un trattamento, necessita di una base, e l'assenza di un banner non è una base.
Mitigazioni server-side legali#
Le mitigazioni seguenti sono quelle che reggono sia sotto il GDPR che sotto il DMA. Condividono un filo comune: lo stato del consenso deve essere osservato prima che qualsiasi dato venga trasmesso a un gatekeeper o utilizzato per la pubblicità.
Measurement Protocol con stato del consenso allegato. Il Measurement Protocol di GA4 accetta gli stessi parametri di consent del client gtag. Il pattern: la landing page risolve il banner, invia lo stato del consenso al server di prima parte del cliente, e il server di prima parte inoltra una richiesta mp/collect a GA4 con consent.ad_user_data e consent.ad_personalization impostati. È server-side, ma a valle della risoluzione del consenso. L'inoltro di Elido (trattato in tracciamento server-side di GA4 tramite redirect) applica lo stato del consenso al payload in uscita.
Conversion API con stringhe di consenso. La CAPI di Meta accetta data_processing_options e opt_out; la Conversions API di LinkedIn accetta enlli; la Events API di TikTok accetta limited_data_use. Tutte segnalano lo stato del consenso alla piattaforma. Il pattern è identico: la landing page si risolve, invia al server di prima parte, il server di prima parte attiva l'invio con lo stato del consenso allegato.
Reportistica server-side aggregata. Laddove lo stato del consenso nega l'uso pubblicitario o analitico, una reportistica server-side che sia realmente aggregata e priva di identificatori per singolo utente è generalmente accettabile secondo l'Art. 5(2) del DMA e secondo l'Art. 6 del GDPR sulla base del legittimo interesse. Le Linee guida 04/2023 dell'EDPB sull'anonimizzazione ribadiscono che i dati pseudonimizzati non sono anonimi e che una bassa k-anonimity permette ancora la re-identificazione. La pratica prudente è pubblicare i conteggi a livello di workspace con una soglia ≥10.
Risoluzione dell'identificatore di prima parte sulla landing page. L'approccio più resiliente consiste nell'identificare l'utente tramite un segnale ex Art. 6(1)(b) del GDPR — ha effettuato l'accesso, ha completato un modulo, ha cliccato su un link di conferma email — e attribuire a ritroso. Questo non dipende affatto da ad_storage o ad_user_data. Il post attribuzione del clic dopo Safari ITP copre questo pattern; è la risposta giusta anche per il mondo post-DMA.
Mitigazioni server-side non legali#
Tre pattern appaiono spesso nelle proposte dei fornitori di strumenti e non dovrebbero.
Attivazione di eventi CAPI dall'edge prima che il consenso della landing page sia risolto. Questa è la modalità di errore descritta sopra. Non c'è uno stato di consenso da allegare; attivare l'evento implica che il titolare del trattamento abbia ottenuto il consenso, cosa che non è avvenuta. Alcuni fornitori descrivono questo come "attribuzione deterministica"; secondo l'Art. 5(2) del DMA, si tratta di un'operazione di combinazione di dati che l'utente non ha autorizzato.
Hashing dell'IP e trattamento dell'hash come anonimo. L'EDPB è stato chiaro fin dal Parere 4/2007 sul concetto di dati personali e lo ha ribadito nelle Linee Guida 04/2023: gli identificatori sottoposti a hash rimangono dati personali quando l'hash è reversibile da chiunque abbia accesso alla popolazione. Gli hash degli IP sono facilmente reversibili su larga scala; l'hash non cambia la natura giuridica del trattamento.
Sincronizzazione degli identificatori server-side con i gatekeeper. Inoltrare l'evento del clic a Google o Meta con un'email o un numero di telefono sottoposti a hash, e affidarsi al gatekeeper affinché lo abbini al proprio grafo di identificatori, è l'operazione che l'Art. 5(2) del DMA limita specificamente. L'abbinamento è una combinazione di dati tra servizi effettuata dal gatekeeper. Il consenso deve essere esplicito e a livello di utente. La presenza dell'hash non rende l'operazione lecita; l'assenza di consenso la rende illecita.
Recente contesto CGUE ed EDPB#
Due recenti mosse dei regolatori rendono il quadro più nitido.
La sentenza della CGUE nella Causa C-621/22 (Royal Lichtervelde, 2024) ha ribadito l'analisi sulla contitolarità del trattamento già emersa in Wirtschaftsakademie (C-210/16) e Fashion ID (C-40/17). Quando un editore integra un tag di terze parti e quel tag trasmette dati utente alla terza parte, l'editore e la terza parte sono contitolari per quel trattamento. L'Art. 26 del GDPR richiede un accordo trasparente tra loro. Per un cliente della Consent Mode v2, l'accordo ex Art. 26 con Google deve essere in atto e lo stato del consenso deve fluire onestamente. Falsificare ad_user_data=granted per recuperare l'attribuzione comporta una responsabilità in solido per entrambe le parti.
Le Linee guida 03/2024 dell'EDPB sui segnali di consenso in contesti pubblicitari (bozza di consultazione, finale prevista per il Q3 2026) affrontano esplicitamente la Consent Mode v2. La bozza sostiene che il segnale ad_user_data è, ai sensi dell'Art. 7(4) del GDPR, condizionato a un consenso liberamente fornito, e che i banner che raggruppano ad_storage con ad_user_data senza controlli granulari falliscono il test del consenso libero ex Art. 7. La maggior parte dei banner attuali li raggruppa. Il nuovo design spetta al cliente; l'abbreviatore espone uno stato pulito, non progetta il banner.
Per quanto riguarda il quadro più ampio dell'impatto dei trasferimenti — consenso concesso, ma i dati lasciano comunque l'UE — il post Schrems II e i pixel di tracciamento copre l'aspetto della TIA (Transfer Impact Assessment). Il DMA non risolve quel problema; aggiunge un altro vincolo.
Cosa Elido fa (e non fa) a livello di redirect#
Elido è il responsabile del trattamento; il titolare decide l'approccio al consenso e gestisce il banner. Il piano dati del redirect fa il minimo indispensabile:
- Preserva gli UTM e l'identificatore di clic del cliente. Gli identificatori pubblicitari specifici del fornitore (
fbclid,gclid,msclkid,ttclid) vengono inoltrati per impostazione predefinita perché rappresentano la superficie di attribuzione del titolare; è disponibile l'opt-out per singolo workspace. - Non attiva alcun evento pubblicitario server-side al momento del redirect. L'evento di clic interno scritto in ClickHouse ha l'IP troncato a /24 o /48 e solo campi del dispositivo analizzati, secondo la minimizzazione dei dati del GDPR. Non viene condiviso con terze parti.
- Supporta l'inoltro delle conversioni server-side consapevole del consenso a GA4, Meta CAPI, LinkedIn, TikTok e Reddit, filtrato dallo stato del consenso fornito dalla landing page. L'inoltro risiede in
/features/conversion-tracking; la configurazione è nella guida alla documentazione del tracciamento delle conversioni. - Richiede un payload
consentdalla landing page quando l'inoltro consapevole del consenso è abilitato; in assenza del payload, l'evento viene scartato, non inviato silenziosamente con valori predefiniti.
La dashboard analitica in /features/analytics mostra la suddivisione dello stato del consenso per campagna — concesso, negato, non impostato — in modo che il team marketing possa vedere quanta attribuzione viene persa a causa dei rifiuti.
Cosa Elido non fa: implementare il banner, decidere preventivamente il consenso o onorare un consenso concesso per utenti che non lo hanno effettivamente fornito. Queste decisioni spettano al titolare del trattamento, come stabilito sia dal GDPR che dal DMA.
La questione del procurement#
Per un titolare del trattamento che valuta un abbreviatore sotto l'Art. 5(2) del DMA, ecco tre domande.
L'abbreviatore inoltra dati di clic a servizi pubblicitari o analitici di terze parti al momento del redirect, indipendentemente dallo stato del consenso della landing page? Se sì, si tratta di un'esposizione all'Art. 5(2) del DMA da terminare.
L'abbreviatore supporta l'inoltro dello stato del consenso ai suoi endpoint di conversione server-side? In caso negativo, il titolare avrà bisogno di un proxy di tagging server-side separato (container server GTM, Stape, Snowplow) tra la landing page e le API del gatekeeper.
Il livello analitico dell'abbreviatore condivide dati aggregati con terze parti? Alcuni strumenti orientati al marketing pubblicano "benchmark di settore" che si rivelano essere dati di clic dei clienti con sottografi identificabili dalla forma del traffico — qual è l'analisi della contitolarità secondo Wirtschaftsakademie e Fashion ID?
Un abbreviatore che è ambiguo su uno di questi punti aggiunge una superficie di rischio DMA che il titolare dovrà difendere in sede di audit.
Dove ci porta tutto questo#
La Consent Mode v2 non è un'iniziativa di marketing. È un meccanismo di conformità per l'Art. 5(2) del DMA distribuito tramite la piattaforma tag di Google. I quattro segnali dicono la verità su quale consenso è stato ottenuto; le mitigazioni server-side funzionano quando lo stato del consenso viaggia con l'evento; la perdita di attribuzione in un mondo con consenso negato è reale ma inferiore a quanto sembri una volta che la risoluzione dell'identificatore di prima parte è attiva. L'abbreviatore fornisce uno stato pulito attraverso il redirect ed espone l'inoltro consapevole del consenso che il titolare collega al proprio banner.
Le linee guida dell'EDPB previste per il Q3 2026 alzeranno l'asticella. Progettare solo per l'asticella attuale è poco lungimirante; progettare per ciò che l'Art. 5(2) intende — un consenso esplicito, granulare e liberamente fornito per la combinazione di dati tra servizi — è la posizione che sopravviverà alla prossima ondata di sanzioni.
Letture correlate#
- GDPR per gli abbreviatori di URL: cosa vuole vedere davvero il tuo DPO — il pilastro per il cluster della conformità.
- Attribuzione del clic dopo Safari ITP — la storia parallela della perdita di attribuzione lato browser.
- Spiegazione dell'attribuzione senza cookie — pattern di identificatori di prima parte che sopravvivono al consenso negato.
- Tracciamento server-side di GA4 tramite redirect — la struttura del Measurement Protocol su cui poggia l'inoltro del consenso.
- Schrems II e i pixel di tracciamento — cosa succede ai dati dopo che hanno attraversato l'Atlantico.
- Funzionalità prodotto:
/features/analyticsper la visualizzazione della suddivisione dello stato del consenso. - Guida operativa: la guida alla documentazione del tracciamento delle conversioni per la configurazione dell'inoltro consapevole del consenso.