Tráfego de Bot em Teste A/B: limpar antes de ler

Tráfego de bot não invalida um teste A/B por existir, invalida quando cai desigual entre as variações. Robô distribuído de forma não enviesada só adiciona ruído e reduz o poder do experimento; robô que age como um usuário só e alimenta sempre a mesma variação desloca a métrica daquele braço e troca o vencedor. Este guia mostra a diferença entre ruído e viés, por que executar JavaScript não separa pessoa de robô, um exemplo trabalhado em que um crawler apagou um ganho real de 13 por cento, e o método de detecção que os autores do tema propõem. Faz parte do nosso guia completo de teste A/B e é o vizinho direto do viés de instrumentação: lá o instrumento mede errado, aqui quem está sendo medido não é gente.

Ruído e viés são problemas diferentes

A intuição comum é que bot é sujeira e sujeira estraga tudo. A literatura de experimentação é mais precisa que isso.

Crook, Frasca, Kohavi e Longbotham, no artigo de KDD 2009 que catalogou sete armadilhas de experimentos controlados na web, colocam a distinção assim: para experimentação, a preocupação primária é remover os robôs que causam viés. Se o tráfego de um robô se distribui entre as variações de forma não enviesada, a presença dele adiciona ruído ao dado e reduz o poder do experimento, mas não invalida os resultados. Robôs vistos como múltiplos usuários únicos, porque resetam cookies ou rodam de várias máquinas, não introduzem viés. O caso que introduz viés é o robô que age como um único usuário e gera tráfego de forma consistente para uma única variação.

Isso muda a ordem das prioridades. Um site pode ter uma fração enorme de acessos automatizados e ainda assim rodar experimentos confiáveis, desde que o sorteio jogue esses acessos nos dois braços na mesma proporção. E um site com pouquíssimo bot pode ter um resultado completamente errado por causa de um único agente que insiste em uma URL.

mecanismo do robô	identidade	como se reparte	efeito no teste
Crawler que reseta cookie a cada visita	muitas, efêmeras	tende a simétrica	ruído, perda de poder
Robô rodando de várias máquinas	muitas	tende a simétrica	ruído, perda de poder
Robô com cookie estável e comportamento extremo	uma, persistente	fica presa a uma variação	viés, troca de vencedor
Crawler que só busca um padrão de URL	qualquer	só um braço em teste de URL dividida	viés, troca de vencedor
Monitor de disponibilidade batendo numa rota fixa	uma, persistente	só um braço	viés, troca de vencedor
Robô compartilhando máquina com uma pessoa	mista	segue o braço da pessoa	contamina a métrica daquele braço

A última linha merece um parágrafo. Os mesmos autores observam que robôs implementados automatizando um navegador real suportam toda a funcionalidade daquele navegador, inclusive cookies e JavaScript, e que quando um robô assim roda numa máquina também usada por uma pessoa, robô e pessoa costumam compartilhar o mesmo cookie. Se a identidade do usuário está guardada num cookie, o que é muito comum, aquele identificador passa a se comportar às vezes como pessoa e às vezes como robô. Não existe filtro por identificador que resolva esse caso de forma limpa.

O caso do portal MSN

O relato mais útil da literatura sobre esse tema é curto e específico. Num experimento no portal MSN, uma mudança pequena foi feita em um único módulo da página. O resultado apareceu com taxa de clique estatisticamente diferente em várias áreas da página, inclusive áreas sem relação nenhuma com a mudança.

A investigação encontrou a causa: robôs que aceitavam cookies e executavam JavaScript. Segundo os autores, executar código em JavaScript é uma das características mais comuns usadas para separar pessoas de robôs, e alguns fornecedores de análise chegam a afirmar que a marcação de página via JavaScript é tão robusta que dispensa qualquer detecção adicional de robô. Naquele caso, porém, os robôs estavam executando eventos de clique, que no portal MSN disparam quando um usuário clica num link, a taxas extremas da ordem de 100 por minuto durante 2,5 horas.

O detalhe que interessa a quem lê painel de teste A/B não é o número em si, é o formato da anomalia: diferença significante onde não houve mudança. Esse é o sinal mais barato de que existe alguma coisa não humana no dado, e ele é lido de graça em qualquer scorecard que mostre métricas secundárias ao lado da primária.

Exemplo trabalhado: o crawler que apagou um ganho real

