Verificação JavaScript ou bloqueio por IP: duas abordagens contra bots

Quando um anunciante decide se proteger de bots, a primeira pergunta costuma ser técnica: bloquear por IP ou colocar um script na página? São duas maneiras diferentes de olhar para uma visita. O bloqueio por IP avalia de onde veio a requisição. A verificação JavaScript avalia que programa a enviou. Cada abordagem tem seu ponto cego, e é exatamente por isso que uma proteção séria não escolhe entre elas, combina as duas.

A seguir: como cada abordagem funciona, o que pega bem, onde erra e como fazer as duas trabalharem juntas sem perder velocidade de página.

Bloqueio por IP: como funciona

O servidor recebe a requisição e sabe pouco sobre ela: o endereço IP, os cabeçalhos do navegador, a página de origem. Mas um IP revela bastante:

• a quem pertence a rede: provedor doméstico, operadora móvel, hospedagem, nuvem (pelo número de sistema autônomo, ASN);
• país e cidade, com precisão suficiente para um filtro de geo;
• marcações em bases: VPN conhecida, proxy, Tor, endereço de armadilhas de spam;
• histórico: quantas vezes esse endereço já apareceu e como terminou.

A decisão é tomada antes de a página ser entregue. Essa é a principal vantagem da abordagem: não custa nada em velocidade e funciona até contra programas que não executam scripts.

O que o bloqueio por IP pega

• Bots de servidor. A maioria dos bots baratos, scrapers e scanners roda em datacenters. Bloquear ASNs de hospedagem elimina esses bots quase sem erro. Mais no artigo VPN, proxy e IPs de datacenter.
• VPNs conhecidas e proxies de servidor. Os endereços deles entram nas bases com frequência.
• Endereços que se repetem. Um limite de cliques por IP e uma lista negra de IP barram visitantes insistentes e o concorrente que clica do escritório.
• Geo errada. Um clique de um país que você não segmentou quase nunca é comprador.

Pontos fracos do bloqueio por IP

• Proxies residenciais e móveis. O bot sai para a internet pelo endereço de um assinante doméstico ou pelo chip de uma operadora. Para um filtro por IP, é uma pessoa comum. Há um artigo só sobre isso: proxies residenciais e móveis.
• Endereços compartilhados. Atrás de um IP móvel há centenas de assinantes, atrás de um de escritório, dezenas de funcionários. Bloquear esse endereço corta gente de verdade.
• Rotação. Um bot que troca de endereço a cada clique escapa dos limites de frequência e das listas negras.
• Atraso das bases. Um endereço novo entra na base horas ou dias depois, e até lá já fez o estrago.
• Sem visão por dentro. O IP não diz se é um navegador ou um script, se há tela ou se o mouse se mexe.

Verificação JavaScript: como funciona

A página entrega ao visitante um script pequeno. Ele roda no navegador e coleta o que só se vê por dentro:

• sinais de automação: a flag webdriver, rastros de ferramentas de controle do navegador, particularidades típicas do modo headless;
• impressão digital do dispositivo: tela, placa de vídeo, fontes, recursos do navegador;
• configurações do sistema: fuso horário, idioma, layout do teclado;
• coerência: se o que o cabeçalho User-Agent declara bate com o que o navegador realmente faz;
• comportamento: movimentos do mouse e do dedo, rolagem, tempo até a primeira ação.

O script envia o resultado ao servidor, e o servidor decide. Como a impressão digital é montada e onde ela é falsificada está no artigo navegadores headless e fingerprint do navegador.

O que a verificação JavaScript pega

• Programas sem navegador. Scrapers e bots simples que baixam a página mas não executam o script nunca devolvem resposta. Isso por si só já é um sinal forte.
• Navegadores headless e automação. Mesmo em IP residencial, um bot controlando um navegador deixa rastros.
• Dispositivos falsificados. Um «iPhone» com placa de vídeo de servidor e tela de 1920×1080 se entrega pela contradição.
• Divergência entre rede e sistema. IP da Alemanha, mas fuso e idioma asiáticos. A rede não vê isso, o script vê.
• Comportamento mecânico. Movimentos perfeitamente retos, saída instantânea, clique sem nenhum movimento antes.

Pontos fracos da verificação JavaScript

• Tempo. É preciso baixar o script, executá-lo e esperar a resposta do servidor. É um atraso que o bloqueio por IP não tem.
• Nem toda visita executa. Os navegadores embutidos das redes sociais às vezes carregam a página em segundo plano e congelam os timers; celulares antigos executam o script devagar; parte das pessoas sai antes de a verificação terminar.
• Dá para falsificar. Os dados vêm do cliente, então um bot avançado pode trocá-los. Os navegadores antidetect existem justamente para isso.
• Falsos positivos em dispositivos incomuns. WebViews de apps, navegadores com privacidade reforçada, extensões que bloqueiam a impressão digital: tudo isso parece falsificação, mesmo com uma pessoa atrás da tela.
• Depende de onde está instalada. O script só funciona onde foi colocado. Se o link leva a uma página sem ele, não há verificação.

Comparação das abordagens

A tabela mostra o essencial: os pontos fracos das duas abordagens quase não se sobrepõem. O que a rede não vê, o navegador vê, e vice-versa.

Por que combinar

Com apenas o bloqueio por IP, toda a fraude em endereços residenciais e móveis passa pelo filtro, e essa é justamente a parte mais cara: os cliques parecem reais e são pagos a preço cheio. Com apenas o script, todo bot de servidor recebe a página, baixa o script e sobrecarrega o servidor, enquanto bots simples que não executaram a verificação ficam indistinguíveis de pessoas que não esperaram a página carregar.

