Risposta breve: IAB Europe ha pubblicato TCF 2.4 il 23 luglio 2026. Le implementazioni Web devono essere migrate entro il 23 ottobre 2026; per Mobile App e CTV la scadenza è il 23 febbraio 2027. La versione del formato TC-String rimane 2 e la versione della policy TCF rimane 5. TCF 2.4 non introduce quindi un nuovo formato di stringa universale. Ciò che conta sono le linee guida aggiornate, in particolare il trattamento più rigoroso del legittimo interesse dei Vendor.
Punti essenziali
- TCF 2.4 è la specifica attuale; la scadenza di migrazione è differenziata per ambiente.
- Web: 23 ottobre 2026. Mobile App e CTV: 23 febbraio 2027.
- La versione binaria del TC-String rimane 2;
tcfPolicyVersionrimane 5. - I consensi già validi non richiedono automaticamente un nuovo consenso solo per la designazione della versione. Una nuova richiesta può però essere necessaria per altri motivi, ad esempio se cambiano i Vendor, gli scopi o i testi legali.
- Il segmento
DisclosedVendorsè diventato obbligatorio con TCF 2.3 e continua con 2.4. Non è una nuova funzionalità di 2.4. - I Vendor non possono segnalare il legittimo interesse basandosi unicamente su Special Purposes. Questa regola di 2.4 è già applicabile da aprile 2026.
- La registrazione e la certificazione sono affermazioni diverse. Verificate inoltre per quale ambiente è registrata una CMP.
Cosa cambia con IAB TCF 2.4?
TCF 2.4 aggiorna le linee guida e le specifiche tecniche del Transparency and Consent Framework. Per chi implementa è particolarmente importante non confondere i numeri di versione con i campi nel TC-String: il segmento Core continua a utilizzare la versione di formato 2 e la versione della policy rimane 5. Le integrazioni non devono quindi né codificare una versione di stringa inventata "2.4" né scartare tutti i segnali esistenti solo per il cambio di versione.
Il cambiamento più rilevante dal punto di vista pratico riguarda Vendor Legitimate Interest. Un Vendor può impostare un bit LI solo se esiste almeno uno scopo di elaborazione ammissibile per questo. Le Special Purposes da sole non sono sufficienti. Le CMP devono applicare questo invariante quando generano, ripristinano e revocano i segnali.
Disclosed Vendors: introdotto in 2.3, ancora richiesto in 2.4
Il segmento DisclosedVendors documenta quali Vendor sono stati effettivamente mostrati alla persona. È diventato obbligatorio con TCF 2.3 e rimane parte di una corretta implementazione 2.4. Durante la migrazione a 2.4, il segmento non dovrebbe quindi essere reinventato, ma verificato rispetto all'elenco dei Vendor visibile:
- Ogni Vendor contenuto nel segmento deve essere stato divulgato nell'interfaccia di consenso.
- I Vendor non visualizzati, eliminati o non attivi non devono essere segnalati come divulgati.
- L'insieme dei Vendor nella configurazione, nell'interfaccia, in
DisclosedVendorse inTCDatadeve corrispondere in modo tracciabile.
Scadenze per ambiente
| Ambiente | Scadenza migrazione a TCF 2.4 |
|---|---|
| Web | 23 ottobre 2026 |
| Mobile App | 23 febbraio 2027 |
| CTV | 23 febbraio 2027 |
Una registrazione Web non copre automaticamente Mobile App o CTV. Verificate la voce della CMP nell'elenco ufficiale delle CMP e gli ambienti ivi indicati. Biscotti CMP è gestito da Campcruisers GmbH ed è registrato con CMP-ID 497 per Web. Non viene rivendicata una registrazione per app native o CTV.
Migrazione graduale a TCF 2.4
1. Verificare lo stato di registrazione e ambiente
Confrontate CMP-ID, soggetto giuridico e ambienti registrati con l'elenco ufficiale delle CMP. Non affidatevi a un logo o a una formulazione generica come "conforme a IAB".
2. Collegare la GVL attuale e la selezione dei Vendor
Scaricate una Global Vendor List attuale e determinate i Vendor effettivamente utilizzati per il sito web o l'app specifico. L'interfaccia e lo stato di consenso generato devono derivare dallo stesso insieme di Vendor.
3. Implementare la regola Vendor-LI fail-closed
Non generate un segnale Vendor-LI se il Vendor dichiara solo Special Purposes o non rimane alcuno scopo LI ammissibile. Verificate questa regola anche dopo Reject, revoca, cambio GVL e ripristino di uno stato salvato.
4. Mantenere la semantica del TC-String
Continuate a codificare la versione di formato TC-String 2 e la versione della policy 5. Mantenete il segmento DisclosedVendors obbligatorio. Non modificate i campi della versione API solo perché la specifica del Framework si chiama 2.4.
5. Decidere il Reconsent in modo mirato
Un cambio di versione da solo non è un motivo universale per il Reconsent. Verificate invece se scopi, Vendor, basi legali, Publisher Restrictions o le informazioni mostrate alla persona sono cambiate sostanzialmente. Documentate la decisione.
6. Testare le transizioni di stato complete
Testate almeno Accept All, Reject All, selezione granulare, legittimo interesse, revoca, riapertura, riavvio del browser e un aggiornamento GVL. Decodificate gli stringhe generate in modo indipendente e confrontate i set di Vendor e Purpose.
Checklist tecnica
__tcfapi('ping', 2, ...)segnala dati CMP e Policy coerenti.- La versione di formato TC-String è 2 e
tcfPolicyVersionè 5. DisclosedVendorscorrisponde all'elenco dei Vendor effettivamente visibile.- Vendor-LI non viene mai impostato senza uno scopo LI ammissibile.
- Reject e revoca rimuovono i segnali di consenso e LI non ammissibili.
- Gli stati salvati vengono accettati solo se corrispondono alla configurazione attuale.
- CMP-ID e ambiente registrato corrispondono all'elenco pubblico delle CMP.
- I rilasci Web, Mobile App e CTV vengono rilasciati separatamente.
Gli utenti esistenti devono essere chiesti di nuovo?
Non automaticamente. La designazione della versione TCF 2.4 non cambia né il formato del TC-String né il numero della versione della policy da sola. Tuttavia, è richiesto un nuovo consenso se la decisione precedente non rappresenta più accuratamente l'elaborazione attuale o se la persona deve ricevere nuove informazioni sostanziali. La decisione dovrebbe essere presa sulla base del cambio di configurazione effettivo e con consulenza legale.
Errori comuni
- Codificare TCF 2.4 come nuova versione di formato TC-String.
- Aumentare
tcfPolicyVersionsenza base normativa. - Descrivere Disclosed Vendors erroneamente come nuovo cambiamento di 2.4.
- Trattare le Special Purposes come base sufficiente per Vendor-LI.
- Rappresentare una registrazione Web come registrazione Mobile App o CTV.
- Usare "registrato", "validato" e "certificato" come sinonimi.
- Testare solo il percorso Accept All e omettere Reject, revoca o riavvio.
Conclusione
La migrazione a TCF 2.4 non è un semplice cambio di testo. Richiede un rilascio pianificato per ambiente, segnali Vendor-LI corretti e la prova che i Vendor visibili, lo stato salvato e il TC-String corrispondono. Chi distingue correttamente la versione di formato 2, la versione della policy 5 e la storia di Disclosed Vendors evita gli errori di migrazione più comuni.
FAQ
TCF 2.4 è una nuova versione di formato TC-String?
No. Il campo della versione nel TC-String rimane 2; la versione del Framework 2.4 non deve essere scritta in questo campo.
Cambia la versione della policy TCF?
No. Per TCF 2.4, tcfPolicyVersion rimane a 5.
Disclosed Vendors sono nuovi in TCF 2.4?
No. Il segmento è diventato obbligatorio con TCF 2.3 e continua in 2.4.
TCF 2.4 richiede sempre Reconsent?
No. Ciò che conta sono i cambiamenti effettivi nell'elaborazione e nell'informazione dell'utente, non solo il numero di versione.
Biscotti CMP è registrato per Mobile App o CTV?
L'attuale voce di registrazione di Campcruisers GmbH, CMP-ID 497, copre Web. Da ciò non segue una registrazione per app native o CTV.
Fonti
- IAB Europe, TCF Policies v5.0.b e Specifications v2.4: https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, elenco CMP: https://cmplist.consensu.org/v2/cmp-list.json
- IAB Tech Lab, Consent String and Vendor List Formats: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework
Questo articolo illustra aspetti tecnici e organizzativi e non costituisce consulenza legale.