Se seus eventos de pageview aparecem duas vezes em uma SPA (aplicação de página única), você não está vendo apenas ruído: está diante de um problema estrutural de mensuração. Em ambientes que utilizam GA4, GTM Web e integrações com server-side, o page_view pode ser enviado tanto na carga inicial da página quanto a cada transição de rota, mesmo que a tela tenha apenas trocas de conteúdo. O resultado é duplicação de dados, distorção de atribuição entre campanhas, e uma leitura inconsistente de qual canal realmente gerou a conversão. Em SPAs, o desafio não é apenas “coletar mais dados” — é assegurar que cada episódio de pageview seja contado uma única vez, com o contexto correto de rota, tela e fonte.
Este artigo nomeia o problema com precisão, oferece diagnóstico direto ao ponto e apresenta um caminho operacional para diagnosticar, corrigir e ajustar a emissão de pageview sem perder visibilidade de dados importantes. Ao término, você deverá entender como estruturar a emissão de eventos para evitar duplicidade, quando manter envio automático e quando migrar para um único disparo por navegação, além de um roteiro prático de auditoria que contempla GA4, GTM Web e, se couber, server-side. O objetivo é você sair com decisões técnicas claras, um plano de ação e um modelo de validação que funciona no mundo real, não num slide bonito.
Por que o pageview duplicado acontece em SPAs
Duplicação de pageview em SPA costuma ser sintoma de duas fontes distintas de emissão: a página é “carregada” pelo GA4 automaticamente e, ao navegar, você dispara outro page_view sem consolidar com o anterior.
Carga inicial da página vs mudança de rota
Em SPAs, a primeira carga da página dispara um page_view porque o GA4 (ou o GTM) interpreta o carregamento como uma visita completa. Quando o usuário navega para outra tela sem recarregar a página, muitos setups emitem um segundo page_view para atualizar o estado da tela. Se o mesmo fluxo também está gerando page_view por meio de uma configuração de roteamento dentro da SPA (por exemplo, React Router, Next.js, Vue Router), você acaba dobrando o volume de page_views para o mesmo conjunto de usuários e sessões. A consequência é uma contagem inflada de visualizações de página, que contamina métricas de fluxo, funis de conversão e a validação de mídia paga com o CRM ou o BI. Em termos práticos, você pode perceber discrepâncias entre GA4 e plataformas de atribuição, ou entre GA4 e o servidor de dados que você utiliza para BigQuery ou Looker Studio.
Configurações concorrentes de GA4 no GTM Web
Um erro comum é manter o envio automático de page_view no GA4 Configuration tag do GTM Web, enquanto há um disparo separado de page_view para mudanças de rota. Em SPA, isso resulta em dois eventos de page_view quase simultâneos para a mesma ação do usuário. A configuração típica que provoca duplicidade é “Send Page View” ligado no GA4 Configuration tag e também um trigger de page_view personalizado para cada alteração de rota. A soma da dupla emissão não apenas inflaciona números, como também dificulta a deduplicação nos dashboards e confirmações com ferramentas de medição externas.
Envio duplicado entre client-side e server-side
Se você utiliza GTM Server-Side (GTM-SS) junto com o GTM Web, existe a tentação de centralizar a lógica de page_view no servidor para reduzir perdas de dados com bloqueadores, consentimento ou redirecionamentos. Porém, sem uma deduplicação cuidadosa, a mesma visualização pode chegar ao GA4 duas vezes: uma pelo cliente e outra pelo servidor, ambas com o mesmo page_path e session_id. A consequência é um “duplo toque” que não representa uma segunda ação do usuário, mas sim a mesma ação sendo reportada por dois canais de emissão. Nessa situação, é essencial estabelecer uma regra de disparo único por evento de rota no conjunto de pipelines (cliente ou servidor) ou consolidar o envio em uma única camada de medição.
Sinais de que você está com duplicação
Duas ocorrências de page_view por navegação
Se você notar que, para a mesma navegação de rota, as ferramentas reportam duas ocorrências de page_view quase no mesmo instante, é um sinal claro de duplicação. Compare logs de GA4 com dados no BigQuery ou no Looker Studio para confirmar: a mesma sessão gerando dois eventos com o mesmo page_path pode indicar que há dois emissores ativos para o mesmo usuário.
Desvios entre GA4 e outras fontes de verdade
Quando o número de page_views ou de sessões não bate com o que aparece em modelos de dados offline (CRM, planilhas de conversão ou integrações com WhatsApp/Telefone), a hipótese de duplicação fica forte. Em SPAs com rastreamento híbrido (client-side e server-side), perdas de deduplicação aparecem como variações de lookback entre fontes, dificultando a escrituração de qual clique de aquisição realmente gerou a conversão.
Arquiteturas de solução: onde colocar o page_view único
Desativar page_view automático no GA4 Configuration tag
A primeira decisão prática é eliminar o envio duplo do page_view automático. Se a sua SPA faz navegação via history API, atendimento primário do GA4 deve ocorrer apenas por meio de um evento específico de rota. Em GTM Web, desative o “Send Page View” no GA4 Configuration tag e substitua por uma emissão controlada de page_view apenas quando houver mudança de rota relevante, com o parâmetro page_path alinhado ao caminho real da tela.
Disparar page_view apenas em mudança de rota com page_path correto
Ao invés de confiar no carregamento da página para disparar page_view, centralize o envio em um evento de rota (route_change) que atualiza o page_path e other parâmetros relevantes. Esse approach reduz duplicatas desde que você padronize o valor de page_path (ex: /produtos/checkout) e respeite o contexto da tela. Em SPAs com várias rotas, a consistência de page_path evita que o mesmo conteúdo seja contado duas vezes por causa de mudanças de estado.
Roteiro de auditoria e configuração
- Mapear o fluxo de navegação da sua SPA (framework, router, pontos de mudança de tela) para entender onde o page_view é emitido hoje.
- Verificar a configuração do GA4 no GTM Web: confirme se “Send Page View” está ativo na GA4 Configuration tag e se há triggers adicionais disparando page_view em mudanças de rota.
- Desativar o envio automático de page_view na configuração base e padronizar a emissão apenas em uma camada central de SPA navigation events.
- Impor uma emissão de page_view única por rota, com page_path refletindo a rota atual e, se possível, incluir page_location e screen_resolution para contexto adicional.
- Habilitar debug/preview: utilize GA4 DebugView e o modo de pré-visualização do GTM para confirmar que apenas um page_view é emitido por mudança de rota.
- Verificar cenários de Server-Side: se estiver usando GTM Server-Side, assegure que o servidor não esteja duplicando eventos já enviados pelo cliente.
- Validar consistência nos dados: compare os números de page_views com fontes internas (CRM, eventos offline, conversões via WhatsApp) para confirmar que a deduplicação está funcionando como esperado.
Erros comuns e como adaptar à realidade do projeto
Esquecer de desativar o envio automático de page_view
Manter o envio automático paralelo a uma emissão manual para cada rota gera duplicação. A correção prática é desabilitar o auto page_view no GA4 Configuration tag e centralizar a emissão apenas no fluxo de navegação da SPA. Além disso, garanta que o event_name utilizado para a rota seja padronizado entre ambientes (dev, staging, produção).
Misturar dados de GA4 e GTM sem deduplicação
Se você usa GA4 direto na página e, ao mesmo tempo, um GTM com eventos de page_view, há grande chance de duplicidade. A regra é simples: escolha uma única origem para o page_view de cada rota — geralmente o GTM Web — e use o GA4 apenas para receber o conjunto já consolidado de events, evitando triggers paralelos que reemitam o mesmo evento.
Configurações de janela de lookback inconsistentes
Diferentes janelas de lookback entre fontes (GA4, BigQuery, Looker Studio) podem fazer parecer que há duplicação quando, na verdade, há apenas variação no momento de envio. Defina políticas consistentes de lookback e de retenção de dados entre o pipeline de coleta e a camada de apresentação (BI/Relatórios) para que você interprete corretamente os números.
Adaptação prática ao seu projeto e governança de dados
Não adianta apagar dados. A prática correta é alinhar o ciclo de vida da aplicação com o fluxo de eventos de mensuração, assegurando que cada ação do usuário seja refletida de forma única, com o contexto de rota correto.
Em SPAs com WhatsApp/CRM integrados, mantenha uma trilha clara de quando o lead fecha a venda e qual clique o gerou. O objetivo é ter dados que resistam a escrutínio, não apenas números que parecem grandes.
Para empresas que operam com várias camadas de rastreamento, de GA4 a CAPI, a decisão entre client-side e server-side não é apenas tecnológica — é sobre confiabilidade de dados, SLA de delivering e custo de manutenção. Se a solução ideal exige estrutura de dados mais profunda, considere um modelo de auditoria de eventos que mise a validação contínua: verifique, a cada sprint, se o pipeline de page_view continua único por rota e se o conjunto de métricas permanece estável após alterações de rota ou de implementação de consentimento.
Se quiser avançar com um diagnóstico técnico específico para o seu stack (SPA em React/Next.js, GTM Web + GTM Server-Side, integração com WhatsApp Business API e BigQuery), a Funnelsheet pode revisar seu setup atual, identificar pontos de duplicação e entregar um plano de ação com alterações acionáveis já alinhadas ao seu ambiente de produção.
Para acelerar o diagnóstico, comece hoje alimentando o time com um olhar crítico sobre sua emissão de page_view: verifique se há duplicidade na mudança de rota, se a configuração automática de GA4 está desativada e se o pipeline está deduplicando efetivamente na origem. O próximo passo concreto é implementar o envio de page_view apenas na transição de rota com um caminho consistente, validar com DebugView e documentar a auditoria para manter o controle em sprints futuras.