Se o seu website depende de publicidade programática: seja através do Google AdSense, Google Ad Manager, header bidding ou trocas de leilão em tempo real (RTB): quase certamente precisa de cumprir o IAB Transparency and Consent Framework (TCF). Desenvolvido pela IAB Europe em resposta direta ao RGPD, o TCF tornou-se o padrão de facto da indústria para recolher, codificar e transmitir o consentimento do utilizador em toda a cadeia de fornecimento da publicidade digital. Neste guia completo explicamos o que é o TCF, como funciona por dentro, o que mudou entre as versões 2.0 e 2.2, porque os reguladores europeus têm escrutinado o framework e como pode implementá-lo no seu website sem se perder nos detalhes técnicos.

O problema que o TCF foi criado para resolver

Antes de o RGPD entrar em vigor a 25 de maio de 2018, o ecossistema da publicidade digital operava com relativamente poucas restrições à recolha de dados. Anunciantes, ad exchanges, demand-side platforms (DSPs) e supply-side platforms (SSPs) partilhavam livremente dados dos utilizadores: impressões digitais do navegador, IDs de cookies, históricos de navegação: para exibir anúncios direcionados. O RGPD mudou isto ao exigir uma base legal (mais comummente o consentimento) antes de os dados pessoais poderem ser processados.

O desafio tornou-se imediatamente evidente: o carregamento de uma única página num website financiado por publicidade pode envolver dezenas, por vezes centenas, de empresas diferentes a processar dados do utilizador em milissegundos. Como podia um editor recolher consentimento significativo para cada um destes fornecedores, e como podia esse sinal de consentimento percorrer toda a cadeia programática na fração de segundo que demora a realizar um leilão?

A resposta da IAB Europe foi o Transparency and Consent Framework: uma especificação técnica que padroniza a forma como o consentimento é recolhido pelos editores, codificado numa string legível por máquina e transmitido a todos os participantes na cadeia de fornecimento publicitária.

O que é o IAB TCF?

O IAB Transparency and Consent Framework (TCF) é um protocolo aberto e transversal à indústria que define três aspetos:

  • Como o consentimento deve ser recolhido: através de uma Consent Management Platform (CMP) registada que apresenta aos utilizadores informação padronizada sobre finalidades de processamento de dados e fornecedores.
  • Que finalidades de processamento existem: o TCF define uma lista fixa de finalidades (como "Armazenar e/ou aceder a informação num dispositivo", "Selecionar anúncios básicos", "Medir o desempenho dos anúncios") e funcionalidades especiais, garantindo consistência em toda a indústria.
  • Como os sinais de consentimento devem ser transmitidos: através de uma string codificada e padronizada (a TC String) que qualquer participante na cadeia ad tech consegue ler e sobre a qual pode agir.

O TCF é mantido pela IAB Europe e regido por um conjunto de políticas que as CMPs, editores e fornecedores devem seguir para poderem participar. O framework é gratuito, mas os participantes têm de se registar e aceitar as políticas do TCF.

Componentes-chave do ecossistema TCF

Compreender o TCF exige familiaridade com vários componentes que funcionam em conjunto:

A Global Vendor List (GVL)

A IAB Europe mantém uma lista pública de todos os fornecedores registados: empresas de ad tech que aceitaram as políticas do TCF e declararam quais as finalidades e bases legais em que se apoiam. No início de 2026, a GVL contém mais de 1.200 fornecedores. Quando uma CMP apresenta um banner de cookies, extrai informação da GVL para mostrar aos utilizadores exatamente que empresas irão processar os seus dados e para que finalidades.

Consent Management Platforms (CMPs)

Uma CMP é o software que apresenta a interface de consentimento (o banner de cookies) aos utilizadores. Para participar no TCF, uma CMP tem de estar registada junto da IAB Europe e receber um CMP ID único. A CMP é responsável por apresentar informação exata e completa, recolher as escolhas do utilizador, codificar essas escolhas numa TC String e disponibilizar essa string aos fornecedores através de uma API JavaScript padronizada (a CMP API, também conhecida como __tcfapi).

