IAB TCF v2.4: Cosa devono cambiare i CMP entro ottobre 2026

IAB TCF v2.4 ha ora un programma di rollout confermato. IAB Europe prevede di pubblicare le specifiche tecniche finali e l'aggiornamento della Global Vendor List (GVL) il 23 luglio 2026. I CMP hanno tempo fino al 23 ottobre 2026 per le implementazioni web e fino al 23 febbraio 2027 per gli ambienti delle app mobili e della TV connessa. Se il tuo stack di consenso partecipa al TCF, questo è un progetto di implementazione, non un semplice aggiornamento del banner.

Le modifiche riguardano la Politica TCF v5.0.b e le Specifiche Tecniche v2.4. Esse influenzano il modo in cui i CMP spiegano le Funzionalità, rivelano l'ambito di una scelta, supportano il consenso multi-dispositivo e codificano un caso di segnalazione dei fornitori ristretto. Per informazioni sul framework attuale, consulta la panoramica sulla compliance IAB TCF di Conzent.

Punti chiave

Le date confermate forniscono ai CMP e agli editori una sequenza breve ma praticabile: ispezionare il pacchetto finale a luglio, completare le modifiche web a ottobre e mantenere mobile e CTV su un piano separato di febbraio. I punti più importanti sono:

• 23 luglio 2026: IAB Europe prevede di pubblicare le Specifiche Tecniche v2.4 e l'aggiornamento corrispondente della GVL.
• 23 ottobre 2026: I CMP devono implementare le nuove rivelazioni negli ambienti web.
• 23 febbraio 2027: la scadenza equivalente si applica agli ambienti delle app mobili e della CTV.
• Le interfacce CMP necessitano di spiegazioni standard più chiare e illustrazioni per le Funzionalità.
• Il livello iniziale deve informare gli utenti se una scelta è specifica per il servizio, specifica per il gruppo o multi-dispositivo.
• Il preview tecnico rimuove una soluzione obsoleta per l'interesse legittimo per i fornitori che dichiarano solo Scopi Speciali; i team dovrebbero verificare la formulazione finale il 23 luglio.
• La partecipazione al TCF supporta il lavoro di compliance, ma non sostituisce la valutazione legale di un editore o di un fornitore.

Le tre date da inserire nel tuo piano di consegna

La conferma di IAB Europe datata 16 luglio 2026 stabilisce tre traguardi separati. Trattare questi come un'unica scadenza comprimerebbe la scoperta, l'implementazione, la traduzione e il QA nello stesso intervallo di rilascio.

La sequenza pratica è:

1. 23 luglio 2026 — pubblicazione delle specifiche e della GVL. Scarica i file finali, confrontali con il materiale di commento pubblico e trasforma ogni differenza confermata in un compito di proprietà.
2. 23 ottobre 2026 — scadenza web. I CMP web di produzione dovrebbero esporre le nuove rivelazioni e seguire i requisiti di segnalazione finali v2.4.
3. 23 febbraio 2027 — scadenza per app e CTV. Gli SDK nativi, i tempi di rilascio degli store, le interfacce televisive e i test di accessibilità specifici per dispositivo hanno una data successiva, non un'esenzione.

Il divario tra pubblicazione e scadenza web è di tre mesi. Questo è sufficiente per un aggiornamento controllato se i team iniziano con una differenza di specifiche e una matrice di test. È stretto se il lavoro inizia con un redesign tardivo del banner.

La sequenza confermata separa il materiale sorgente, l'implementazione web e il rollout per app/CTV. Pianifica e testali come tre traguardi piuttosto che un unico lancio.

Chi deve agire—e chi dovrebbe comunque prestare attenzione

Le scadenze si applicano alle implementazioni TCF attive e ai CMP responsabili di esse. Le Politiche TCF ufficiali coprono sia i CMP commerciali che servono clienti sia i CMP privati gestiti da un editore per le proprie proprietà. Gli editori rimangono responsabili per l'interfaccia del framework presentata sulle loro proprietà digitali, anche quando un terzo fornisce il CMP.

Dovresti inserire questo lavoro in un piano di consegna se:

• costruisci o gestisci un CMP TCF registrato;
• utilizzi un CMP commerciale su un sito web finanziato da pubblicità programmatica;
• mantieni un CMP privato per editori;
• offri la stessa esperienza di consenso su web, app e CTV;
• dipendi dai segnali TCF per fornitori, offerte, misurazione o annunci personalizzati.

