Todo lojista que abre o GA4 e o painel da loja no mesmo dia faz a mesma pergunta: por que a receita é diferente? A resposta curta é que as duas ferramentas contam coisas diferentes, em momentos diferentes, por métodos diferentes. A plataforma registra o pedido no servidor. O GA4 só registra a compra se o navegador do cliente disparar o evento, e se o dado sobreviver ao consentimento, aos bloqueadores e ao processamento.
Este guia lista as causas mais comuns de divergência entre o GA4 e Shopify, VTEX ou Nuvemshop, cada uma com a fonte oficial, e termina com uma fórmula de conciliação que você pode aplicar em uma planilha. Os exemplos numéricos são hipotéticos e estão identificados.
Um ponto de partida importante: nenhuma das fontes oficiais que analisamos (Google, Shopify, VTEX e Nuvemshop) informa uma faixa aceitável de divergência. Qualquer percentual que você ouça é experiência de quem o cita, inclusive o que usamos nos exemplos.
Por que as duas receitas nunca são idênticas
A VTEX descreve a diferença de forma direta em sua FAQ sobre Google Analytics: as transações são sempre registradas na VTEX, e o tipo de atribuição não afeta a venda, apenas a interpretação de cada plataforma. Em outras palavras, a plataforma é a referência do total de pedidos; o GA4 é a referência do comportamento e da origem.
Isso muda o uso de cada número. Para o resultado financeiro, use a plataforma. Para saber de onde vieram os pedidos e como o funil se comporta, use o GA4, sabendo que ele enxerga uma parte dos pedidos. A tarefa é entender o tamanho dessa parte e o que a faz variar.
Antes de comparar, alinhe as definições
Boa parte da diferença nasce de comparar métricas que não são equivalentes. No GA4, a receita de compra (purchase revenue) é a receita de compras de e-commerce e in-app, enquanto a receita total (total revenue) inclui também assinaturas e publicidade, menos reembolsos. A documentação de moeda lista receita de compra, imposto, frete e receita de itens como métricas separadas. Na Shopify, as vendas totais equivalem a vendas líquidas mais taxas adicionais, tarifas, frete e impostos, conforme a página de campos de análise.
O GA4 usa o valor enviado pela tag no evento. A documentação de e-commerce que consultamos não diz se esse valor inclui frete e imposto, então a conciliação depende de como a sua tag foi montada. Abra o payload real do evento purchase antes de comparar.
| Item | Plataforma (exemplo Shopify) | GA4 | O que fazer |
|---|---|---|---|
| Receita de produtos | Vendas líquidas | Receita de itens, se enviada | Comparar com a mesma base |
| Frete e impostos | Incluídos nas vendas totais | Dependem do value enviado | Verificar o payload e igualar a base |
| Cancelados e não pagos | Podem entrar na venda bruta | Não aparecem se a compra não foi concluída | Excluir da base da plataforma |
| Reembolsos | Relatório financeiro e devoluções | Receita total desconta; compra não | Usar a mesma definição nos dois lados |
| Moeda e fuso | Configuração da loja | Configuração da propriedade | Igualar antes de comparar |
As causas da divergência
Causas do lado do navegador
Bloqueadores, JavaScript e cookies. A Shopify informa em sua página de discrepâncias que clientes podem usar extensões para bloquear o Google Analytics em sessões e compras e que o Google só conta visitantes com JavaScript e cookies ativos. A VTEX cita configurações estritas de privacidade, bloqueio de JavaScript e ad blockers. Tags bloqueadas, segundo a ajuda do GA4, não conseguem enviar nenhuma informação.
Consentimento e LGPD. Com o analytics_storage negado, as tags não gravam cookies e enviam apenas pings sem identificação; os dados completos só são enviados quando o usuário concede consentimento, segundo a documentação do Consent Mode. A modelagem comportamental estima usuários, sessões e novos usuários de quem recusa cookies, mas a página de modelagem não informa se a receita é modelada, e a exportação para o BigQuery não suporta dados modelados. Por isso, não afirme que o Consent Mode recupera a receita: a fonte não diz isso.
Causas ligadas ao evento de compra
transaction_id ausente, vazio ou repetido. O GA4 deduplica compras com o mesmo transaction_id, mas só em fluxos web. Enviar o campo vazio faz o GA4 deduplicar todas as compras com ID vazio; o mesmo ID em transações diferentes gera subcontagem. O transaction_id também é necessário para processar reembolsos.
Evento amarrado à página de obrigado. A VTEX explica que, se a tag da transação depende da página de confirmação, carregamentos falhos ou duplicados distorcem a contagem, e que integrações de pagamento que não redirecionam para a confirmação fazem o GA4 não registrar a compra. Na Shopify, o evento checkout_completed dispara uma vez por checkout, em geral na página de agradecimento; em fluxos de upsell ou pós-compra dispara na primeira página de oferta, e se a página não carregar o evento não dispara.
Pix e boleto. Nenhuma das páginas oficiais que consultamos trata Pix ou boleto especificamente. O que a Nuvemshop e a VTEX dizem, em termos gerais, é que o GA4 só tem a compra se o evento disparar e que pagamento não aprovado não aparece. A consequência para pagamento assíncrono é inferência nossa: se o evento nasce na página de obrigado, antes da aprovação, ele pode registrar pedidos que nunca serão pagos; se o cliente paga depois e não volta ao site, o evento pode nunca nascer. A compensação do boleto, segundo a Febraban, depende do horário e pode levar de horas a dias úteis.
Pedidos multivendedor. Na VTEX, antes do orderPlaced v4 um pedido com produtos de dois ou mais sellers gerava um evento por seller; hoje o orderGroup dispara um evento só, com o transactionId do grupo e os totais somados, como descreve o comunicado da VTEX. Pedidos feitos dentro de marketplaces externos não passam pelo seu site; nenhuma fonte trata disso, então é inferência.
Causas de definição: o que entra na conta
Cancelados, não pagos, reembolsos e pedidos manuais. A Nuvemshop informa, na página sobre diferenças entre as estatísticas da loja e do Google Analytics, que o GA4 só reconhece o cancelamento de pedidos já pagos e que pagamentos não aprovados não aparecem; pedidos criados por aplicativos ou manualmente não são enviados ao GA4. Na Shopify, a página de discrepâncias de vendas explica que pedidos cancelados, pendentes e não pagos entram na venda bruta, que devoluções e reembolsos aparecem em relatórios diferentes e que um reembolso pendente pode aparecer como positivo até ser concluído.
Fuso horário e moeda. A Shopify lembra que fusos de relatório diferentes introduzem discrepâncias. Na moeda, a documentação do GA4 diz que o campo currency é obrigatório para as métricas de receita, que a moeda padrão da propriedade é USD, que alterá-la converte também o histórico e que, com moeda local por transação, o GA4 converte pela cotação do dia anterior. No BigQuery, os valores brutos ficam na moeda local. Em uma loja em reais, confira a moeda e o fuso da propriedade e da plataforma.
Causas do lado do GA4
Atraso de processamento. A documentação de tempos de processamento informa que o processamento pode levar de 24 a 48 horas, com dados diários prontos entre 12 e 24 horas ou mais e alguns dados chegando com até 7 dias de atraso. Não é um SLA. A Nuvemshop diz que o painel dela atualiza na hora e o GA4 pode levar até 24 horas; a VTEX cita até 48 horas. Compare apenas períodos já fechados.
Filtros, bots e relatórios. O GA4 exclui automaticamente bots e spiders conhecidos, sem que seja possível desativar ou ver o volume excluído. O filtro de tráfego interno, quando ativo, remove os dados de forma permanente: eles nunca serão processados nem estarão disponíveis no GA4 ou no BigQuery. Pedidos de teste da equipe podem existir na plataforma e não no GA4. Relatórios e Explorações também podem diferir, como explica a página de diferenças entre relatórios e explorações, inclusive por modelagem comportamental e processamento das últimas 48 horas. Os limites de dados (data thresholds) tratam de dados demográficos e consultas de busca, e a página não trata de receita.
Não incluímos enhanced measurement, amostragem ou cardinalidade como causas de divergência de receita porque não encontramos fonte oficial que as ligue a esse problema.
Checkout em outro domínio e gateways
Sem configuração entre domínios, cada domínio raiz gera cookies e IDs novos: o mesmo visitante vira dois usuários e duas sessões, e a atribuição pode ficar errada. A medição entre domínios carrega o ID no parâmetro _gl. Quando o gateway de pagamento devolve o cliente ao site, a lista de referências indesejadas evita que ele apareça como origem; adicionar o domínio depois não altera sessões já gravadas. Isso afeta a atribuição por canal, não o total de receita.
Fórmula de conciliação em seis passos
A fórmula abaixo é uma proposta da Analytikos, não uma fórmula oficial. O objetivo não é zerar a diferença, e sim explicá-la: separar o que é diferença de definição, o que é pedido sem evento e o que é evento a mais.
- 1Fechar o períodoMesmo intervalo, mesmo fuso, mesma moeda, apenas dias já fechados (aguarde 48 horas ou mais).
- 2Montar a base da plataformaPedidos pagos no período, sem cancelados nem não pagos, menos reembolsos.
- 3Igualar a definiçãoAjustar frete, imposto e desconto conforme o value que a tag envia.
- 4Ler o GA4Receita de compra (ou receita total, que desconta reembolsos) no mesmo período.
- 5Calcular o resíduoBase da plataforma menos receita do GA4, em reais e em percentual.
- 6Decompor por causaCruzar por ID do pedido para separar pedidos sem evento, eventos extras e definições.
Veja um exemplo hipotético. A plataforma mostra 1.200 pedidos e R$ 300.000 no mês. Desse total saem R$ 21.000 de pedidos cancelados ou não pagos, e R$ 6.000 de reembolsos no período, restando R$ 273.000. A tag do GA4 não inclui frete no value, e o frete foi de R$ 14.000, o que leva a base comparável a R$ 259.000. O GA4 mostra R$ 238.000 de receita de compra. O resíduo é R$ 259.000 menos R$ 238.000, ou R$ 21.000, que equivale a 8,1% da base (21.000 ÷ 259.000).
| Etapa | Valor (R$) | Conta |
|---|---|---|
| Receita na plataforma | 300.000 | Pedidos criados no mês |
| Menos cancelados e não pagos | -21.000 | Exclui o que não foi pago |
| Menos reembolsos do período | -6.000 | Mesma definição nos dois lados |
| Menos frete fora do value | -14.000 | Igualar com o payload da tag |
| Base comparável | 259.000 | 300.000 menos 21.000, menos 6.000, menos 14.000 |
| Receita de compra no GA4 | 238.000 | Leitura do GA4 no mesmo período |
| Resíduo | 21.000 | 8,1% da base |
Ao cruzar os pedidos da plataforma com os transaction_id do GA4, por exportação para o BigQuery, o resíduo se decompõe: R$ 12.000 de pedidos sem evento por bloqueio ou consentimento, R$ 6.000 de pedidos pagos por Pix aprovado fora do navegador e R$ 3.000 de pedidos manuais. A soma fecha em R$ 21.000. O cruzamento por ID do pedido é um método que recomendamos, e não vem de fonte oficial. Para configurar a exportação e os eventos corretamente, veja como configurar o GA4 do zero e GA4 para e-commerce: eventos recomendados e como validar.
Como conciliar os pedidos de forma automática
A fórmula em seis passos funciona, mas feita à mão em planilha ela consome horas, depende de exportações manuais e envelhece rápido: basta uma mudança no checkout para a conta deixar de fechar. Quando a loja tem volume, o caminho mais seguro é automatizar a conciliação, usando o pedido da loja como fonte da verdade e comparando o GA4 contra ele de forma contínua.
O que uma conciliação automática precisa fazer
- Sincronizar os pedidos direto da plataforma da loja, sem exportação manual.
- Aplicar sempre a mesma definição de receita, com a mesma regra para frete, juros, descontos e cancelamentos.
- Casar cada pedido com a jornada do cliente, para saber de onde veio a venda.
- Mostrar a parte da receita que não foi associada a nenhuma origem, em vez de escondê-la.
- Comparar o resultado com o GA4 lado a lado, para que a diferença apareça como número acompanhável.
Como a Athena entra nessa conciliação
A Athena, plataforma de BI para e-commerce da Analytikos, foi desenhada para esse fluxo. Ela mede na própria loja com um pixel próprio e usa o pedido sincronizado como fonte da verdade. Cada pedido é casado com a jornada real do cliente, e o painel executivo mostra a receita captada e a faturada, calculada de forma líquida de frete e juros com a mesma definição para Shopify, Tray, ShopPub e VTEX.
Como o pixel nunca alcança 100% das compras, a Athena exibe a chamada quebra de rastreio: a fatia da receita que não foi associada a uma origem, com nome e percentual. Isso transforma a divergência em um indicador que você acompanha, em vez de uma surpresa na reunião de resultados. Telas de validação comparam a atribuição da Athena com a do GA4 lado a lado, e os modelos de atribuição (primeiro clique, último clique, último clique pago e distribuído) permitem ver o mesmo pedido por ângulos diferentes.
Na prática, o time deixa de montar a conciliação toda semana e passa a revisar apenas as exceções: pedidos sem origem, quedas na taxa de rastreio e desvios que fogem do padrão. Quem quiser ver com os próprios números pode testar a Athena por 30 dias, conectando as contas da loja, do GA4 e da mídia.
Erros comuns ao conciliar o GA4 com a loja
Os erros abaixo fazem a equipe perseguir diferenças que não existem ou aceitar diferenças que são problemas reais. Cada um traz o motivo, o efeito e a correção.
Erros de cálculo e de comparação
| Erro | Por que acontece e qual o efeito | Como corrigir |
|---|---|---|
| Comparar períodos abertos | O gestor olha o dia de ontem nos dois painéis. O GA4 pode levar 24 a 48 horas para processar, então a diferença parece maior do que é. | Comparar só dias fechados, com pelo menos 48 horas de intervalo. |
| Comparar venda bruta com receita de compra | A plataforma mostra vendas totais com frete, imposto e cancelados. O GA4 usa o value da tag. A diferença de base vira falsa divergência. | Montar a base comparável antes de calcular o resíduo. |
| Ignorar fuso e moeda | A loja está em um fuso e a propriedade em outro. Pedidos perto da meia-noite caem em dias diferentes e a moeda da propriedade pode converter valores. | Igualar fuso e moeda e conferir o histórico. |
| Exigir que os números sejam idênticos | Nenhuma fonte oficial define uma faixa aceitável. A busca por igualdade absoluta consome tempo e esconde o objetivo: explicar o resíduo. | Definir uma meta interna de resíduo e acompanhar a tendência. |
Erros de implementação
| Erro | Por que acontece e qual o efeito | Como corrigir |
|---|---|---|
| transaction_id vazio ou repetido | A tag usa uma variável que falha em alguns fluxos. O GA4 deduplica todas as compras com ID vazio e subconta quem repete o ID. | Usar o número do pedido como valor dinâmico e testar todos os meios de pagamento. |
| Evento só na página de obrigado | Pix, boleto e integrações de pagamento nem sempre levam o cliente à confirmação. Compras somem do GA4 ou entram antes da aprovação. | Disparar a compra no momento da aprovação, quando a plataforma permitir, ou conciliar por ID. |
| Checkout em outro domínio sem configuração | O pagamento acontece em um domínio externo. O mesmo cliente vira dois usuários e a venda é atribuída ao gateway. | Configurar medição entre domínios e a lista de referências indesejadas. |
| Filtro de tráfego interno ativo sem aviso | A equipe cria pedidos de teste e esquece do filtro. Os pedidos existem na plataforma e nunca chegam ao GA4. | Documentar os filtros e separar pedidos de teste na plataforma. |
| Tag mudada sem teste de compra | Uma alteração no GTM ou no tema quebra o evento. A perda só aparece na reconciliação semanas depois. | Testar uma compra real após qualquer mudança e acompanhar uma checagem diária. |
Erros de interpretação
| Erro | Por que acontece e qual o efeito | Como corrigir |
|---|---|---|
| Tratar o GA4 como fonte da verdade financeira | O GA4 é o painel mais conveniente. Ele mede só o que o navegador envia; decisões de caixa baseadas nele subestimam a receita. | Usar a plataforma para o financeiro e o GA4 para comportamento e origem. |
| Culpar o consentimento sem checar | O Consent Mode é a explicação mais conhecida. Sem medir, a causa real (evento, domínio, definição) permanece. | Decompor o resíduo por causa antes de atribuí-lo ao consentimento. |
| Corrigir o GA4 com ajustes manuais | Alguém soma um percentual fixo ao relatório. O ajuste esconde mudanças reais na implementação. | Corrigir a origem do problema e documentar a margem de resíduo conhecida. |
Checklist de diagnóstico
- Período fechado, com ao menos 48 horas de atraso.
- Mesmo fuso horário e mesma moeda nos dois lados.
- Payload do evento purchase aberto, com value, tax, shipping e items conferidos.
- transaction_id presente, único e dinâmico em todos os meios de pagamento.
- Compra testada em cartão, Pix e boleto.
- Comportamento do evento em pedidos aprovados depois, fora do navegador, conhecido.
- Cross-domain e lista de referências indesejadas configurados, se o checkout é externo.
- Filtros de tráfego interno e pedidos de teste documentados.
- Consent Mode e banner de consentimento verificados.
- Base da plataforma montada sem cancelados e com reembolsos tratados.
- Resíduo decomposto por ID de pedido, via exportação para o BigQuery.
- Meta interna de resíduo definida e acompanhada ao longo do tempo.
Perguntas frequentes
Qual é a diferença aceitável entre a receita do GA4 e a da loja?
Nenhuma fonte oficial analisada, entre Google, Shopify, VTEX e Nuvemshop, informa uma faixa. O que existe é experiência de mercado. Defina uma meta interna e acompanhe a tendência: o importante é explicar o resíduo.
Qual número devo usar para decidir investimento em mídia?
Para o resultado financeiro, use a plataforma, que registra os pedidos no servidor. Use o GA4 para comparar canais e funil, sabendo que ele enxerga uma parte dos pedidos. Se a parte invisível variar por canal, a leitura de origem pode distorcer.
O Consent Mode recupera a receita perdida?
A documentação mostra que a modelagem comportamental estima usuários e sessões de quem recusa cookies, mas não informa se a receita é modelada, e a exportação para o BigQuery não suporta dados modelados. Não conte com recuperação de receita.
Por que meu GA4 mostra menos pedidos que a loja?
As causas mais comuns são bloqueadores, recusa de consentimento, eventos que não disparam em Pix e boleto, pedidos manuais e pedidos fora do site. Cruze os IDs de pedido para quantificar cada causa.
E se o GA4 mostrar mais receita do que a loja?
Pode haver evento duplicado, evento disparado em pedido não aprovado ou cancelamentos que o GA4 não reconhece. A Nuvemshop informa que o GA4 só reconhece o cancelamento de pedidos já pagos. Confira o transaction_id e a definição de receita.
Preciso exportar para o BigQuery para conciliar?
Não é obrigatório, mas facilita muito. A exportação permite cruzar o transaction_id do GA4 com os pedidos da plataforma e decompor o resíduo por causa. Lembre que os dados modelados não são exportados.
