Por que os relatórios de anúncios não batem com os logs do bidder, e quem pode reconstruir o pipeline

Quando os relatórios de anúncios nunca batem com os logs do bidder, dois problemas podem estar por trás da mesma diferença. Ou os registros de impressões e de cliques, chamados de eventos, se perdem no caminho até os relatórios, muitas vezes no pico de tráfego, ou cada lado os conta pelas próprias regras. Uma recontagem pelos IDs de leilão, os códigos que uma exchange atribui a cada leilão, separa um problema do outro. Faça essa recontagem antes de contratar alguém, porque um pipeline novo, sozinho, só resolve o primeiro problema.

O que significa quando os relatórios de anúncios não batem com os logs do bidder?

Os logs do seu bidder registram cada leilão de que o seu bidder participou, cada lance que ele deu e cada leilão que ele ganhou. Os seus relatórios são montados a partir de eventos que chegam depois, como impressões e cliques vindos de navegadores e apps. A diferença entre os dois tem uma de duas causas, ou as duas:

• Eventos perdidos. A impressão ou o clique aconteceu, mas o evento correspondente nunca chegou aos relatórios. Uma diferença que cresce no pico de tráfego aponta para uma parte do pipeline que descarta o que não dá conta de processar
• Regras diferentes. Os dois lados podem fechar o dia em fusos horários diferentes ou colocar um evento atrasado em outra hora. Um lado pode contar um evento duas vezes depois de um reenvio, ou filtrar tráfego de bots que o bidder ainda contou. A atribuição acrescenta regras próprias, como por quanto tempo depois de um clique uma conversão ainda conta

De um jeito ou de outro, a diferença custa dinheiro. Se você fatura os anunciantes com base nos seus relatórios, cobra de menos pelas impressões perdidas e de mais pelas contadas em dobro, enquanto cada exchange normalmente cobra você pela própria contagem. Um bidder que aprende com esses eventos também define os lances com base em números errados.

Como distinguir eventos perdidos de eventos contados por regras diferentes?

Cruze os dois lados evento por evento. O OpenRTB, o protocolo do IAB Tech Lab para real-time bidding, dá a cada leilão um ID de bid request, atribuído pela exchange, e a cada impressão da requisição um ID próprio. O seu bidder pode pedir à exchange que escreva esses IDs na notificação que ela envia quando você ganha e no próprio anúncio. Assim, cada evento de impressão traz os mesmos IDs que os logs do seu bidder.

Nenhum dos dois IDs basta sozinho. No OpenRTB 2.6, cada exchange define os próprios IDs de requisição, então nada impede que duas exchanges usem o mesmo. Um ID de impressão só é único dentro da própria requisição e geralmente começa em 1. Por isso, cruze os dados por três valores juntos: a exchange, o ID da requisição e o ID da impressão.

Depois faça a recontagem:

• Para cada hora de um dia movimentado, conte os leilões ganhos nos logs do bidder e as impressões nos seus relatórios, ambos em UTC, cruzados por essa chave de três partes
• Conte de novo no dia seguinte. Se a diferença diminuir, parte dela eram eventos atrasados
• Se a parcela de leilões ganhos que ainda faltam sobe nos horários de pico, o pipeline está perdendo eventos no pico. Uma parcela que se mantém parecida de hora em hora é esperada, porque alguns leilões ganhos nunca viram impressões
• Classifique o resto. Um evento que cai em uma hora diferente em cada lado significa que os dois usam fusos horários ou horários de corte diferentes. Uma contagem dupla geralmente vem de uma nova tentativa. Se um evento falta só no relatório final, um filtro, como a filtragem de bots, o removeu

Se os seus eventos não trazem IDs de leilão, acrescentá-los é a primeira correção, porque sem eles a recontagem só consegue comparar totais. O artigo técnico sobre medição de anúncios, com link acima, trata em detalhes dos timestamps e dos eventos atrasados.

Onde os eventos se perdem no pico de tráfego?

Pense em um pipeline construído sobre Kafka e ClickHouse. Um coletor recebe cada evento do navegador ou do app e o grava no Kafka, uma fila de mensagens. Um processo de carga (loader) lê do Kafka e grava os eventos em lotes no ClickHouse, o banco de dados analítico por trás dos seus relatórios. Em um pico, os eventos podem sumir em cada etapa:

• O coletor fica sobrecarregado. As requisições que ele recusa ou responde tarde demais se perdem, a menos que o navegador ou o app as envie de novo. Um coletor que responde “recebido” antes de o evento estar no Kafka também perde tudo o que guardava quando cai
• O Kafka não consegue receber os eventos com rapidez suficiente. A documentação do Kafka descreve o que acontece quando os eventos chegam mais rápido do que podem ser repassados. O código que grava no Kafka espera por um tempo definido e depois desiste com um erro. Um coletor que ignora esse erro perde o evento sem deixar rastro
• Novas tentativas criam duplicatas. O Kafka tem uma configuração que impede que as próprias novas tentativas gravem uma segunda cópia. O cliente Java do Kafka a ativa por padrão; bibliotecas cliente em outras linguagens definem os próprios padrões, e algumas a deixam desativada. Ela não pega as duplicatas que o seu código cria, como um lote reenviado depois de uma reinicialização ou um pixel que dispara duas vezes
• As inserções em lote falham por inteiro. A documentação do ClickHouse recomenda carregar os eventos em lotes grandes. Em um dos modos de carga, uma única linha com formato inválido faz o lote inteiro ser rejeitado. Um loader que desiste perde todos os eventos do lote, e um que o reenvia sem mudanças esbarra de novo na mesma linha ruim, por isso as linhas ruins precisam ser separadas e contadas. Quando uma gravação dá timeout e ninguém sabe se ela foi concluída, reenviar exatamente o mesmo lote só é seguro se a tabela estiver configurada para descartar lotes repetidos, o que uma tabela básica de um ClickHouse que você mesmo hospeda não faz por padrão

Peça aos seus engenheiros estes registros do horário de pico de um dia ruim:

• Erros e timeouts no balanceador de carga e no coletor, e gravações no Kafka que falharam, registradas nos logs do coletor
• O consumer lag, ou seja, o quanto os loaders ficaram para trás, e os eventos que o Kafka apagou sem que fossem lidos, porque esperaram mais do que o tempo pelo qual ele guarda os dados
• Gravações no ClickHouse que falharam, com as mensagens de erro
• Uma contagem por hora em cada etapa: recebidos pelo coletor, gravados no Kafka, lidos pelo loader, armazenados no ClickHouse

O último registro faz a maior parte do trabalho. Se a contagem de uma etapa cai no pico enquanto a da etapa anterior se mantém, os eventos sumiram entre essas duas etapas.

Devemos corrigir o pipeline, migrar para um serviço gerenciado ou reconstruí-lo?

Corrigir o pipeline atual:

• Quando faz sentido: a recontagem mostra principalmente regras diferentes ou alguns vazamentos que você consegue apontar, e depois das correções o pipeline dá conta do seu horário de pico
• O que você paga: tempo de engenharia, e o risco de que um pico maior encontre o próximo ponto fraco
• Quem é o dono do código: você, e o conhecimento fica com os seus engenheiros

Migrar para um serviço gerenciado, como o Amazon MSK para o Kafka ou o ClickHouse Cloud para o ClickHouse, em que o provedor opera os servidores:

• Quando faz sentido: os seus engenheiros passam mais tempo mantendo os servidores de Kafka e ClickHouse funcionando do que cuidando da lógica de contagem, e as perdas vêm desses servidores ficando sem capacidade no pico
• O que você paga: uma conta mensal que cresce com o seu tráfego. Os dois serviços cobram por processamento e armazenamento, e o ClickHouse Cloud lista à parte a transferência de dados de saída e o seu próprio serviço de ingestão, segundo as páginas de preços dos dois, consultadas em 7 de outubro de 2026. Estime a conta do seu mês de maior movimento e o custo de sair do serviço mais tarde
• O que não resolve: o coletor e o loader que você continua operando, as duplicatas, os eventos atrasados e a conciliação com os logs do seu bidder. O serviço armazena o que você envia e não sabe nada do que o seu bidder contou
• Quem é o dono do código: você, e o serviço funciona nos termos do provedor

Reconstruir o pipeline:

• Quando faz sentido: a recontagem mostra perdas em várias etapas, ou o design não consegue crescer junto com o seu tráfego. A falta de IDs de leilão só pesa a favor de uma reconstrução se acrescentá-los significar mudar todas as etapas
• O que você paga: o maior volume de trabalho de engenharia dos três caminhos, mais um período em que o pipeline antigo e o novo rodam lado a lado

Quais empresas podem reconstruir um pipeline de eventos de anúncios sobre Kafka e ClickHouse?