Un sito web che non partecipa al TCF non è automaticamente obbligato a implementare TCF v2.4. Potrebbe comunque aver bisogno di un meccanismo di consenso valido ai sensi della legge applicabile o delle regole della piattaforma. La versione del framework e il dovere legale di ottenere consenso sono domande correlate, ma non la stessa domanda.

Questa distinzione è importante per i prodotti editoriali di Google. Google richiede un CMP certificato integrato con il TCF per annunci personalizzati serviti tramite AdSense, Ad Manager o AdMob a utenti nell'EEA, nel Regno Unito e in Svizzera. Google afferma anche che la sua revisione della certificazione non verifica la piena conformità con il TCF o con la legge sulla privacy applicabile.

Cosa vedranno gli utenti di diverso in un CMP

Il cambiamento più visibile è uno sforzo per spiegare Funzionalità in modo più chiaro. Nel TCF, uno Scopo descrive perché i dati vengono elaborati e offre all'utente una scelta di consenso o obiezione, se applicabile. Una Funzionalità descrive un metodo di elaborazione utilizzato nel perseguimento di uno o più Scopi; non comporta un controllo separato per l'utente nello stesso modo.

Secondo la Politica v5.0.b e l'aggiornamento GVL confermato, i CMP devono tenere conto di:

• un nuovo campo standardTexts contenente la spiegazione standard per le Funzionalità;
• illustrazioni per ogni Funzionalità nell'aggiornamento GVL;
• la spiegazione standard della Funzionalità visualizzata con il nome standard e il testo completo a misura di utente;
• informazioni sulle Funzionalità che non sono visivamente associate a controlli che non possono effettivamente disabilitare la Funzionalità;
• un nuovo nome e indicazioni per la Funzionalità Speciale 2.

Il nome aggiornato per la Funzionalità Speciale 2 è “Identificare i dispositivi in base alle informazioni richieste attivamente.” Le indicazioni politiche coprono esplicitamente le caratteristiche raccolte tramite JavaScript o API—come font, risoluzione dello schermo e plugin—e informazioni richieste attivamente tramite User-Agent Client Hints. Gli utenti devono acconsentire prima che un fornitore utilizzi questa Funzionalità Speciale.

Perché questo è più di un semplice aggiornamento del testo

Un CMP che codifica in modo rigido le etichette o presume la vecchia forma della GVL potrebbe fallire anche se il banner appare ancora normale. I team di prodotto devono tracciare i nuovi dati dall'ingestione a ogni livello dell'interfaccia utente, etichetta di accessibilità, record di fornitori memorizzati nella cache e test di regressione. Il principio di design sicuro è semplice: rendere il significato ufficiale in modo accurato, rendere inconfondibile la presenza o l'assenza di una scelta dell'utente e non trasformare una Funzionalità esplicativa in un falso interruttore.

Il consenso multi-dispositivo ha bisogno di un ambito esplicito

La Politica v5.0.b aggiunge l'ambito multi-dispositivo alle definizioni del framework. Una base legale può applicarsi attraverso i punti di accesso per lo stesso servizio o gruppo—ad esempio, un sito web e un'app mobile utilizzati da un account autenticato—quando l'implementazione supporta tale ambito. Il livello iniziale dell'interfaccia del framework deve informare l'utente se la scelta di consenso è specifica per il servizio, specifica per il gruppo e/o multi-dispositivo.

Questa comodità crea una responsabilità di prodotto. Un CMP ha bisogno di un modo definito per risolvere una scelta effettuata su un dispositivo prima del login rispetto alle preferenze già memorizzate sull'account. Deve anche mantenere il rifiuto e il ritiro utilizzabili quanto l'accettazione attraverso lo stesso ambito.

La raccomandazione di CNIL di gennaio 2026 sui dispositivi incrociati è una guida normativa francese piuttosto che una regola TCF valida in tutta l'UE, ma è un utile benchmark di implementazione. CNIL raccomanda che:

• accettare, rifiutare e ritirare abbiano la stessa portata multi-dispositivo;
• gli utenti siano informati prima di scegliere che la preferenza si applicherà ai dispositivi connessi al loro account;
• un breve promemoria venga mostrato quando l'utente accede a un nuovo dispositivo;
• i conflitti siano gestiti in modo trasparente, sia dando priorità alla scelta più recente prima del login sia alla preferenza dell'account.

Documenta la regola di conflitto scelta e testa entrambe le direzioni. Un archivio delle preferenze tecnicamente coerente può comunque creare un'esperienza fuorviante se gli utenti non vengono informati su quale scelta prevalga.

