Porque aumentou a taxa de rejeição? Como encontrar a alteração que a causou

O que significa a taxa de rejeição subir no GA4?

Uma taxa de rejeição mais alta no GA4 significa que uma parte maior das sessões falhou todos os testes de interação. Não é o mesmo que no Universal Analytics, onde qualquer sessão de uma só página contava como rejeição.

A Google define uma sessão com interação (no ecrã aparece como "sessão engajada") como aquela que cumpre pelo menos uma de três condições. A taxa de rejeição é a percentagem de sessões que não cumpre nenhuma, ou seja, é sempre o inverso da taxa de interação.

Esta tabela é o diagnóstico inteiro em ponto pequeno. Qualquer causa real passa por uma destas linhas: o visitante fica menos tempo, dispara menos eventos principais ou vê menos páginas, ou o GA4 deixa de contar uma destas coisas corretamente.

O tempo de interação só conta enquanto a página está em foco ou o ecrã da aplicação está em primeiro plano. Quem abre a página num separador em segundo plano e nunca olha para ela pode contar como rejeição, mesmo com o separador aberto durante uma hora.

A subida é real ou resulta de uma alteração de tracking?

Verifique primeiro o tracking, porque uma alteração na medição pode mexer na taxa de rejeição de um dia para o outro em todos os canais, sem que o comportamento dos visitantes mude. Uma subida que começa num dia exato em todas as origens e dispositivos aponta para o tracking ou para o site, não para o público.

As alterações de tracking que mais fazem subir a taxa de rejeição:

• O temporizador foi alterado. No GA4 está em "Administrador" > "Fluxos de dados" > o seu fluxo web > "Definir as configurações da tag" > "Mostrar tudo" > "Ajustar o temporizador das sessões engajadas". Subir acima dos 10 segundos transforma sessões curtas com interação em rejeições, sem qualquer mudança no site.
• Um evento principal deixou de disparar ou foi desmarcado. As sessões que só tinham interação por causa dele passam a contar como rejeição.
• As visualizações virtuais deixaram de funcionar numa aplicação de página única. Sem elas, o GA4 trata a aplicação como uma só página, e o guia da Google avisa que isso distorce as métricas.
• As visualizações eram contadas a dobrar e alguém corrigiu. A Google avisa que usar a medição otimizada para eventos do histórico do navegador juntamente com a sua própria configuração no Google Tag Manager pode duplicar visualizações. Ao corrigir, desaparecem as segundas páginas falsas e a taxa sobe para o valor real.
• A etiqueta desapareceu de alguns modelos. Um redesign ou um modelo novo do CMS sem a etiqueta do GA4 muda as páginas que são medidas.
• O consentimento mudou. Um banner novo ou outra configuração de consentimento pode mudar as sessões que consegue medir por completo.

Para confirmar, abra o histórico de versões do Google Tag Manager dos dias anteriores à subida, pergunte à equipa quem mexeu nas definições do GA4 e percorra o site no DebugView para confirmar que page_view e eventos principais continuam a chegar. O artigo sobre o histórico de versões do GTM mostra como ver quem publicou o quê.

O mix de tráfego mudou ou os visitantes comportaram-se de outra forma?

Se o tracking está limpo, veja se está a receber visitantes diferentes antes de concluir que os mesmos visitantes interagem menos. Uma origem nova com pouca intenção pode fazer subir a média do site enquanto todos os canais antigos se mantêm estáveis.

1. Acrescente a taxa de rejeição a um relatório de detalhe. O GA4 não a mostra por predefinição: abra o relatório, clique em "Personalizar relatório", em "Dados do relatório" clique em "Métricas", "Adicionar métrica", escreva "Taxa de rejeição" e clique em "Aplicar". Precisa da função de editor ou administrador.
2. Divida por canal e por origem / meio. Compare as duas semanas anteriores à subida com a semana seguinte.
3. Olhe para o peso de cada canal nas sessões, não só para a taxa. Se Display, Performance Max, posicionamentos da Meta ou um site de referência passaram de 5% para 25% das sessões, o mix explica a média.
4. Separe por dispositivo e por página de destino. Uma subida só no telemóvel e numa landing page é um problema muito diferente de uma subida em todo o site.
5. Procure padrões de spam ou de bots: uma origem, uma cidade, sessões com tempo de interação zero e sem eventos principais.

Do lado dos anúncios, procure expansão da correspondência ampla, posicionamentos novos, expansão de público ou uma campanha lançada no mesmo dia. Qualquer uma pode trazer visitantes que saem em segundos.

Que alterações no site fazem subir a taxa de rejeição?

Excluídos o tracking e o mix de tráfego, veja o que mudou nas páginas onde as pessoas chegam. Os suspeitos habituais são alterações que pioram os primeiros 10 segundos.

