GA4 para e-commerce: eventos recomendados e como validar

Um evento de e-commerce enviado fora da especificação não gera aviso. O GA4 aceita o dado e o relatório mostra um número, mas errado: receita inflada, compra em duplicidade, itens ausentes. O problema só aparece quando alguém compara o GA4 com a loja, e a essa altura já há meses de dado ruim.

Os eventos de e-commerce do GA4 não são automáticos. Segundo a documentação do Google, é preciso enviá-los a partir do site ou do app, com parâmetros específicos. Se um parâmetro obrigatório falta, o evento é tratado como personalizado e some dos relatórios de monetização.

Este guia reúne a ordem do funil, os parâmetros de cada evento, um exemplo de dataLayer com a conta do valor, o passo a passo de validação e as particularidades de Shopify, VTEX e Nuvemshop. Cada regra traz a fonte. O que é recomendação da Analytikos está identificado.

A ordem do funil de e-commerce no GA4

A página Measure ecommerce, do Google for Developers (atualizada em 14/10/2026), lista os eventos nesta ordem. Promoções são medidas à parte, com view_promotion e select_promotion.

Os eventos do funil, do catálogo ao reembolso

1. 1
   view_item_listO usuário vê uma lista de produtos (categoria, busca, vitrine).
2. 2
   select_itemO usuário clica em um produto da lista.
3. 3
   view_itemO usuário vê a página do produto.
4. 4
   add_to_cart (e add_to_wishlist)O usuário adiciona o produto ao carrinho ou à lista de desejos.
5. 5
   view_cartO usuário abre o carrinho.
6. 6
   begin_checkoutO usuário inicia o checkout.
7. 7
   add_shipping_infoO usuário escolhe o frete.
8. 8
   add_payment_infoO usuário informa o pagamento.
9. 9
   purchaseO pedido é concluído. Este é o evento que fecha a receita.
10. 10
    refundO reembolso é emitido.

Duas observações da mesma página: o evento purchase substitui o antigo ecommerce_purchase, e o refund substitui o ecommerce_refund. O in_app_purchase é automático e separado de purchase.

Parâmetros que cada evento exige

A regra mais importante é a do valor. O Google define value como a soma de preço × quantidade de todos os itens, sem frete e sem imposto. Sempre que value for enviado, currency é obrigatório. A referência de eventos detalha cada evento; a tabela resume o que li nas tabelas de add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase e refund, e nos exemplos da página para os demais.

Evento	Obrigatório ou recomendado	Opcionais relevantes
view_item_list, select_item	items; os exemplos trazem item_list_id e item_list_name	index em cada item
view_item, view_cart	items, currency e value (exemplos da página)	Não há tabela formal consultada para estes eventos
add_to_cart	items, currency e value	Nenhum relevante
begin_checkout	items, currency e value	coupon
add_shipping_info	items, currency e value	shipping_tier, coupon
add_payment_info	items, currency e value	payment_type, coupon
purchase	transaction_id e items obrigatórios; currency e value condicionais	tax, shipping, coupon, customer_type (new ou returning)
refund	transaction_id obrigatório; currency e value condicionais; items recomendado	Sem items, não há métrica de reembolso por item

O array items

Cada item precisa de item_id ou item_name, e o Google recomenda enviar os dois. Entre os opcionais estão price, quantity (padrão 1), discount, index, coupon, affiliation, item_brand, item_category até item_category5, item_list_id, item_list_name e item_variant. A documentação permite até 27 parâmetros personalizados por item e até 200 elementos no array. No Measurement Protocol, a documentação cita um número menor de parâmetros personalizados por item, então confirme o limite do contexto em que você está enviando.

Exemplo de dataLayer com a conta do valor

Antes de cada envio, o Google manda limpar o objeto anterior com dataLayer.push({ ecommerce: null }). Em seguida, envie o evento com o objeto ecommerce. Exemplo ilustrativo de compra com duas camisetas e uma meia:

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "PED-100245",
    currency: "BRL",
    value: 199.70,
    shipping: 15.00,
    items: [
      { item_id: "CAM-001", item_name: "Camiseta básica", price: 89.90, quantity: 2 },
      { item_id: "MEI-007", item_name: "Meia esportiva", price: 19.90, quantity: 1 }
    ]
  }
});

