A versão curta

O TCF v2.3 é uma evolução do v2.2, não uma nova arquitetura. O formato da TC String é compatível, as finalidades e funcionalidades existentes são preservadas, e a maioria dos requisitos de UI visíveis aos publishers permanece inalterada. As mudanças significativas se concentram em quatro áreas:

• Regras mais claras sobre como as CMPs devem apresentar informações do vendor e períodos de retenção.
• Novos requisitos para controles granulares de segunda camada que os reguladores vêm exigindo desde a decisão da DPA belga de 2022.
• Aplicação mais rigorosa da política em torno de dark patterns, igualdade de destaque e opções pré-marcadas.
• Ajustes ao schema da Global Vendor List (GVL) e ao fluxo de divulgação de vendors.

Por que existe o v2.3

Cada versão do TCF é uma negociação entre três audiências: publishers que precisam continuar monetizando, vendors que precisam de uma interface técnica estável e reguladores que continuam encontrando lacunas específicas de conformidade. O v2.3 é uma resposta direta a três pressões:

1. Ações de fiscalização contra o uso excessivo de “interesse legítimo” sob o v2.2. Várias DPAs europeias consideraram que muitos vendors estavam reivindicando LI para finalidades em que, na verdade, apenas o consentimento era legalmente válido. O v2.3 aperta as divulgações da base legal declarada pelo vendor e as exibe mais cedo no UI de consentimento.
2. Reclamações contínuas sobre dark patterns. As Policies atualizadas tornam a regra da igualdade de destaque mais explícita e fecham brechas em torno de toggles pré-marcados na segunda camada.
3. Feedback operacional de grandes CMPs e publishers. O v2.2 introduziu várias divulgações obrigatórias que eram difíceis de implementar de forma limpa em mobile e CTV. O v2.3 simplifica o conjunto de divulgações obrigatórias e permite que mais delas residam em uma visão em camadas.

Compatibilidade da TC String

A TC String em si permanece retrocompatível. Uma CMP v2.3 produz strings que os vendors v2.2 podem ler, e um vendor v2.3 pode consumir strings v2.2 durante o período de transição. O indicador de versão no segmento principal da string identifica com qual versão de política a CMP está alegando conformidade, e o ponteiro de versão da GVL avança de forma independente.

O que isso significa na prática: você não precisa atualizar todos os vendors ao mesmo tempo, e não precisa forçar um novo evento de consentimento em cada usuário no dia em que implantar o v2.3. Uma implementação em fases é explicitamente suportada.

Principais mudanças técnicas

1. Divulgação do vendor e retenção

O v2.3 exige que as CMPs exibam o período de retenção de dados declarado por cada vendor na UI em camadas, e não apenas em uma lista de vendors separada. O valor de retenção sempre fez parte da GVL, mas o v2.2 não exigia que os usuários o vissem ao lado das finalidades. O v2.3 fecha essa lacuna porque os reguladores argumentaram que os usuários não podiam fazer uma escolha informada sem saber por quanto tempo seus dados persistiriam.

2. Controles mais rígidos na segunda camada

Na segunda camada — a visão “gerenciar preferências” — o v2.3 é explícito ao dizer que os toggles para finalidades e vendors não essenciais devem vir por padrão desligados. Caixas pré-marcadas ou sliders pré-habilitados são uma violação de política mesmo que o usuário nunca clique explicitamente em “aceitar”. CMPs que antes dependiam de um padrão de “soft opt-in” precisarão re-renderizar a segunda camada.

3. Aplicação da igualdade de destaque

A regra da igualdade de destaque existe desde o v2.1, mas o v2.3 a define com menos espaço para interpretação: o controle “rejeitar tudo” deve estar na mesma camada, com o mesmo peso visual, a mesma classe de contraste de cor e a mesma distância de interação que “aceitar tudo”. Esconder a rejeição atrás de um link, um botão menor ou uma tela secundária agora é uma falha explícita de conformidade, e não uma questão de julgamento.

4. Sinalização de interesse legítimo

Vendors que declararem interesse legítimo como base legal sob o v2.3 agora também devem declarar quais finalidades avaliaram e para quais concluíram um Legitimate Interests Assessment. As CMPs são obrigadas a repassar essa declaração à interface do usuário para que os usuários possam se opor com informações completas. Na prática, isso significa que o fluxo de “oposição” agora mostra o status de LIA específico por vendor, e não um toggle genérico.

5. Atualizações do schema da GVL

