GDPR, TCF e consent strings: o que um DSP precisa tratar na Europa

Todo anúncio programmatic comprado na Europa começa com uma pergunta que a maioria dos compradores nunca vê: essa pessoa concordou que seus dados fossem usados para publicidade e, se sim, por quem? A resposta viaja dentro do bid request como um texto curto e codificado chamado consent string. Se uma DSP não consegue lê-lo, está apenas adivinhando.

Adivinhar sai caro. Uma DSP que dá lances usando dados pessoais sem uma base legal válida expõe a si mesma, seus clientes e seus parceiros de supply a riscos regulatórios previstos no GDPR. Já uma DSP que vai para o extremo oposto e simplesmente para de dar lances na Europa abre mão de parte do inventário mais valioso do mundo. A resposta certa está no meio-termo, e é, em grande parte, um problema de engenharia.

Este guia explica como o GDPR se aplica à compra programmatic, o que é o Transparency and Consent Framework (TCF) da IAB Europe, o que existe dentro de um consent string do TCF, como esse string chega a uma DSP em um bid request OpenRTB e quais verificações uma DSP precisa executar antes de dar um lance. Trata-se de uma orientação prática, não de aconselhamento jurídico.

Por que o GDPR importa para compradores de mídia programmatic

O Regulamento Geral sobre a Proteção de Dados (GDPR) entrou em vigor em 25 de maio de 2018. Ele se aplica sempre que uma empresa trata dados pessoais de pessoas na União Europeia, e no mundo programmatic quase tudo conta como dado pessoal: IDs de cookie, IDs de publicidade móvel, endereços IP e localização precisa são identificadores capazes de individualizar uma pessoa ou um dispositivo.

Uma segunda lei atua em conjunto. A Diretiva ePrivacy trata do armazenamento ou da leitura de informações no dispositivo do usuário, que é exatamente o que um cookie ou uma consulta de device ID faz. Na prática, isso significa que uma DSP geralmente precisa de consentimento antes de ler ou gravar o próprio cookie no navegador de um usuário europeu, mesmo antes de fazer qualquer outra coisa com os dados.

Para um comprador, isso gera três perguntas práticas em cada impressão europeia:

• O GDPR se aplica a esta requisição?
• O usuário concordou com os usos específicos que a DSP pretende fazer, como criar perfis ou mensurar resultados?
• O usuário concordou que esta empresa em particular, a própria DSP, trate seus dados?

O que é o Transparency and Consent Framework da IAB Europe?

O Transparency and Consent Framework é um padrão voluntário mantido pela IAB Europe. Ele oferece a publishers, fornecedores de tecnologia e ferramentas de consentimento uma forma comum de descrever para que os dados são usados, quem os usa e o que o usuário disse a respeito. A IAB Europe descreve três grupos de participantes:

• Publishers: os donos dos sites e apps onde os dados são coletados.
• Vendors: empresas terceiras, como ad servers, provedores de mensuração, agências, SSPs e DSPs.
• Consent Management Platforms (CMPs): as ferramentas que exibem o banner de consentimento, registram as escolhas do usuário e as convertem em um consent string.

Os vendors se registram na Global Vendor List (GVL), uma lista pública mantida pela IAB Europe. Cada vendor registrado recebe um ID numérico e declara para quais finalidades trata dados e com base em qual fundamento legal. Em novembro de 2026, a lista oficial reunia mais de 1.200 vendors registrados. Quando um usuário faz uma escolha em um banner de consentimento, a CMP a registra vinculada a esses IDs de vendor.

O TCF v2.2 foi lançado em 16 de maio de 2023. Em abril de 2025, a IAB Europe lançou o TCF v2.3, que torna obrigatória a seção Disclosed Vendors do consent string para resolver uma ambiguidade relacionada ao legítimo interesse. Os participantes tiveram até 28 de fevereiro de 2026 para adotar a v2.3, portanto qualquer DSP que compre inventário europeu hoje deve esperar receber strings v2.3.

As finalidades do TCF que uma DSP precisa conhecer

O TCF não faz ao usuário uma única pergunta de sim ou não. Ele divide o uso de dados em finalidades padronizadas, cada uma com número e nome fixos. A DSP declara de quais precisa, e o consent string registra a resposta do usuário para cada uma. Estas são as onze finalidades da Global Vendor List oficial:

Além dessas, o TCF define finalidades especiais que não exigem consentimento, como garantir a segurança e prevenir fraudes, e entregar e exibir anúncios. Ele também define recursos especiais que exigem um opt-in separado, sendo o mais relevante o uso de dados de geolocalização precisa.

Cada finalidade se apoia em uma base legal: consentimento ou legítimo interesse. Desde o TCF v2.2, as finalidades 3 a 6, as de criação de perfis, só podem se basear em consentimento. Para uma DSP que faz segmentação de público ou retargeting, esta é a regra mais importante de todas: sem consentimento para as finalidades 3 e 4, não há lance personalizado.

O que existe dentro de um consent string do TCF?

O consent string do TCF, também chamado de TC string, é um texto compacto e codificado que a CMP gera depois que o usuário faz sua escolha. Decodificada, a parte principal do string contém:

• Metadados: a versão do TCF, quando o string foi criado e atualizado pela última vez, o ID da CMP, o idioma do consentimento e a versão da Global Vendor List utilizada.
• Consentimentos por finalidade: um sim ou não para cada finalidade apresentada ao usuário.
• Legítimos interesses por finalidade: se o tratamento com base em legítimo interesse foi apresentado ao usuário, e se ele não se opôs, para cada finalidade elegível.
• Opt-ins de recursos especiais: por exemplo, se a geolocalização precisa pode ser usada.
• Consentimentos e legítimos interesses por vendor: um sim ou não para cada ID de vendor da lista.
• Restrições do publisher: regras definidas pelo publisher para vendors específicos, como exigir consentimento onde um vendor usaria legítimo interesse, ou bloquear totalmente uma finalidade.

No TCF v2.3, o string também inclui um segmento Disclosed Vendors, que lista os vendors efetivamente apresentados ao usuário no aviso de consentimento. Isso permite que um vendor distinga entre “o usuário se opôs a mim” e “o usuário nunca foi informado sobre mim”.

O ponto-chave para compradores: um consent string é bidimensional. A DSP precisa que a finalidade esteja permitida e que o seu próprio ID de vendor esteja permitido. Um usuário pode aceitar publicidade personalizada em geral, mas recusar uma DSP específica, e o string registra as duas respostas.

Como o consent string chega à DSP

O consent string percorre a cadeia de supply junto com a requisição de anúncio. O caminho habitual é este:

1. O usuário acessa um site ou abre um app, e a CMP exibe um aviso de consentimento.
2. O usuário faz sua escolha, e a CMP a armazena como um TC string, geralmente em um cookie first-party ou no armazenamento do app.
3. Quando um espaço publicitário é carregado, o ad stack do publisher lê o string e o repassa à SSP.
4. A SSP o inclui no bid request OpenRTB que envia a todas as DSPs conectadas.
5. A DSP decodifica o string, verifica as próprias permissões e decide como dar o lance, ou se vai dá-lo.

No bid request OpenRTB, dois campos carregam o sinal. O OpenRTB 2.6 tem um campo nativo regs.gdpr, definido como 1 quando o GDPR se aplica e 0 quando não se aplica, e um campo nativo user.consent que contém o próprio TC string. Integrações mais antigas em OpenRTB 2.5 colocam os mesmos valores em extensões, como regs.ext.gdpr e user.ext.consent, por isso uma DSP conectada a muitos parceiros de supply deve ler os dois locais. Nosso guia sobre a anatomia de um bid request mostra onde esses objetos ficam na requisição completa.

Alguns parceiros também enviam um string do Global Privacy Platform (GPP) em regs.gpp e regs.gpp_sid. O GPP é um contêiner do IAB Tech Lab que pode conter o string do TCF ao lado de outros sinais regionais, então a DSP deve extrair a seção do TCF e aplicar a mesma lógica.

O string não para na DSP. Ad tags e pixels de rastreamento podem recebê-lo por meio de macros padrão, como ${GDPR} para o indicador de aplicabilidade e ${GDPR_CONSENT_XXX} para o string, em que XXX é o ID de vendor da empresa chamada.

As verificações que uma DSP deve executar antes de dar um lance