A conta de value: (2 × 89,90) + (1 × 19,90) = 179,80 + 19,90 = 199,70. O frete de 15,00 vai em shipping, não em value. O preço é enviado como número com ponto, e não como texto com vírgula. Essa regra vem dos exemplos da documentação, que usam número com ponto; não encontrei uma regra textual sobre isso, por isso a tratamos como boa prática da Analytikos.

No Google Tag Manager, a documentação indica criar uma tag de evento do GA4 com o nome {{Event}}, ativar a opção de enviar dados de e-commerce a partir da camada de dados (Data Layer) e criar um gatilho de evento personalizado para cada evento. Para a base do GTM e da camada de dados, veja o contexto em GTM ganha Guided Setup para conversões do Google Ads.

Limites que quebram o evento sem avisar

A página Property limits, da Ajuda do Google Analytics, define limites que valem para eventos de e-commerce. Passar deles faz o parâmetro ou o evento ser descartado.

Limite	Valor
Parâmetros por evento	25
Nome de evento	40 caracteres
Nome de parâmetro	40 caracteres
Valor de parâmetro	100 caracteres (exceções: page_title 300, page_referrer 420, page_location 1.000)
Parâmetros personalizados por item	27
Eventos por usuário por dia (coleta por tag ou SDK)	100.000

Como os relatórios dependem dos eventos

O relatório de compras de e-commerce usa view_item para itens visualizados, add_to_cart para itens adicionados ao carrinho e purchase para itens comprados. As dimensões vêm de item_brand, item_category até item_category5, item_id e item_name. A receita do item é price × quantity, sem imposto nem frete. Parâmetros personalizados só aparecem se você registrar dimensões ou métricas personalizadas.

A jornada de compra usa as etapas session_start, view_item, add_to_cart, begin_checkout e purchase (ou in_app_purchase). Para alterar as etapas, é preciso abrir o relatório como exploração. Para marcar a compra como evento-chave, siga a documentação de eventos-chave; a Ajuda recomenda enviar value quando o evento for marcado assim.

Como validar em quatro camadas

Validar é conferir, em sequência, que o evento dispara, que chega ao GA4, que aparece no relatório e que bate com a loja. Cada camada usa uma ferramenta diferente.

1. Disparo: Tag Assistant e preview do GTM

O modo de visualização do GTM mostra se o evento disparou e qual objeto ecommerce foi enviado. Confira o nome do evento, o currency, o value e o array items completo.

2. Chegada: DebugView e Realtime

O DebugView mostra eventos e parâmetros em tempo real: o fluxo de segundos cobre 60 segundos e o de minutos cobre 30 minutos. O modo de depuração é ativado pelo Tag Assistant ou pelo preview do GTM, e também com debug_mode: true no config do gtag ou na tag do Google. Para desligar, remova o parâmetro; colocar false não desliga. Os eventos não aparecem no DebugView se o consentimento de analytics estiver negado ou se houver controles de privacidade no cliente. O Realtime cobre os últimos 30 minutos.

3. Relatório: espere o processamento

Segundo a página sobre atualização de dados, relatórios e explorações podem levar de 24 a 48 horas. Não conclua que um evento falhou antes disso. Depois do prazo, abra o relatório de compras de e-commerce e confira se os itens, as marcas e as categorias aparecem.

4. Conciliação: compare com a loja

Compare, no mesmo período, número de pedidos e receita do GA4 com a plataforma. A documentação do Google não traz uma tolerância aceitável. Na prática, a Analytikos investiga diferenças acima de 5% a 10% (heurística própria, ajustável conforme o uso de consentimento e os meios de pagamento). Exemplo: a loja registrou 1.000 pedidos e o GA4, 930. A diferença é (1.000 − 930) ÷ 1.000 = 7%. Verifique consentimento, bloqueadores, pedidos sem passar pela página de confirmação e compras por Pix ou boleto. Para entender por que as plataformas divergem, leia por que suas conversões não batem entre as plataformas.

Pix, boleto e o evento purchase

O Pix e o boleto criam uma situação típica no Brasil: o pedido é criado, mas o pagamento é confirmado depois. A documentação do Google que consultei não trata desse cenário. A recomendação da Analytikos é enviar purchase apenas quando o pagamento for confirmado, ou, se o negócio precisa contar o pedido criado, usar um evento personalizado para o pedido em aberto.

