Quebra de tráfego no GA4: como distinguir um erro de medição de uma perda real de visitas

Porque é que o tráfego caiu no GA4?

A maioria das quebras de tráfego no GA4 tem origem em cinco sítios: tracking avariado, uma alteração no consentimento, uma definição de administração como um filtro de dados, uma mudança num canal de aquisição ou uma descida real da procura. O caminho mais rápido é verificar por esta ordem, porque as três primeiras causas são invisíveis para quem não acede à conta de analytics.

Antes de abrir qualquer relatório, registe três factos: o primeiro dia da quebra, a métrica que desceu (utilizadores, sessões ou ambas) e a dimensão. «Sessões a descer 35% desde 14 de março, utilizadores 33%» é uma pergunta com resposta. «O tráfego está fraco» não é.

Se também gere meios pagos, leia em conjunto com como descobrir porque caíram as conversões, porque uma quebra de tráfego e uma quebra de conversões partilham muitas vezes a mesma causa.

Como verificar se o tracking do GA4 deixou de funcionar?

Abra o relatório de tempo real enquanto navega no site: se a sua visita não aparecer, a recolha está avariada pelo menos nessa página. Depois confirme se a etiqueta continua a carregar em todos os modelos de página, e não apenas na página inicial.

1. Tempo real e DebugView. O centro de ajuda da Google indica que o relatório de tempo real mostra a atividade dos últimos 30 minutos e que o DebugView mostra os eventos de um dispositivo em modo de depuração. Teste as páginas que perderam mais tráfego.
2. Etiqueta em todas as páginas. A Google afirma que o Analytics só recolhe dados das páginas que incluem a etiqueta. Um novo modelo de landing page, um checkout noutro subdomínio ou uma migração de CMS podem ir para produção sem ela.
3. ID de medição. O ID na etiqueta tem de coincidir com o da stream de dados da propriedade. Copiar a configuração de testes para produção é uma forma comum de enviar tráfego para a propriedade errada.
4. Publicação no Tag Manager. As alterações no Google Tag Manager não recolhem nada até a versão do contentor ser submetida e publicada. Consulte o histórico de versões na data da quebra.
5. Tempo de processamento. A Google indica que muitos relatórios demoram 24 a 48 horas a processar. Uma «quebra» nos números de ontem pode ser apenas informação incompleta.

Verifique também o problema inverso: a Google avisa que usar a etiqueta Google e o Tag Manager em simultâneo na mesma propriedade pode duplicar a contagem. Se alguém removeu uma etiqueta duplicada, o tráfego desce para o nível real. Parece uma quebra, mas é uma correção. Registe essa alteração para que ninguém a «repare» mais tarde.

O modo de consentimento ou o banner de cookies explicam a quebra?

Sim, podem explicar. Se o banner, o estado de consentimento predefinido ou a integração com as etiquetas mudou no dia em que a quebra começou, o GA4 pode estar apenas a observar menos utilizadores. As visitas continuam a existir; o GA4 é que vê menos.

O GA4 pode compensar parte da diferença com a modelação comportamental do modo de consentimento, que usa machine learning para estimar o comportamento de quem recusa cookies de analytics. Segundo a Google, a propriedade precisa do modo de consentimento em todas as páginas com a implementação avançada, de pelo menos 1000 eventos por dia com analytics_storage='denied' durante no mínimo 7 dias e de pelo menos 1000 utilizadores diários com analytics_storage='granted' em pelo menos 7 dos 28 dias anteriores. Cumprir estes limiares não garante a elegibilidade.

Para ver dados modelados é necessária a opção Combinado em "Administrador" > "Exibição de dados" > "Identidade do relatório" (função de editor ou superior). Duas verificações práticas:

• Alguém mudou a identidade do relatório, o fornecedor do banner, o layout ou o estado de consentimento predefinido? Qualquer destas alterações muda a contagem de utilizadores sem perder uma única visita.
• Compare as sessões do GA4 com uma fonte que não depende de cookies de analytics, como os cliques no Google Ads ou as encomendas no seu sistema. Se cliques e encomendas estão estáveis e o GA4 desceu, a causa é a medição.

A Google indica funcionalidades que não usam dados modelados, como públicos-alvo, relatórios de retenção e a exportação para o BigQuery, por isso esses números podem divergir dos relatórios-padrão.

Um filtro de dados ou uma definição de administração removeu tráfego?

Verifique a administração antes de culpar o mercado. Um filtro de dados ou uma definição de referências pode remover ou reatribuir tráfego de um dia para o outro, sem que ninguém fora desse ecrã repare.

