O que a TC string realmente é

O IAB Transparency & Consent Framework produz um único token compacto — a TC string — que viaja com cada solicitação de anúncio e diz aos fornecedores exatamente com o que um usuário concordou e com o que não concordou. Ela é codificada em Base64-URL e empacotada no nível de bits, então parece algo sem sentido (CPxy...AAA) mas codifica um registro preciso e auditável.

Os segmentos

Uma TC string completa são vários segmentos separados por pontos. O primeiro é a string principal; os outros são opcionais:

• Principal — ID do CMP, versão do CMP, os carimbos de data/hora do consentimento, a versão da política e, crucialmente, os campos de bits de consentimentos de propósito e consentimentos de fornecedor.
• Fornecedores divulgados — quais fornecedores foram mostrados ao usuário.
• TC do publisher — consentimentos específicos para você, o publisher.

Os campos de bits são o núcleo: o bit N definido como 1 significa consentimento para o propósito N ou o fornecedor N. O propósito 1 é “armazenar/acessar informações em um dispositivo,” os propósitos 3 e 4 cobrem anúncios personalizados, e assim por diante.

Decodificando uma na prática

Você raramente decodifica bits manualmente. Use as bibliotecas fornecidas pelo IAB ou um decodificador público:

• Divida em . e decodifique em Base64-URL o segmento principal.
• Leia os campos de cabeçalho de largura fixa (version, created, lastUpdated, cmpId, cmpVersion).
• Percorra os campos de bits de propósito e fornecedor para ver exatamente quais estão concedidos.

Em JavaScript, a chamada __tcfapi('getTCData', 2, cb) retorna o objeto já analisado — tcData.purpose.consents e tcData.vendor.consents são mapas de id → booleano. Essa é a sua verdade fundamental em tempo de execução.

Os erros que matam a receita

Quando a demanda personalizada desaparece silenciosamente, a TC string geralmente é o motivo:

• String ausente — a solicitação de anúncio não carrega gdprApplies/TC string, então os SSPs em conformidade caem para não personalizado.
• Fornecedor sem consentimento — o bit do ID de fornecedor do seu parceiro de demanda é 0, então ele não pode dar lances com personalização.
• String expirada ou desatualizada — um carimbo de data/hora antigo faz as plataformas posteriores desconfiarem dela.
• ID de CMP errado — um ID de CMP não registrado ou de teste invalida toda a string.

Um fluxo de depuração

Reproduza o consentimento do usuário, capture a TC string ao vivo de __tcfapi ou da solicitação de anúncio, passe-a por um validador e compare os propósitos/fornecedores decodificados com o que seus parceiros exigem. Nove em cada dez vezes a falha é um único bit de fornecedor ou um propósito 1 ausente.

Onde o FlexyConsent se encaixa

O FlexyConsent gera TC strings válidas conforme a especificação com um ID de CMP registrado, mantém-nas atualizadas, expõe o estado decodificado para depuração e relata quais propósitos e fornecedores estão realmente sendo concedidos em todo o seu tráfego — para que você possa ver, não adivinhar, onde o consentimento (e a receita) está vazando.

Principais conclusões

• A TC string é um registro auditável e empacotado em bits de cada escolha de consentimento.
• Os campos de bits de propósito e fornecedor decidem se os parceiros podem veicular anúncios personalizados.
• A maioria das quedas de receita remonta a uma string ausente, um fornecedor sem consentimento ou um ID de CMP desatualizado/inválido.
• Decodifique a string ao vivo com __tcfapi e valide-a contra os requisitos dos parceiros ao depurar.