Para enviar o purchase a partir do servidor, usa-se o Measurement Protocol. Segundo a documentação de envio de eventos, o envio é por POST em /mp/collect, com api_secret e measurement_id na URL e client_id no corpo, que no web deve ser o mesmo gerado pela tag do site. Há limite de 25 eventos por requisição, 25 parâmetros por evento e corpo de menos de 130 kB. O backdating aceita até 72 horas pelo timestamp_micros, e eventos que precisam se juntar aos do navegador devem chegar em até 48 horas. Guarde o client_id no pedido, e use um transaction_id único: a Ajuda diz que ele ajuda a evitar duplicidade, mas não detalha janela nem escopo. Um boleto que compensa depois desses prazos pode não ser conciliado.

Para validar o envio, use o endpoint /debug/mp/collect. Ele devolve validationMessages com códigos como VALUE_INVALID e VALUE_REQUIRED, e não devolve erro HTTP para evento malformado, então leia o corpo da resposta (validação de eventos do Measurement Protocol, atualizada em 20/10/2026).

Plataformas: o que cada uma já envia

Plataforma	O que a documentação diz	Atenção
Shopify	Configuração pelo canal de vendas Google & YouTube. Alguns eventos de e-commerce são coletados automaticamente.	Eventos além dos automáticos exigem implementação manual. O GA4 não rastreia com a loja em modo privado.
VTEX IO	O app de GTM converte eventos dos Pixel Apps em eventos GA4: vtex:orderPlaced vira purchase, vtex:productView vira view_item, vtex:productImpression vira view_item_list e vtex:productClick vira select_item.	Importe o container e valide com o preview do GTM e o DebugView.
Nuvemshop	Envia nativamente os 11 eventos do funil, de view_item_list a refund. A chave secreta de API permite enviar conversões pelo back-end.	view_promotion, select_promotion e add_to_wishlist exigem configuração manual. A própria página relata purchase como (not set) em alguns casos.

Consulte as páginas oficiais: Shopify, VTEX e Nuvemshop (atualizada em 08/05/2026).

Consentimento e dados que faltam

Com o Consent Mode, a coleta depende do consentimento. No modo básico, as tags só carregam depois da resposta do visitante e, se ele recusa, nada é enviado. No modo avançado, as tags carregam e enviam pings sem cookies, que o GA4 usa para modelar (documentação do Google, atualizada em 30/07/2026). A modelagem exige um volume mínimo de dados. Se a loja usa banner de consentimento, parte da diferença de pedidos entre o GA4 e a plataforma é esperada. Leia também ChatGPT sem UTM: por que o tráfego de IA caiu no GA4 para outro caso em que a origem se perde.

Erros comuns e como corrigi-los

Erro de evento de e-commerce quase nunca gera aviso. O GA4 aceita o dado e o relatório mostra um número, mas um número errado. A tabela de cada bloco traz o sintoma, como diagnosticar (com a ferramenta indicada) e a correção. As regras vêm da documentação do Google; a coluna de correção e os exemplos numéricos são da Analytikos.

Erros de valor e de moeda

Erro	Sintoma no GA4	Como diagnosticar	Como corrigir
value sem currency	O evento perde a receita nos relatórios de monetização.	No preview do GTM ou no DebugView, confira se currency acompanha todo evento com value.	Envie currency (por exemplo, BRL) em todo evento que tenha value.
Frete ou imposto dentro de value	Receita acima da real. Exemplo: value 214,70 em vez de 199,70, uma diferença de 15,00 ÷ 199,70 = 7,5%.	Compare value com a soma de price × quantity dos itens.	Mantenha value como soma de preço × quantidade; envie frete em shipping e imposto em tax.
value diferente da soma dos itens	Receita do evento e receita por item divergem.	Recalcule a soma no payload do DebugView.	Calcule value no código a partir do array de itens, não de outro campo.
Preço como texto com vírgula	Receita zerada ou lida de forma errada.	Veja o tipo do campo price no preview do GTM.	Envie número com ponto, como 89.90. É boa prática da Analytikos, a partir dos exemplos da documentação.
Moeda inconsistente entre eventos	Receita misturada na mesma propriedade.	Filtre os eventos por currency em uma exploração.	Padronize a moeda no dataLayer e confira a loja multimoeda.

Erros de identificação e de duplicidade

