Quando um pipeline de eventos de anúncios perde eventos no pico, primeiro calcule quanto a diferença custa por ano. Depois compare com esse valor a correção do pipeline, um serviço gerenciado e uma reconstrução.
Se o seu pipeline de eventos de anúncios perde impressões e cliques no pico de tráfego, há três saídas. Você pode corrigir as partes que vazam, migrar para um serviço gerenciado os servidores que transportam e armazenam os eventos, muitas vezes Kafka e ClickHouse, ou reconstruir o pipeline com uma empresa externa. O caminho também decide quem você contrata. Uma correção precisa de engenheiros que trabalhem dentro do seu time, enquanto uma reconstrução precisa de uma empresa capaz de entregar um pipeline inteiro e passá-lo para você. Antes de escolher, calcule quanto custa por ano a diferença entre os seus relatórios de atribuição e os logs do seu bidder. Depois compare cada caminho pelo custo, pelo controle que você mantém e pelo tempo que leva até os números que você usa para faturar voltarem a estar certos.
A resposta curta: primeiro calcule quanto a diferença entre os seus relatórios e os logs do seu bidder custa a você em um ano. Para cada caminho, some o custo dele nos próximos doze meses ao que a diferença continua custando até esse caminho fechá-la, e compare apenas os caminhos capazes de eliminar as perdas que você realmente encontrou. Um serviço gerenciado também traz uma conta que cresce com o tráfego e um calendário de atualizações definido pelo provedor, e uma reconstrução deixa com você apenas o controle que o contrato dela prevê.
Leia também
A maior parte do custo aparece nas faturas, então comece por elas. Pegue um mês e coloque três contagens lado a lado: as impressões que você cobrou dos anunciantes, as impressões que cada exchange cobrou de você e os leilões ganhos que o seu bidder registrou.
É a exchange que decide pelo que você paga. O OpenRTB 2.6, o padrão do IAB Tech Lab que exchanges e bidders usam para negociar anúncios em tempo real, diz que a exchange envia uma notificação de cobrança “quando um lance vencedor se torna faturável com base na política de negócios específica da exchange”. Cada exchange cobra você segundo a própria política e com base nos próprios registros, enquanto os seus anunciantes são cobrados com base nos seus relatórios. Cada impressão que o seu pipeline perde foi paga e nunca cobrada. Uma impressão contada duas vezes é cobrada duas vezes, e você devolve o valor em forma de crédito quando a contagem do próprio anunciante não bate.
Use números redondos, e não os dados reais de alguém. Uma plataforma compra 500 milhões de impressões por mês e as revende aos anunciantes a US$ 2 por mil. Se ela perde 3 por cento dos eventos de impressão, 15 milhões de impressões ficam sem cobrança, o que dá US$ 30.000 por mês ou US$ 360.000 por ano, sem contar duplicatas e créditos.
Outros dois custos são mais difíceis de calcular. O primeiro são as horas que o seu pessoal gasta todo mês explicando diferenças a anunciantes e exchanges. O segundo são os lances definidos com base em dados incompletos. Anote os dois ao lado do total.
O total anual é, aproximadamente, o máximo que um caminho deveria custar. Um caminho que custa mais do que a diferença que elimina precisa de outro motivo, como um crescimento de tráfego que o pipeline atual não consegue suportar.
Divida a diferença antes de calcular o custo dos caminhos. O artigo sobre relatórios que não batem com os logs do bidder descreve a recontagem, que cruza cada leilão ganho nos logs do seu bidder com uma impressão nos seus relatórios pelo ID de leilão, o ID que cada exchange atribui a um leilão. A recontagem mostra quanto da diferença são eventos perdidos e quanto vem de os dois lados contarem por regras diferentes. Regras diferentes se resolvem combinando um único conjunto de regras e aplicando-o em qualquer pipeline que você opere. Um serviço gerenciado ou um pipeline novo não muda as regras de contagem.
Uma correção e uma reconstrução são pagas principalmente como projetos. Um serviço gerenciado acrescenta uma conta todo mês, enquanto você o usar.
Corrigir o pipeline atual custa tempo de engenharia, dos seus próprios engenheiros ou de engenheiros externos trabalhando dentro do seu time. Não há nenhuma assinatura nova. Planeje uma segunda rodada de correções, porque o primeiro período de muito movimento depois das correções muitas vezes revela a próxima parte que não acompanha o ritmo.
Um serviço gerenciado cobra todo mês, e parte da conta é calculada por gigabyte de eventos, então ela acompanha o seu tráfego. Os seus engenheiros continuam operando tudo o que fica fora dos servidores do provedor. O Amazon MSK Serverless é uma das opções do serviço gerenciado da AWS para o Kafka, a fila que guarda os eventos entre a coleta e o banco de dados. A página de preços dele, consultada em 14 de outubro de 2026, lista uma tarifa por hora para cada cluster, ou seja, cada instalação separada do serviço, e para cada partição, uma fatia da fila. A página acrescenta uma taxa sobre cada gigabyte gravado na fila e sobre cada gigabyte lido dela, além de uma tarifa de armazenamento. Por isso, cada programa a mais que lê os mesmos eventos, como uma recontagem diária comparada com os logs do seu bidder, aumenta a conta.
Calcule o custo do caminho gerenciado com o tráfego que você espera para o seu mês de maior movimento no ano que vem, e confira esse tráfego com os limites do provedor. Um cluster MSK Serverless, por exemplo, desacelera as gravações acima de 200 megabytes por segundo, segundo a página de cotas dele, consultada em 14 de outubro de 2026.
Na reconstrução, a maior parte do dinheiro vai para o projeto em si. Some os meses em que o pipeline antigo e o novo rodam lado a lado e as horas do seu próprio pessoal para revisar e aprovar o trabalho. Depois do handover, alguém tem que operar o pipeline novo, e o contrato deve dizer quem. Peça a todas as empresas que orcem o mesmo escopo por escrito, incluindo o período em paralelo, para que você possa comparar os orçamentos lado a lado, item por item.
Um serviço gerenciado tira parte do controle, a começar pelo seu calendário. Pela política de suporte de versões do MSK, um cluster que continua em uma versão do Kafka depois da data de fim do suporte dessa versão “é atualizado automaticamente para a versão recomendada do Kafka”. A política acrescenta: “Você não receberá nenhuma notificação antes da atualização.” Planeje as suas próprias atualizações antes dessas datas, ou aceite o momento escolhido pelo provedor. Sair mais tarde é uma migração à parte. Os dados são copiados para sistemas que você opera em outro lugar, e cada programa que grava ou lê esses dados é migrado para eles.
Corrigir o pipeline atual mantém com você o controle total do pipeline. As pessoas que fizeram as correções sabem como elas funcionam, então, se algumas delas forem terceirizadas, peça uma nota por escrito sobre cada correção antes que elas saiam.
Na reconstrução, o seu controle é o que o contrato der a você. O contrato deve dizer que o código pertence à sua empresa e fica nas contas da sua empresa desde o início do trabalho. Os documentos de design devem chegar junto com o código, acompanhados dos runbooks, as instruções escritas para lidar com cada alerta. Os seus engenheiros também devem começar a responder aos alertas do pipeline novo enquanto a empresa externa ainda está no projeto.
Uma correção no pipeline atual pode ser conferida no próximo pico, comparando as contagens por hora em cada etapa do pipeline antes e depois. A migração para um serviço gerenciado leva mais tempo, porque os dados são copiados, cada programa que grava ou lê eventos é migrado e os dois sistemas rodam lado a lado até que as contagens deles batam. Os vazamentos fora dos servidores do provedor continuam precisando de correção, por exemplo no coletor, o programa que recebe os eventos de navegadores e apps. A reconstrução é a que leva mais tempo. Os dois pipelines rodam com os mesmos eventos por pelo menos um ciclo de faturamento completo antes que os relatórios que você usa para faturar passem para o pipeline novo, como explica o artigo sobre relatórios que não batem com os logs do bidder.
Quatro respostas decidem a maior parte da escolha. As três primeiras vêm de registros que você já mantém, e a quarta pode exigir um teste.
Lado a lado, os três caminhos ficam assim.
Para comparar os caminhos, some, para cada um, o custo dele nos próximos doze meses e o custo mensal da diferença multiplicado pelo número de meses até esse caminho fechá-la. Compare os totais apenas entre os caminhos capazes de eliminar as perdas que você realmente encontrou. Um banco de dados gerenciado não vai ajudar se os eventos se perdem antes de chegar a ele. Uma reconstrução não vai ajudar se a diferença vem de os dois lados fecharem o dia em horários diferentes.
Muitas vezes, o plano mais barato mistura os três caminhos, em uma ordem definida. Combine primeiro as regras de contagem, porque elas valem seja qual for o sistema que roda por baixo. Em seguida, corrija os vazamentos que você consegue apontar. Decida sobre servidores e design por último, quando algumas semanas de contagens por hora limpas mostrarem o que sobrou.
Uma reconstrução não precisa significar operar os seus próprios servidores. Um pipeline novo pode rodar sobre uma fila gerenciada e um banco de dados analítico gerenciado, e alguns provedores também operam o loader, a etapa que grava os eventos da fila no banco de dados. O ClickHouse Cloud, a versão hospedada do banco de dados ClickHouse, oferece o ClickPipes para isso. A documentação do ClickHouse Cloud chama o ClickPipes de “uma plataforma de integração gerenciada” e lista o Kafka e o AWS MSK entre as fontes dele. A empresa externa então constrói o que é específico da sua plataforma, como as regras de contagem e a recontagem diária comparada com os logs do seu bidder, além do coletor e de um loader onde nenhuma opção gerenciada servir.
Seja qual for o caminho que uma empresa propõe, a proposta dela deve poder ser conferida com os seus próprios dados. Peça as verificações que combinam com o caminho.
A amBrain constrói pipelines de analytics de eventos para ad tech: coleta, processamento e relatórios de eventos de impressão e de clique. Em AdTech, ela também trabalha com desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange, e 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. A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.”
Nada aqui descreve o pipeline de um cliente. Amazon MSK, Kafka, ClickHouse e ClickPipes são citados como exemplos comuns, e a amBrain não afirma tê-los usado nem ter migrado um pipeline para um serviço gerenciado. O artigo não traz preços nem prazos da amBrain, e os valores em dólares acima são um exemplo inventado.
Se você conversar com a amBrain, comece pelo custo anual da sua diferença e pelas contagens por hora do seu dia de maior movimento.
Traga sua arquitetura atual e o modo de falha que preocupa você, e vamos analisá-lo juntos em meia hora.