GA4 page_view duplicado: como encontrar a causa e corrigir

Visualizações duplicadas quase nunca aparecem como erro. Você percebe porque os números param de fazer sentido. Sinais típicos:

• As visualizações por sessão subiram de repente a partir de uma data, sem mudança visível na loja ou no tráfego.
• No DebugView ou no relatório de tempo real, um único carregamento de página mostra dois eventos page_view com praticamente o mesmo horário.
• No relatório de páginas e telas, algumas páginas têm visualizações exageradas em relação ao número de usuários.
• Explorações de funil mostram uma etapa com mais visualizações do que a anterior, o que quase não faz sentido.

Não é um detalhe estético. page_view duplicado distorce visualizações por sessão, análises de caminho e qualquer relatório baseado em páginas. Se a mesma causa afetar eventos como add_to_cart ou purchase, receita e conversões também ficam infladas. Vale a pena encontrar a causa real em vez de simplesmente dividir os números por dois de cabeça.

Quase todos os casos seguem o mesmo padrão: o mesmo evento é enviado por dois lugares diferentes. No e-commerce, os suspeitos de sempre são estes.

GTM e gtag.js ao mesmo tempo

A tag do Google (antiga tag de configuração) roda no Google Tag Manager, mas ainda existe um snippet gtag.js fixo no tema, ou instalado por um app ou plugin, com o mesmo ID de métricas. Os dois enviam um page_view automaticamente ao carregar a página. Isso é comum depois de migrar para o GTM sem remover o código antigo.

Integração nativa da plataforma mais GTM

A maioria das plataformas de e-commerce tem uma integração própria com o Google Analytics, e muitos apps também. Se o ID do GA4 estiver preenchido nessa integração e o GTM também tiver uma tag do Google para o mesmo ID, o GA4 conta em dobro. O princípio vale para qualquer plataforma; no Shopware 6, por exemplo, essa configuração fica no canal de vendas.

Container carregado duas vezes

O próprio container do GTM é carregado duas vezes, por exemplo uma vez no template e outra por um plugin ou pela ferramenta de consentimento. Dependendo da configuração, as tags disparam mais de uma vez, e isso afeta todas as tags do container, não só o GA4.

Medição otimizada e mudanças no histórico

A medição otimizada do GA4 pode contar visualizações quando o histórico do navegador muda. Isso foi pensado para SPAs e frontends headless, em que a página não recarrega por completo. Se o frontend também envia seu próprio page_view, ou se o GTM tem um acionador de alteração de histórico, surgem duplicatas. Lojas tradicionais também são afetadas quando filtros, ordenação ou seleção de variação alteram a URL via JavaScript.

Outros gatilhos

• Uma tag de evento do GA4 extra com o nome page_view, embora a tag do Google já envie esse evento automaticamente.
• A tag do Google dispara ao carregar a página e de novo depois do consentimento, porque tem dois acionadores.
• O mesmo ID de métricas está configurado como destino em mais de uma tag do Google.

Para o diagnóstico você não precisa de acesso ao GA4, só de um navegador com as ferramentas de desenvolvedor. Siga esta ordem:

1. Abra a aba Rede (Network). Abra as ferramentas de desenvolvedor, ative a opção de preservar o log e recarregue uma página de produto. Filtre por collect. As requisições do GA4 vão para um endereço que contém /g/collect.
2. Conte as requisições. Em cada uma, veja o parâmetro en (nome do evento) e tid (ID de métricas). O GA4 pode agrupar vários eventos em uma única requisição, então confira também o conteúdo enviado. Dois page_view com o mesmo tid em um único carregamento confirmam o problema.
3. Pesquise no código-fonte. Procure por gtm.js e por gtag/js. Se o ID do GTM aparece duas vezes, ou se existe um snippet gtag separado com um ID G-, você achou o candidato.
4. Use o modo de visualização do GTM. O Tag Assistant mostra quais tags dispararam em cada evento. Se a tag do Google dispara duas vezes, ou uma tag de evento extra envia page_view, a causa está no container.
5. Teste uma mudança de histórico. Clique em um filtro ou variação que muda a URL e observe quantos page_view são enviados.