• Velocidade: imagem de topo mais pesada, um script novo ou um widget de chat que atrasa o primeiro ecrã.
• Janelas sobrepostas: pop-up de newsletter ou barreira de cookies que surge antes do conteúdo.
• Coerência da mensagem: anúncio ou e-mail que promete uma oferta quando a landing page mostra outra.
• Navegação: ligações internas removidas, menu recolhido ou bloco de "relacionados" que gerava a segunda visualização.
• Formulários e CTAs: formulário avariado ou botão removido que era o evento principal de muitas sessões.
• Conteúdo: introdução reescrita, preço mudado de sítio ou tabela comparativa removida numa página com muito tráfego.

Ordene tudo pela data em que entrou em produção. Uma alteração publicada na véspera da subida, nas páginas onde a subida aconteceu, vale mais do que uma longa lista de problemas possíveis. O artigo sobre o registo de alterações do site explica como guardar as publicações para as datar mais tarde.

Como isolar a alteração que fez subir a taxa de rejeição?

Encontre o dia exato em que a taxa mudou, coloque todas as alterações dos dias anteriores numa única cronologia e teste-as por ordem. A causa é quase sempre uma alteração que entrou em produção pouco antes da subida e mexe nas mesmas páginas, canais ou dispositivos.

1. Datar a subida
2. Excluir o tracking
3. Analisar o mix de tráfego
4. Alinhar as alterações
5. Testar uma causa

Use dados diários, não médias semanais, para encontrar a data de início. Depois reúna tudo dos cinco a sete dias anteriores: edições da equipa no Google Ads e na Meta, automatismos das plataformas, publicações no GTM, ajustes no GA4, publicações do site, alterações no CRM ou nos formulários e acontecimentos externos, como uma newsletter ou uma notícia.

Compare cada alteração com a forma da subida. Subida em todo o site e em todos os canais encaixa num problema de tracking ou de modelo. Subida só em redes sociais pagas encaixa numa alteração na Meta. Subida numa só landing page encaixa numa edição dessa página. Com todas as alterações numa única cronologia, veria que o contentor do GTM foi publicado na mesma manhã da subida, enquanto a campanha nova só arrancou dois dias depois. Um registo de alterações de marketing no Changeline mantém essa cronologia por cliente: as edições do Google Ads podem ser importadas automaticamente e o resto é registado pela equipa com data, responsável e motivo.

Exemplo: um cliente pergunta porque é que a taxa de rejeição passou de 38% para 55% na semana passada. A agência alinha as alterações dos dias anteriores: campanha nova na Meta na terça-feira, publicação no GTM na quarta-feira, modelo do blogue atualizado na quinta-feira. A subida começa na quarta-feira, em todos os canais e dispositivos, por isso a publicação no GTM passa a ser a suspeita. A nova versão do contentor tinha deixado de enviar visualizações virtuais nas páginas de produto da loja de página única, e quem via três produtos contava como rejeição de uma página. Reposto o acionador, a taxa voltou aos 39% em dois dias.

Como provar a causa antes de a reportar?

A causa está provada quando o segmento afetado mudou e o não afetado não, e quando desfazer a alteração traz a métrica de volta. A coincidência no tempo é o ponto de partida, não a prova.

• Compare segmentos. Se a alteração só mexeu no telemóvel, nas páginas de produto ou numa campanha, o resto do site deve estar estável nos mesmos dias.
• Confirme o mecanismo. Volte às três condições: as sessões perderam tempo, eventos principais ou a segunda página? A resposta tem de bater certo com o que a alteração fez.
• Reverta ou corrija e acompanhe. Reponha a versão anterior, pause a campanha ou corrija a etiqueta e compare os dias seguintes com os dias antes da subida.
• Registe. Anote a alteração, a data em que entrou em produção, a data da correção e o efeito na taxa, para ninguém repetir a investigação.

Quando o cliente ou a chefia perguntarem, responda com a alteração, a data e a evidência, não com uma lista de hipóteses. O guia sobre como explicar uma queda ao cliente tem uma estrutura que pode reutilizar.

Como evitar que o próximo pico de rejeição seja um mistério?

Registe cada alteração no momento em que a faz, com data, responsável e motivo, e marque as maiores nos gráficos. Assim o próximo pico demora minutos a explicar, não dias.

• Mantenha um registo de alterações de marketing por cliente ou site, com anúncios, site, tracking e CRM.
• Crie anotações no GA4 para publicações, alterações de tracking e lançamentos de campanha, para que apareçam nos gráficos que a equipa consulta.
• Guarde um relatório de detalhe com a taxa de rejeição e a taxa de interação por canal e página de destino, pronto a usar.
• Combine com a equipa que ninguém mexe no temporizador nem nos eventos principais sem registar, porque ambos mudam a taxa de rejeição sem qualquer mudança de comportamento.

Para quedas maiores, o mesmo método serve para tráfego e taxa de conversão: veja queda de tráfego no GA4 e porque caiu a taxa de conversão.