Como verificar se o evento de compra (purchase) do GA4 Ecommerce está sendo enviado corretamente

"Configurei o ecommerce no GA4, mas a receita no meu relatório de Monetização não bate com o carrinho." Essa é uma das dores de cabeça mais comuns na medição de lojas online. As compras estão acontecendo, mas o valor não aparece, ou nenhum item foi registrado. Na maioria das vezes, a causa é uma falha dentro do evento purchase enviado no checkout.

Alguma dessas situações soa familiar?

• O relatório de Monetização mostra compras, mas receita (value) zerada (ou em branco)
• "Compras de ecommerce" aparece, mas a lista items está vazia
• O painel do seu carrinho e o GA4 discordam sobre o valor da receita
• O mesmo pedido é contado duas vezes, inflando a receita acima do real

Este guia organiza como verificar se o evento de compra do GA4 está sendo enviado corretamente, parâmetro por parâmetro. De forma prática: onde olhar para isolar "enviado vs. não enviado".

Primeiro, os parâmetros que um evento de compra precisa ter

O centro da medição de ecommerce do GA4 é o evento recomendado purchase, enviado quando uma compra é concluída. Para registrar corretamente a receita e os produtos, todos estes parâmetros precisam estar presentes.

Parâmetro	Função	Falha comum
transaction_id	Identifica o pedido de forma única	Ausente → a mesma compra é contada em dobro
value	Valor total da compra	Não definido / enviado como string → a receita aparece como 0
currency	Código da moeda (ISO 4217)	Não é BRL/USD, ou está ausente → o valor não é agregado
items	Array de produtos comprados	Array vazio ou esquema errado → os produtos não são registrados

O ponto-chave: value e currency sempre andam juntos. Sem uma moeda, o GA4 não consegue agregar o valor como receita. E items é um array em que cada produto carrega campos como item_id e item_name. Se esse array estiver vazio ou com estrutura errada, a compra continua sendo contada, mas os produtos dentro dela desaparecem.

A armadilha do array items (produtos não registrados)

Quando "as compras aparecem, mas os produtos ficam vazios", quase sempre é um problema de items. Três causas típicas:

1. Array items vazio: o purchase é enviado, mas items: []. Os dados do carrinho estão sendo cortados em algum ponto da passagem.
2. Esquema errado: cada produto não tem nem item_id nem item_name. O GA4 exige pelo menos um dos dois, então, se ambos estiverem ausentes, o item não é tratado como produto.
3. Nomes de campo errados: você ainda está enviando chaves antigas do Universal Analytics, como id ou name. O GA4 espera item_id / item_name.

Armadilha comum: se você consegue ver a requisição purchase disparar no DevTools, mas nenhum produto é registrado, verifique o corpo da requisição item por item — o items está vazio, e as chaves são item_id / item_name? "O evento está disparando" não significa "os produtos chegaram corretamente".

A armadilha de value / currency (a receita não bate)

Falhas em torno do valor quebram silenciosamente seus relatórios de receita.

• value enviado como string: enviar "3000" como string pode impedir que o GA4 o agregue como número, então ele nunca chega à receita. Passe um número (3000).
• currency ausente ou fora do padrão ISO: se currency estiver ausente, ou escrito como R$ ou reais, não haverá agregação. Precisa ser o código ISO 4217 de três letras (BRL, USD, etc.).
• Tratamento inconsistente de impostos/frete: se value inclui ou não impostos e frete precisa ser igual entre o seu carrinho e o GA4, ou isso aparece como uma discrepância de valor. Qualquer escolha serve — ser consistente é o que importa.

Armadilha comum: se "as contagens de compras batem, mas só a receita está errada", suspeite primeiro do que você está incluindo em value (com ou sem impostos, com ou sem frete). A maioria das discrepâncias está aqui.

A armadilha do transaction_id (contagem duplicada)

transaction_id é o parâmetro que identifica um pedido de forma única. Se estiver ausente, ou mudar a cada vez, o GA4 trata a mesma compra como compras separadas e conta mais de uma vez.

• Toda vez que a página de agradecimento é recarregada, o purchase dispara de novo — e sem um transaction_id, cada recarregamento é contado como receita nova
• Por outro lado, com um transaction_id correto, o GA4 elimina duplicidades de compras repetidas que compartilham o mesmo ID

Para um detalhamento mais completo sobre a contagem duplicada em si, veja Por que as conversões são contadas duas vezes e como corrigir. A regra básica: coloque em transaction_id um valor que seja único por pedido e nunca mude — como o número do pedido.