A TC String

A TC String é uma string codificada em Base64 que contém todos os sinais de consentimento e interesse legítimo do utilizador, a lista de fornecedores abrangidos, as finalidades consentidas, quaisquer restrições impostas pelo editor e metadados como a data em que o consentimento foi dado e a CMP que o recolheu. Esta string é normalmente armazenada num cookie first-party (frequentemente designado euconsent-v2) e é transmitida ao longo da cadeia ad tech através de pedidos de licitação, URLs de pixel e chamadas de API.

A CMP API (__tcfapi)

O TCF define uma API JavaScript que os fornecedores invocam para verificar o estado atual do consentimento. Quando o script de um fornecedor carrega numa página, este chama __tcfapi('getTCData', ...) para obter a TC String e determinar se tem consentimento para processar dados para as finalidades que declarou. Se o consentimento não tiver sido dado, um fornecedor que cumpra as regras deve abster-se de colocar cookies ou recolher dados.

Porque é que o seu website precisa do TCF

A realidade prática é simples: se monetiza o seu website através de publicidade, a conformidade com o TCF é, na prática, obrigatória. Eis a razão:

  • O Google exige-o. Desde janeiro de 2024, o Google exige que todos os editores que exibem anúncios no Espaço Económico Europeu (EEE) e no Reino Unido utilizem uma CMP certificada pelo Google que suporte o TCF 2.2. Sem isso, o Google pode restringir ou bloquear totalmente a exibição de publicidade personalizada no seu site, reduzindo drasticamente a sua receita publicitária.
  • As principais ad exchanges exigem-no. A Xandr (anteriormente AppNexus), a Index Exchange, a PubMatic, a Criteo, a The Trade Desk e praticamente todos os intervenientes relevantes na publicidade programática exigem, ou recomendam fortemente, a conformidade com o TCF por parte dos seus parceiros editores.
  • Demonstra conformidade com o RGPD. Embora o TCF seja um padrão da indústria e não propriamente um requisito legal, utilizar uma CMP compatível com o TCF fornece prova documentada de que recolheu o consentimento de forma padronizada e transparente: exatamente o que os reguladores esperam.
  • Protege a sua receita. Sem sinais de consentimento válidos a fluir através do bid stream, os anunciantes licitarão menos (ou nada) pelo seu inventário. Os editores que implementaram o TCF corretamente registam habitualmente taxas de preenchimento e CPMs significativamente melhores do que aqueles que dependem de mecanismos de consentimento não padronizados.

Sem conformidade com o TCF, o Google pode restringir ou bloquear completamente a exibição de publicidade personalizada no seu website: podendo reduzir a sua receita publicitária em 50% ou mais.

Como o TCF funciona na prática: um percurso passo a passo

Vejamos o que acontece quando um utilizador visita pela primeira vez um website compatível com o TCF:

Passo 1: A CMP carrega. Quando a página carrega, o script da CMP inicializa-se e verifica se já existe uma TC String válida (de uma visita anterior). Se não existir, apresenta o banner de consentimento.

Passo 2: O utilizador vê a interface de consentimento. O banner apresenta informação sobre as finalidades de processamento de dados (extraída da lista de finalidades do TCF) e os fornecedores envolvidos (extraídos da Global Vendor List). O utilizador pode aceitar tudo, rejeitar tudo, ou fazer escolhas granulares finalidade a finalidade e fornecedor a fornecedor.

Passo 3: O consentimento é codificado. Assim que o utilizador faz uma escolha, a CMP codifica as decisões numa TC String. Esta string é armazenada num cookie first-party e disponibilizada através da API JavaScript __tcfapi.

Passo 4: Os scripts dos fornecedores verificam o consentimento. À medida que os scripts publicitários carregam, cada fornecedor chama a CMP API para obter a TC String e verifica se tem consentimento para as finalidades que declarou. Se o consentimento existir, o fornecedor prossegue normalmente. Caso contrário, deve abster-se de processar dados pessoais.