Cosa cambia sotto il cofano

Il pacchetto tecnico è programmato per il 23 luglio, quindi i team di implementazione dovrebbero utilizzare il materiale attuale per prepararsi, non per fingere che la differenza finale sia già stata verificata. Il riassunto dei commenti pubblici di IAB Tech Lab identifica due aree di ingegneria concrete.

In primo luogo, la GVL guadagna l'oggetto standardTexts utilizzato per le spiegazioni delle Funzionalità. I parser, i tipi, le cache, le API e il codice di rendering devono accettare e preservare il nuovo campo. Un fallback elegante è utile per la resilienza operativa, ma non deve omettere silenziosamente una rivelazione richiesta dopo la scadenza.

In secondo luogo, il preview rimuove una soluzione per i fornitori che dichiarano solo Scopi Speciali. Poiché il TCF v2.3 ha reso obbligatorio il segmento disclosedVendors, quei fornitori possono determinare se sono stati rivelati da quel segmento. Il preview rimuove quindi il requisito di collocare i fornitori solo per Scopi Speciali nella sezione Interesse Legittimo dei fornitori della stringa TC.

Una regola di implementazione cauta

Prepara i test ora, quindi lega il comportamento di produzione al testo finale v2.4 pubblicato il 23 luglio. In particolare, confronta la specifica finale della stringa TC, il materiale API CMP, lo schema GVL, le traduzioni e gli esempi con il preview. Registra la versione che hai testato. “Abbiamo seguito l'articolo di giugno” non è una traccia di audit utile quando esiste una specifica finale.

Una checklist di prontezza TCF v2.4 in sette punti

La scadenza è più facile da gestire quando ogni requisito ha un proprietario e un test di accettazione osservabile. Inizia con questa checklist e ampliala per la tua architettura.

1. Inventaria ogni superficie TCF. Elenca le proprietà web, le esperienze incorporate, le app mobili, le app CTV, le impostazioni di consenso, i centri di preferenze degli account, gli SDK e i consumatori GVL memorizzati nella cache. Contrassegna ciascuna come web, app o CTV per la pianificazione delle scadenze.
2. Diff il rilascio del 23 luglio. Confronta la specifica finale, lo schema GVL, le traduzioni, le illustrazioni e i riferimenti politici con la tua attuale implementazione v2.3 e il preview dei commenti pubblici.
3. Aggiorna l'ingestione GVL. Verifica che standardTexts, illustrazioni, la rinominata Funzionalità Speciale 2 e i futuri campi sconosciuti sopravvivano al parsing, allo storage, alle API e alla cache.
4. Testa l'interfaccia utente. Controlla che le spiegazioni delle Funzionalità appaiano accanto alle informazioni corrette, non sembrino controlli, rimangano leggibili con zoom e tecnologia assistiva e funzionino in ogni lingua supportata. Rivedi l'esperienza del banner dei cookie come un flusso completo piuttosto che un singolo primo livello.
5. Testa la segnalazione. Crea fixture per fornitori solo per Scopi Speciali e verifica le regole finali di codifica e decodifica v2.4 attraverso il CMP, i fornitori downstream e qualsiasi gestione del consenso lato server.
6. Definisci il comportamento multi-dispositivo. Documenta l'ambito, i requisiti di identità, lo storage, la propagazione, il ritiro e la regola utilizzata quando le scelte del dispositivo e dell'account sono in conflitto. Testa i percorsi di accettazione, rifiuto, modifica, disconnessione, nuovo dispositivo e cancellazione dell'account.
7. Rilascia e osserva. Rilascia le modifiche web prima del 23 ottobre monitorando i fallimenti della GVL, gli errori della stringa di consenso, le rivelazioni mancanti e cambiamenti insoliti nei tassi di scelta. Mantieni i rilasci per app e CTV su un piano separato per il 23 febbraio 2027.

Il self-hosting non rimuove queste responsabilità. Se gestisci OCI sulla tua infrastruttura, controlli la finestra di aggiornamento e puoi ispezionare l'implementazione, ma possiedi anche la revisione della specifica finale, il deployment e la verifica.

Cosa dovrebbero chiedere gli editori al loro fornitore CMP

Gli editori non devono implementare ogni modifica del parser da soli, ma non dovrebbero accettare “pronto per TCF” come risposta completa. Chiedi prove legate ai tuoi ambienti e date reali.

Domande utili includono:

• Quali versioni delle Politiche TCF e delle Specifiche Tecniche sono attualmente in produzione?
• Quando sarà generalmente disponibile il supporto web per v2.4 e quale azione del cliente è richiesta?
• Come vengono renderizzate e tradotte le nuove spiegazioni delle Funzionalità, le illustrazioni e il testo della Funzionalità Speciale 2?
• Il prodotto supporta l'ambito multi-dispositivo e come vengono esattamente risolte le scelte in conflitto?
• Quali versioni degli SDK web, app e CTV contengono le modifiche?
• Quali test automatizzati e manuali coprono il comportamento finale della stringa TC v2.4?
• Gli utenti dovranno vedere di nuovo l'interfaccia del framework e qual è la fonte per quella decisione?

Chiedi al fornitore di separare la compliance del framework, la certificazione di Google e il supporto generale per la legge sulla privacy. Si sovrappongono, ma nessuna è prova dell'altra. I tuoi obblighi come controllore, editore e fornitore necessitano comunque di una valutazione di compliance GDPR appropriata per l'elaborazione che esegui.

Cosa non significa TCF v2.4

TCF v2.4 è un aggiornamento del framework dell'industria, non un nuovo statuto e non un mandato universale per ogni sito web. La politica stessa di IAB Europe descrive la partecipazione come volontaria e afferma che il framework non è un sostituto per i singoli partecipanti che si assumono la responsabilità delle proprie obbligazioni legali.

Mantieni questi confini visibili nella comunicazione interna e con i clienti:

• rispettare la scadenza TCF non rende di per sé un flusso di consenso lecito;
• la certificazione CMP di Google non equivale a piena conformità con il TCF o con la legge sulla privacy;
• una stringa TC tecnicamente valida non prova che l'utente abbia ricevuto informazioni chiare o abbia effettuato una scelta valida;
• la comodità multi-dispositivo non giustifica un ambito nascosto o una propagazione unidirezionale;
• una nuova etichetta standard non risolve un'interfaccia fuorviante attorno ad essa.

Utilizza consulenza legale per conclusioni specifiche per giurisdizione. Utilizza la specifica, la politica e le indicazioni del regolatore come input separati per i requisiti di prodotto piuttosto che fonderli in un unico vago ticket di “compliance”.

Domande frequenti

Cosa significa IAB TCF?

IAB TCF significa il Framework di Trasparenza e Consenso di IAB Europe. Standardizza il modo in cui editori, CMP e fornitori partecipanti rivelano l'elaborazione dei dati, catturano scelte rilevanti e comunicano segnali di consenso, obiezione e trasparenza nell'ecosistema della pubblicità digitale.

Cos'è IAB TCF v2 3?

TCF v2.3 è la versione tecnica immediatamente precedente a v2.4. Tra le altre modifiche, ha reso obbligatorio il segmento disclosedVendors. Questo è importante per v2.4 perché la bozza di commento pubblico utilizza il segmento obbligatorio per rimuovere la vecchia soluzione di interesse legittimo per i fornitori solo per Scopi Speciali.

Cos'è la lista TCF?

Il termine si riferisce solitamente alla Global Vendor List, o GVL. IAB Europe la mantiene per i fornitori TCF registrati, e i CMP utilizzano le sue dichiarazioni, il testo standard e i dati correlati per presentare informazioni e produrre segnali del framework. Il rollout v2.4 include un aggiornamento corrispondente della GVL programmato per il 23 luglio 2026.

Ogni CMP deve implementare TCF v2.4?

No. Le scadenze riguardano i CMP e le installazioni attive che partecipano al TCF di IAB Europe. Uno strumento di consenso non TCF può comunque avere obblighi ai sensi della legge sulla privacy o della politica della piattaforma, ma tali obblighi non lo trasformano automaticamente in un partecipante TCF.

Quando è la scadenza TCF v2.4 per i CMP?

La scadenza confermata è il 23 ottobre 2026 per gli ambienti web e il 23 febbraio 2027 per gli ambienti delle app mobili e della CTV. Le specifiche e l'aggiornamento corrispondente della GVL sono programmati per la pubblicazione il 23 luglio 2026.

Conclusione

TCF v2.4 non è un motivo per ridisegnare ogni flusso di consenso. È un motivo per verificare le parti su cui utenti e fornitori fanno affidamento: spiegazioni chiare delle Funzionalità, ambito onesto, scelte reversibili tra dispositivi e segnali accurati. Inizia con i file del 23 luglio, testa il web prima del 23 ottobre e mantieni mobile e CTV sul piano di febbraio 2027. Un rollout documentato e basato su prove supererà un aggiornamento frettoloso solo del banner.