Adservers
Regras de adserver e prova de entrega real
Um adserver decide qual anúncio mostrar, entrega o criativo e conta o que aconteceu. É com base nessa contagem que o anunciante paga. Por isso a pergunta certa nunca foi “quantas impressões deu?”, e sim “o que essa contagem consegue provar?”.
As seis provas de uma entrega real
Uma entrega só é real quando as seis se sustentam ao mesmo tempo. Falha uma e o número vira estimativa otimista.
- Render: o criativo foi carregado e desenhado num navegador de verdade. A contagem começa depois disso, nunca antes.
- URL de veiculação: o relatório diz em qual endereço o anúncio apareceu, e esse endereço é conferível. Sem isso, não há como separar site real de site disfarçado.
- Viewability medida: 50% da área na tela por 1 segundo (2 em vídeo), medido no render. Não estimado por tempo de espera, muito menos sorteado.
- Tráfego inválido filtrado: bots, data centers e automação detectados e descontados da fatura, não apenas mencionados no contrato.
- Contexto seguro: brand safety com bloqueio de categorias e palavras, para o anúncio não financiar o que a marca não quer financiar.
- Vínculo à prova: o evento que gera cobrança está amarrado àquela renderização específica e não vale nada se for reproduzido fora dela. Verificação independente confere o conjunto.
O item 6 é o que segura todos os outros. Sem ele, as cinco provas anteriores são declarações de boa vontade do próprio fornecedor que emite a fatura.
O problema do “script desconectado”
Em muitos sistemas, o evento que conta a impressão é só um chamado HTTP. Se esse chamado pode ser disparado sem abrir a página e sem desenhar o anúncio, um programa consegue inflar números indefinidamente. A CGU chama isso de pixel contador e recomenda evitá-lo.
A regra de ouro é essa: se o evento que gera a cobrança pode ser reproduzido sem executar o anúncio num navegador real, o problema não é de configuração: é de arquitetura. Nenhuma cláusula contratual conserta um desenho de sistema que conta aquilo que qualquer um pode repetir.
E agora o script aprendeu a parecer gente
Durante anos, exigir navegador real foi defesa suficiente, porque fraude em escala era feita com script sem tela. Isso mudou. Navegadores operados por IA e agentes autônomos executam a página inteira, renderizam o criativo, esperam o conteúdo, movem o mouse de forma plausível e carregam cookies e sessão com histórico. Onde isso bate em cada tipo de adserver:
- Adservers de pixel puro nem chegam a ser testados. Continuam contando um chamado de rede: só que agora o chamado vem de algo que também saberia renderizar, se precisasse.
- Adservers com assinatura no callback ganham menos do que parece. A assinatura prova que o evento veio do servidor, não que uma pessoa viu. Quem pede o anúncio recebe os callbacks já assinados e válidos.
- Adservers que exigem execução no navegador perderam a maior parte da vantagem. A barreira era “tem que ter navegador”, e navegador é justamente o que o agente tem.
- Viewability por si só deixou de filtrar. Manter o criativo 50% na tela por 1 segundo é trivial para quem controla a página e o navegador.
Não é alarmismo: o próprio Google descreve publicamente o uso de IA e de grandes modelos de linguagem no Ad Traffic Quality contra tráfego inválido: e afirma que é improvável identificar proativamente todo o tráfego inválido. Quem tem o maior conjunto de sinais do mercado avisa que não pega tudo. Um adserver pequeno que promete número limpo está prometendo mais do que o Google.
Comparativo simplificado
| Plataforma | O que a contagem prova | Onde a automação passa |
|---|---|---|
| Sense Ads | Que um chamado chegou. | Eventos reproduzíveis sem render; visibilidade por probabilidade, não por medição. |
| AdButler / Metrike | Que o evento veio do servidor: não que houve visão. | Pedir o anúncio já devolve os callbacks assinados; basta repeti-los. |
| 00px / SPACE | Que houve execução no navegador. | Página e origem podem ser forjadas; sem verification forte de terceira parte. |
| Google Ad Manager | Render em navegador real, viewability medida e IVT filtrado. | Barreira mais alta do mercado, mas não intransponível: e a própria plataforma diz que não pega tudo. |
A leitura do quadro não é “use o Google”. É que, sem verificação independente e sem vínculo entre render e cobrança, o anunciante fica dependente da autodeclaração de quem emite a fatura: em qualquer uma das quatro linhas.
Checklist rápido para anunciantes e agências
- A impressão só conta depois do criativo renderizar em navegador real?
- O relatório informa a URL de veiculação, e ela é conferível?
- A viewability é medida no render (não estimada por tempo nem sorteada)?
- Há detecção de tráfego inválido com desconto na fatura?
- Há brand safety com bloqueio de categorias e palavras?
- O evento de cobrança está assinado e amarrado àquele render específico?
- Existe verificação independente, ou a prova é a palavra do fornecedor?
- O fornecedor admite o que não consegue detectar: ou promete 100%?
Se a resposta a qualquer um dos quatro primeiros for “não”, o anunciante está pagando por um número que um programa consegue inflar. Em verba pública, isso provavelmente também desatende à IN SECOM/PR nº 4/2024.
Como sair do papel
Duas formas de conferir isso na prática: veja a tag que prova entrega real: que só conta após renderizar, informa a URL e assina o evento de cobrança: ou leve uma tag qualquer para o laboratório e observe o que ela consegue, ou não, provar.