Um pedido pode produzir vários eventos purchase se o site tiver GA4 e GTM instalados em paralelo, a plataforma já enviar a compra por um pixel ou a confirmação disparar novamente ao recarregar. Corrija a origem da duplicação; o transaction_id único do pedido é uma salvaguarda de deduplicação documentada pelo GA4, não motivo para manter tags duplicadas.
Mapeie quem envia a compra
- Liste todas as integrações que podem enviar ecommerce: código
gtag.js, containers GTM da página/servidor, pixel/app da plataforma, app de checkout e integração do gateway. - Use o Preview do GTM e DebugView do GA4 em uma compra de teste. Anote quantas vezes o evento surge na camada de dados, quantas tags disparam e qual origem envia cada chamada.
- Recarregue a página de confirmação, use voltar/avançar e abra novamente o comprovante. Se a compra for transmitida de novo sem um novo pedido, o gatilho está ligado à visualização da página ou à repetição do evento.
- Mantenha uma implementação responsável pelo
purchase. Se o ecommerce já é enviado por integração oficial, não replique manualmente o mesmo evento sem uma arquitetura de deduplicação definida.
Use um ID estável e implemente idempotência
O transaction_id precisa ser único por pedido, dinâmico e não conter dado pessoal. Nunca envie um valor vazio nem reaproveite o mesmo ID em compras diferentes. O GA4 informa que eventos purchase com o mesmo ID de transação são deduplicados em web streams; o segundo pode ser ignorado. Essa regra não elimina a necessidade de corrigir o disparo duplicado nem deve ser tratada como garantia para todas as integrações e contextos de consentimento.
Quando você controla a aplicação, emita a compra só depois da confirmação de pagamento/pedido aceita pelo seu fluxo e registre o envio por ID de pedido. Antes de transmitir, consulte ou persista uma marca de idempotência, por exemplo purchase_sent:<order_id> no backend. Para serviços de terceiros, use o mecanismo oficial do plugin/plataforma e confira se a confirmação é baseada em pedido concluído, não apenas em carregar a URL.
Exemplo conceitual no servidor — pseudocódigo, adapte ao seu banco/transação:
quando pedido passa para pago:
em transação atômica:
se order_id já consta como purchase enviado: encerrar
marcar order_id como purchase enviado
enfileirar evento purchase com transaction_id únicoO estado de pedido e a emissão devem ser coordenados de forma atômica ou com fila/outbox; um sessionStorage no navegador pode reduzir repetição numa aba, mas perde eficácia em outra aba, outro dispositivo ou limpeza de sessão e não substitui o controle do sistema de pedidos.
Valide a correção
Faça ao menos um novo pedido de teste com ID não reutilizado. Confirme um evento em DebugView, parâmetros transaction_id, value, currency e items, ausência de segundo disparo ao recarregar e correspondência com o pedido na plataforma. Confira chamadas de rede e uma compra em que o consentimento de analytics é recusado, seguindo a configuração de privacidade aprovada para a loja.
Se o evento aparece uma vez no DebugView mas o relatório posterior difere, espere o processamento, confira filtros/consentimento e compare IDs anonimizados com os pedidos. Não publique dados pessoais como ID de transação.
Fontes: Minimizar eventos principais duplicados com IDs de transação — Google Analytics, Validar ecommerce — Google for Developers e Configurar eventos ecommerce — Google Analytics. Consulte métricas.