O schema da Global Vendor List adiciona campos para granularidade de retenção, status de LIA e um link legível por máquina para a seção da política de privacidade de cada vendor referente às finalidades declaradas. CMPs que fazem cache da GVL devem atualizar seu parser de schema para entender os novos campos antes de apontarem para uma GVL v2.3.

Mudanças de política que afetam a UX

O TCF é tanto uma especificação técnica quanto um conjunto de Policies. Várias mudanças nas Policies do v2.3 incidem diretamente sobre o UI de consentimento:

• Nada de “continuar sem aceitar” como equivalente de rejeição, a menos que corresponda visualmente ao botão de aceitar e produza a mesma TC String que uma rejeição completa produziria.
• Paridade linguística — o aviso de consentimento deve estar disponível em todos os idiomas em que o próprio site está disponível, e não apenas no idioma do navegador do usuário. As CMPs devem suportar sobreposição de locale.
• Acesso persistente — os usuários devem conseguir acessar o centro de preferências a partir de qualquer página do site, não apenas da landing page, e o link de acesso deve estar rotulado de forma que um usuário não especialista reconheça como relacionado ao consentimento.

O que os publishers devem fazer

1. Confirme o suporte do seu vendor de CMP ao v2.3. Peça a data exata em que a build certificada para v2.3 estará disponível e a string de versão que ela reportará.
2. Atualize a lógica de cache da GVL. Se você hospedar algum mirror da GVL, atualize o parser de schema antes do lançamento da GVL v2.3, caso contrário sua CMP falhará em validar novos vendors.
3. Reescreva o UI da segunda camada para que cada toggle venha desligado por padrão, a igualdade de destaque seja aplicada visualmente e os períodos de retenção sejam exibidos junto às finalidades.
4. Refaça sua auditoria de conformidade. As vitórias regulatórias mais fáceis são violações de dark patterns que o v2.3 agora identifica explicitamente. Corrija-as antes da sua próxima revisão de fiscalização.
5. Planeje uma estratégia de re-prompt. Embora a TC String seja retrocompatível, as Policies incentivam os publishers a solicitar novamente o consentimento quando o escopo ou a divulgação do processamento mudar materialmente. Decida se a sua implantação do v2.3 se qualifica como “material” para a sua audiência.

O que os vendors devem fazer

1. Conclua um Legitimate Interests Assessment para cada finalidade em que você declara LI e submeta o resultado à GVL.
2. Atualize sua entrada na GVL com os campos do schema v2.3: granularidade de retenção, declaração de LIA e o deep link da política de privacidade.
3. Valide seu parser de TC String contra as strings de referência v2.3 fornecidas pela IAB Europe.
4. Coordene-se com seus parceiros de CMP sobre uma data de migração compartilhada, para que a primeira requisição de comprador que carrega uma string v2.3 não caia em um vendor ainda em v2.2.

Armadilhas comuns de migração

• Tratar o v2.3 como uma oportunidade de redesenho de UI. É tentador combinar atualizações de marca com a implantação do v2.3, mas isso complica o teste de conformidade. Entregue primeiro um release v2.3 apenas de conformidade e depois itere no design.
• Esquecer o requisito de exibição da retenção. As equipes muitas vezes atualizam a visão da lista de vendors, mas esquecem que a retenção agora também precisa aparecer na visão em camadas, finalidade por finalidade.
• Assumir que a TC String é suficiente. Uma string em conformidade produzida por uma UI não conforme continua sendo não conforme. Os reguladores multaram repetidamente operadores cujas strings pareciam ok, mas cujos banners escondiam o botão de rejeitar.
• Deixar CTV e mobile fora do escopo. O v2.3 se aplica a toda superfície onde sinais de TCF são produzidos. Publishers que entregam uma atualização web e ignoram seus apps CTV ou mobile criam um ambiente híbrido em não conformidade.

Conclusão

O TCF v2.3 não é uma ruptura disruptiva com o v2.2, mas é um aperto significativo das regras que mantêm o ecossistema programático europeu coeso. A direção é clara: mais transparência, menos dark patterns, mais controle granular do usuário e menos tolerância para os casos de borda que antes passavam despercebidos. CMPs e publishers que tratarem o v2.3 como um patch rápido vão se encontrar de volta diante do regulador. Aqueles que usarem a migração para limpar a UX da segunda camada, aposentar atalhos de interesse legítimo e reconstruir um fluxo de consentimento real com igualdade de destaque sairão do outro lado com inventário que efetivamente limpa na era do v2.3 — e com uma postura de consentimento que sobreviverá ao que o v2.4 trouxer em seguida.