O seu painel de análise mostra uma taxa de rejeição. Talvez seja 68 %. Talvez tenha subido de 52 % para 71 % no mês passado. A pergunta que a maioria das equipas faz a seguir é: «como a reduzo?» Essa é a pergunta errada. A certa é: «isto é realmente um problema e, se for, por que é alta?»
Este guia é sobre diagnóstico, não sobre dicas genéricas. Para uma definição completa de taxa de rejeição, como é calculada e intervalos de referência por tipo de página, consulte a nossa entrada do glossário sobre taxa de rejeição. Aqui focamo-nos em ler os sinais, identificar a causa real e corrigir o problema certo.
O número global é quase sempre enganador
Uma taxa de rejeição a nível de site agrega páginas que se comportam de forma completamente diferente. Uma taxa de 65 % pode significar que o seu blog está a fazer o seu trabalho (os leitores encontram o que precisam e saem satisfeitos) enquanto a sua página de preços está a perder potenciais clientes. Ou o contrário. O agregado não lhe diz nada acionável.
Antes de tirar conclusões, precisa de responder a duas perguntas: que páginas têm taxa de rejeição alta, e de que fontes de tráfego? A interseção dessas duas respostas aponta para o problema real.
Passo 1: Isole as páginas que realmente importam
Extraia os dados de taxa de rejeição por página individual. Foque-se nas páginas onde uma rejeição representa uma oportunidade perdida: a sua página inicial, páginas de produto, página de preços, página de pedido de demo e quaisquer landing pages com muito tráfego de campanhas pagas. Os artigos do blog podem esperar; uma taxa de rejeição de 75 % num artigo de blog é geralmente aceitável.
Ordene por volume de tráfego × taxa de rejeição. Uma página com 5.000 visitas/mês e uma taxa de rejeição de 70 % é um problema maior do que uma página com 200 visitas/mês e 90 %. Priorize em conformidade.
Passo 2: Segmente por fonte de tráfego
Depois de ter uma lista de páginas prioritárias, desagregue a taxa de rejeição por canal para cada uma. O padrão que encontrar aponta para um diagnóstico específico:
| Padrão | Causa mais provável |
|---|---|
| Alta em pago, baixa em orgânico | Discrepância anúncio-página: a promessa do anúncio não corresponde à página |
| Alta em orgânico, baixa em direto | Discrepância de intenção de pesquisa: o conteúdo não responde ao que a palavra-chave implicava |
| Alta em todos os canais | A própria página é o problema (carregamento lento, copy fraco, sem próximo passo claro) |
| Pico repentino em todas as páginas | Problema técnico ou tag de análise quebrada: verifique primeiro a sua configuração de rastreamento |
| Alta em móvel, normal em desktop | Falha na experiência móvel (layout, velocidade ou usabilidade) |
Esta matriz por si só eliminará metade das causas possíveis antes de abrir uma única gravação de sessão.
Passo 3: Observe o que os visitantes realmente fazem
Depois de saber que página e que fonte têm o problema, a próxima camada é comportamental. A análise diz-lhe que os visitantes saem. As gravações de sessão e mapas de calor dizem-lhe o que aconteceu mesmo antes de saírem.
Veja entre 15 e 20 gravações de sessão na sua página com maior taxa de rejeição, filtradas pela fonte de tráfego identificada no Passo 2. Procure padrões:
- Rage-clicks em elementos que parecem clicáveis mas não são, sinalizando expectativas quebradas
- Dead scroll onde os visitantes param de fazer scroll no mesmo ponto, significando que o conteúdo os perde ali
- Saídas imediatas sem qualquer scroll, significando que a experiência above-the-fold está a falhar imediatamente
- Abandono de formulário num campo específico, revelando fricção num passo preciso do funil de conversão
Ferramentas como Hotjar e Sublim oferecem gravações de sessão junto a dados de tráfego. Com uma plataforma integrada pode filtrar gravações diretamente por fonte de tráfego, estado de rejeição ou resultado de conversão, sem exportar dados entre ferramentas.
Passo 4: Verifique os seus dados antes de agir
Má configuração do rastreamento
Se a sua tag de análise disparar várias vezes num único carregamento de página, cada sessão parece uma rejeição. As aplicações de página única (SPA) que não rastreiam as mudanças de rota como visualizações de página separadas também mostrarão taxas de rejeição infladas. Abra as ferramentas de programador do seu navegador e verifique que a sua tag dispara uma vez por página e que navegar entre páginas aciona um novo evento.
Lacunas de dados por consentimento
Nos mercados europeus com banners de consentimento ativos, entre 30 e 50 % dos visitantes recusam tipicamente o rastreamento. Esses visitantes são completamente invisíveis na sua taxa de rejeição do Google Analytics. Os visitantes que aceitam o rastreamento tendem a ser utilizadores familiarizados com a marca ou envolvidos, o que faz com que a sua taxa de rejeição pareça artificialmente mais baixa do que realmente é.
Se utiliza uma ferramenta de análise sem cookies que não requer consentimento (como Sublim, Plausible ou Fathom), está a ver 100 % do seu tráfego e os seus dados de taxa de rejeição refletem a realidade. Se utiliza o Google Analytics com um banner de consentimento, os seus dados têm um ponto cego estrutural.
A auditoria de taxa de rejeição de 30 minutos
Quando uma taxa de rejeição alta não é um problema
Nem toda taxa de rejeição alta requer ação. Uma página de contacto com uma taxa de 15 % e um artigo de blog com 80 % podem estar a funcionar exatamente como pretendido. O sinal a que deve prestar atenção é uma combinação de três coisas: taxa de rejeição alta, numa página onde o engagement importa, de uma fonte de tráfego onde está a gastar dinheiro ou esforço.
Conclusão
A taxa de rejeição é um ponto de partida, não um diagnóstico. O processo que realmente funciona: isole as páginas que importam → segmente por fonte para identificar o padrão → use dados comportamentais para ver o que os visitantes fazem antes de sair → verifique que os seus dados estão completos e corretamente configurados → formule uma hipótese testável e aja.
As equipas que perseguem o número global sem esta estrutura acabam por fazer mudanças que não movem a métrica. As equipas que diagnosticam antes de corrigir encontram consistentemente o problema real mais depressa.
