La versione breve

TCF v2.3 è un'evoluzione della v2.2, non una ri‑architettura. Il formato della TC String è compatibile, le finalità (purposes) e le funzionalità esistenti sono preservate e la maggior parte dei requisiti di interfaccia verso i publisher rimane invariata. I cambiamenti sostanziali si concentrano in quattro aree:

• Regole più chiare su come i CMP devono presentare le informazioni sui vendor e i periodi di conservazione.
• Nuovi requisiti per controlli granulari nel secondo livello che i regolatori richiedono fin dalla decisione dell'autorità belga del 2022.
• Maggiore rigore nell'enforcement delle policy su dark pattern, pari evidenza e opzioni preselezionate.
• Aggiustamenti allo schema della Global Vendor List (GVL) e al flusso di disclosure dei vendor.

Perché esiste la v2.3

Ogni versione del TCF è una negoziazione tra tre pubblici: i publisher che devono continuare a monetizzare, i vendor che hanno bisogno di un'interfaccia tecnica stabile e i regolatori che continuano a individuare specifici gap di conformità. La v2.3 è una risposta diretta a tre pressioni:

1. Azioni di enforcement contro l'abuso di "legittimo interesse" sotto la v2.2. Diverse autorità europee per la protezione dei dati hanno stabilito che troppi vendor rivendicavano il LI per finalità per le quali l'unica base giuridica lecita era il consenso. La v2.3 rende più stringenti le disclosure sulla base giuridica dichiarata dai vendor e le porta più in evidenza nell'interfaccia di consenso.
2. Reclami continui sui dark pattern. Le Policies aggiornate rendono la regola della pari evidenza più esplicita e chiudono le scappatoie relative alle opzioni preselezionate nel secondo livello.
3. Feedback operativo da grandi CMP e publisher. La v2.2 ha introdotto diverse disclosure obbligatorie difficili da implementare in modo pulito su mobile e CTV. La v2.3 semplifica il set di informazioni obbligatorie e consente che una parte maggiore viva in una vista a livelli.

Compatibilità della TC String

La TC String in sé rimane retro‑compatibile. Un CMP v2.3 produce stringhe che i vendor v2.2 possono leggere, e un vendor v2.3 può consumare stringhe v2.2 durante il periodo di transizione. L'indicatore di versione nel segmento core della stringa identifica con quale versione di policy il CMP dichiara di essere conforme, mentre il puntatore alla versione GVL avanza indipendentemente.

Cosa significa in pratica: non è necessario aggiornare tutti i vendor nello stesso momento e non è necessario forzare un nuovo evento di consenso per ogni utente il giorno in cui si distribuisce la v2.3. Un rollout graduale è esplicitamente supportato.

Cambiamenti tecnici chiave

1. Vendor disclosure e conservazione

La v2.3 richiede che i CMP rendano visibile il periodo di conservazione dei dati dichiarato da ciascun vendor nell'interfaccia a livelli, non solo in un elenco vendor separato. Il valore di conservazione è sempre stato parte della GVL, ma la v2.2 non imponeva che gli utenti lo vedessero insieme alle finalità. La v2.3 colma questo gap perché i regolatori hanno sostenuto che gli utenti non possono compiere una scelta informata senza sapere per quanto tempo i loro dati saranno conservati.

2. Controlli più rigorosi nel secondo livello

Nel secondo livello — la vista "gestisci preferenze" — la v2.3 stabilisce esplicitamente che gli interruttori per finalità e vendor non essenziali devono essere impostati di default su off. Caselle preselezionate o slider pre‑abilitati costituiscono una violazione delle policy anche se l'utente non clicca mai esplicitamente su "accetta". I CMP che finora si sono basati su un pattern di "soft opt‑in" dovranno ri‑renderizzare il secondo livello.

3. Enforcement della pari evidenza

La regola della pari evidenza esiste dalla v2.1, ma la v2.3 la definisce con minore margine di interpretazione: il controllo "rifiuta tutto" deve trovarsi sullo stesso livello, avere lo stesso peso visivo, la stessa classe di contrasto cromatico e la stessa distanza di interazione di "accetta tutto". Nascondere il rifiuto dietro un link, un pulsante più piccolo o una schermata secondaria è ora un fallimento di conformità esplicito, non più una valutazione discrezionale.

4. Segnalazione del legittimo interesse

I vendor che dichiarano il legittimo interesse come base giuridica lecita sotto la v2.3 devono ora anche dichiarare per quali finalità hanno effettuato una valutazione di legittimo interesse (LIA) e per quali l'hanno completata. I CMP sono tenuti a trasmettere questa dichiarazione all'interfaccia utente, in modo che gli utenti possano opporsi con piena informazione. In pratica ciò significa che il flusso di "opposizione" mostra ora lo stato LIA specifico per vendor, invece di un semplice interruttore generico.

5. Aggiornamenti dello schema GVL