Importante: teste aceitando e recusando o banner de cookies. Algumas duplicatas só aparecem depois do consentimento, quando as tags são disparadas de novo.

A correção segue um princípio simples: para cada ID de métricas e cada evento, existe exatamente um responsável. Na maioria das lojas esse lugar é o Google Tag Manager, porque nele dá para controlar consentimento, acionadores e versões de forma centralizada.

• Remova o gtag.js fixo se o GA4 roda pelo GTM. Confira tema, extensões de template, apps e plugins.
• Desative a integração nativa de Analytics da plataforma, ou apague o ID ali, se o GTM assumir a função. O contrário também funciona: se você usa só a integração da plataforma, o GTM não pode ter uma segunda tag do Google para o mesmo ID.
• Carregue o container uma única vez. Escolha uma forma de instalação e remova a outra, inclusive em ferramentas de consentimento que podem carregar o GTM por conta própria.
• Defina quem cuida das mudanças de histórico. Em SPAs e frontends headless, use ou a detecção automática da medição otimizada ou um page_view enviado pelo frontend, nunca os dois. Se o envio for manual, desligue o page view automático da tag do Google, por exemplo com send_page_view como false, e desative a detecção por histórico nas configurações da medição otimizada.
• Exclua tags de evento redundantes que enviam page_view a mais.
• Organize os acionadores para que a tag do Google não dispare uma vez antes e outra depois do consentimento. Com o Consent Mode, normalmente basta um acionador; o consentimento é controlado pelo status de consentimento.

Publique as mudanças no GTM como uma nova versão com um nome claro, para poder voltar atrás se necessário.

O GA4 não corrige dados já coletados. As visualizações duplicadas continuam no período anterior à correção. Registre a data da mudança, internamente ou como anotação nos seus relatórios, para que ninguém confunda depois a correção com uma queda repentina de visualizações.

Para comparar períodos antes e depois da correção, use métricas menos afetadas, como usuários, sessões ou os pedidos registrados na plataforma. Métricas baseadas em páginas só devem ser comparadas a partir da data da correção.

Verifique também se outros eventos foram afetados. Se duas tags do Google rodaram em paralelo, eventos de e-commerce podem ter sido enviados em dobro. Comparar as compras do GA4 com os pedidos reais da loja no mesmo período mostra rapidamente se a receita estava inflada. Alguma diferença é normal, por exemplo por falta de consentimento, bloqueadores de anúncios ou pedidos via Pix e boleto que nunca foram pagos. Bem mais compras no GA4 do que pedidos na loja, porém, é um sinal claro de alerta.

• Cada carregamento de página envia exatamente um page_view por ID de métricas, conferido na aba Rede, incluindo requisições agrupadas.
• O container do GTM aparece uma única vez no código-fonte.
• Não há snippet gtag.js extra com o mesmo ID G- no tema, em apps ou plugins.
• A integração de Analytics da plataforma está vazia, ou o GTM não cuida do mesmo ID.
• O GTM não tem uma tag de evento separada para page_view enquanto a tag do Google envia esse evento automaticamente.
• A tag do Google tem exatamente um acionador e não dispara de novo após o consentimento.
• Para mudanças de URL sem recarregar, está definido quem envia o page view: medição otimizada ou frontend.
• Teste feito aceitando e recusando o banner de cookies.
• Data da correção documentada.
• Compras do GA4 comparadas com os pedidos da loja em um período de teste.

Para ter uma primeira visão rápida de tags duplicadas na sua loja, use o autodiagnóstico gratuito: ele abre a página inicial e uma página de produto como um visitante e aponta, entre outros pontos, tags duplicadas, GA4 e GTM em cerca de um minuto.