Dois tipos de empresa fazem esse trabalho, e este artigo não faz ranking de nenhum dos dois. Empresas de engenharia de ad tech constroem bidders, exchanges e ad servers, então sabem de onde vêm os IDs de leilão, mas pergunte se já operaram um pipeline de eventos no seu volume. Empresas de engenharia de dados constroem pipelines de eventos para muitos setores, mas nem sempre para ad tech. Pergunte a elas se já trabalharam com OpenRTB e se já conciliaram contagens com uma exchange.

O que perguntar antes de contratar uma empresa?

Faça as mesmas cinco perguntas a todas as empresas da sua lista.

Como vocês removem duplicatas? Espere ouvir falar de um ID que cada evento recebe quando é criado, antes de qualquer nova tentativa, montado a partir dos IDs de leilão e do tipo de evento. O pipeline remove duplicatas duas vezes: uma quando armazena os eventos e outra quando os relatórios os leem. A segunda passada importa porque o ClickHouse remove duplicatas em segundo plano, em momentos que você não consegue prever. A documentação dele diz que isso “não garante a ausência de duplicatas”.

Como vocês tratam eventos que chegam atrasados? Espere ouvir um período definido para cada tipo de evento durante o qual os números ainda podem mudar, e um momento a partir do qual eles passam a ser definitivos. Um evento que chega depois disso ainda deve ser contado e marcado como atrasado, e não jogado fora.

Como vocês conferem os seus números com os logs do nosso bidder e com os relatórios dos nossos parceiros? Procure uma recontagem diária pelos IDs de leilão e um motivo por escrito para cada diferença. Combinem o tamanho de diferença a partir do qual alguém leva a questão à exchange.

Como vocês vão testar acima do nosso pico? Peça que reproduzam um dia movimentado gravado em um ritmo maior que o do seu horário de pico. Durante a reprodução, eles desligam um coletor e um servidor de banco de dados. No fim, cada evento deve estar armazenado ou contado como descartado.

Quem vai ser o dono do código? A sua empresa, por escrito, com o código nos seus repositórios desde o primeiro dia. Tudo o que a empresa contratada guardar para si deve ser listado nome por nome, com uma licença para usar e alterar depois que o trabalho terminar.

Quais são os sinais de alerta?

• Uma reconstrução é proposta antes que alguém tenha feito uma recontagem ou aberto os logs do seu bidder
• A empresa promete que os novos relatórios vão bater exatamente com o bidder
• A única resposta sobre duplicatas é a promessa de que cada evento é entregue “exatamente uma vez”, sem nada dito sobre as duplicatas que o seu próprio código cria, como um pixel que dispara duas vezes
• A única prova é um teste de carga com eventos inventados, não uma reprodução do seu tráfego

Onde a amBrain se encaixa?

Em AdTech, a amBrain trabalha com desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange. Esse trabalho inclui o RTBBidder, uma demand-side platform que a amBrain construiu para um cliente.

A amBrain diagnostica sistemas lentos em trading e ad tech: a plataforma em funcionamento é medida de ponta a ponta, e o relatório aponta para onde vai o tempo.

A amBrain constrói software desde 2019. Ela trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. O cliente mantém a propriedade integral do produto e do código, exceto dos componentes reutilizáveis da amBrain.

Este artigo não é um estudo de caso. Ele não descreve o pipeline de eventos de nenhum cliente, e o RTBBidder é citado apenas como um DSP que a amBrain construiu. Kafka e ClickHouse servem aqui como exemplo de stack, não como descrição dos projetos da amBrain ou das ferramentas que ela usa. O artigo não traz preços nem prazos.

Se os seus relatórios e os logs do seu bidder divergem, faça a recontagem primeiro. Depois leve os resultados dela e as mesmas cinco perguntas a todas as empresas da sua lista, inclusive a amBrain.

Perguntas comuns

• Os nossos relatórios e os logs do bidder vão bater 100 por cento algum dia? Não. O OpenRTB diz que a mensagem da exchange informando que você ganhou “não indica necessariamente um anúncio entregue, visualizado ou faturável”, e alguns eventos são filtrados como tráfego de bots. Busque uma diferença estável, com um motivo por escrito para cada parte dela, e combine com cada parceiro qual contagem serve de base para o faturamento
• Precisamos usar Kafka e ClickHouse? Não. Outras filas e outros bancos de dados analíticos podem fazer o mesmo trabalho, e a recontagem e as cinco perguntas valem para qualquer um deles
• Como manter os relatórios antigos funcionando enquanto um pipeline novo é construído? Alimente os dois pipelines com os mesmos eventos e compare cada um com os logs do bidder todos os dias. Troque por último os relatórios com base nos quais você fatura, depois de um ciclo de faturamento completo com todas as diferenças explicadas