Todos os números abaixo saíram da mesma calculadora de significância embutida logo a seguir, com teste bilateral, e você pode reproduzir cada linha colando as contagens.

O cenário é um teste de URL dividida numa página de produto. A variação B mora numa URL própria. Um crawler de comparação de preços descobre essa URL e passa a visitá-la, em várias sessões, sem nunca comprar nada.

Leitura A, o dado real das pessoas. A recebeu 40.000 visitantes e 1.200 pedidos, uma taxa de 3,000 por cento. B recebeu 40.000 visitantes e 1.360 pedidos, 3,400 por cento. A calculadora devolve lift relativo de 13,33 por cento, z igual a 3,2141 e valor-p de 0,001309, com intervalo de confiança de 0,156 a 0,644 ponto percentual para a diferença absoluta. B vence, e vence com folga.

Leitura B, o dado como ele chega ao painel. O crawler somou 6.000 visitas à variação B, nenhuma delas com pedido. Agora B tem 46.000 visitantes e os mesmos 1.360 pedidos, uma taxa de 2,957 por cento. A calculadora devolve lift relativo de menos 1,45 por cento, z igual a menos 0,3742 e valor-p de 0,708243, com intervalo de menos 0,271 a 0,184 ponto percentual. O resultado não é apenas não significante: o sinal inverteu, e a leitura de superfície é “a variação nova perdeu”.

leitura	visitantes A	pedidos A	visitantes B	pedidos B	taxa B	lift relativo	valor-p	veredito
Só pessoas	40.000	1.200	40.000	1.360	3,400%	+13,33%	0,001309	B vence
Com 3.000 visitas de robô em B	40.000	1.200	43.000	1.360	3,163%	+5,43%	0,175281	inconclusivo
Com 6.000 visitas de robô em B	40.000	1.200	46.000	1.360	2,957%	menos 1,45%	0,708243	B perde

Repare na linha do meio. Com metade da contaminação o experimento não vira uma derrota, vira um empate. Empate é o desfecho mais caro dos três, porque ninguém investiga um empate: a variação é descartada em silêncio e o ganho de 13 por cento nunca é implementado.

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.

Vale registrar que a direção do estrago depende de qual lado da fração o robô toca. No exemplo acima o robô inflou o denominador e afundou a taxa. Um robô que dispara eventos de clique, como no caso do MSN, infla o numerador e levanta a taxa da variação onde ele mora, produzindo um vencedor que não existe. As duas falhas têm a mesma origem e o mesmo remédio.

Por que a lista de bots conhecidos não basta

A camada mais comum de defesa é a lista de agentes conhecidos. A documentação do Google Analytics informa que o tráfego de bots e spiders conhecidos é excluído automaticamente, usando uma combinação de pesquisa do Google com a International Spiders and Bots List mantida pelo Interactive Advertising Bureau. A mesma página registra que, no momento, não é possível desativar essa exclusão nem ver quanto tráfego de bot conhecido foi excluído.

Isso é útil e é insuficiente, por dois motivos estruturais.

O primeiro é o critério de entrada na lista: ela cataloga agentes que se declaram. Um rastreador de busca, um verificador de link, um pré-visualizador de rede social e um monitor de disponibilidade se identificam porque ser identificável faz parte da função deles. Um agente que não quer ser reconhecido simplesmente não aparece com um nome catalogável.

O segundo é a falta de visibilidade. Quando a exclusão acontece antes do dado chegar ao seu relatório e o volume excluído não é exposto, você não consegue responder à única pergunta que importa para experimentação: o que foi removido caiu igual nos dois braços? Uma exclusão simétrica é inofensiva. Uma exclusão que removeu mais de um lado do que do outro é, ela mesma, uma fonte de viés.

camada	o que pega	o que não pega
Lista de agentes conhecidos (IAB e similares)	rastreadores de busca, ferramentas de SEO, pré-visualizadores de link, monitores	agente que não se declara
Exigir execução de JavaScript	script simples, cliente HTTP puro	navegador automatizado (o caso do MSN)
Limiar de eventos por sessão	comportamento extremo e óbvio	robô calibrado para parecer humano
Teste A/A e re-sorteio retroativo	viés de alocação, qualquer que seja a origem	não diz quem é o robô, só que existe assimetria

A última linha é a que fecha o problema, e é a proposta original dos autores do artigo de 2009.

