A maior parte do nosso tráfego de busca nunca foi humana
Por Oleg Sidorkin, CTO da Cinevva
Nosso tráfego de busca orgânica está crescendo, e isso vem acontecendo durante todo o ano. Essa parte é real. Mas, no início de julho, a linha deu um salto que não correspondia a nada que havíamos lançado, e vale a pena dedicar uma tarde a investigar um salto sem causa aparente.
Fomos procurar e encontramos uma frota de Chrome headless chegando com um referenciador do Google.
O formato importa mais do que o pico
Durante a primavera, a proporção de tráfego falso oscilou entre um terço e dois terços das sessões. Isso corresponde, aproximadamente, ao ruído de fundo com o qual qualquer site público convive.
No fim de junho, ela começou a subir e continuou subindo. Considerando a primeira semana de abril como ponto de partida, as sessões reais cresceram cerca de 5,5 vezes até meados de julho. As automatizadas cresceram cerca de 18,6 vezes.
O que dificultou enxergar o problema
Acompanhamos esses números de perto, e qualquer movimento sem explicação leva à criação de uma consulta para investigá-lo. O motivo pelo qual este caso exigiu uma investigação profunda é que nossas linhas de sessão realmente não conseguiam distinguir as duas populações.
O engajamento era inferido a partir do timestamp last_activity_at de cada sessão. Em uma visita de página única, esse campo nunca muda depois da primeira gravação.
Assim, um bot que carrega uma página e vai embora grava a mesma linha que uma pessoa que chega a um guia e passa cinco minutos lendo. Taxa de rejeição, tempo no site, engajamento — tudo era calculado com base em um campo que não contém informação alguma para sessões de página única. Isso não é incomum. É o padrão na maioria das soluções próprias de analytics e seria a primeira coisa que eu verificaria na sua.
A solução foi parar de inferir a partir da linha da sessão e, em vez disso, ler o beacon de saída, que informa o tempo real na página e a profundidade da rolagem a partir do cliente. Com evidências em vez de inferências, os dois grupos se separaram imediatamente.
| Marcadas | Todas as demais | |
|---|---|---|
| Rolou a página em algum momento | 1,8% | 56,5% |
| Pertence a uma conta conectada | 0,05% | 29% |
Essa diferença é nossa evidência de que o classificador descreve algo real, em vez de rotular visitantes discretos como robôs.
O que realmente denuncia uma frota
O user agent é o pior lugar para procurar, porque é a coisa mais barata de alterar. O melhor sinal acabou sendo a placa de vídeo.
Navegadores headless em um data center não têm GPU, por isso recorrem à renderização por software, e o WebGL revela a string do renderizador sem precisar ser perguntado duas vezes. SwiftShader, llvmpipe, Mesa OffScreen. Visitantes reais têm GPUs reais.
| Sinal | O que detecta | Proporção das nossas evidências |
|---|---|---|
| Renderizador de GPU por software | Ausência de placa de vídeo física | 90,5% |
| ASN de data center ou proxy | Origem de rede alugada | 58% |
navigator.webdriver | Indicador de automação deixado ativado | 10,4% |
A origem da rede ajudou menos do que se poderia esperar. Aproximadamente quatro em cada dez dessas sessões saem por provedores de internet residenciais legítimos. Proxies residenciais agora são baratos, e qualquer regra que presuma que bots vêm da AWS deixará passar quase metade deles.
O restante veio de impossibilidades físicas nas informações que o cliente fornecia sobre si mesmo. Um user agent do Chromium sempre termina com um token do Safari correspondente ao seu token AppleWebKit, fixado em 537.36 desde 2013, e essa frota emitia erros de digitação: Safari/537.35 e .38. Um user agent de celular alegava ter uma tela de 1600x1200. Outra variante alegava um quadrado perfeito de 1600x1600. Uma delas alegava 1200x3000, um monitor de desktop em modo retrato com proporção de 2,5:1 que ninguém fabrica.
Cada uma dessas configurações pertence ao emulador de alguém, e nenhuma aparece a menos que você vá procurá-la.
A frota se adaptou toda vez que a marcamos
O primeiro perfil era Linux Chrome, um referenciador do Google, America/New_York, 1920x1080. Criamos uma regra.
Uma variante voltou com 800x600 em UTC. Ampliamos a regra.
Depois apareceu um grupo chinês usando endereços residenciais da China Mobile e da Unicom, com versões fixas de navegador, incluindo o Chrome 99 de março de 2022 e o padrão de emulação de dispositivos do Chrome DevTools: um Nexus 5 de 2015 executando o WeChat de 2018. Esses acessos saem por provedores residenciais, então todas as nossas regras de rede eram inúteis contra eles.
Depois surgiu uma versão dos EUA na Cox e na Comcast, com um user agent atual e totalmente plausível do Chrome 146, em 1920x1080. Nada nessa impressão digital está errado e, analisando uma sessão de cada vez, ela é indistinguível de um visitante real.
Por isso, o último detector que criamos não analisa sessões individuais. Ele agrupa as 48 horas anteriores por país, user agent, tamanho de tela e origem do tráfego, e então procura clusters de pelo menos 20 sessões anônimas nos quais 95% ou mais nunca leem por três segundos nem rolam um único pixel.
Visitantes reais não formam clusters tão precisos. Vinte desconhecidos com um navegador idêntico, em uma resolução idêntica, que saem sem ler nada são uma máquina com vinte endereços. Qualquer integrante do cluster que tenha lido ou rolado continua sendo considerado humano, e sessões associadas a uma conta real nunca são marcadas.
A auditoria também encontrou o erro oposto
Enquanto removíamos visitantes falsos dos números, encontramos visitantes reais que vínhamos descartando.
Quando obtivemos tempos de leitura reais, descobrimos que 34,2% do que havíamos contado como bounces humanos eram pessoas que liam por 30 segundos ou mais, ou rolavam além da metade da página. Um terço dessas "falhas" era, na verdade, o conteúdo funcionando. Leitores chineses que chegavam pelo Bing passavam cinco minutos em um único guia e eram registrados como bounces.
Os números estavam errados nas duas direções ao mesmo tempo, e ambos os erros apontavam para a mesma conclusão equivocada. Juntos, eles fazem seu tráfego parecer grande e superficial quando, na verdade, ele é menor e mais profundo.
O canal pelo qual pagamos foi o mais honesto
Últimos 30 dias. A busca orgânica do Google representou 63,7% de todas as sessões nesse período.
Todo instinto de crescimento aponta na direção contrária. Você presume que o tráfego pago é onde está sendo fraudado e que o orgânico é onde conquistou os resultados. No nosso caso, era o inverso.
Se tivéssemos realocado o orçamento com base nos números de julho, teríamos tirado dinheiro do canal que realmente trazia humanos e investido na produção de mais conteúdo para um scraper.
Por que vale a pena dedicar uma tarde a isso
O número em si é apenas um número. Depois dele vêm as páginas que escreveremos, o idioma em que investiremos, a sobrevivência ou não de uma campanha à avaliação e se o trimestre pareceu bom o bastante para continuarmos fazendo a mesma coisa. Tudo isso pode ser influenciado por um desconhecido com um pool barato de proxies.
Se você administra um site pequeno, verifique as strings dos renderizadores de GPU e os beacons de saída antes de confiar na sua própria curva de crescimento.
E trate nossos números como um piso, não como um veredito. Aqui, "humano" significa apenas "ainda não detectado"; as regras foram criadas a partir das impressões digitais que por acaso observamos, e ainda não sabemos quem opera essa frota nem o que querem com um site de criação de jogos.
Conteúdo relacionado:
- A armadilha do custo fixo — outro número que acabou não tendo nenhum amortecedor por trás
- Por que criamos nosso próprio motor WebGPU — o mesmo argumento sobre controlar a camada da qual você depende
- Guias — o conteúdo que esta auditoria deveria estar medindo