Compras do GA4 não batem com a Shopify? Por quê, e a solução

Por que o GA4 não bate com os pedidos da Shopify?

O GA4 e a Shopify contam coisas diferentes: a Shopify registra todo pedido, enquanto o GA4 registra só os eventos de compra que um navegador ou servidor lhe envia. O GA4 fica para trás quando compradores recusam cookies de analytics, bloqueiam a tag do Google ou uma tag de compra falha, e conta a mais quando duas tags relatam um pedido com IDs diferentes. Compare pedidos, não sessões, e confira os IDs de transação.

Uma diferença de algum tamanho é normal. A própria página de discrepâncias da Shopify lista as causas comuns: o Google só consegue contar visitantes cujos navegadores rodam JavaScript e aceitam cookies, extensões de navegador podem impedir o Google Analytics de rastrear sessões e compras, e as duas ferramentas podem relatar em fusos horários diferentes.

Fontes: os relatórios de vendas da Shopify e a referência do evento de compra do Google, verificado em 24 de setembro de 2026.

Como a Shopify envia compras ao GA4?

Pelo app Google & YouTube, se você usa o caminho nativo da Shopify. Você conecta uma propriedade do GA4 no app (Shopify), e a tag do Google que ele instala envia ao GA4 os eventos de loja, carrinho, checkout e compra do navegador do comprador (Google).

A lista de eventos que o app envia do Google (atualizada pela última vez em 28 de julho de 2026) vai de page_view e view_item até begin_checkout e add_payment_info, passando por purchase. Não tem nenhum evento de reembolso. O pixel do app aparece em Settings → Customer events, e a Shopify carrega pixels na loja, no checkout, na página de agradecimento e na página de status do pedido (resumo de pixels).

A própria compra depende do evento checkout_completed da Shopify. Ele dispara uma vez por checkout, geralmente na página de agradecimento, ou na primeira página de oferta adicional se você mostrar uma. Se essa página não carregar, o evento simplesmente não dispara.

Uma tag do GA4 colada em Additional scripts não alcança mais a compra. Isso parou quando a Shopify substituiu a antiga página de agradecimento, e o prazo para lojas fora do Plus foi 26 de agosto de 2026 (veja Additional scripts parou de funcionar). Uma tag no seu tema também não consegue alcançá-la, porque o layout de um tema só se aplica a páginas fora do checkout. O rastreamento no checkout de hoje passa por pixels de app e pixels personalizados, comparados em pixels de app e pixels personalizados.

O que faz o GA4 perder compras?

Qualquer coisa que impeça o evento de compra de sair do navegador do comprador: consentimento recusado, uma tag bloqueada, uma página de agradecimento que nunca carrega, ou uma tag que não roda mais.

• Consentimento recusado. Onde você exige consentimento, geralmente o EEE e o Reino Unido, a Shopify roda um pixel só quando o comprador deu as permissões que ele precisa, e pixels novos exigem permissão de analytics e marketing por padrão (Shopify). Um comprador que recusa é um pedido na Shopify e nada no GA4.
• Um banner que nunca avisa a Shopify. Seu banner de consentimento precisa passar a escolha do comprador para a Customer Privacy API da Shopify. Num tópico da comunidade de agosto de 2026, uma loja da UE tinha visualizações de página mas nenhuma compra no GA4 depois de reinstalar o app Google & YouTube. As respostas atribuíram isso a um banner que nunca passava o consentimento para a Shopify, então o pixel do app ficava bloqueado no checkout enquanto uma tag no tema continuava enviando visualizações de página.
• Tags bloqueadas. Extensões de navegador, bloqueadores de anúncio entre elas, podem impedir o Google Analytics de rastrear sessões e compras, como observa a página de discrepâncias da Shopify.
• A página nunca carrega. Um comprador que paga mas nunca chega à página de agradecimento, ou cuja página de oferta adicional falha, não dispara nenhum checkout_completed.
• Um ID de transação vazio. O GA4 trata toda compra enviada com um transaction_id vazio como uma cópia da primeira e descarta o resto (Google).
• Ainda não chegou. O GA4 pode levar de 24 a 48 horas para processar dados, e os relatórios podem mudar nesse meio-tempo (atualização dos dados).

O que faz o GA4 contar demais?

Duas tags enviando a mesma compra para uma propriedade do GA4 com IDs de transação diferentes. O Google documenta a deduplicação só para compras que compartilham um ID de transação, e só em streams da web.

