Filtragem de tráfego inválido em uma plataforma de publicidade: o que o seu time pode construir e quando comprar um fornecedor de verificação

Construa você mesmo a filtragem do tráfego inválido geral e compre a detecção do tipo sofisticado de um fornecedor de verificação, a menos que possa bancar um time antifraude próprio. O tráfego inválido geral, como endereços conhecidos de data centers, bots declarados e anúncios invisíveis de 1x1, é pego com listas e regras. Os seus próprios engenheiros podem aplicá-las quando chega uma requisição e de novo nos logs. O tráfego inválido sofisticado, como dispositivos sequestrados e apps falsificados, precisa de dados de muito mais tráfego do que uma única plataforma vê, e de analistas que o estudem. Programas de certificação, como o da TAG, também esperam uma filtragem feita por um terceiro qualificado.

O que conta como tráfego inválido?

O Media Rating Council (MRC) é o órgão dos EUA que credencia a medição publicitária. O seu Invalid Traffic Detection and Filtration Standards Addendum (a atualização de junho de 2020, consultada em 27 de outubro de 2026, como as demais fontes aqui) divide o tráfego inválido em dois tipos. O tráfego inválido geral, ou GIVT, é o “tráfego identificado por meios rotineiros de filtragem, executados com a aplicação de listas ou de outras verificações padronizadas de parâmetros”. Entre os exemplos do MRC estão:

• Tráfego inválido conhecido vindo de data centers
• Bots, spiders e outros crawlers
• Requisições de user agents que não são navegadores ou de navegadores desconhecidos
• Páginas pré-carregadas ou pré-renderizadas que nenhum usuário real chegou a ver
• Posicionamentos invisíveis, como anúncios de 0x0 ou 1x1 pixel

O tráfego inválido sofisticado, ou SIVT, abrange “situações mais difíceis de detectar, que exigem análises avançadas, corroboração ou coordenação a partir de vários pontos, intervenção humana significativa etc. para serem analisadas e identificadas”. Entre os exemplos do MRC estão:

• Softwares de automação e emuladores
• Dispositivos infectados e sequestrados
• Atividade humana paga e organizada, como fazendas de cliques
• Cliques e redirecionamentos forçados
• Eventos de medição falsificados
• Domínios e apps falsificados

Quais filtros os nossos próprios engenheiros podem construir?

O tipo geral foi feito para ser compartilhado. O MRC diz que a filtragem de GIVT “deve ser consistente entre fornecedores”, e por isso ela se apoia em listas comuns. Um time interno trabalha com duas delas:

• A IAB/ABC International Spiders & Bots List, mantida pela Alliance for Audited Media em nome do IAB Tech Lab
• A Data Center IP List, que o Trustworthy Accountability Group (TAG) publica todo mês

Além das listas, o time escreve regras para user agents, tamanhos de anúncio e requisições de pré-carregamento, aplicadas quando chega uma requisição e de novo quando os eventos são registrados. Ele também guarda um registro de cada requisição filtrada e do motivo, para que os números possam ser explicados aos parceiros.

Para as empresas de medição que audita, o MRC define um ponto de partida para o tráfego de data centers. Elas precisam filtrar o tráfego inválido vindo de endereços IP das “três maiores entidades de hospedagem conhecidas: Amazon AWS, Google e Microsoft”. Há exceções para que usuários reais que acessam a web por essas redes não sejam filtrados por engano.

A filtragem pode acontecer em dois momentos. Logo de início, a plataforma bloqueia uma requisição de anúncio ou deixa de dar lance nela. Depois, ela remove os eventos inválidos dos logs e das contagens. O MRC escreve: “Cada técnica tem certos pontos fortes e fracos, e ambas têm lugar em uma estratégia de proteção de tráfego bem executada.” Bloquear cedo também economiza o custo de processar uma requisição que seria descartada depois.

As listas perdem força à medida que navegadores e apps compartilham menos dados. Em uma atualização de 2024, o MRC colocou assim: “Um endereço IP limitado ou ausente e uma string de User Agent (UA) menos granular podem prejudicar as abordagens baseadas em listas.”

Quando vale a pena pagar um fornecedor de verificação?

A detecção do tráfego sofisticado depende de ver padrões em muitos publishers, apps e dispositivos, e de analistas que acompanham os novos esquemas à medida que surgem. Uma plataforma vê apenas o próprio tráfego, então deixa passar os padrões que só aparecem quando muitas delas são vistas juntas. Um time que faz isso bem equivale a uma empresa antifraude dentro da sua empresa.

