Resposta breu: IAB Europe va publicar TCF 2.4 el 23 de juliol de 2026. Les implementacions web han de migrar fins al 23 d'octubre de 2026; per a aplicacions mòbils i CTV, la data límit és el 23 de febrer de 2027. La versió de format del TC string es manté en 2 i la versió de política TCF es manté en 5. Per tant, TCF 2.4 no introdueix un format de string completament nou. Els aspectes clau són les directrius actualitzades, especialment el tractament més estricte de l'interès legítim dels proveïdors.
Els punts més importants en resum
- TCF 2.4 és l'especificació actual; el termini de migració es divideix per entorn.
- Web: 23 d'octubre de 2026. Aplicació mòbil i CTV: 23 de febrer de 2027.
- La versió binària del TC string es manté en 2;
tcfPolicyVersiones manté en 5. - Els consentiments ja vàlids no requereixen automàticament un nou consentiment només per la designació de versió. Una nova consulta pot ser necessària per altres raons, com ara canvis en proveïdors, finalitats o textos legals.
- El segment
DisclosedVendorses va fer obligatori amb TCF 2.3 i es manté sota 2.4. No és una nova funcionalitat de 2.4. - Els proveïdors no poden senyalitzar interès legítim només basant-se en Special Purposes. Aquesta regla de 2.4 ja s'aplica des d'abril de 2026.
- El registre i la certificació són declaracions diferents. Comproveu també per a quin entorn està registrat un CMP.
Què canvia amb IAB TCF 2.4?
TCF 2.4 actualitza les directrius i les especificacions tècniques del Transparency and Consent Framework. Per als implementadors, és especialment important no confondre els números de versió amb els camps del TC string: el segment Core continua utilitzant la versió de format 2, i la versió de política es manté en 5. Les integracions no han de codificar una versió de string inventada "2.4" ni descartar tots els senyals existents només per un canvi de versió.
El canvi més important en la pràctica afecta Vendor Legitimate Interest. Un proveïdor només pot establir un bit LI si hi ha almenys una finalitat de tractament permesa per a això. Special Purposes per si soles no són suficients. Els CMP han d'aplicar aquesta invariant quan es creen, es restauren i es revoquen senyals.
Disclosed Vendors: introduït en 2.3, continuat en 2.4
El segment DisclosedVendors documenta quins proveïdors va veure realment la persona. Es va fer obligatori amb TCF 2.3 i continua sent part d'una implementació correcta de 2.4. En migrar a 2.4, el segment no hauria de ser reinventat, sinó verificat contra la llista de proveïdors visible:
- Cada proveïdor contingut en el segment ha d'haver estat revelat a la interfície de consentiment.
- Els proveïdors no mostrats, eliminats o inactius no han de ser senyalitzats com a revelats.
- El conjunt de proveïdors en configuració, interfície,
DisclosedVendorsiTCDataha de ser clarament coherent.
Terminis per entorn
| Entorn | Termini de migració a TCF 2.4 |
|---|---|
| Web | 23 d'octubre de 2026 |
| Aplicació mòbil | 23 de febrer de 2027 |
| CTV | 23 de febrer de 2027 |
Un registre web no cobreix automàticament aplicacions mòbils o CTV. Comproveu l'entrada del CMP a la llista oficial de CMP i els entorns indicats allà. Biscotti CMP és operat per Campcruisers GmbH i està registrat amb CMP-ID 497 per a Web. No es reclama registre per a Native App o CTV.
Migració gradual a TCF 2.4
1. Comproveu l'estat de registre i entorn
Compareu CMP-ID, entitat legal i entorns registrats amb la llista oficial de CMP. No confieu en un logo o una formulació general com "compatible amb IAB".
2. Vinculeu la GVL actual i la selecció de proveïdors
Carregueu una Global Vendor List actual i determineu els proveïdors que s'utilitzen realment per al lloc web o aplicació específic. La interfície i l'estat de consentiment generat han de derivar-se del mateix conjunt de proveïdors.
3. Implementeu la regla Vendor-LI fail-closed
No genereu un senyal Vendor-LI si el proveïdor només declara Special Purposes o no queda cap finalitat LI permesa. Comproveu aquesta regla també després de Reject, revocació, canvi de GVL i restauració d'un estat guardat.
4. Mantingueu la semàntica del TC string
Continueu codificant la versió de format del TC string 2 i la versió de política 5. Mantingueu el segment obligatori DisclosedVendors. No canvieu els camps de versió de l'API només perquè l'especificació del framework s'anomena 2.4.
5. Decidiu estratègicament sobre Reconsent
Un canvi de versió per si sol no és una raó general per a Reconsent. En lloc d'això, comproveu si les finalitats, proveïdors, bases legals, Publisher Restrictions o la informació mostrada a la persona han canviat substancialment. Documenteu la decisió.
6. Proveu transicions d'estat completes
Proveu almenys Accept All, Reject All, selecció granular, interès legítim, revocació, reapertura, reinici del navegador i una actualització de GVL. Descodifiqueu els strings generats de forma independent i compareu els conjunts de proveïdors i finalitats.
Llista de verificació tècnica
__tcfapi('ping', 2, ...)informa de dades de CMP i política coherents.- La versió de format del TC string és 2 i
tcfPolicyVersionés 5. DisclosedVendorscorrespon a la llista de proveïdors realment visible.- Vendor-LI mai s'estableix sense una finalitat LI permesa.
- Reject i revocació eliminen senyals de consentiment i LI no permesos.
- Els estats guardats només s'adopten si coincideixen amb la configuració actual.
- CMP-ID i entorn registrat coincideixen amb la llista pública de CMP.
- Les versions web, aplicació mòbil i CTV es publiquen per separat.
Els usuaris existents han de ser consultats de nou?
No automàticament. La designació de versió TCF 2.4 no canvia per si sola el format del TC string ni el número de versió de política. Tanmateix, es requereix un nou consentiment si la decisió anterior ja no representa amb precisió el tractament actual o la persona ha de rebre informació essencial nova. La decisió ha de prendre's basant-se en el canvi de configuració real i amb assessorament legal.
Errors comuns
- Codificar TCF 2.4 com a nova versió de format de TC string.
- Augmentar
tcfPolicyVersionsense base normativa. - Descriure incorrectament Disclosed Vendors com a canvi nou de 2.4.
- Tractar Special Purposes com a base suficient per a Vendor-LI.
- Representar un registre web com a registre d'aplicació mòbil o CTV.
- Utilitzar "registrat", "validat" i "certificat" com a sinònims.
- Provar només la ruta Accept All i ometre Reject, revocació o reinici.
Conclusió
La migració a TCF 2.4 no és només un canvi de text. Requereix una versió planificada per entorn, senyals Vendor-LI correctes i prova que els proveïdors visibles, l'estat guardat i el TC string coincideixen. Qui distingeix correctament la versió de format 2, la versió de política 5 i l'historial de Disclosed Vendors evita els errors de migració més comuns.
FAQ
És TCF 2.4 una nova versió de format de TC string?
No. El camp de versió del TC string es manté en 2; la versió del framework 2.4 no ha de ser escrita en aquest camp.
Canvia la versió de política TCF?
No. Per a TCF 2.4, tcfPolicyVersion es manté en 5.
Són Disclosed Vendors nous en TCF 2.4?
No. El segment es va fer obligatori amb TCF 2.3 i es manté en 2.4.
TCF 2.4 sempre requereix Reconsent?
No. Els canvis reals en tractament i informació de l'usuari són decisius, no només el número de versió.
Està Biscotti CMP registrat per a aplicacions mòbils o CTV?
L'entrada de registre actual de Campcruisers GmbH, CMP-ID 497, cobreix Web. D'això no es dedueix registre per a aplicacions mòbils o CTV.
Fonts
- IAB Europe, TCF Policies v5.0.b i Specifications v2.4: https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, llista de 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
Aquest article explica aspectes tècnics i organitzatius i no és assessorament legal.