Tráfego de bots e qualidade do clique: o que a sua contagem está contando

Todo serviço de redirecionamento sabe dizer quantas requisições atendeu. Quase nenhum sabe dizer quantas dessas requisições eram pessoas, que é o número que todo relatório presume conter, em silêncio. Os links vivem na web aberta: eles são indexados, têm prévias montadas, são varridos, monitorados e raspados, e boa parte disso acontece segundos depois da publicação, antes de um único humano ter visto o post.

Este artigo trata da camada entre o contador bruto e um número que você consegue defender numa reunião com o cliente: que automação você quer deixar passar, por que identificar um crawler pelo nome não é identificação, o que um tipo de rede prova e como transformar isso em regras e num relatório honesto.

O contador bruto é um contador de requisições

Um mecanismo de redirecionamento conta o que chega. Essa é a virtude dele — funciona para destinos que você não controla, sobrevive a bloqueadores e conta um escaneamento de QR feito de um cartaz que não tem sessão nem referenciador, como mostra o nosso guia sobre rastrear cliques em links. E é também por isso que o número precisa de ressalva.

O tráfego automatizado que chega a um link curto se divide em grupos reconhecíveis:

• Scanners de link. Provedores de e-mail, plataformas de mensagens e gateways de segurança buscam os links na entrega para conferir aonde eles levam — e é por isso que um link acumula cliques no minuto seguinte a um disparo, antes de a entrega ter terminado.
• Buscadores de prévia. Redes sociais e aplicativos de conversa buscam o link para montar o card com título e imagem. Um redirecionador bem-comportado responde a eles com metadados, em vez de roteá-los e contá-los.
• Crawlers de busca e de SEO. Indexadores de busca, mais as ferramentas comerciais de SEO que rastreiam tudo o que encontram.
• Monitores. Checagens de disponibilidade, inclusive as suas. É por isso que as requisições HEAD são atendidas sem contar clique.
• Scrapers e sondas. Coletores de preço, colhedores de dados e scanners à procura de links que possam apontar para outro lugar.

Dois desses grupos são tráfego que você pediu, um é infraestrutura neutra, um não é bem-vindo. “Bloquear bots” trata todos igual.

Bots bons, e a única coisa que os identifica

Um user agent é uma alegação

O user agent é um cabeçalho que quem envia escreve. Qualquer coisa pode colocar qualquer texto ali, então uma requisição que se diz Googlebot não prova nada, e um scraper que se diz Chrome é mais comum do que um que assume o que é. A correspondência por user agent ainda merece o seu lugar — ela pega a automação que se identifica com honestidade e corrobora outros sinais —, mas no classificador ela é explicitamente um sinal fraco: confirma, não decide.

A verificação testa algo que quem envia não controla

O endereço de onde uma requisição chega não é escolhido por quem envia em nenhum sentido útil, e é isso que faz dele a coisa certa a testar. Há duas maneiras de fazer isso.

Alguns operadores publicam as faixas que os seus crawlers usam. Google, Bing e Apple publicam, e esses arquivos são baixados uma vez por dia para uma consulta rápida, então uma requisição vinda de uma faixa listada é confirmada sem nenhum trabalho de rede na hora da requisição.

Para os crawlers sem lista publicada — Yandex, DuckDuckGo, Baidu, Petal — a verificação é uma checagem de nome em duas etapas, e as duas etapas são obrigatórias:

Claim: "Googlebot" in the user agent

Step 1  reverse lookup of the address
        <address>  ->  crawl-<address>.googlebot.com   ends in the crawler's domain
Step 2  forward lookup of that name
        crawl-<address>.googlebot.com  ->  <address>    matches the original address
        verdict: verified crawler

Same claim, different address

Step 1  203.0.113.9  ->  host9.example-hosting.net     not the crawler's domain
        verdict: not verified, the claim is rejected

A etapa direta não é opcional. Quem controla um bloco de endereços em geral consegue definir o registro reverso dele como bem entender, então um nome reverso sozinho pode ser fabricado. Resolver esse nome no sentido direto e receber de volta o endereço original é o que fecha o ciclo.

O CDN à frente do redirecionador também faz a sua própria categorização de bot verificado, um veredito que quem envia não consegue forjar e que não custa caro para ler. A confirmação é então tomada em ordem decrescente de autoridade: lista publicada, verificação do CDN, checagem de nome reversa e direta, e por fim a presença numa faixa conhecida de spider no banco de endereços.

Por que a checagem de nome nunca roda com um visitante esperando