Armadilhas do dataLayer (implementações via GTM)

Se você usa o Google Tag Manager para enviar o evento purchase, os dados passam pelo dataLayer. Três problemas aqui respondem por boa parte dos chamados de "purchase dispara, mas os dados estão errados".

1. Não limpar o objeto ecommerce antes de cada push. O GTM mescla os pushes do dataLayer de forma recursiva. Se um evento de ecommerce anterior (como add_to_cart) deixou dados de produto no objeto ecommerce, esses dados residuais vazam para o seu push de purchase. A solução: sempre enviar { ecommerce: null } imediatamente antes do push de compra.
2. Timing do gatilho vs. disponibilidade do dataLayer. Se a sua tag de evento GA4 dispara no DOM Ready, mas a plataforma de carrinho envia os dados da transação ao dataLayer um pouco depois, a tag dispara com um objeto ecommerce vazio. Verifique a ordem no modo Preview do GTM: o push de purchase no dataLayer precisa aparecer antes de a tag disparar.
3. Usar o tipo errado de variável. O GTM tem uma "Variável de Camada de Dados" nativa para campos de ecommerce (por exemplo, ecommerce.transaction_id). Se você acidentalmente criar uma variável de JavaScript personalizada ou fixar o valor manualmente, o mapeamento pode quebrar silenciosamente quando o formato do carrinho mudar.

Teste rápido: abra o modo Preview do GTM, conclua uma compra de teste e olhe a aba Variables do evento purchase. Todo campo de ecommerce (transaction_id, value, currency, items) deve estar preenchido. Se algum estiver undefined, o push do dataLayer está faltando esse dado ou disparando depois da tag. Para uma solução de problemas mais ampla no GTM, veja Por que sua tag do GTM não está rastreando.

Redirecionamentos de gateway de pagamento e perda do evento de compra

Quando o checkout redireciona o comprador para um gateway de pagamento externo (PayPal, Stripe Checkout, Klarna, etc.) e depois de volta para a sua página de agradecimento, o evento purchase corre alto risco de nunca disparar ou de perder seus dados.

• Quebra de sessão no retorno. O redirecionamento cria uma nova navegação. Se o navegador tratar o retorno como uma nova sessão (comum com o ITP do Safari e heurísticas de bloqueadores de anúncios), a página de agradecimento pode carregar sem o contexto do carrinho necessário para preencher items ou value. Para mais sobre a perda de dados específica do Safari, veja ITP do Safari e perda de conversões.
• Sobrescrita de atribuição. Mesmo quando o purchase dispara, o GA4 pode atribuir a conversão ao domínio de pagamento como origem "referral", em vez da origem de tráfego original. Adicione o domínio do gateway de pagamento à sua lista de vinculação entre domínios nas configurações do fluxo de dados do GA4 para preservar a sessão. Veja Por que o rastreamento entre domínios quebra para a configuração completa.
• Fallback no lado do servidor. Para gateways que enviam de forma confiável um webhook no lado do servidor (como o checkout.session.completed do Stripe), considere disparar o evento purchase via GA4 Measurement Protocol no seu servidor, em vez de depender do script do lado do cliente. Isso evita o problema do redirecionamento por completo. Para a abordagem server-side, veja Verificação de GTM server-side.

A sequência de eventos de ecommerce importa

Os eventos de ecommerce do GA4 seguem um funil: view_item → add_to_cart → begin_checkout → purchase. Embora o purchase possa disparar de forma independente, uma quebra em um evento anterior pode mascarar problemas que acabam surgindo nos dados de purchase.

• Se o add_to_cart nunca preenche corretamente o ecommerce.items do dataLayer, é provável que o mesmo array de itens malformado seja carregado até o purchase.
• Algumas plataformas de carrinho constroem o array items progressivamente ao longo das etapas do funil. Se o begin_checkout for pulado ou disparar com erro, o array entregue ao purchase pode ficar incompleto.
• Verificar o funil completo — não só o purchase final — pega erros de esquema mais cedo e torna a depuração mais rápida.

Quatro formas de confirmar que está sendo enviado

Você pode confirmar que o evento purchase e seu conteúdo estão sendo enviados corretamente, nesta ordem:

1. DebugView do GA4: ative o modo de depuração, faça uma compra real (ou de teste) e, em "Admin → DebugView", observe o evento purchase e se value, currency e items estão presentes. O ponto-chave é expandir os items e checar o conteúdo.
2. Network do DevTools: no DevTools do seu navegador, filtre por collect e confirme que uma requisição para …/g/collect dispara quando a página de agradecimento carrega. No corpo, inspecione en=purchase, transaction_id, value, currency e items.
3. Relatório de Monetização do GA4: em "Relatórios → Monetização → Compras de ecommerce", confirme se a quantidade e a receita por produto estão se acumulando (relatórios padrão têm um atraso de processamento).
4. Verifique duplicidades por transaction_id: em um relatório de exploração, verifique se o mesmo pedido não está sendo contado duas vezes procurando duplicidades no nível de transaction_id.

Para confirmar se a própria tag do GA4 está disparando, leia primeiro Como verificar se sua tag do GA4 está funcionando — isso agiliza o isolamento do problema.

O que checar na sua própria máquina não consegue te dizer

O DebugView e o DevTools são muito úteis, mas rodar uma compra de teste na sua própria máquina tem dois limites estruturais.

1. Seu ambiente não é o ambiente dos seus visitantes. Estado de login, extensões, exclusão de IP do escritório e bloqueadores de anúncios fazem com que o purchase possa disparar corretamente na sua máquina, mas ficar ausente nas condições reais do comprador. Especialmente em fluxos que passam por um gateway de pagamento ou redirecionamentos, a sessão pode cair antes de voltar à página de agradecimento, deixando items vazio.
2. Receita envolvendo um clique em anúncio é difícil de verificar. Para ver de fato "se uma compra vinda de anúncio realmente é registrada como receita", seria necessário clicar em um anúncio ao vivo para recriar o caminho — o que carrega o risco de uma violação de política de anúncios por autoclique.

Julgar que "apareceu no DebugView, então está tudo bem" tende a deixar passar o problema de value ou items sumirem no fluxo real de checkout que seus compradores percorrem. Para a mentalidade de ir além do disparo e verificar se de fato é registrado, veja Por que dispara mas não é registrado.

Checklist de verificação

• O evento purchase dispara na página de agradecimento (compra concluída)?
• value é um número (não uma string)?
• currency é um código ISO 4217 (BRL / USD, etc.)?
• O array items não está vazio, com item_id / item_name em cada produto?
• transaction_id está presente e é único por pedido (para evitar contagem duplicada)?
• A inclusão ou não de impostos/frete em value está alinhada com o lado do carrinho?
• O mesmo pedido não está sendo contado duas vezes (verifique no nível de transaction_id)?
• Também não está faltando em condições reais de usuário em produção (não julgue por uma única execução na sua máquina)?

Perguntas frequentes

P. As compras aparecem, mas a receita (value) fica zerada. Por quê? R. Normalmente value não está definido ou é enviado como string, ou currency está ausente/fora do padrão ISO e por isso não consegue agregar. Verifique o conteúdo de value e currency na requisição …/g/collect no Network do DevTools.

P. Por que só os itens não são registrados? R. O mais provável é que o array items esteja vazio, ou que cada produto não tenha item_id / item_name. Verifique também se você não está enviando ainda as antigas chaves id / name do UA.

P. Por que a mesma compra é contada duas vezes? R. Normalmente transaction_id está ausente, ou muda a cada recarregamento. Coloque nele um valor único e imutável, como o número do pedido, e o GA4 fará a deduplicação. Veja o artigo sobre rastreamento duplicado para mais detalhes.

P. Impostos e frete devem ser incluídos em value? R. O GA4 não tem uma regra rígida, mas o mais importante é alinhar a definição de receita do carrinho com o value do GA4. Uma incompatibilidade sempre aparece como uma discrepância de valor.

P. Se eu consigo ver o purchase no DebugView, estou seguro? R. Isso confirma apenas que foi enviado. Você só está seguro depois de confirmar que ele se acumula corretamente no relatório padrão de Monetização — e que não está faltando no fluxo real de checkout dos seus compradores em produção.

Conclusão: não pare no disparo — verifique o conteúdo e o registro em produção

A medição de compras de ecommerce do GA4 só funciona corretamente quando o evento purchase tem transaction_id, value, currency e items todos em ordem. O DebugView e o DevTools confirmam que está "sendo enviado", mas o que importa é o que vem depois — se o valor e os produtos são registrados sem perdas, no fluxo real de checkout que seus compradores percorrem, em produção.

O ConversionOK executa sua página em produção em um navegador independente e isolado e intercepta o evento de compra realmente enviado (incluindo value, currency e items), verificando-o. Sem precisar clicar no seu próprio anúncio, e sem interferência do ambiente do seu escritório. Comece com uma checagem estática gratuita para confirmar o ponto de entrada da sua medição de ecommerce.