Tudo isso acontece dentro da janela de lances, que normalmente vai de algumas dezenas a algumas centenas de milissegundos, como descrito em nosso guia sobre como funciona o real-time bidding. A lógica de consentimento precisa ser rápida, previsível e igual para todas as requisições. Uma DSP bem construída executa estas verificações nesta ordem:

1. O GDPR se aplica? Leia o indicador gdpr. Se for 1, as regras de consentimento se aplicam. Se ele estiver ausente em tráfego de um país da UE, trate a requisição como se o GDPR se aplicasse.
2. O string está presente e é válido? Um string ausente, vazio ou corrompido significa ausência de consentimento. Não use dados pessoais.
3. O ID de vendor da DSP está permitido? Verifique as seções de consentimento e de legítimo interesse por vendor para o seu próprio ID.
4. As finalidades necessárias estão permitidas? Verifique a finalidade 1 antes de ler o cookie ou o device ID do usuário, as finalidades 3 e 4 antes de usar segmentos de público e a finalidade 7 antes de mensurar.
5. As restrições do publisher mudam algo? Aplique qualquer restrição definida pelo publisher para o seu ID de vendor antes de agir com base nas respostas de vendor e de finalidade.
6. É necessário algum recurso especial? Só use geolocalização precisa se o opt-in desse recurso especial estiver ativado.

O resultado não deve ser um simples “dar lance” ou “não dar lance”. Uma DSP bem construída escolhe um destes modos por requisição:

Vale a pena construir bem o modo contextual. Muitos usuários europeus recusam a publicidade personalizada, e os compradores que ainda conseguem dar lances com base em contexto e formato continuam alcançando esse inventário. Nosso artigo sobre publicidade cookieless aborda as opções de segmentação que continuam funcionando sem dados em nível de usuário.

Erros comuns de consentimento em DSPs

A maioria dos problemas de consentimento vem de pequenos atalhos de engenharia, não de mal-entendidos jurídicos. Os mais comuns:

• Verificar as finalidades, mas não o vendor. O usuário aceitou anúncios personalizados, mas não a sua empresa. Usar os dados continua não sendo permitido.
• Sincronizar IDs de usuário sem a finalidade 1. Cookie syncs e consultas de ID contam como acesso ao dispositivo. Eles exigem antes a finalidade 1 e o consentimento do vendor.
• Tratar um string ausente como consentimento. Quando o GDPR se aplica e nenhum string chega, o padrão seguro é não usar dados pessoais.
• Ler apenas um local do OpenRTB. Alguns parceiros enviam regs.gdpr, outros regs.ext.gdpr, outros GPP. Leia todos.
• Usar uma vendor list desatualizada. Atualize sua cópia da Global Vendor List periodicamente.
• Descartar o string nas etapas seguintes. Se criativos e trackers não recebem o string por meio de macros, não conseguem tomar a própria decisão, e o comprador assume esse risco.
• Não registrar a decisão em log. Se um regulador ou parceiro perguntar por que os dados de um usuário foram usados, você precisa do estado de consentimento vigente no momento da impressão.

A mesma disciplina vale para os dados que você traz para a plataforma. Se você conecta uma DMP à sua DSP, os segmentos de público só devem ser ativados em requisições cujo consent string permita a criação de perfis para o seu ID de vendor.

A posição de reguladores e tribunais

O TCF é um padrão de autorregulação, não uma lei, e os reguladores o examinaram de perto. Em março de 2024, o Tribunal de Justiça da União Europeia decidiu, em um caso envolvendo a IAB Europe, que um TC string pode ser considerado dado pessoal quando puder ser vinculado a um identificador, como um endereço IP. Portanto, o próprio string merece o mesmo cuidado que os demais dados de usuário.

Para quem é dono de uma DSP, a lição prática é simples. O TCF oferece uma linguagem comum, não um escudo jurídico. Defina seu papel em cada fluxo de dados com assessoria jurídica qualificada, documente sua lógica de consentimento e garanta que a plataforma se comporte conforme documentado.

O que muda quando a DSP é sua

Quando você compra pela plataforma de outra empresa, é a lógica de consentimento dela que decide como suas campanhas se comportam na Europa, e muitas vezes você não consegue entender por que o alcance europeu ficou abaixo do esperado.

Quando a plataforma é sua, o consentimento passa a ser algo que você pode configurar e auditar:

• Você decide o quão rigoroso é o padrão para ausência de consentimento e se o lance contextual roda em requisições sem consentimento para criação de perfis.
• Você pode gerar relatórios de alcance europeu por estado de consentimento, para que os clientes entendam por que uma campanha de público escala de forma diferente na França e no Brasil.
• Você controla por quanto tempo os registros e logs de consentimento são mantidos e quem pode acessá-los.
• Você escolhe quais parceiros de supply conectar com base na qualidade com que eles repassam indicadores gdpr e consent strings.

A DSP da AdTech Europe inclui um módulo de Consent Management e TCF que se integra ao IAB Transparency and Consent Framework para gerenciar sinais de consentimento nas regiões sujeitas ao GDPR, de modo que a segmentação e a mensuração respeitem as permissões tanto de anunciantes quanto de publishers.

Pronto para fazer compras em conformidade com o consentimento na sua própria DSP?

A AdTech Europe fornece tecnologia de demand-side platform para agências, ad networks, equipes de compra de mídia e empreendedores de adtech que querem ser donos do próprio stack de compra em vez de alugar um. A plataforma opera com a sua marca e o seu domínio, lê os sinais de consentimento do supply conectado e mantém as regras de lance nas suas mãos.

Em novembro de 2026, você pode alugar a DSP por $500 por mês (os planos mensais têm uma taxa única de setup equivalente a um mês) ou $5,000 por ano, licenciá-la por $25,000 à vista ou em 12 parcelas, ou ser dono do código-fonte completo por $50,000. Os valores atualizados em todas as moedas aceitas estão na página de preços, e a página White Label DSP apresenta a opção com a sua marca. Para planejar uma estrutura europeia de acordo com seus clientes e seu supply, agende uma reunião de estratégia programmatic com a nossa equipe.

Perguntas frequentes

O que é um consent string do TCF?

Um consent string do TCF, ou TC string, é um texto codificado criado por uma consent management platform depois que o usuário faz uma escolha de privacidade. Ele registra quais finalidades e quais vendors o usuário permitiu e viaja com as requisições de anúncio para que todas as empresas da cadeia possam verificá-lo.

Onde fica o consent string em um bid request OpenRTB?

No OpenRTB 2.6, ele fica no campo user.consent, com o campo regs.gdpr definido como 1 quando o GDPR se aplica. Integrações mais antigas em OpenRTB 2.5 usam user.ext.consent e regs.ext.gdpr. Alguns parceiros também o enviam dentro de um string GPP em regs.gpp.

O que uma DSP deve fazer se não houver consent string?

Se o GDPR se aplica e nenhum string válido chega, a DSP não deve usar dados pessoais. Isso significa nada de IDs de usuário, segmentos de público ou cookie syncs. Dependendo da sua assessoria jurídica, ela pode ignorar a requisição ou dar lance apenas com base em sinais não pessoais.

De quais finalidades do TCF uma DSP precisa para fazer retargeting?

O retargeting usa perfis, por isso exige consentimento para a finalidade 3, criar perfis para publicidade personalizada, e para a finalidade 4, usar perfis para selecionar publicidade personalizada. Também exige a finalidade 1 para ler o cookie ou o device ID do usuário, além do consentimento para o próprio ID de vendor da DSP.

Qual é a versão atual do TCF?

A versão atual é o TCF v2.3, lançado pela IAB Europe em abril de 2025. Ele torna obrigatória a seção Disclosed Vendors do consent string. Os participantes tiveram até 28 de fevereiro de 2026 para adotá-lo.

O TCF é exigido por lei?

Não. O TCF é um padrão voluntário do setor mantido pela IAB Europe. As leis são o GDPR e a Diretiva ePrivacy. O TCF é uma forma comum de as empresas coletarem, repassarem e respeitarem o consentimento para cumprir essas leis na velocidade de um leilão.

Uma DSP ainda pode dar lances sem consentimento para publicidade personalizada?

Muitas vezes, sim. Se o ID de vendor da DSP estiver permitido, mas as finalidades de criação de perfis forem recusadas, ela pode dar lances usando dados limitados, como o site, o app, o formato do anúncio e a localização aproximada. Esse lance contextual preserva o alcance europeu e, ao mesmo tempo, respeita a escolha do usuário.