Uma consulta reversa é uma requisição de rede com latência imprevisível, e o redirecionamento é o único lugar em que milissegundos são visíveis para uma pessoa, então ela nunca roda de forma síncrona. Se uma regra pergunta se um crawler é verificado e a resposta não está em cache, a regra o trata como não verificado, a consulta corre em segundo plano e a resposta fica em cache para o próximo clique daquele endereço. Errar para o lado de “não verificado” custa uma classificação correta; errar para o lado de uma consulta síncrona custa a uma pessoa real um atraso em toda requisição.

O tipo de rede é contexto, não veredito

Independentemente do que um visitante alega ser, a faixa de endereços de onde ele veio tem um caráter conhecido. O banco comercial de endereços por trás disso classifica as faixas num pequeno conjunto de tipos:

| Tipo | O que é a faixa | Fatia das faixas IPv4 no banco | | --- | --- | --- | | Não listada | Endereços comuns, em boa parte de consumo e corporativos | 72,1% | | Data center, hospedagem, nuvem | Servidores, instâncias de nuvem, navegadores hospedados | 15,3% | | Proxy público aberto | Relays abertos por onde qualquer um pode rotear | 9,2% | | VPN comercial | Serviços de VPN de consumo e corporativos | 3,2% | | Spider de buscador | Faixas conhecidas por pertencerem a crawlers | 0,17% | | Nó de saída TOR | Pontos de saída da rede TOR | 0,005% | | Anonimizador web | Páginas de proxy que rodam no navegador | 0,005% |

Leia essa tabela com cuidado, porque é fácil lê-la errado. Aquelas são fatias de faixas de endereços num banco de referência, e não fatias do tráfego de ninguém. Uma faixa de provedor residencial atende um número enorme de pessoas; uma faixa de hospedagem pode não atender ninguém. A tabela diz quais são as categorias e com que granularidade o espaço de endereços se divide entre elas, e nada sobre o que a sua campanha recebeu.

O ponto interpretativo importa mais que os números. Um endereço de data center não significa um bot. Redes corporativas roteiam funcionários por infraestrutura de nuvem, consumidores atentos à privacidade usam VPNs comerciais para tudo, inclusive para comprar, e navegadores hospedados são um jeito normal de ler a web. Apague todo clique de data center e você vai apagar clientes reais. O tipo de rede desloca a confiança; sozinho, ele é um fato sobre roteamento.

A nota de qualidade e para que ela serve

O classificador produz duas saídas: um tipo de visitante — humano, crawler de busca, biblioteca, data center, VPN, TOR ou desconhecido — e uma nota de qualidade de 1 a 100 com os motivos por trás dela. As entradas são as de cima mais sinais de comportamento: com que frequência o mesmo endereço bate no mesmo link dentro de um minuto, se a requisição sequer traz uma preferência de idioma e se o conjunto de cabeçalhos combina com a plataforma que o user agent alega.

A nota deliberadamente não é uma chave. Nada é bloqueado porque a nota está baixa; a nota explica um veredito e alimenta os relatórios, enquanto o bloqueio é configurado de forma explícita. O custo de um falso positivo é assimétrico: um bot contado como humano distorce uma porcentagem, enquanto um cliente bloqueado como bot nunca chega à página e nunca te avisa.

Tipo, nota e motivos aparecem nas quebras de geografia e qualidade do tráfego, onde a tabela de redes é a que os compradores de mídia procuram primeiro: número de sistema autônomo, nome do provedor, tipo da faixa, total de cliques e cliques humanos em colunas separadas. A diferença entre esses dois últimos, por provedor, costuma ser a história inteira de uma compra de tráfego. O conjunto completo está documentado em analytics geográfico.

Transformar um veredito em decisão

Um veredito só é útil se alguma coisa puder agir sobre ele. As regras de filtragem de tráfego prendem a um link uma lista ordenada de condições, avaliadas no edge antes de o destino ser escolhido, e a primeira correspondência decide o desfecho. Um link sem regras não faz trabalho extra nenhum.

As condições relevantes aqui são o tipo de visitante, a situação de crawler verificado, o tipo de rede e um limite de nota de qualidade, ao lado de geografia, sistema autônomo, listas de endereços, dispositivo, idioma, referenciador, padrão de user agent, tags de campanha, hora local e primeira visita contra visita repetida. Os desfechos: deixar passar, bloquear com 404, bloquear com 410, redirecionar para outro lugar, mostrar uma página de aviso com a sua marca, ou deixar passar marcando a visita como suspeita.

Três detalhes de projeto decidem se isso é seguro de rodar em produção.

As condições têm três valores. Atendida, não atendida ou sem resposta porque o dado falta — e “sem resposta” nunca conta como correspondência. Se o banco de endereços estiver indisponível, uma regra condicionada ao tipo de rede não dispara e o visitante chega ao destino normal. A filtragem falha abrindo, nunca fechando.

