Resposta rápida: IAB Europe publicou TCF 2.4 em 23 de julho de 2026. As implementações Web devem ser migradas até 23 de outubro de 2026; para Mobile Apps e CTV, o prazo é 23 de fevereiro de 2027. A versão de formato TC-String permanece 2 e a versão de política TCF permanece 5. TCF 2.4 não introduz, portanto, um novo formato de string de forma generalizada. O essencial são as diretrizes atualizadas, particularmente o tratamento mais rigoroso do interesse legítimo dos fornecedores.
O Essencial em Resumo
- TCF 2.4 é a especificação atual; o prazo de migração é separado por ambiente.
- Web: 23 de outubro de 2026. Mobile App e CTV: 23 de fevereiro de 2027.
- A versão binária TC-String permanece 2;
tcfPolicyVersionpermanece 5. - Os consentimentos já válidos não requerem automaticamente um novo consentimento apenas pela designação de versão. Uma nova consulta pode ser necessária por outras razões, como alterações de fornecedores, fins ou textos legais.
- O segmento
DisclosedVendorstornou-se obrigatório com TCF 2.3 e continua em 2.4. Não é uma nova funcionalidade 2.4. - Os fornecedores não podem sinalizar interesse legítimo apenas com base em Special Purposes. Esta regra 2.4 já se aplica desde abril de 2026.
- Registo e certificação são declarações diferentes. Verifique também para qual ambiente um CMP está registado.
O Que Muda com IAB TCF 2.4?
TCF 2.4 atualiza as diretrizes e especificações técnicas do Transparency and Consent Framework. Para quem implementa, é particularmente importante não confundir números de versão com campos no TC-String: o segmento Core continua a usar a versão de formato 2, e a versão de política permanece 5. As integrações não devem, portanto, codificar uma versão de string inventada "2.4" nem descartar todos os sinais existentes apenas por causa da mudança de versão.
A mudança praticamente mais importante diz respeito ao Vendor Legitimate Interest. Um fornecedor só pode definir um bit LI se houver pelo menos um fim de processamento permitido para isso. Special Purposes sozinhos não são suficientes. Os CMPs devem impor esta invariante ao gerar, restaurar e revogar sinais.
Disclosed Vendors: introduzido em 2.3, ainda obrigatório em 2.4
O segmento DisclosedVendors documenta quais fornecedores foram realmente mostrados à pessoa. Tornou-se obrigatório com TCF 2.3 e continua a fazer parte de uma implementação 2.4 correta. Ao migrar para 2.4, o segmento não deve ser reinventado, mas verificado em relação à lista de fornecedores visível:
- Cada fornecedor contido no segmento deve ter sido divulgado na interface de consentimento.
- Fornecedores não mostrados, eliminados ou não ativos não devem ser sinalizados como divulgados.
- O conjunto de fornecedores em configuração, interface,
DisclosedVendorseTCDatadeve ser rastreável e consistente.
Prazos por Ambiente
| Ambiente | Prazo de Migração para TCF 2.4 |
|---|---|
| Web | 23 de outubro de 2026 |
| Mobile App | 23 de fevereiro de 2027 |
| CTV | 23 de fevereiro de 2027 |
Um registo Web não cobre automaticamente Mobile Apps ou CTV. Verifique a entrada do CMP na lista oficial de CMPs e os ambientes listados lá. Biscotti CMP é operado pela Campcruisers GmbH e está registado com CMP-ID 497 para Web. Nenhum registo de Native App ou CTV é afirmado com isso.
Migração Gradual para TCF 2.4
1. Verificar Estado de Registo e Ambiente
Compare CMP-ID, entidade legal e ambientes registados com a lista oficial de CMPs. Não confie num logótipo ou numa formulação geral como "compatível com IAB".
2. Vincular GVL Atual e Seleção de Fornecedores
Carregue uma Global Vendor List atual e determine os fornecedores que são realmente utilizados no website ou aplicação específicos. A interface e o estado de consentimento gerado devem ser derivados do mesmo conjunto de fornecedores.
3. Implementar Regra Vendor-LI Fail-Closed
Não gere um sinal Vendor-LI se o fornecedor apenas declarar Special Purposes ou se nenhum fim LI permitido permanecer. Verifique esta regra também após Reject, revogação, mudança de GVL e restauração de um estado guardado.
4. Manter Semântica TC-String
Continue a codificar a versão de formato TC-String 2 e versão de política 5. Mantenha o segmento obrigatório DisclosedVendors. Não altere campos de versão de API apenas porque a especificação do Framework é chamada 2.4.
5. Decidir Reconsent de Forma Direcionada
Uma mudança de versão sozinha não é uma razão geral para reconsent. Em vez disso, verifique se fins, fornecedores, bases legais, Publisher Restrictions ou as informações mostradas à pessoa mudaram substancialmente. Documente a decisão.
6. Testar Transições de Estado Completas
Teste pelo menos Accept All, Reject All, seleção granular, interesse legítimo, revogação, reabertura, reinício do navegador e uma atualização de GVL. Descodifique os strings gerados independentemente e compare conjuntos de fornecedores e fins.
Lista de Verificação Técnica
__tcfapi('ping', 2, ...)relata dados de CMP e política consistentes.- A versão de formato TC-String é 2 e
tcfPolicyVersioné 5. DisclosedVendorscorresponde à lista de fornecedores realmente visível.- Vendor-LI nunca é definido sem um fim LI permitido.
- Reject e revogação removem sinais de consentimento e LI não permitidos.
- Estados guardados são apenas adotados se corresponderem à configuração atual.
- CMP-ID e ambiente registado correspondem à lista oficial de CMPs.
- Lançamentos Web, Mobile App e CTV são lançados separadamente.
Os Utilizadores Existentes Devem Ser Consultados Novamente?
Não automaticamente. A designação de versão TCF 2.4 não altera por si só o formato TC-String nem o número de versão de política. No entanto, um novo consentimento é necessário se a decisão anterior não representar mais adequadamente o processamento atual ou se a pessoa tiver de receber novas informações substanciais. A decisão deve ser tomada com base na mudança de configuração real e com aconselhamento legal.
Erros Comuns
- Codificar TCF 2.4 como uma nova versão de formato TC-String.
- Aumentar
tcfPolicyVersionsem base normativa. - Descrever Disclosed Vendors falsamente como uma mudança nova 2.4.
- Tratar Special Purposes como base suficiente para Vendor-LI.
- Representar um registo Web como um registo Mobile App ou CTV.
- Usar "registado", "validado" e "certificado" como sinónimos.
- Testar apenas o caminho Accept All e omitir Reject, revogação ou reinício.
Conclusão
A migração para TCF 2.4 não é uma simples mudança de texto. Requer um lançamento planeado por ambiente, sinais Vendor-LI corretos e prova de que fornecedores visíveis, estado guardado e TC-String são consistentes. Quem distinguir corretamente versão de formato 2, versão de política 5 e o histórico de Disclosed Vendors evita os erros de migração mais comuns.
FAQ
TCF 2.4 é uma nova versão de formato TC-String?
Não. O campo de versão do TC-String permanece 2; a versão do Framework 2.4 não deve ser escrita neste campo.
A versão de política TCF muda?
Não. Para TCF 2.4, tcfPolicyVersion permanece em 5.
Disclosed Vendors são novos em TCF 2.4?
Não. O segmento tornou-se obrigatório com TCF 2.3 e continua em 2.4.
TCF 2.4 sempre requer Reconsent?
Não. O que importa são as mudanças reais no processamento e informação do utilizador, não apenas o número de versão.
Biscotti CMP está registado para Mobile Apps ou CTV?
O registo atual da Campcruisers GmbH, CMP-ID 497, cobre Web. Isto não implica um registo para Mobile Apps 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 aspetos técnicos e organizacionais e não constitui aconselhamento legal.