O vazamento silencioso de receita

Quando seu eCPM cai alguns pontos percentuais a cada mês, a causa raramente é o inventário ou os preços mínimos. Mais frequentemente é uma TC string quebrada — o sinal do IAB Transparency & Consent Framework (TCF) que viaja com cada solicitação de anúncio. Uma string malformada ou ausente não gera nenhum erro barulhento. Em vez disso, o servidor de anúncios recorre silenciosamente a anúncios não personalizados, os parceiros de demanda saem e a receita sangra sem um único alerta. Para os publishers de apps e jogos que monetizam no EEE e no Reino Unido, é a causa mais negligenciada de perda de receita.

O que a TC string realmente carrega

A TC string é um bloco codificado em base64 criado pela sua Plataforma de Gestão de Consentimento (CMP). Ela codifica as escolhas do usuário: finalidades consentidas, fornecedores permitidos, seu ID de CMP, a versão da política e um carimbo de data/hora. Os compradores a decodificam em milissegundos para decidir se podem dar lances com segmentação personalizada. Dois sinais importam tanto quanto:

• gdprApplies — uma flag (1, 0 ou indefinida) que diz aos compradores se o GDPR é aplicável.
• Google Consent Mode v2 — os sinais ad_storage, ad_user_data e ad_personalization que o Google lê de forma independente da string do TCF.

Se algum deles estiver errado, a demanda evapora — mesmo quando o usuário de fato consentiu.

Os cinco erros que silenciosamente custam seu dinheiro

1. String ausente ou expirada. Se a CMP nunca escreve uma string, ou o consentimento em cache envelhece além da sua janela de reexibição, as solicitações saem sem sinal. Os compradores tratam "sem string" como "sem consentimento" e dão lances apenas com demanda contextual de baixo eCPM, ou pulam o leilão.

2. ID de CMP errado. Toda CMP certificada tem um ID registrado embutido na string. Se um ID não reconhecido é escrito, o Google e os fornecedores do IAB o rejeitam — comum após uma migração com o SDK antigo ainda empacotado.

3. Fornecedor não declarado. Um parceiro de demanda pode ter consentimento completo, mas se o ID de fornecedor dele não estiver na lista de fornecedores permitidos, ele não pode dar lances personalizados. Os publishers muitas vezes esquecem de atualizar a lista após adicionar um parceiro.

4. gdprApplies malformado. Passar uma string "1" em vez de um inteiro, ou deixá-lo undefined para um usuário claramente no EEE, confunde os compradores. Um gdprApplies=0 incorreto também pode expor você a risco de conformidade enquanto parece tudo certo.

5. Sinais do Consent Mode não disparando. A string do TCF pode estar perfeita enquanto o Consent Mode permanece em seu estado negado padrão — por exemplo, quando o SDK carrega anúncios antes de o consentimento ser resolvido. O Google então serve anúncios não personalizados independentemente da TC string.

Um fluxo de depuração passo a passo

Trabalhe do dispositivo para fora, em direção ao servidor de anúncios, e reproduza em um estado limpo — limpe os dados do app ou use um perfil de navegador novo para que o consentimento obsoleto não o engane.

• Passo 1 — Capture a string bruta. Na web, leia-a via __tcfapi('getTCData', 2, cb). Em um app, extraia a chave IABTCF_TCString de SharedPreferences (Android) ou NSUserDefaults (iOS).
• Passo 2 — Decodifique e valide. Cole-a no decodificador do IAB TCF ou em um validador de CMP. Confirme que o ID de CMP é o seu, que a versão da política e o carimbo de data/hora estão atuais, e que seus IDs de fornecedores principais aparecem na lista.
• Passo 3 — Inspecione a solicitação de anúncio. Use o Charles Proxy ou um inspetor de rede para observar a solicitação do GAM e verifique se os parâmetros gdpr e gdpr_consent carregam os valores corretos.
• Passo 4 — Verifique o Consent Mode. Use o Google Tag Assistant para confirmar que ad_user_data e ad_personalization mudam para granted quando o usuário aceita.
• Passo 5 — Confirme no GAM. Abra a dimensão de relatório de anúncios não personalizados do Ad Manager. Um pico de tráfego NPA que não corresponde à sua taxa de recusa é a impressão digital de uma string ruim.

Corrigindo a causa raiz

Remendar uma solicitação ruim é fácil; prevenir a próxima é o trabalho de verdade. Faça os anúncios esperarem pelo consentimento antes de inicializar, mantenha sua lista de fornecedores sincronizada com sua pilha de demanda e acompanhe a proporção de impressões personalizadas para não personalizadas — uma mudança aí é seu aviso mais precoce.

É aqui que uma CMP certificada pelo Google prova seu valor. O FlexyConsent emite strings IAB TCF 2.3 válidas com o ID de CMP e as declarações de fornecedores corretos, dispara os sinais do Consent Mode v2 para que ad_user_data e ad_personalization acompanhem a escolha do usuário, e expõe analytics de taxa de consentimento na web, Android e iOS — de modo que uma string quebrada apareça em um painel, não no seu pagamento.

Principais conclusões

• Uma TC string ruim não trava — ela silenciosamente rebaixa você para anúncios não personalizados e eCPM mais baixo.
• Cinco culpados: strings ausentes/expiradas, ID de CMP errado, fornecedores não declarados, gdprApplies malformado e sinais mortos do Consent Mode.
• Depure do dispositivo ao servidor de anúncios: capture, decodifique, inspecione a solicitação, verifique o Consent Mode, cheque o GAM.
• Acompanhe continuamente sua proporção de personalizados para NPA — uma CMP certificada como o FlexyConsent torna strings válidas e sinais corretos do Consent Mode v2 o comportamento padrão.