Discrepância entre WooCommerce e GA4: o caos dos plugins (e como zerar com server-side)
O WooCommerce é a plataforma de e-commerce mais instalada do mundo. Também é a mais fácil de quebrar.
A mesma liberdade que permite customizar tudo permite que três plugins diferentes disparem o mesmo purchase, que um plugin de cache congele o dataLayer com dados do pedido anterior e que uma atualização automática de quinta-feira à noite derrube a coleta sem ninguém perceber até o fechamento do mês.
Se a sua loja WooCommerce mostra uma receita e o GA4 mostra outra, a causa quase nunca é uma. É um empilhamento de pequenas quebras que esse artigo organiza em um diagnóstico único.
O que é a discrepância entre WooCommerce e GA4?
Discrepância entre WooCommerce e GA4 é a diferença entre pedidos e receita registrados no WooCommerce (relatórios nativos ou tabela de pedidos) e os números equivalentes no Google Analytics 4.
Diferente de plataformas SaaS fechadas, no WooCommerce a discrepância pode ir para os dois lados: GA4 abaixo do real (coleta perdida) ou acima do real (eventos duplicados). Em auditorias da Métricas Boss, é comum encontrar as duas distorções na mesma loja, se compensando parcialmente e criando a ilusão de que está tudo bem.
As 7 causas técnicas da discrepância no WooCommerce
1. Múltiplos plugins de tracking disparando em paralelo
O cenário mais comum do ecossistema: um plugin oficial de Google, um plugin de pixel tudo-em-um, um GTM instalado manualmente pela agência e um snippet esquecido no functions.php do tema. Cada um dispara seu próprio purchase.
O GA4 até deduplica transaction_id repetido dentro de limites, mas parâmetros divergentes entre os disparos contaminam receita, itens e atribuição. A primeira etapa de qualquer correção no WooCommerce é um inventário completo do que dispara o quê.
2. Cache servindo dataLayer congelado
Plugins de cache de página (WP Rocket, LiteSpeed, W3 Total Cache) e CDNs mal configurados podem cachear a página de obrigado com o dataLayer de um pedido antigo. Clientes diferentes carregam a mesma página congelada e o GA4 recebe o mesmo purchase repetido, ou nenhum.
A regra profissional: página de checkout e de confirmação nunca entram no cache. É configuração de uma linha que metade das lojas não tem.
3. Recarregamento da página de obrigado
O cliente volta à página de confirmação pelo histórico, atualiza a página ou clica no link do e-mail de pedido. Sem trava de disparo único por transaction_id, cada visita gera um purchase novo.
Receita inflada no GA4 é tão perigosa quanto receita faltando: infla o ROAS e sustenta campanhas que deveriam ser cortadas.
4. Gateways de pagamento com redirect externo
Mercado Pago, PagSeguro, PayPal e afins no modo redirect levam o cliente para fora do domínio. Parte não volta, especialmente em Pix e boleto, cuja aprovação acontece horas depois com a aba fechada.
O pedido muda para "processando" no WooCommerce via IPN do gateway. Nenhum navegador estava aberto para contar isso ao GA4.
5. Atualizações que quebram silenciosamente
WordPress atualiza core, tema e plugins em ciclos independentes. Uma atualização de tema que sobrescreve o header, um plugin de tracking com breaking change, um construtor de página que muda a estrutura do checkout. Qualquer um derruba a coleta sem erro visível.
Loja WooCommerce sem monitoramento de paridade descobre a quebra semanas depois, no fechamento.
6. Status de pedido tratado como venda (ou não)
O WooCommerce tem status: pendente, processando, concluído, cancelado, reembolsado. O purchase client-side dispara na confirmação, antes do pagamento compensar. Pedidos pendentes que nunca pagam ficam registrados no GA4 como venda.
No sentido inverso, relatórios do WooCommerce filtrados por "concluído" ignoram pedidos em processamento que o GA4 já contou. Comparar sem alinhar o critério de status é comparar frutas diferentes.
7. Reembolsos invisíveis
Reembolso feito no admin do WooCommerce não gera evento de refund no GA4 na maioria das implementações client-side. Com o tempo, a receita do analytics descola da receita líquida real, e o descolamento cresce em datas de troca intensa como pós-Black Friday.
Quanto de discrepância é aceitável entre WooCommerce e GA4?
| Discrepância de receita | Diagnóstico |
|---|---|
| 0% a 3% | Excelente. Server-side com hooks de pedido ativo. |
| 3% a 8% | Saudável. Ajustes em refund e status de pedido. |
| 8% a 18% | Atenção. Provável conflito de plugins ou cache. |
| 18% a 30% | Crítico. Coleta estruturalmente quebrada. |
| Acima de 30% | Falha grave ou duplicação mascarando perda. |
No WooCommerce, vale medir também a razão purchase vs pedidos: purchase acima do número de pedidos denuncia duplicação, mesmo quando a receita "parece" próxima.
Como o server-side resolve no WooCommerce?
O WooCommerce tem uma vantagem única sobre plataformas fechadas: acesso total ao servidor. Os hooks nativos de mudança de status de pedido permitem disparar eventos direto do backend para um container GTM Server-Side, via Measurement Protocol.
A arquitetura profissional:
- •purchase disparado pelo hook de pagamento aprovado, não pela página de obrigado. Cobre Pix, boleto, redirect de gateway e cliente que fechou a aba.
- •refund disparado pelo hook de reembolso, mantendo o GA4 alinhado à receita líquida.
- •Deduplicação por transaction_id entre o evento client-side (mantido para atribuição de sessão) e o server-side (fonte de verdade da transação).
- •Cache e atualizações de plugin deixam de ameaçar o evento crítico, porque ele não mora mais no navegador.
Em lojas WooCommerce auditadas pela Métricas Boss, essa arquitetura combinada com a limpeza de plugins leva a paridade para menos de 3%, com monitoramento que denuncia qualquer quebra futura em dias, não em fechamentos de mês.
O protocolo em 5 etapas
- •Inventário de tracking: mapear todo plugin, snippet e tag que dispara eventos. Eleger um único caminho e desativar o resto.
- •Correção de infraestrutura: excluir checkout e confirmação do cache, travar disparo único por transaction_id, alinhar critério de status entre relatórios.
- •dataLayer de funil completo: eventos de e-commerce GA4 com items em todas as etapas.
- •Server-side via hooks: purchase e refund do backend para o GTM Server-Side, com deduplicação.
- •Monitoramento de paridade: dashboard diário WooCommerce vs GA4 com alerta acima de 5% e verificação pós-atualização de plugins.
Como a Métricas Boss resolve isso?
A Métricas Boss audita e implementa infraestrutura de medição em lojas WooCommerce, do inventário de plugins à arquitetura server-side por hooks, com monitoramento contínuo que transforma quebra silenciosa em alerta imediato.
Se a sua loja WooCommerce vive o ciclo de quebrar, descobrir tarde e remendar, conheça o que a Métricas Boss faz e solicite uma auditoria preliminar.
Perguntas frequentes sobre discrepância WooCommerce vs GA4
Por que o WooCommerce e o GA4 mostram receitas diferentes? Pelo empilhamento de causas: plugins de tracking duplicados, cache congelando a página de confirmação, gateways com redirect externo, purchase disparando antes do pagamento compensar e reembolsos que nunca chegam ao GA4. No WooCommerce a distorção pode ser para cima e para baixo ao mesmo tempo.
Qual o melhor plugin de GA4 para WooCommerce? A pergunta certa é outra: um único caminho de tracking bem implementado vence qualquer combinação de plugins. Para operações que dependem do dado para decidir mídia, a arquitetura recomendada é GTM com dataLayer próprio no client-side e hooks de pedido no server-side, não plugins tudo-em-um empilhados.
Por que meu purchase está duplicado no GA4? As causas mais comuns: mais de um plugin disparando o evento, página de obrigado sem trava de disparo único sendo recarregada pelo cliente, ou cache servindo a página de confirmação para visitantes diferentes.
Pix e boleto aparecem no GA4 do WooCommerce? Na coleta client-side, muitas vezes não. A aprovação acontece com a aba fechada. A solução definitiva é disparar o purchase pelo hook de pagamento aprovado no servidor, via Measurement Protocol.
Reembolso no WooCommerce atualiza o GA4? Na implementação padrão, não. O GA4 mantém a receita bruta. A propagação do evento refund via server-side é o que alinha o analytics à receita líquida real.
Como saber se uma atualização de plugin quebrou meu tracking? Sem monitoramento, só no fechamento do mês. Com um dashboard diário de paridade WooCommerce vs GA4 e alertas automáticos, a quebra aparece em 24 a 48 horas.
Gustavo Esteves
Gustavo Esteves é fundador e CEO da Métricas Boss, já trabalhou dentro de gigantes como B2W. Autoridade na área de Digital Analytics, com mais de 15 anos de experiência e 3 mil projetos atendidos, incluindo gigantes como PUC, Rede D'Or, Globo, Stanley, Médico Sem Fronteiras, Alura, entre outras.
Publicado em 2 de julho de 2026
