A maioria das campanhas com bots de tráfego falha por razões banais: o ritmo está errado, a combinação de referenciadores é implausível, a propriedade de analítica nunca foi segmentada, ou ninguém escreveu como seria um bom resultado. São estes os detalhes operacionais que decidem se uma campanha produz dados de teste utilizáveis ou um mês de números impossíveis de interpretar.
Pontos essenciais
- Marcar antes de lançar. Quase todos os problemas abaixo têm solução se o tráfego puder ser isolado depois, e quase nenhuma se não puder.
- Ritmar segundo uma curva, não segundo um total diário. Um fluxo plano, ininterrupto ao longo das 24 horas, é o indício mais claro de tráfego sintético e distorce todas as médias calculadas.
- Copiar a própria plausibilidade. A analítica existente já descreve uma geografia e uma combinação de dispositivos credíveis; convém usá-la como especificação.
- Escolher primeiro a métrica de sucesso. Numa campanha de validação técnica, essa métrica costuma ser a fidelidade dos eventos, não as sessões.
Configurar a campanha com bot de tráfego para que os dados continuem legíveis
O erro de configuração mais difícil de desfazer é enviar visitas sintéticas para a mesma vista de analítica dos utilizadores reais. Ainda é possível separá-las depois, com segmentos e comparações, mas apenas se a marcação estiver em vigor desde o início, ficando as sessões na propriedade em qualquer dos casos. O que não se pode fazer é aplicar um filtro de dados retroativamente. A decisão tem de ser tomada antes de chegar a primeira sessão.
- Marcar cada campanha com parâmetros UTM que nunca seriam usados organicamente. Um
utm_sourcededicado transforma a exclusão posterior num filtro de um só clique. Isto não é arrumação opcional; é a diferença entre uma experiência reversível e uma propriedade permanentemente contaminada. - Criar o filtro de exclusão antes do lançamento, não depois. Os filtros no GA4 não são retroativos. Um filtro acrescentado ao 12.º dia deixa onze dias de dados misturados em todos os relatórios históricos que alguma vez venham a ser extraídos.
- Usar uma propriedade separada ou um fluxo de dados dedicado se o site tiver relatórios de receita. Nada do que alimente uma apresentação à administração ou o sinal de conversão de uma plataforma de anúncios deve sequer ver sessões sintéticas.
- Escrever numa frase o objetivo da campanha antes de gastar dinheiro. «Confirmar que o funil de checkout dispara corretamente os eventos sob carga a partir de três países» é um objetivo. «Aumentar o tráfego» não é.
Ritmo do bot de tráfego: a forma importa mais do que o total diário
Convém ritmar uma campanha de acordo com a curva diária do mercado-alvo e aumentar o volume ao longo de vários dias, em vez de a ligar logo no débito máximo. Um fluxo plano, ininterrupto ao longo das 24 horas, é simultaneamente o sinal mais claro de tráfego sintético e a forma mais rápida de tornar as próprias médias irrelevantes.
Uma campanha que entrega 3000 visitas por dia num fluxo plano e uniformemente espaçado não se parece nada com tráfego humano e nada ensina sobre o comportamento do site em condições reais. As audiências reais chegam em curva: mais densas durante as horas de vigília locais, mais leves de madrugada, com formas diferentes durante a semana e ao fim de semana.
Duas regras práticas:
- Ajustar a curva de entrega ao fuso horário da geografia visada. Ao testar uma página de destino alemã, tráfego com pico às 04:00 CET indica que algo está mal configurado, e torna também irrelevante qualquer média de envolvimento calculada, porque está a fazer a média sobre as horas erradas.
- Subir gradualmente em vez de ligar de uma vez. Passar de zero ao volume máximo num único passo torna impossível saber que nível de volume causou um problema de servidor ou de monitorização. Subindo por etapas ao longo de vários dias, obtém-se um limiar em vez de um mistério.
O ritmo protege também aquilo que se está a medir. O tempo de resposta do servidor degrada-se de forma não linear sob carga; um pico pode produzir carregamentos lentos que reduzem as métricas de envolvimento por razões que nada têm que ver com a qualidade da fonte de tráfego.
Combinação de referenciadores e dispositivos: a plausibilidade vale mais do que a variedade
Há a tentação de maximizar a variedade (muitos referenciadores, muitos dispositivos, muitos países) partindo do princípio de que a diversidade parece natural. Normalmente parece pior. Um site pequeno que nunca se posicionou fora de um país não recebe de repente visitantes de quarenta.
| Definição | Erro comum | Abordagem melhor |
|---|---|---|
| Geografia | Distribuição global num site de mercado único | Espelhar os países já presentes nos dados orgânicos |
| Combinação de dispositivos | 100 % computador, ou uma divisão exata de 50/50 | Copiar da analítica o rácio existente entre telemóvel e computador |
| Referenciadores | Dezenas de domínios sem relação | Duas ou três fontes plausíveis, ou apenas direto |
| Profundidade da sessão | Todas as sessões idênticas | Uma distribuição: a maioria curta, algumas profundas |
O princípio subjacente: os dados de analítica existentes já descrevem o que é plausível para o site em causa. Convém usá-los como especificação, em vez de inventar uma.
Decidir a métrica de sucesso antes de olhar para o painel
Uma métrica escolhida depois de os dados chegarem não é uma métrica, é uma busca por algo lisonjeiro. Escolhe-se antecipadamente um número principal e um número de salvaguarda.
Numa campanha orientada para validação técnica, a métrica principal normalmente nem sequer é o tráfego: é a fidelidade dos eventos. Os eventos que se esperava que disparassem dispararam mesmo, ao ritmo esperado e com os parâmetros esperados? Uma campanha que revele um evento purchase avariado pagou-se a si própria, independentemente do que aconteceu às sessões.
A salvaguarda é o número que manda parar. Tipicamente: taxa de erros do servidor, tempo mediano de carregamento da página ou taxa de sessões com envolvimento. Se a salvaguarda evoluir desfavoravelmente, a campanha é suspensa mesmo que a métrica principal pareça boa.
Cinco modos de falha de bots de tráfego que convém reconhecer cedo
- A miragem da taxa de rejeição. Sessões sintéticas com tempo de permanência programado produzem uma bela taxa de rejeição que não significa nada. Se a taxa de rejeição melhorar na semana em que uma campanha arranca, isso é um artefacto de medição, não uma melhoria.
- Inflação de conversões a partir de formulários de teste. Se um bot chegar a um formulário e o formulário disparar um evento de conversão, a contagem de conversões sobe e a taxa de conversão pode subir também. A jusante, esse número pode fluir para a otimização das plataformas de anúncios e distorcer silenciosamente licitações reais.
- A ilusão da página em cache. Acessos repetidos ao mesmo URL aquecem a cache do CDN, pelo que os tempos de carregamento descem. Isto parece um ganho de desempenho. Convém testar um URL frio para verificar.
- Limitação de débito invisível. O alojamento ou o WAF começa a estrangular o tráfego ou a servir-lhe desafios sem avisar. As sessões continuam a ser registadas, mas registam falhas. Convém observar os registos do lado do servidor, não apenas a analítica.
- Contaminação de relatórios descoberta tarde. Alguém extrai um valor trimestral de tráfego que inclui a campanha. Esta é a falha que danifica a confiança dentro da empresa, e é inteiramente evitável com disciplina de marcação.
Ler os resultados à luz dos registos do servidor, não apenas da analítica
É também assim que se distingue um tipo de tráfego automatizado de outro. A analítica informa sobre as sessões que executaram JavaScript e comunicaram de volta. Os registos do servidor informam sobre todos os pedidos que chegaram. É na diferença entre os dois que vivem os problemas interessantes.
Se o fornecedor reportar 10 000 visitas, a analítica mostrar 6000 sessões e o registo de acessos mostrar 10 000 pedidos, ficou-se a saber algo concreto: cerca de 40 % do tráfego não está a executar a monitorização. Isso pode ser perfeitamente aceitável para um teste de carga e inútil para um teste comportamental. Em qualquer dos casos, agora já se sabe qual.
Quando parar uma campanha com bot de tráfego
As condições de paragem devem ser escritas antes do lançamento e ser suficientemente mecânicas para que um colega as pudesse aplicar sem pedir opinião:
- A taxa de erros 5xx do servidor excede a sua banda normal durante mais de uma hora.
- O tempo mediano de carregamento da página degrada-se para além de um limiar acordado.
- Qualquer evento de conversão dispara a um ritmo implausível para o volume enviado.
- O volume reportado pelo fornecedor e o registo do servidor divergem para além de uma margem acordada.
- O objetivo da campanha já foi respondido: a condição de paragem mais esquecida de todas.
O que registar por escrito no fim
Registar a configuração (volume, ritmo, geografia, combinação de dispositivos, referenciadores, duração), o que estava a ser testado, o que se observou e o que se mudou em consequência. Incluir as definições que não funcionaram; caso contrário, a próxima pessoa a conduzir uma campanha voltará a descobri-las ao mesmo custo.
Uma entrada de registo útil cabe num parágrafo e responde a uma pergunta: se repetíssemos isto amanhã, o que faríamos de diferente?
Perguntas frequentes
As campanhas com bots de tráfego melhoram os meus posicionamentos?
Não. O posicionamento responde ao conteúdo, às ligações, à rastreabilidade e à correspondência com a intenção, e nada disso está à venda; o assunto está tratado no nosso guia sobre o que se vende realmente como tráfego SEO. Uma campanha pode ajudar a verificar se a analítica, o servidor e o funil se comportam corretamente, o que é um benefício genuíno de engenharia, e outra coisa completamente diferente.
De que volume preciso para um teste útil?
De menos do que os pacotes propostos dão a entender. Verificar que os eventos disparam corretamente exige dezenas de sessões, não milhares. O volume elevado só é necessário quando a própria pergunta é sobre carga.
O tráfego sintético deve ser excluído da analítica de forma permanente?
Sim, de qualquer vista de relatório usada para decisões de negócio. Convém mantê-lo visível numa vista ou num segmento dedicado, para que os próprios dados de teste continuem a poder ser inspecionados.
Qual é o hábito mais valioso de todos?
Marcar cada campanha de forma distinta a partir da primeira sessão. Quase todos os problemas sérios desta lista passam a ter solução se o tráfego puder ser isolado depois, e quase nenhuma se não puder.