Passo 5: A TC String percorre a cadeia publicitária. Quando é feito um pedido de anúncio (por exemplo, uma chamada de header bidding ou um pedido ao Google Ad Manager), a TC String é incluída no pedido de licitação. Todos os participantes no leilão: SSPs, DSPs, plataformas de gestão de dados: podem ler a string e agir em conformidade. Os anunciantes que não têm consentimento do utilizador não devem licitar por essa impressão.

Passo 6: Visitantes recorrentes. Quando o utilizador regressa, a CMP lê a TC String existente a partir do cookie. Se ainda for válida (não expirada, versão da CMP corresponde, etc.), o banner não é mostrado novamente e os sinais de consentimento armazenados são utilizados.

As finalidades do TCF explicadas

O TCF define um conjunto fixo de finalidades de processamento. Na versão TCF 2.2, são as seguintes:

  • Finalidade 1: Armazenar e/ou aceder a informação num dispositivo
  • Finalidade 2: Selecionar anúncios básicos
  • Finalidade 3: Criar um perfil de anúncios personalizado
  • Finalidade 4: Selecionar anúncios personalizados
  • Finalidade 5: Criar um perfil de conteúdo personalizado
  • Finalidade 6: Selecionar conteúdo personalizado
  • Finalidade 7: Medir o desempenho dos anúncios
  • Finalidade 8: Medir o desempenho do conteúdo
  • Finalidade 9: Aplicar estudos de mercado para gerar informações sobre audiências
  • Finalidade 10: Desenvolver e melhorar produtos
  • Finalidade 11: Utilizar dados limitados para selecionar conteúdo

Cada fornecedor na GVL declara em que finalidades se apoia e se utiliza o consentimento ou o interesse legítimo como base legal. No TCF 2.2, o interesse legítimo já não pode ser utilizado para as finalidades 3, 4, 5 e 6: estas passam a exigir consentimento explícito.

TCF 2.0 vs. 2.2: o que mudou

A versão 2.2 do TCF foi lançada em maio de 2023 e tornou-se obrigatória para todos os participantes até novembro de 2023. As principais alterações foram:

  • Eliminação do interesse legítimo para determinadas finalidades. No TCF 2.0, os fornecedores podiam invocar o interesse legítimo para finalidades de publicidade personalizada. O TCF 2.2 eliminou esta possibilidade, exigindo consentimento para as finalidades 3 a 6. Esta foi uma resposta direta às críticas de reguladores que argumentavam que o interesse legítimo estava a ser utilizado de forma abusiva.
  • Requisitos de informação mais rigorosos. As CMPs têm agora de apresentar os nomes dos fornecedores, as finalidades e os períodos de retenção de dados de forma mais evidente. A "primeira camada" da interface de consentimento tem de incluir mais detalhe do que era anteriormente exigido.
  • Melhor controlo por parte do utilizador. Os utilizadores têm de poder opor-se ao processamento com base no interesse legítimo diretamente a partir da primeira camada da interface de consentimento, sem terem de navegar para um ecrã separado.
  • Divulgação do período de retenção de dados dos fornecedores. Os fornecedores têm de declarar os seus períodos máximos de retenção de dados, e esta informação tem de estar visível para os utilizadores na interface de consentimento.
  • Consentimento baseado em URL. O TCF 2.2 introduziu a possibilidade de transmitir sinais de consentimento através de parâmetros de URL, além da abordagem baseada em cookies, apoiando ambientes onde os cookies são restringidos.

Escrutínio regulatório do TCF

É importante notar que o TCF não escapou às críticas dos reguladores. Em fevereiro de 2022, a Autoridade de Proteção de Dados belga (APD) concluiu que o sistema TCF da IAB Europe infringia o RGPD por vários motivos, incluindo o facto de a própria TC String constituir dados pessoais e de a IAB Europe estar a atuar como responsável pelo tratamento sem uma base legal suficiente. A IAB Europe foi multada em 250.000 euros e foi-lhe ordenado que colocasse o TCF em conformidade.