A inversão só inverte respostas seguras. Uma regra escrita como “todos menos a Alemanha” não dispara em silêncio para visitantes cujo país não pôde ser determinado. Essa é a forma mais comum de uma regra geográfica bem-intencionada virar uma queda de serviço.

Deixar passar existe para que os filtros possam ser auditados. Uma regra que deixa o tráfego passar e registra que casou é como você testa um filtro antes de deixá-lo bloquear qualquer coisa: rode-a no modo de passagem, leia a quebra de tráfego filtrado, confirme que ela pega o que você esperava e só então mude a ação.

Coloque a política geral no conjunto de regras que vale para todo o espaço de trabalho, já que uma política sobre data centers raramente trata de um link só, e depois use as regras do próprio link — avaliadas primeiro — para carregar exceções acima da proibição geral. É assim que o seu monitor de disponibilidade continua funcionando no único link que ele observa. Os limites de regras e de listas de endereços estão na documentação de regras de tráfego.

Um detalhe antes de você escrever uma regra de primeira visita: distinguir uma primeira visita de uma repetida exige um cookie pequeno no seu domínio de redirecionamento, gravado apenas quando uma regra de fato faz essa pergunta. Isso tem consequências de privacidade, e é por isso que a adesão vem pelo mecanismo, e não por padrão.

O que muda no relatório para o cliente

É aqui que o trabalho se paga, e trata-se sobretudo de quais números vão para a página.

| Linha do relatório | Sem camada de qualidade | Com ela | | --- | --- | --- | | Número principal | Cliques | Cliques humanos, com o total de cliques ao lado | | Composição | Ausente | Humano, crawler verificado, data center, VPN, TOR, desconhecido | | Tabela de provedores | Cliques por rede | Cliques e cliques humanos por rede | | Tráfego filtrado | Invisível | Volume por regra, com a ação que cada regra aplicou | | Explicação de um pico | “Alguma coisa aconteceu na terça” | O tipo e a rede de onde o pico veio |

Dois hábitos tornam esse relatório honesto, e não apenas detalhado. Mostre sempre os dois números: um valor de cliques humanos sem o total ao lado convida à suspeita de que o total era inconveniente. E relate o que você filtrou e por quê — o identificador da regra e a ação guardados em cada evento que casou fazem com que a quebra de tráfego filtrado continue legível para regras que você editou ou excluiu depois.

Para agências, a tabela de provedores também é um instrumento comercial: uma rede que manda volume com quase nenhum clique humano é uma conversa com um fornecedor, e essa conversa é mais fácil com uma quebra por provedor do que com um agregado. As nossas páginas de soluções para agências e soluções para afiliados mostram como isso se encaixa no relatório ao cliente e nos pagamentos.

Uma coisa a dizer sem rodeios, porque os fornecedores desta categoria costumam não dizer: a classificação é probabilística. Um scraper determinado rodando um navegador de verdade a partir de um endereço residencial vai ser classificado como humano, e nenhum produto do mercado vai te dizer o contrário. Esta camada remove a maioria grande, fácil e honesta consigo mesma da automação, e te dá evidência para investigar o resto. Um relatório que sugere certeza uma hora vai estar errado na frente de um cliente.

Uma sequência que funciona

1. Deixe a filtragem de bots ligada por padrão em analytics e trate como automação, até prova em contrário, qualquer pico que comece antes de um humano ter podido ver o link.
2. Leia a quebra por composição antes do número principal. Uma fatia automatizada incomum para aquele canal já é, por si só, a descoberta.
3. Confira na tabela de redes os provedores em que o total de cliques e os cliques humanos divergem muito.
4. Escreva a primeira regra no modo de passagem, acompanhe a quebra de tráfego filtrado por uma semana e só a promova a uma ação de bloqueio quando o volume que ela casa parecer o que você pretendia.
5. Mantenha os crawlers verificados passando e isente os seus próprios monitores com uma regra no nível do link, acima da política do espaço de trabalho.
6. Relate cliques humanos e total de cliques juntos, com o volume filtrado exibido, e não subtraído em silêncio.

A ideia de fundo é simples: um clique é uma requisição, uma requisição tem procedência, e procedência é mensurável. O que faz valer a pena é o efeito de segunda ordem. Taxas de conversão calculadas sobre cliques humanos são estáveis, quebras geográficas sem faixas de hospedagem descrevem mercados em vez de infraestrutura, e um cliente a quem se mostrou uma vez a composição do seu tráfego para de perguntar se os números são reais.