Erro	Sintoma no GA4	Como diagnosticar	Como corrigir
purchase sem transaction_id	A compra não é identificada e pode ser contada duas vezes.	Confirme o campo no payload do DebugView.	Envie um transaction_id único por pedido, igual ao número do pedido na loja.
purchase disparado de novo ao recarregar a página de confirmação	Pedidos do GA4 acima dos da loja. Exemplo: 1.000 pedidos viram 1.080, ou 8% a mais.	Recarregue a página de agradecimento com o DebugView aberto.	Dispare o evento uma vez por pedido (por exemplo, controlando por transaction_id na camada de dados). O Google diz que o transaction_id ajuda a evitar duplicidade, mas não detalha janela nem escopo.
purchase na criação de pedido Pix ou boleto	Receita de pedidos que nunca foram pagos.	Cruze os pedidos do GA4 com os pagos na plataforma.	Dispare purchase na confirmação do pagamento. Recomendação da Analytikos.
refund sem transaction_id ou sem items	O reembolso não se liga à compra, e não há métrica por item.	Confira o payload do refund.	Envie transaction_id e, para reembolso parcial, os itens e quantidades reembolsados.

Erros no array de itens

Erro	Sintoma no GA4	Como diagnosticar	Como corrigir
items vazio	O evento não alimenta o relatório de compras de e-commerce.	Veja se o array chega com elementos no preview do GTM.	Preencha o array com os itens do carrinho no momento do evento.
Item sem item_id nem item_name	O item não aparece nos relatórios por produto.	Procure itens sem identificação no payload.	Envie item_id e item_name, como recomenda o Google.
Mais de 27 parâmetros personalizados por item, ou de 200 itens	Parâmetros ou itens descartados.	Conte os campos do item e o tamanho do array.	Mantenha-se nos limites e registre só o que for usar em relatório.
Mais de 25 parâmetros por evento, nome acima de 40 caracteres ou valor acima de 100	Parâmetros descartados sem aviso.	Compare com a tabela de limites deste guia.	Encurte nomes e valores, e remova parâmetros que ninguém usa.
Parâmetro personalizado sem dimensão registrada	O parâmetro existe no evento, mas não aparece nos relatórios.	Procure o parâmetro na lista de dimensões personalizadas.	Registre a dimensão ou a métrica personalizada em Administração.

Erros de disparo e de sequência do funil

Erro	Sintoma no GA4	Como diagnosticar	Como corrigir
Não limpar o objeto ecommerce antes do envio	Itens do evento anterior contaminam o seguinte.	Veja se o evento novo traz itens que não são dele.	Faça dataLayer.push({ ecommerce: null }) antes de cada push de e-commerce.
Etapa do funil que nunca dispara	A jornada de compra tem um buraco. Exemplo: há add_to_cart, mas não view_item.	Abra a jornada de compra e compare as etapas: session_start, view_item, add_to_cart, begin_checkout e purchase.	Mapeie todos os caminhos da loja, inclusive compra rápida e botão de compra na vitrine, e dispare cada evento.
Gatilho do GTM com nome diferente do evento do dataLayer	A tag não dispara e o evento não chega ao GA4.	No preview do GTM, confira o nome do evento recebido e o gatilho.	Use o mesmo nome em ambos. Prefira o formato exato da documentação (purchase, begin_checkout).
Opção de enviar dados de e-commerce desligada na tag	O evento chega sem itens e sem valor.	Abra a tag do evento no GTM e verifique a opção.	Ative o envio de dados de e-commerce a partir da camada de dados.
Evento disparado antes de o dataLayer estar pronto	Parâmetros vazios ou dados do pedido anterior.	Veja a ordem dos eventos na linha do tempo do preview do GTM.	Faça o push do ecommerce antes do evento que dispara a tag.

Erros de teste e de leitura dos dados