O segundo remetente geralmente é um destes: o app Google & YouTube mais a tag do Google ou o Tag Manager que ficou no tema, um pixel personalizado, ou outro app enviando para o mesmo Measurement ID. O guia do Google sobre o app pede para você verificar tags duplicadas quando tiver conversões no app e na loja ou num pixel personalizado (Google), e o guia de migração da Shopify aponta rastrear o mesmo evento mais de uma vez como um problema comum. Num tópico da comunidade de 2023, comerciantes rodando o GA4 tanto pelo Tag Manager quanto pelo canal do Google da Shopify relataram compras e receita em dobro, e um deles resolveu pausando a cópia do Tag Manager.

Dois padrões denunciam isso:

• Um pedido, dois IDs de transação. Por exemplo, uma tag envia o ID do pedido e outra o número do pedido, então o GA4 vê duas vendas.
• Visualizações de página em dobro enquanto a receita parece certa. Dois remetentes que usam o mesmo ID de transação são deduplicados na compra, mas visualizações de página e adições ao carrinho não têm ID para comparar, então duplicam.

O mesmo problema no Meta e no TikTok está em por que o Meta conta compras duas vezes.

O Measurement Protocol pode preencher a lacuna?

Em parte. O Measurement Protocol do Google deixa um servidor enviar eventos do GA4, como a compra, então um pedido pode chegar ao GA4 quando a tag do navegador não conseguiu, mas o Google o projetou para complementar a tag do Google, não para substituí-la.

O que a documentação do Google diz (verificado em 24 de setembro de 2026):

• O Measurement Protocol foi pensado para complementar a coleta baseada em tags, e enviar eventos só com ele pode gerar relatórios parciais.
• Para um stream da web, o client_id deve coincidir com o ID que a tag do Google definiu no seu site (enviando eventos).
• Um evento de servidor só compartilha a origem, a mídia e a campanha da visita se trouxer o session_id dessa visita e chegar dentro de 24 horas do início da sessão (casos de uso).
• Os eventos podem ser retrodatados em até 72 horas.
• O endpoint não retorna nenhum erro HTTP, nem para eventos malformados, e o servidor de validação do Google não confere o segredo de API (validando eventos). Um segredo errado falha silenciosamente.

Então uma compra enviada pelo servidor ajuda com tags bloqueadas e páginas de agradecimento que nunca carregam, e pode enviar reembolsos, que não estão na lista do Google para o app Google & YouTube. Ela não ajuda com o consentimento: mover a compra de um comprador que recusou para um servidor não a torna consentida. Também precisa de um client ID e session ID do navegador do comprador para cair na visita certa, o que leva ao próximo problema. Para saber como os eventos de servidor funcionam em outras plataformas, veja rastreamento pelo servidor na Shopify.

Por que o GA4 mostra (not set) depois do rastreamento pelo servidor?

Porque o servidor enviou eventos que o GA4 não conseguiu ligar a uma visita. O GA4 pega a origem e a campanha de um evento do Measurement Protocol do que a tag do Google coletou na mesma sessão, e a localização dos eventos com tag anteriores do mesmo visitante, a menos que o servidor envie uma. Sem um client ID e session ID correspondentes, essas colunas aparecem como (not set).

A documentação do Google (verificado em 24 de setembro de 2026) dá as regras:

• Para eventos do Measurement Protocol relatados como (not set) / (not set), a correção do Google é enviar o session_id com um valor válido tirado do evento do lado do cliente (Google); o limite de 24 horas acima continua valendo.
• O GA4 junta a localização e as informações de dispositivo mais recentes das tags aos eventos do Measurement Protocol que compartilham o mesmo client_id (changelog). Um servidor pode enviar a localização por conta própria em user_location ou ip_override; sem nenhum dos dois, o GA4 a tira só das tags (referência).

Então a causa comum é um visitante cuja tag do Google nunca rodou, geralmente porque um bloqueador a parou: o GA4 não tem nada para juntar, e se o servidor enviar um client ID inventado, o GA4 registra um usuário novo sem origem nem localização. As correções seguem as regras do Google: envie o client ID e o session ID que a tag do Google definiu, envie rapidamente e, onde o consentimento permitir, envie a localização do comprador em user_location ou ip_override. Anote a data em que você mudou sua configuração, e deixe de fora das comparações de antes e depois os dias próximos a essa mudança.

Como eu confiro se o GA4 está recebendo compras?