A IAB Europe recorreu e propôs subsequentemente um plano de ação que foi provisoriamente aprovado pela APD em janeiro de 2024. O principal resultado foi que a IAB Europe reconheceu o seu papel como responsável conjunto pelo tratamento dos dados da TC String e comprometeu-se a implementar salvaguardas adicionais, incluindo uma verificação mais rigorosa dos fornecedores e mecanismos de auditoria reforçados.

Este episódio sublinha um ponto crucial: a conformidade com o TCF, por si só, não garante a conformidade com o RGPD. O TCF é uma ferramenta útil para gerir o consentimento no ecossistema publicitário, mas os editores continuam a ter de garantir que as suas práticas gerais de processamento de dados cumprem o RGPD: incluindo ter políticas de privacidade válidas, responder a pedidos dos titulares dos dados e manter registos das atividades de processamento.

Erros comuns na implementação do TCF

Mesmo com uma CMP compatível com o TCF, os editores podem deparar-se com problemas. Eis os erros mais comuns:

  • Carregar scripts de fornecedores antes do consentimento. Alguns editores carregam scripts publicitários no cabeçalho da página antes de a CMP ter tido oportunidade de recolher o consentimento. Isto significa que os cookies são definidos e os dados são recolhidos antes de o utilizador ter feito uma escolha: uma violação clara do RGPD, independentemente do estado do TCF.
  • Não atualizar a GVL. A Global Vendor List é atualizada regularmente à medida que novos fornecedores se registam e os existentes atualizam as suas declarações. Se a sua CMP estiver a utilizar uma GVL desatualizada, poderá estar a recolher consentimento para as finalidades erradas ou a omitir fornecedores por completo.
  • Ignorar as restrições do editor. O TCF permite que os editores imponham restrições aos fornecedores: por exemplo, exigindo consentimento em vez de interesse legítimo para uma finalidade específica. Se não configurar estas restrições, os fornecedores podem processar dados com base em fundamentos legais que não pretendia permitir.
  • Não testar a implementação. Muitos editores instalam uma CMP e presumem que está tudo a funcionar. Na prática, deve verificar se a TC String está a ser gerada corretamente, se os scripts dos fornecedores estão a verificar o consentimento antes de serem executados, e se a CMP API está acessível a todos os fornecedores presentes na página.

TCF e Google Consent Mode v2

Se utiliza serviços Google (Analytics, Ads, AdSense), precisa de compreender como o TCF interage com o Google Consent Mode v2. O Google Consent Mode é um mecanismo separado que ajusta o comportamento das tags Google com base no estado do consentimento. Quando utilizado em conjunto com o TCF, uma CMP corretamente configurada atualiza simultaneamente a TC String e os sinais do Google Consent Mode, garantindo que os serviços Google se comportam corretamente independentemente das escolhas de consentimento do utilizador.

Na prática, a maioria das CMPs modernas: incluindo a Consentio: trata desta integração automaticamente. Quando um utilizador consente na Finalidade 1 (armazenamento no dispositivo) e na Finalidade 7 (medição de anúncios), a CMP define os bits apropriados na TC String e atualiza simultaneamente os sinais analytics_storage e ad_storage do Google Consent Mode.

Implementação com a Consentio

Configurar o TCF no seu website não tem de ser complicado. Com a Consentio, obtém um banner de cookies totalmente compatível com o TCF 2.2 e registado junto da IAB Europe como CMP certificada. A nossa plataforma trata de toda a complexidade técnica por si:

  • Sincronização automática com a Global Vendor List
  • Geração e armazenamento corretos de TC Strings
  • Implementação completa da CMP API (__tcfapi)
  • Integração com o Google Consent Mode v2
  • Configuração de restrições do editor através de um painel simples
  • Bloqueio automático de scripts de fornecedores até que o consentimento seja dado

Tudo isto é implementado com uma única linha de código. Concentre-se no seu conteúdo e na sua receita: nós tratamos da infraestrutura de consentimento.