Erro	Sintoma	Como diagnosticar	Como corrigir
Esperar o relatório logo depois do teste	Parece que o evento falhou.	Confira o DebugView e o Realtime primeiro.	Aguarde 24 a 48 horas antes de olhar o relatório, segundo a Ajuda do Google.
Testar com consentimento negado	O DebugView não mostra o evento.	Verifique o estado do banner e do Consent Mode.	Teste com o consentimento concedido e, depois, com ele negado, para entender as diferenças.
Desligar o debug_mode com false	A depuração continua ligada.	Procure o parâmetro no config do gtag e na tag do Google.	Remova o parâmetro. Colocar false não desliga.
Misturar tráfego de teste e de desenvolvedor com o real	Pedidos de teste entram na receita.	Filtre por hostname e por tráfego interno na exploração.	Filtre o tráfego de desenvolvedor, como recomenda a Ajuda do DebugView.
Medir pelo Measurement Protocol sem ler a resposta de validação	O evento parece enviado, mas é inválido.	O endpoint /debug/mp/collect não devolve erro HTTP para evento malformado.	Leia validationMessages no corpo da resposta, com códigos como VALUE_INVALID e VALUE_REQUIRED.
Enviar compra de servidor fora do prazo	A compra não se junta à sessão do navegador.	Compare o horário do pedido com o envio.	Respeite 72 horas de backdating e 48 horas para unir com eventos do navegador.

Por que o GA4 e a loja nunca batem em 100%

Mesmo sem erro de implementação, parte da diferença é esperada. O exemplo abaixo é hipotético e mostra como a conta se decompõe: a loja registrou 1.000 pedidos e o GA4, 930.

Exemplo: 1.000 pedidos na loja e 930 no GA4, onde estão os 70 que faltam

Consentimento negado

40

Pix e boleto sem confirmação enviada

20

Bloqueadores e falhas de carregamento

10

A diferença total é (1.000 − 930) ÷ 1.000 = 7%. Desses 70 pedidos, 40 (57%) vêm do consentimento, o primeiro ponto a investigar. A conta mostra por que a conciliação deve separar as causas antes de culpar a tag. Reduzir a diferença aos itens que você controla, como o Pix e o boleto, é o ganho mais rápido.

Checklist de implementação

• Os dez eventos do funil mapeados para os momentos reais da loja.
• Objeto ecommerce limpo antes de cada envio.
• currency em todo evento com value.
• value igual à soma de preço × quantidade, sem frete e sem imposto.
• transaction_id único em purchase e refund.
• item_id e item_name em todos os itens.
• Dimensões personalizadas registradas para os parâmetros que você quer ver nos relatórios.
• Testes no preview do GTM e no DebugView, com o consentimento concedido.
• Conferência de 24 a 48 horas depois, nos relatórios de compras e de jornada.
• Conciliação com a plataforma e regra para Pix e boleto definida.
• Eventos de compra marcados como evento-chave.
• Revisão periódica, com pedidos de teste a cada mudança no checkout ou na plataforma.

Perguntas frequentes

Quais eventos de e-commerce o GA4 recomenda?

A documentação lista view_item_list, select_item, view_item, add_to_cart, add_to_wishlist, view_cart, remove_from_cart, begin_checkout, add_shipping_info, add_payment_info, purchase e refund. Promoções usam view_promotion e select_promotion.

O value inclui o frete?

Não. Segundo o Google, value é a soma de preço × quantidade dos itens, sem frete e sem imposto. O frete vai no parâmetro shipping e o imposto em tax.

Por que meu evento aparece no DebugView, mas não no relatório?

O relatório pode levar de 24 a 48 horas para processar. Se persistir, verifique se faltam parâmetros obrigatórios, porque o evento passa a ser tratado como personalizado e não aparece no relatório de compras.

O que acontece se eu enviar o mesmo purchase duas vezes?

O transaction_id ajuda a evitar duplicidade, segundo a Ajuda do Google, mas a janela e o escopo dessa deduplicação não estão detalhados. O caminho seguro é impedir o disparo duplicado na origem.

Como contar vendas por Pix e boleto?

A documentação não trata o tema. A recomendação da Analytikos é enviar purchase apenas na confirmação do pagamento, pelo servidor com o Measurement Protocol, guardando o client_id do pedido e respeitando os prazos de 72 e 48 horas.

O GA4 precisa bater 100% com a loja?

Não. Consentimento, bloqueadores e meios de pagamento criam diferenças. O Google não define tolerância; a Analytikos investiga diferenças acima de 5% a 10%.

Preciso de dataLayer em Shopify, VTEX e Nuvemshop?

Cada plataforma envia parte dos eventos. Shopify coleta alguns automaticamente, a VTEX converte eventos do Pixel para GA4 no app de GTM e a Nuvemshop envia os 11 eventos do funil. Valide sempre no DebugView.

Conteúdos Relacionados

• Por que suas conversões não batem entre as plataformas
• GTM ganha Guided Setup para conversões do Google Ads
• Dashboards chegam ao Google Analytics