Um esquema que funciona é assim:

1. Rede como primeira camada. Datacenters, bots conhecidos, endereços da lista negra e geo errada são cortados sem conversa. Barato, rápido e quase sem erro.
2. Navegador como segunda camada. Tudo o que passou pela rede é checado pelo script: automação, impressão digital, fuso e idioma, comportamento.
3. Pontuação de confiança em vez de proibições. Sinais fracos (marcação de proxy, endereço móvel, fuso que não bate, ausência de click ID) não bloqueiam a visita sozinhos, eles se somam. A decisão sai do total.
4. Estatísticas por fonte como terceiro olhar. Nem a melhor verificação de uma visita substitui olhar a fonte de tráfego inteira: fatia de visitas suspeitas, conversões, aprovação. É assim que aparecem os cliques de fazendas e a fraude em anúncios sistemática.

Assim os erros pendem a favor do anunciante: uma pessoa real com VPN não é cortada por um único sinal, e um bot em endereço residencial não passa só porque o endereço está limpo.

Como isso afeta a velocidade da página

Velocidade importa por mais do que conforto: cada segundo extra de carregamento derruba a conversão, e uma proteção que espanta compradores sai mais cara que os bots. O que dá para fazer:

• Resolver a parte de rede antes. Enquanto o navegador carrega o script, o servidor já pode checar IP, ASN e bases. Quando o script manda os dados, metade da decisão está pronta.
• Script pequeno e uma conexão só. Quanto menos requisições e mais perto o servidor estiver do visitante, menor a espera. Script comprimido e reaproveitamento da conexão economizam dezenas de milissegundos no móvel.
• Não esperar comportamento onde não precisa. Checar movimentos do mouse exige que o visitante faça algo na página. Ative isso para fontes rigorosas, não para todo o tráfego.
• Cortar bots de servidor antes do script. Se o bot caiu na rede, não precisa receber o script: isso poupa recursos do servidor e deixa as estatísticas mais limpas.
• Medir. Olhe o tempo do clique até a página aparecer em visitas reais, não um teste de laboratório num computador rápido.

Conclusão sobre velocidade: bem implementada, a verificação combinada acrescenta frações de segundo ao carregamento. É bem menos do que se perde com imagens pesadas e contadores de terceiros, e incomparavelmente mais barato do que cliques de bots pagos.

Exemplo: três visitas vistas por duas camadas

Para ver como as abordagens se completam, vamos analisar três cliques numa mesma campanha segmentada para a Alemanha.

Visita A. Endereço de hospedagem em nuvem em Frankfurt, o cabeçalho do navegador diz Chrome recente no Windows. A camada de rede corta na hora: rede de hospedagem em tráfego de anúncio é servidor, não comprador. Nem foi preciso o script, a página não foi entregue e o servidor não gastou recursos.

Visita B. Endereço de provedor doméstico em Munique, limpo nas bases, click ID presente. Pela rede não há o que questionar. O script informa: flag de automação ligada, placa de vídeo por software, fuso America/New_York, nenhum movimento de mouse antes do clique. O bloqueio por IP deixaria essa visita passar, e você pagaria por ela como se fosse real. A camada do navegador a barra.

Visita C. Endereço móvel de uma operadora alemã, marcado como compartilhado, navegador embutido de uma rede social, fuso Europe/Berlin, idioma alemão. O script rodou com atraso porque o app carregava a página em segundo plano. Se o filtro cortasse endereços móveis ou exigisse resposta instantânea do script, esse comprador estaria perdido. A pontuação de confiança vê que os sinais batem e deixa a visita passar.

Nesse exemplo, cada camada sozinha teria errado pelo menos uma vez: só a rede deixaria passar a visita B, e um script rígido sem pontuação de confiança arriscaria cortar a visita C. Juntas, acertaram as três. No tráfego real é igual: a camada de rede, barata, tira a maior parte do lixo, a do navegador pega o que se disfarça de gente, e a soma dos sinais protege contra recusas desnecessárias.

Onde a verificação é desnecessária ou atrapalha

• Páginas sem tráfego pago. Se nenhum anúncio leva à página, uma verificação rígida do navegador mais atrapalha do que ajuda.
• Fontes em que quase tudo vem por navegador embutido. Ali vale suavizar a exigência de executar o script e se apoiar na pontuação de confiança.
• Robôs de busca no site principal. Proteja as landing pages das campanhas, não o site inteiro com o tráfego de SEO. Mais sobre a escolha no artigo antibot para site.

Como isso funciona no ArtisanClo

O ArtisanClo usa as duas camadas: as verificações de rede filtram tráfego de datacenter, VPN e proxy, e a verificação do navegador pega automação e falsificação de dispositivo em endereços que parecem limpos pela rede. Cada clique no registro mostra o código do motivo da decisão, então dá para ver na hora se agiu a rede ou o navegador. O tracker embutido conta gasto, conversões, lucro e ROI por campanha, mostrando quanto dinheiro foi para tráfego lixo e qual fonte o traz. Todas as verificações estão na página de recursos.

Em resumo

O bloqueio por IP e a verificação JavaScript respondem a perguntas diferentes: de onde veio a visita e que programa a enviou. O primeiro é rápido, barato e confiável contra bots de servidor, mas cego para proxies em endereços residenciais e móveis. A segunda vê o navegador por dentro, mas custa tempo, é falsificada por bots avançados e erra em dispositivos incomuns. Os pontos fracos das duas quase não se sobrepõem, então a rede vem na primeira camada, o navegador na segunda, sinais fracos se somam numa pontuação de confiança e o resultado é conferido com estatísticas por fonte. Para calcular quanto custam os bots que passam, leia quanto orçamento se perde com bots.