Purchase duplicado no GA4 e receita diferente da loja: onde está o erro

Publicado em 10 de outubro de 2026 pela equipe do UTM Builder, na Limner.

O GA4 conta os eventos purchase que recebe. Quando ele mostra mais compras do que a loja tem de pedidos, o motivo mais comum é ter duas instalações mandando a mesma compra, ou uma página de obrigado que dispara de novo. Já a receita diferente costuma vir de regra: frete fora do value, pedido manual, cancelamento, e Pix ou boleto contados antes do pagamento.

O que o GA4 faz com o transaction_id

A ajuda do Google Analytics diz que, se duas compras chegam com o mesmo ID da transação, o GA4 elimina a duplicação. O mesmo artigo traz três ressalvas:

• A deduplicação só vale para dados de fluxos da Web. Compra registrada em app não passa por ela.
• Não envie o ID vazio. Com transaction_id="", o GA4 deduplica todas as compras que chegarem assim, e elas viram uma só.
• O mesmo ID usado em pedidos diferentes derruba a contagem. Use o número do pedido, que é único, e nunca e-mail ou CPF do cliente.

Na referência de eventos do Google, transaction_id, value e currency são obrigatórios no purchase.

Duas instalações mandando a mesma compra

O guia de parceiros da Nuvemshop pede para não usar o GA4 nativo e o GA4 pelo GTM ao mesmo tempo, manter uma tag e um ID do GA4 ativos e não repetir scripts em Códigos externos. A recomendação é usar a integração nativa e deixar o GTM só para o que ela não cobre, como clique no WhatsApp e formulário. O mesmo guia avisa que, com tudo pelo GTM, os eventos só são capturados enquanto a página está aberta, e o reembolso não é enviado.

A Loja Integrada instala o GA4 por app (Soluções > Aplicativos) e manda desativar o GA3 ao instalar o GA4, para não duplicar conversões. Na Shopify e na Tray, a regra é a mesma: uma fonte de purchase por loja. Se as duas fontes mandam IDs diferentes para o mesmo pedido, cada uma vira uma compra.

Página de obrigado recarregada

A VTEX documenta isso como problema conhecido: a transação vai para o Google Analytics quando a página de pedido confirmado carrega, e recarregar ou voltar a ela dispara o evento de novo. A VTEX diz que não há contorno para esse tipo de integração no front-end e sugere enviar a compra pelo back-end, ligando as APIs de pedido ao Google Analytics. Em qualquer plataforma, confira se o ID enviado é o número do pedido, igual a cada carregamento. Com o mesmo ID, a deduplicação da Web segura a repetição.

Pix e boleto contados antes do pagamento

Na Nuvemshop, o disparo do purchase é configurado em Configurações > Códigos externos: na finalização do pedido ou na confirmação do pagamento. Na finalização, Pix e boleto que nunca foram pagos entram como compra. Na confirmação, o pedido não pago aparece no painel da loja como iniciado e fica fora do GA4.

A Kiwify tem uma opção para enviar o purchase ao gerar um Pix ou boleto e permite definir uma conversão personalizada para cada forma de pagamento. Se a opção estiver ligada, o GA4 conta a geração do Pix, não o pagamento.

Receita diferente sem nenhuma duplicidade

• Frete. A referência do Google define value como a soma de preço vezes quantidade dos itens, sem frete e sem imposto, que vão em shipping e tax. O painel da loja costuma mostrar o total pago.
• Comissão. Na Kiwify, o value enviado ao GA4 é o valor de comissão do produtor, não o valor pago pelo cliente.
• Pedidos que não passam pelo site. A Nuvemshop avisa que pedidos manuais e criados por aplicativos não vão para o GA4.
• Cancelamento e reembolso. Segundo a Nuvemshop, o GA4 só reconhece cancelamento de pedido já pago, tira a receita na data do reembolso e aceita o evento de reembolso até 3 dias depois da compra. A métrica Receita de compra do GA4 já desconta os reembolsos.
• Fuso e atraso. Compare no mesmo fuso horário. A Nuvemshop lembra que o GA4 pode levar até 24 horas para atualizar.

Como conferir

1. Faça um pedido de teste com o modo de depuração ligado e abra Administrador > Exibição de dados > DebugView. Conte quantos purchase chegaram e veja o transaction_id e o value de cada um.
2. Recarregue a página de obrigado e veja se um segundo purchase aparece.
3. Numa exploração, use a dimensão ID da transação com as métricas Transações e Receita de compra. Exporte o período e compare com a planilha de pedidos da loja, no mesmo fuso, separando pedidos pagos, cancelados e manuais.