Filtros de dados

Os filtros estão em "Administrador" > "Coleta e modificação de dados" > "Filtros de dados". A documentação da Google é clara: um filtro Ativo faz alterações permanentes, e os dados excluídos nunca são processados nem ficam disponíveis no Analytics ou no BigQuery. Uma propriedade pode ter até 10 filtros de dados, e um filtro pode demorar 24 a 36 horas a ser aplicado.

Procure um filtro que tenha passado recentemente de Testes para Ativo, ou uma regra de tráfego interno com um intervalo de IP demasiado largo (por exemplo, um intervalo que também apanha o escritório de um cliente ou uma VPN usada por clientes reais). Em modo de testes, a dimensão "Nome do filtro de dados de teste" mostra o que o filtro removeria, que é a forma segura de o validar primeiro.

Referências indesejadas

A opção "Listar indicações indesejadas" está na stream de dados web, em "Definir as configurações da tag". Acrescentar um domínio aí não apaga sessões, mas muda a origem que recebe o crédito: as referências descem enquanto o tráfego direto ou outro canal sobe. A Google permite até 50 referências indesejadas por stream de dados.

A quebra aconteceu num canal ou em todos?

Divida a quebra por grupo de canais predefinido no relatório de aquisição de tráfego. Uma descida num único canal aponta para uma alteração nesse canal; uma descida semelhante em todos aponta de volta para o tracking ou o consentimento.

• Pesquisa paga ou redes sociais pagas desceram: verifique orçamentos, campanhas em pausa, alterações à estratégia de licitação e recomendações aplicadas automaticamente. Compare cliques com sessões do GA4 nas mesmas datas. Cliques estáveis e sessões a descer indicam normalmente uma landing page sem etiqueta ou parâmetros UTM perdidos.
• Pesquisa orgânica desceu: compare o GA4 com os cliques na Search Console. Se a Search Console também desceu, analise os lançamentos do site (robots, redirecionamentos, modelos) e as alterações de posições. Se só o GA4 desceu, volte ao tracking.
• Referências subiram e outro canal desceu: procure um novo meio de pagamento, ferramenta de reservas ou domínio de login que devolve o utilizador ao site, ou uma alteração à lista de referências indesejadas.
• Direto ou não atribuído subiu: normalmente são UTM perdidos, redirecionamentos que cortam a query string ou um modelo de link de campanha que mudou.

Divida também por landing page e dispositivo. Uma quebra numa única landing page após um lançamento é quase sempre uma alteração no site, não no mercado.

Como provar que alteração causou a quebra de tráfego no GA4?

Coloque todas as alterações dos 7 a 14 dias anteriores à quebra numa única cronologia, exclua primeiro a medição e teste uma hipótese de cada vez. A causa costuma ser a alteração mais próxima da data da quebra que afeta as páginas ou o canal em queda.

1. Reúna todas as alterações com data. Edições da equipa (campanhas, orçamentos, lançamentos do site, etiquetas e consentimento), automatismos das plataformas (recomendações aplicadas automaticamente, atualizações de algoritmo ou de políticas) e eventos externos (feriados, falhas de serviço, uma campanha de um concorrente).
2. Exclua o tracking. Faça as verificações acima. Se cliques ou encomendas não mudaram, pare e corrija a medição antes de mais nada.
3. Compare forma e data. Um degrau num único dia corresponde a um lançamento ou a uma definição. Uma descida gradual corresponde à procura, às posições ou a um orçamento a diminuir.
4. Teste uma hipótese. Reverta ou isole uma alteração, aguarde o processamento e compare os mesmos dias da semana.

Exemplo: as sessões descem 30% numa terça-feira. A cronologia mostra um novo banner de cookies publicado nessa manhã e um corte de orçamento no Google Ads duas semanas antes. Cliques e encomendas estão estáveis, por isso o corte não é a causa; o banner é. A correção está no consentimento, não no plano de meios.

O GA4 permite registar estes eventos como anotações nos gráficos de linhas, até 1000 por propriedade, com um título de 60 caracteres no máximo (veja como usar anotações no GA4). Para alterações espalhadas entre plataformas de anúncios, site e tracking, um registo de alterações de marketing partilhado reúne tudo. O Changeline faz isso: regista cada alteração com data, responsável e motivo numa cronologia por cliente, e pode começar um registo de alterações gratuito enquanto está em acesso antecipado. Quando o cliente perguntar o que aconteceu, este guia para explicar uma quebra ao cliente ajuda na conversa.