Lo schema della Global Vendor List aggiunge campi per la granularità della conservazione, lo stato LIA e un link machine‑readable alla sezione dell'informativa privacy di ciascun vendor relativa alle finalità dichiarate. I CMP che mettono in cache la GVL devono aggiornare il parser dello schema per comprendere i nuovi campi prima di puntare a una GVL v2.3.

Cambiamenti di policy che impattano la UX

Il TCF è sia una specifica tecnica sia un insieme di Policies. Diversi cambiamenti di policy nella v2.3 impattano direttamente sull'interfaccia di consenso:

• Basta usare "continua senza accettare" come equivalente del rifiuto a meno che non corrisponda visivamente al pulsante di accettazione e non produca la stessa TC String che produrrebbe un rifiuto totale.
• Parità linguistica — l'informativa di consenso deve essere disponibile in ogni lingua in cui il sito stesso è disponibile, non solo nella lingua del browser dell'utente. I CMP devono supportare l'override della locale.
• Accesso persistente — gli utenti devono poter raggiungere il centro preferenze da ogni pagina del sito, non solo dalla landing page, e il link di accesso deve essere etichettato in modo che un utente non esperto lo riconosca come relativo al consenso.

Cosa devono fare i publisher

1. Confermare il supporto alla v2.3 da parte del vostro CMP vendor. Chiedete la data esatta in cui sarà disponibile la build certificata v2.3 e la stringa di versione che riporterà.
2. Aggiornare la logica di cache della GVL. Se auto��ospitate un mirror della GVL, aggiornate il parser dello schema prima del rollout della GVL v2.3, altrimenti il vostro CMP non riuscirà a validare i nuovi vendor.
3. Riscrivere la UI del secondo livello in modo che ogni interruttore sia di default su off, la pari evidenza sia garantita visivamente e i periodi di conservazione siano mostrati accanto alle finalità.
4. Ripetere il vostro audit di conformità. Le violazioni più facili da colpire per i regolatori sono i dark pattern che la v2.3 ora menziona esplicitamente. Correggeteli prima della prossima verifica di enforcement.
5. Pianificare una strategia di ri‑prompt. Sebbene la TC String sia retro‑compatibile, le Policies incoraggiano i publisher a richiedere nuovamente il consenso quando l'ambito o le disclosure del trattamento cambiano in modo sostanziale. Decidete se il vostro rollout della v2.3 rientra nella nozione di cambiamento "sostanziale" per il vostro pubblico.

Cosa devono fare i vendor

1. Completare una Legitimate Interests Assessment per ogni finalità per cui dichiarate il LI e inviarne l'esito alla GVL.
2. Aggiornare la vostra voce nella GVL con i campi dello schema v2.3: granularità della conservazione, dichiarazione LIA e deep link all'informativa privacy.
3. Validare il vostro parser di TC String rispetto alle stringhe di riferimento v2.3 fornite da IAB Europe.
4. Coordinarsi con i vostri partner CMP su una data di cutover condivisa, in modo che la prima richiesta di acquisto che porta una stringa v2.3 non arrivi a un vendor che supporta solo la v2.2.

Trappole comuni nella migrazione

• Trattare la v2.3 come un'occasione per ridisegnare la UI. È allettante unire aggiornamenti di brand al rollout della v2.3, ma questo complica i test di conformità. Rilasciate prima una versione v2.3 focalizzata solo sulla compliance, poi iterate sul design.
• Dimenticare il requisito di visualizzare la conservazione. I team spesso aggiornano la vista dell'elenco vendor ma dimenticano che ora la conservazione deve comparire anche nella vista a livelli per singola finalità.
• Dare per scontato che la sola TC String basti. Una stringa conforme prodotta da una UI non conforme è comunque non conforme. I regolatori hanno ripetutamente sanzionato operatori le cui stringhe sembravano corrette ma i cui banner nascondevano il pulsante di rifiuto.
• Lasciare CTV e mobile fuori dal perimetro. La v2.3 si applica a ogni superficie in cui vengono prodotti segnali TCF. I publisher che aggiornano il web ma ignorano le app CTV o mobile creano un ambiente ibrido non conforme.

Conclusione

TCF v2.3 non è una rottura traumatica con la v2.2, ma rappresenta un irrigidimento significativo delle regole che tengono insieme l'ecosistema programmatic europeo. La direzione di marcia è chiara: più trasparenza, meno dark pattern, controlli utente più granulari e minore tolleranza per i casi limite che in passato passavano inosservati. I CMP e i publisher che trattano la v2.3 come una semplice patch rapida si ritroveranno presto di nuovo davanti al regolatore. Chi invece sfrutta la migrazione per ripulire la UX del secondo livello, abbandonare scorciatoie basate sul legittimo interesse e ricostruire un flusso di consenso con reale pari evidenza uscirà dall'altra parte con un'inventory che effettivamente verrà scambiata nell'era v2.3 — e con una postura di consenso in grado di reggere qualunque cosa porterà la futura v2.4.