Detecção por teste A/A e por re-sorteio retroativo

Os autores reconhecem que identificar todos os robôs é difícil em geral e que não existe uma forma clara de avaliar quão bem um algoritmo de detecção se comporta em dado real. A saída que eles propõem é elegante: usar o próprio experimento controlado como função de avaliação, pelo menos para os robôs mais críticos para a análise, aqueles que conseguem distorcer resultados por aceitarem cookies e se comportarem como usuários extremos.

O esquema é o teste A/A: usuários são divididos em controle e tratamento, mas não existe diferença sistemática entre as duas versões a que eles são expostos. A hipótese nula num teste A/A deveria ser rejeitada em torno de 5 por cento das vezes quando se usa nível de confiança de 95 por cento. Se isso não se sustenta, existe viés introduzido por comportamento extremo de usuários, que muito provavelmente são robôs alocados numa variação específica. Os autores destacam que é preciso rodar múltiplos testes A/A para ter confiança sobre a existência de robôs enviesados.

O detalhe operacional mais valioso vem em seguida: esses testes não precisam ser ao vivo. Segundo os autores, é suficiente rodar de forma retroativa, re-sorteando os usuários e atribuindo-os a controle e tratamento, e avaliando a hipótese de que os dois grupos são iguais. Em termos práticos, isso significa que você pode auditar viés de robô no dado histórico que já tem, hoje, sem consumir uma semana de tráfego.

Assinaturas práticas no seu próprio dado

Antes de investir em detecção sofisticada, existem consultas baratas que resolvem a maioria dos casos. Todas partem do mesmo princípio: robô que enviesa é robô que se comporta como usuário extremo.

1. Cauda de eventos por identificador. Ordene os identificadores pelo número de eventos no período. Se o topo da lista tiver ordens de grandeza a mais que a mediana, olhe esses identificadores um a um. O tratamento estatístico da cauda longa está em outliers e capping, e vale notar que capping trata o sintoma sem responder se o extremo era pessoa.
2. Ritmo dentro da sessão. Pessoas têm intervalos irregulares entre eventos. Cadência quase constante, ou dezenas de eventos por minuto sustentados por horas, é assinatura mecânica.
3. Distribuição por variação dos identificadores extremos. Esta é a consulta que decide se você tem ruído ou viés: pegue o top 1 por cento de identificadores por volume e verifique como eles se repartem entre os braços. Repartição igual é ruído. Repartição desigual é o seu problema.
4. Divisão de tráfego geral. Um desvio na proporção de visitantes entre as variações é o alarme mais barato do arsenal, e vale tanto para robô quanto para qualquer outra falha de coleta. O procedimento completo está em divisão desigual de tráfego e pode ser rodado no verificador de SRM.
5. Métricas que não deveriam ter mudado. É a assinatura do caso MSN. Se o experimento tocou um módulo e três áreas não relacionadas mudaram, a hipótese de robô entra na frente da hipótese de efeito.
6. Simetria do próprio filtro. Depois de aplicar qualquer regra de exclusão, compare quantos registros ela removeu de cada braço. Um filtro assimétrico é uma nova fonte de viés.

Onde filtrar tráfego de bot: coleta, ingestão ou análise

ponto	vantagem	risco
Na coleta (o evento nem é enviado)	dado limpo desde a origem	o que foi descartado não pode ser auditado depois
Na ingestão (marcado e separado)	permite comparar bruto contra limpo	exige guardar o volume marcado
Na análise (excluído na consulta)	regra revisável, reprodutível	regra pode ser mexida depois de ver o resultado

A configuração mais defensável costuma ser a do meio: marcar na ingestão, guardar tudo, excluir na análise por uma regra escrita no plano de análise pré-registrado. Assim você consegue reportar as duas leituras, bruta e limpa, e mostrar que a conclusão não depende do filtro. Quando as duas leituras discordam, isso é informação, não constrangimento: é exatamente o achado que justifica investigar antes de decidir.

Checklist antes de confiar no número

1. A regra de exclusão está escrita antes do teste começar? Filtro escolhido depois é grau de liberdade.
2. Você consegue ver o volume filtrado por variação? Se não, não dá para afirmar que o filtro foi simétrico.
3. A divisão de tráfego passa no dado já limpo? Verificar antes de filtrar responde a pergunta errada.
4. O top de identificadores por volume está repartido igual entre os braços?
5. Alguma métrica sem relação com a mudança se mexeu?
6. Existe uma bateria de testes A/A, ao vivo ou retroativa, sobre este mesmo segmento de tráfego?
7. A conclusão sobrevive às duas leituras, bruta e limpa?