A certificação pode decidir a questão. O programa Certified Against Fraud da TAG cita como um dos requisitos principais que “100% das suas transações monetizáveis sejam filtradas para detecção e remoção de IVT por um terceiro qualificado”. A TAG permite que os publishers cumpram isso por meio de uma supply-side platform que tenha um selo de certificação válido. Se os seus compradores ou parceiros pedem a certificação da TAG, filtros construídos por você não vão cumprir esse requisito sozinhos.

O MRC publica uma lista dos serviços que credencia. A lista digital inclui empresas de verificação como DoubleVerify, HUMAN, Integral Ad Science, Pixalate e Protected Media. O credenciamento cobre serviços e métricas específicos, então pergunte ao fornecedor quais dos serviços dele são credenciados e se isso inclui o tráfego inválido sofisticado.

Construir, comprar ou os dois: o que cada caminho cobre?

• Só com recursos próprios: você pega o tráfego inválido geral ao custo do tempo dos seus engenheiros e de eventuais assinaturas de listas, e as regras e os dados são seus. Os esquemas sofisticados passam, e os requisitos de filtragem por terceiros ficam sem atender.
• Só um fornecedor: os dois tipos são detectados, mas cada decisão depende dos sistemas e das tarifas do fornecedor, e uma verificação do fornecedor dentro do caminho do lance acrescenta tempo a cada requisição.
• Os dois: os seus próprios filtros descartam cedo e com pouco custo o tráfego óbvio, e o fornecedor vê apenas o tráfego que passou por eles.

O que a plataforma precisa registrar em qualquer caminho?

Quem faz a detecção precisa dos detalhes de cada transação de anúncio. O MRC lista os campos que uma empresa de medição deve capturar quando possível, entre eles:

• O tipo de evento, um ID de transação e um timestamp
• O endereço IP, incluindo o cabeçalho X-Forwarded-For quando o tráfego passa por proxies
• A string completa do user agent e o tipo de dispositivo
• O identificador do app, ou a URL completa da página onde o anúncio foi exibido
• Os IDs do publisher, do site e do posicionamento, e as informações de ads.txt ou app-ads.txt do publisher
• Os atributos de OpenRTB da requisição de lance

Os relatórios devem manter separados os números brutos e os filtrados. Para relatórios de campanha, o padrão do MRC lista “Gross Metrics (Completely Unfiltered)” e “Net Metrics (Filtered for GIVT Requirements)”. Quando se aplicam, os números filtrados para tráfego inválido sofisticado aparecem como uma etapa à parte. Se o seu pipeline de eventos já perde eventos ou os conta duas vezes, corrija isso primeiro: a filtragem não consegue consertar números que já estavam errados antes dela.

O que perguntar à empresa que integra a filtragem à nossa plataforma?

• Em que ponto do caminho do lance roda cada filtro, e quanto tempo ele acrescenta a uma requisição?
• Se a verificação do fornecedor não responder a tempo, a requisição segue ou é descartada?
• Como as listas são atualizadas, e quem confere que usuários reais não estão sendo filtrados por engano?
• Como os números brutos e filtrados vão aparecer nos nossos relatórios e nos relatórios dos nossos parceiros?
• Quais campos de cada requisição ficam armazenados, por quanto tempo e sob quais regras de privacidade?

A última pergunta também importa para o MRC. A atualização de 2024 diz que “as regulamentações de privacidade não são uma barreira a ser contornada com engenharia, mas requisitos rígidos que precisam ser cumpridos”.

Onde a amBrain se encaixa?

A amBrain, que publica este blog, constrói os sistemas aos quais a filtragem se conecta. Uma das suas linhas diz: “A amBrain constrói ad servers: segmentação, limite de frequência e relatórios.” Outra diz: “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.” Entre os trabalhos dela em AdTech está o RTBBidder, uma demand-side platform que ela construiu para um cliente.

Ela constrói software desde 2019 e 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.”

Este artigo não é um estudo de caso. Ele não diz que a amBrain construiu detecção de fraude para algum cliente nem que ela oferece verificação. Se a amBrain estiver na sua lista curta, faça a ela as mesmas perguntas que faria a qualquer outra empresa.