Resposta rápida: IAB Europe publicou TCF 2.4 o 23 de xullo de 2026. As implementacións web deben migrarse antes do 23 de outubro de 2026; para aplicacións móbiles e CTV aplícase o 23 de febreiro de 2027. A versión de formato do TC string segue sendo 2 e a versión de política TCF segue sendo 5. TCF 2.4 non introduce un novo formato de string de forma xeral. O decisivo son as directrices actualizadas, en particular o tratamento máis rigoroso do interese lexítimo dos vendedores.
O máis importante en resumo
- TCF 2.4 é a especificación actual; o prazo de migración está separado por ambiente.
- Web: 23 de outubro de 2026. Aplicación móbil e CTV: 23 de febreiro de 2027.
- A versión binaria do TC string segue sendo 2;
tcfPolicyVersionsegue sendo 5. - Os consentimentos xa válidos non requiren automaticamente un novo consentimento só pola designación de versión. Unha nova consulta pode ser necesaria por outras razóns, como cambios en vendedores, propósitos ou textos legais.
- O segmento
DisclosedVendorsfixose obrigatorio con TCF 2.3 e continúa en 2.4. Non é unha nova función de 2.4. - Os vendedores non poden sinalar interese lexítimo baseándose unicamente en Special Purposes. Esta regra de 2.4 xa se aplica desde abril de 2026.
- O rexistro e a certificación son afirmacións diferentes. Verifique tamén para que ambiente está rexistrada unha CMP.
Que cambia con IAB TCF 2.4?
TCF 2.4 actualiza as directrices e especificacións técnicas do Transparency and Consent Framework. Para os que implementan é especialmente importante non confundir os números de versión cos campos no TC string: o segmento Core segue usando a versión de formato 2, e a versión de política segue sendo 5. As integracións non deben codificar unha versión de string inventada "2.4" nin descartar todos os sinais existentes só polo cambio de versión.
O cambio máis importante na práctica afecta a Vendor Legitimate Interest. Un vendedor só pode establecer un bit LI se existe polo menos un propósito de procesamento permitido para iso. Os Special Purposes non son suficientes por si sós. As CMPs deben aplicar esta invariante ao xerar, restaurar e revogar sinais.
Disclosed Vendors: introducido en 2.3, aínda requirido en 2.4
O segmento DisclosedVendors documenta que vendedores foron realmente mostrados á persoa. Fixose obrigatorio con TCF 2.3 e segue sendo parte dunha implementación correcta de 2.4. Ao migrar a 2.4, o segmento non debe ser reinventado, senón verificado contra a lista de vendedores visible:
- Todo vendedor contido no segmento debe ter sido revelado na interface de consentimento.
- Os vendedores non mostrados, eliminados ou non activos non deben ser sinalizados como revelados.
- O conxunto de vendedores en configuración, interface,
DisclosedVendorseTCDatadebe ser rastrexable e coherente.
Prazos por ambiente
| Ambiente | Prazo de migración a TCF 2.4 |
|---|---|
| Web | 23 de outubro de 2026 |
| Aplicación móbil | 23 de febreiro de 2027 |
| CTV | 23 de febreiro de 2027 |
Un rexistro web non cobre automaticamente aplicacións móbiles ou CTV. Verifique a entrada da CMP na lista oficial de CMPs e os ambientes mencionados alí. Biscotti CMP é operada por Campcruisers GmbH e está rexistrada con CMP-ID 497 para Web. Non se afirma ningún rexistro de aplicación nativa ou CTV.
Migración gradual a TCF 2.4
1. Verificar estado de rexistro e ambiente
Compare CMP-ID, entidade legal e ambientes rexistrados coa lista oficial de CMPs. Non confíe nun logo ou nunha formulación xeral como "conforme con IAB".
2. Vincular GVL actual e selección de vendedores
Descargue unha Global Vendor List actual e determine os vendedores que se usan realmente no sitio web ou aplicación específica. A interface e o estado de consentimento xerado deben derivarse do mesmo conxunto de vendedores.
3. Implementar a regra Vendor-LI fail-closed
Non xere un sinal Vendor-LI se o vendedor só declara Special Purposes ou non queda ningún propósito LI permitido. Verifique esta regra tamén despois de Reject, revogación, cambio de GVL e restauración dun estado gardado.
4. Manter a semántica do TC string
Continúe codificando a versión de formato do TC string 2 e a versión de política 5. Manteña o segmento obrigatorio DisclosedVendors. Non cambie os campos de versión da API só porque a especificación do framework se chama 2.4.
5. Decidir reconsent de forma selectiva
Un cambio de versión por si só non é razón xeral para reconsent. En cambio, verifique se os propósitos, vendedores, bases legais, Publisher Restrictions ou a información mostrada á persoa cambiaron substancialmente. Documente a decisión.
6. Probar transicións de estado completas
Probe polo menos Accept All, Reject All, selección granular, interese lexítimo, revogación, reapertura, reinicio do navegador e actualización de GVL. Decodifique os strings xerados de forma independente e compare os conxuntos de vendedores e propósitos.
Lista de verificación técnica
__tcfapi('ping', 2, ...)informa de datos de CMP e política consistentes.- A versión de formato do TC string é 2 e
tcfPolicyVersioné 5. DisclosedVendorscorresponde coa lista de vendedores realmente visible.- Vendor-LI nunca se establece sen un propósito LI permitido.
- Reject e revogación eliminan sinais de consentimento e LI non permitidos.
- Os estados gardados só se adoptan se coinciden coa configuración actual.
- CMP-ID e ambiente rexistrado coinciden coa lista pública de CMPs.
- Os lanzamentos de web, aplicación móbil e CTV se libran por separado.
Deben ser preguntados de novo os usuarios existentes?
Non automaticamente. A designación de versión TCF 2.4 non cambia por si soa nin o formato do TC string nin o número de versión de política. Porén, é necesario un novo consentimento se a decisión anterior xa non representa con precisión o procesamento actual ou se a persoa debe recibir información nova substancial. A decisión debe tomarse baseándose no cambio de configuración real e con asesoramento legal.
Erros comúns
- Codificar TCF 2.4 como nova versión de formato de TC string.
- Aumentar
tcfPolicyVersionsen base normativa. - Describir Disclosed Vendors falsamente como novo cambio de 2.4.
- Tratar Special Purposes como base suficiente para Vendor-LI.
- Presentar un rexistro web como rexistro de aplicación móbil ou CTV.
- Usar "rexistrado", "validado" e "certificado" como sinónimos.
- Probar só a ruta Accept All e omitir Reject, revogación ou reinicio.
Conclusión
A migración a TCF 2.4 non é un mero cambio de texto. Require un lanzamento planificado por ambiente, sinais correctos de Vendor-LI e proba de que os vendedores visibles, o estado gardado e o TC string coinciden. Quen distingue correctamente a versión de formato 2, a versión de política 5 e o historial de Disclosed Vendors evita os erros de migración máis comúns.
FAQ
¿É TCF 2.4 unha nova versión de formato de TC string?
Non. O campo de versión do TC string segue sendo 2; a versión do framework 2.4 non debe escribirse neste campo.
¿Cambia a versión de política TCF?
Non. Para TCF 2.4, tcfPolicyVersion segue sendo 5.
¿Son Disclosed Vendors novos en TCF 2.4?
Non. O segmento fixose obrigatorio con TCF 2.3 e continúa en 2.4.
¿Require TCF 2.4 sempre reconsent?
Non. O decisivo son os cambios reais no procesamento e na información do usuario, non só o número de versión.
¿Está Biscotti CMP rexistrada para aplicacións móbiles ou CTV?
A entrada de rexistro actual de Campcruisers GmbH, CMP-ID 497, cobre web. Diso non se deduce ningún rexistro para aplicacións móbiles ou CTV.
Fontes
- IAB Europe, TCF Policies v5.0.b e Specifications v2.4: https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, lista de CMPs: 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
Este artigo explica aspectos técnicos e organizativos e non é asesoramento legal.