Erros comuns

• Tratar volume de bot como se fosse o problema. O que quebra o experimento é assimetria, não volume.
• Confiar que executar JavaScript separa pessoa de robô. O caso MSN existe justamente para desmentir isso.
• Filtrar depois de ver quem ganhou. Se o filtro muda o vencedor e foi escolhido depois, o resultado não é defensável, mesmo que o filtro esteja tecnicamente certo.
• Excluir sem contar o que foi excluído. Um filtro assimétrico substitui um viés por outro.
• Rodar um único teste A/A e concluir que está tudo bem. Um A/A isolado rejeita a nula 5 por cento das vezes por construção. O sinal está na distribuição de uma bateria.
• Confundir robô com fraude. Boa parte do tráfego automatizado é legítima e declarada. O objetivo aqui é medir gente, não punir ninguém.
• Aplicar capping e considerar o caso encerrado. Limitar a cauda reduz a variância e não responde se o extremo era humano.

Faça isso automático na Donnu

O problema prático raramente é a falta de vontade de filtrar. É que a decisão sobre bot acontece longe do painel: alguém escreveu uma regra em algum lugar, meses atrás, e ninguém consegue dizer se ela removeu mais de um braço do que do outro neste experimento específico.

Na Donnu, a proporção observada de visitantes por variação fica visível ao lado do resultado desde o primeiro dia do teste, e não escondida num relatório de saúde separado, porque assimetria de alocação é o sintoma comum a robô, a falha de coleta e a bug de sorteio. Se você quiser refazer qualquer conta na mão, a calculadora de significância aceita as contagens brutas e as filtradas para você comparar as duas leituras lado a lado, e o verificador de SRM testa a divisão de tráfego antes de você olhar o vencedor.

Referências

• Crook, T., Frasca, B., Kohavi, R. e Longbotham, R. Seven Pitfalls to Avoid when Running Controlled Experiments on the Web. KDD 2009. Fonte da armadilha 5 (negligenciar a filtragem de robôs); da distinção entre robô distribuído de forma não enviesada, que adiciona ruído e reduz o poder sem invalidar resultados, e robô que age como usuário único alimentando uma variação, que cria viés significativo; da observação de que robôs vistos como múltiplos usuários únicos por resetarem cookies ou rodarem de várias máquinas não introduzem viés; do caso do portal MSN, com diferenças estatisticamente significantes em áreas não relacionadas da página causadas por robôs que aceitavam cookies e executavam JavaScript disparando eventos onclick a cerca de 100 por minuto durante 2,5 horas; do registro de que alguns fornecedores de análise afirmam que a marcação via JavaScript dispensa detecção adicional de robô; do caso do robô que compartilha cookie com uma pessoa na mesma máquina; e do esquema de avaliação por testes A/A, incluindo a variante retroativa por re-sorteio dos usuários. exp-platform.com.
• Google. [GA4] Bot traffic. Central de Ajuda do Google Analytics. Fonte da afirmação de que o tráfego de bots e spiders conhecidos é excluído automaticamente, de que a identificação usa uma combinação de pesquisa do Google com a International Spiders and Bots List mantida pelo Interactive Advertising Bureau, e de que não é possível desativar essa exclusão nem ver quanto tráfego de bot conhecido foi excluído. support.google.com.
• Interactive Advertising Bureau. IAB/ABC International Spiders and Bots List. Fonte da existência e do escopo da lista de agentes automatizados declarados usada como referência de mercado para exclusão de tráfego não humano. iab.com.
• Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. e Pohlmann, N. Online Controlled Experiments at Large Scale. KDD 2013. Fonte do contexto de escala em que essas verificações rodam, com cada experimento expondo vários milhões de usuários e mais de 200 experimentos concorrentes por dia, e da descrição do sistema de alerta que detecta automaticamente eventos de qualidade de dado. exp-platform.com.

Leia também: Viés de instrumentação · Divisão desigual de tráfego (SRM) · Teste A/A: validar a montagem · Outliers e capping · Plano de análise pré-registrado · Calculadora de significância · Read in English