Faça um pedido real e observe-o chegar no relatório Realtime do GA4, depois compare um dia inteiro de pedidos da Shopify com as compras do GA4, ID de transação por ID de transação.

1. Faça um pedido na sua loja com um método de pagamento real.
2. No GA4, abra o relatório Realtime. A compra costuma aparecer em poucos minutos.
3. Dois dias depois, com o processamento já estabilizado, abra Explore e crie uma tabela livre com a dimensão Transaction ID e a métrica Ecommerce purchases, que conta só eventos purchase (Google).
4. Fixe a mesma data na lista de pedidos da Shopify, restrinja-se aos pedidos da sua loja online, e confira se as duas ferramentas usam o mesmo fuso horário.
5. Compare as listas.

Onde o cPixel se encaixa?

Enviar a compra a partir do registro do pedido ajuda quando a compra do navegador nunca dispara. Comece pelo app Google & YouTube, que basta para muitas lojas, e lembre que nenhuma ferramenta deveria preencher uma lacuna que vem de um consentimento recusado.

O cPixel, que nós desenvolvemos, envia compras e reembolsos ao GA4 a partir dos seus servidores pelo Measurement Protocol. Ele os constrói a partir do pedido da Shopify, com o pedido como ID de transação, então a própria deduplicação do GA4 se aplica. Todos os outros eventos do GA4 saem do navegador do comprador pelo pixel do cPixel, e se algum nunca sair do dispositivo, o cPixel envia esse único evento a partir dos seus servidores e o marca na sua visão Ao vivo. O cPixel não envia ao GA4 o endereço IP nem a localização do comprador, então um evento recuperado ganha a localização só das visitas anteriores daquele visitante, e aparece como (not set) quando não houve nenhuma.

A compra pelo servidor leva o client ID e o session ID que o cPixel guarda do comprador desde a loja até o checkout, que é o que o Google precisa para atribuir a compra à visita que a gerou. O Google mantém essa atribuição só para eventos enviados dentro de 24 horas do início da sessão, então compras enviadas depois, por exemplo com Quando o pedido é enviado nas Configurações do cPixel, podem perder a campanha. Um checkout sem sessão de navegador não é enviado: Ao vivo mostra Dados insuficientes para montar o payload deste destino. Um comprador que recusa cookies de analytics também não é enviado ao GA4.

A configuração precisa do seu Measurement ID e de um segredo de API do Measurement Protocol. Sem o segredo, o GA4 não recebe nenhuma compra do cPixel, e como o GA4 nunca informa um segredo errado, confirme com um pedido real: conecte o GA4 ao cPixel. Envie cada propriedade do GA4 a partir de uma única ferramenta. Se o app Google & YouTube também enviar para ela, as visualizações de página e outros eventos de navegador são contados duas vezes. Mais sobre o cPixel, que envia compras da Shopify para sete plataformas de anúncios.

Perguntas frequentes

Por que a receita do GA4 é menor que a da Shopify?

Geralmente porque algumas compras nunca chegaram ao GA4, e porque os dois totais são construídos de forma diferente. O Google pede um valor de compra que cubra os produtos sem frete nem impostos, enquanto Total sales da Shopify soma impostos, taxas, frete e tarifas. Confira o que sua tag envia como valor, depois compare com a cifra da Shopify construída da mesma forma. Reembolsos puxam na direção oposta: a Shopify os subtrai, e o GA4 só quando um evento de reembolso é enviado.

A mudança de sessões da Shopify de setembro de 2026 afetou o GA4?

Não. Entre 21 e 23 de setembro de 2026, a Shopify mudou como seus próprios relatórios contam sessões: agora uma sessão termina após 30 minutos de inatividade em vez de à meia-noite UTC, e sessões de bots identificadas são filtradas por padrão (Shopify). A Shopify diz que pedidos, vendas e contagem de clientes não são afetados. O GA4 conta suas próprias sessões, que por padrão também terminam após 30 minutos de inatividade (Google). Se as sessões da Shopify caíram a partir de 21 de setembro enquanto as do GA4 não, essa mudança é a causa mais provável.

O GA4 exclui bots?

Os conhecidos, automaticamente. O GA4 exclui tráfego de bots e spiders conhecidos usando a pesquisa do Google e a International Spiders and Bots List do IAB, e você não pode desligar isso nem ver quanto foi excluído (Google). Uma lista não consegue pegar bots que se passam por navegadores comuns, mas eles raramente compram, então inflam sessões mais do que compras. Como eles aparecem numa loja Shopify: tráfego de bots na Shopify.