GA4 para e-commerce: setup, eventos e enhanced ecommerce

O critério que decide qual setup de GA4 o seu e-commerce precisa é um só: quanto da receita que entrou no gateway aparece dentro do GA4 com canal atribuído.

Não é quantidade de evento. Não é enhanced ecommerce ligado ou desligado. Nas auditorias de tracking que a Moyker fez em e-commerce ao longo de 2025, a conta que quase nunca fechava era essa. O GA4 mostrava de 5% a 25% menos receita do que o extrato do gateway no mesmo período. Ninguém sabia dizer se o buraco vinha de consentimento recusado, evento duplicado, frete fora do value ou reembolso que nunca voltou para o relatório.

A ressalva vem antes das opções. Se o seu e-commerce fatura abaixo de R$ 80 mil por mês, vende catálogo simples e roda em Shopify ou Nuvemshop, a integração nativa já entrega a maior parte do resultado. Trocar por arquitetura server-side nesse estágio é custo de infraestrutura e de manutenção sem ganho de decisão. O setup certo é o mais barato que fecha a conta com o financeiro, não o mais sofisticado.

Os eventos que sustentam a análise são view_item, add_to_cart, begin_checkout e purchase. O purchase precisa de transaction_id, value, currency e o array items, conforme a referência de eventos do GA4. Sem transaction_id, cada recarga da página de obrigado entra como venda nova. Sem o array items, você mede receita sem saber o que vendeu. Esse é o alicerce de mensuração que alimenta qualquer decisão de mídia depois.

Opção A: integração nativa da plataforma

A plataforma dispara os eventos de comércio eletrônico por conta própria, com o seu ID de mensuração colado em um campo de configuração. Shopify, Nuvemshop e WooCommerce com plugin oficial fazem isso.

Vence com catálogo de até algumas centenas de SKUs, checkout padrão e time sem desenvolvedor dedicado. Sobe em menos de uma hora, custa zero de licença e zero de infraestrutura, e cobre os quatro eventos no formato que a documentação de comércio eletrônico do GA4 especifica.

O que ela esconde é o conteúdo do value. Boa parte das integrações nativas envia value com frete e imposto embutidos, enquanto a receita de itens é calculada por price vezes quantity. As duas métricas convivem no relatório de Monetização e nunca batem. Quem não sabe disso passa meses tentando reconciliar dois números que foram desenhados para serem diferentes.

O segundo ponto cego é o reembolso. O evento refund existe na especificação de comércio eletrônico e quase nenhuma integração nativa envia. O GA4 reporta receita bruta, o financeiro reporta líquida, e o ROAS que sai daí é sempre mais bonito do que o real.

Opção B: GTM web com dataLayer próprio

O desenvolvedor escreve o dataLayer no template da loja, o Google Tag Manager lê e envia para o GA4. Você controla quando o evento dispara e o que vai dentro dele.

Vence em catálogo com variação de preço, cupom, assinatura ou marketplace interno, ou seja, tudo que a integração nativa não modela. Vence também quando você precisa de parâmetro customizado que não existe no schema padrão do Google: margem por item, tipo de cliente, origem do estoque.

O custo fica entre 15 e 40 horas de desenvolvimento para um catálogo médio, mais manutenção a cada troca de tema ou de checkout.

O que ela esconde é que continua sendo client-side. Bloqueador de anúncio, Safari com prevenção de rastreamento e recusa de cookie derrubam o evento antes de ele sair do navegador. O modo de consentimento do Google preenche parte do buraco com modelagem, e modelagem é estimativa, não é o pedido. Com taxa de aceite baixa no banner, o dataLayer perfeito ainda entrega receita incompleta.

Opção C: GTM server-side com Measurement Protocol

Um container do Tag Manager roda em servidor próprio, recebe o evento do navegador, enriquece e reenvia para o GA4. A compra confirmada no backend entra pelo Measurement Protocol, sem depender do navegador do comprador.

Vence quando a receita perdida no client-side custa mais caro que a infraestrutura. O purchase confirmado no seu banco de dados sempre chega, e essa é a diferença que aparece no relatório.

O custo é o container rodando em nuvem, cobrado por instância ativa, mais desenvolvimento inicial e um serviço a mais para manter no ar e monitorar.

O que ela esconde é a parte que quase ninguém conta. O Measurement Protocol do GA4 não fabrica sessão. Se o evento server-side não carrega o client_id que o gtag gerou no navegador, o GA4 aceita a compra e a joga em tráfego direto ou não atribuído. Você troca perda de receita por receita registrada sem canal, que para decidir mídia serve quase tanto quanto não ter o evento. O mesmo raciocínio de sinal server-side vale do lado da Meta, onde a CAPI só funciona com o identificador casado.

Matriz de decisão pelo critério único

Um critério, três contextos. Quem monta matriz com dez critérios não decide nada.

Como medir o seu gap em 30 minutos

Abra Relatórios, Monetização, Visão geral, período de 30 dias, e anote a receita total de compras. Compare com o bruto do gateway no mesmo intervalo. Gap acima de 10% significa setup quebrado, não margem de erro.

No mesmo relatório, coloque a receita de itens ao lado da receita total de compras. A diferença entre as duas é frete mais imposto. Se a receita de itens for maior, o seu value está errado e o número que você usa para calcular retorno também.

Vá em Explorar, exploração livre, dimensão ID da transação, métrica Compras. Qualquer transaction_id com mais de uma compra é duplicata de página de obrigado. Uma linha basta para desconfiar do relatório inteiro.

Ligue o DebugView com o Tag Assistant, dispare uma compra de teste e confirme que o purchase chega com transaction_id, value, currency e items preenchidos. Campo vazio aqui vira relatório vazio depois.

Se você emite reembolso e não envia o evento refund, corrija isso antes de qualquer outra coisa. É o item de maior impacto e menor esforço da lista.

O que fazer em e-commerce de R$ 50 mil a R$ 500 mil

A recomendação direta: dataLayer próprio no GTM web para todos os eventos, server-side só para o purchase, com client_id repassado, e refund implementado desde o primeiro dia. Essa combinação custa menos que server-side completo e resolve a maior parte do gap, porque a compra é o único evento em que perder 15% muda decisão de orçamento.

Deixe enhanced ecommerce completo para depois de o número bater. Ler funil de produto com receita errada só gera confiança em leitura falsa. O agrupamento de canais do GA4 segue mudando de comportamento, como no caso do novo canal de assistentes de IA. Cada mudança dessas reabre a conversa sobre o que o relatório está de fato contando.

Depois que o GA4 e o gateway param de divergir, sobra a pergunta que importa de verdade: o retorno que você mede sustenta a operação no caixa? Qual é o seu gap hoje?