Discrepância entre Adobe Commerce (Magento) e GA4: o diagnóstico enterprise
Em operações Adobe Commerce, a discrepância com o GA4 raramente é um problema de tag. É um problema de arquitetura.
Multi-store com domínios distintos, checkout de página única renderizado dinamicamente, dezenas de extensões de terceiros, frontend headless em PWA e um ciclo de pedido que vive no ERP tanto quanto na plataforma. Cada camada dessa sofisticação é um ponto onde a medição pode quebrar sem barulho.
O paradoxo: quanto maior e mais madura a operação, maior a chance de o GA4 estar errado e maior o custo de decidir com base nele. Esse artigo organiza o diagnóstico para o nível de complexidade que o Adobe Commerce exige.
O que é a discrepância entre Adobe Commerce e GA4
Discrepância entre Adobe Commerce (Magento) e GA4 é a diferença entre pedidos e receita registrados na plataforma (Sales, Order Management) e os números refletidos no Google Analytics 4.
Em operações enterprise auditadas pela Métricas Boss, a diferença em implementações client-side típicas fica entre 15% e 30%. O agravante do Adobe Commerce é que a diferença raramente tem uma causa dominante: é a soma de cinco ou seis vazamentos médios, cada um pequeno demais para chamar atenção sozinho.
As 7 causas técnicas da discrepância no Adobe Commerce
1. Checkout de página única renderizado via JavaScript
O checkout do Magento (Luma e derivados) é uma aplicação Knockout.js que renderiza etapas dinamicamente, sem recarregar página. Tags configuradas com gatilhos de pageview tradicionais não enxergam as transições entre envio, pagamento e revisão.
O funil de checkout no GA4 fica cego exatamente onde a operação mais perde dinheiro, e eventos como add_payment_info e add_shipping_info exigem escuta de eventos JavaScript específicos, não de URLs.
2. Frontend headless (PWA Studio, Hyvä, React custom)
Operações que migraram para headless carregam o problema clássico de SPA em escala: roteamento client-side sem pageviews reais, título e dados de produto disponíveis depois do disparo da tag, e um dataLayer que precisa ser construído do zero na camada de frontend, porque o backend Magento não o alcança mais.
Migrações de frontend que não incluíram a medição no escopo são a maior fonte de discrepância súbita em contas enterprise: a loja nova estreia bonita e cega.
3. Multi-store e multi-domínio sem estratégia de propriedade
Adobe Commerce nasceu para operar múltiplas lojas: marcas, países, B2B e B2C na mesma instalação. Sem uma decisão deliberada de arquitetura de propriedades GA4 (uma por loja? uma consolidada com filtros? subpropriedades?), os dados se misturam ou se perdem entre domínios.
Cross-domain mal configurado entre store views é fábrica de sessões quebradas e transações atribuídas a (direct).
4. Extensões de terceiros com tracking embutido
O marketplace de extensões do Magento é vasto e desregulado no que toca à medição. Extensões de one-step checkout, de recuperação de carrinho e de marketing enviam eventos próprios, às vezes com Measurement IDs codificados de forma rígida pelo desenvolvedor.
Em auditorias, é comum encontrar três fontes simultâneas de purchase em produção, herdadas de gestões e agências diferentes.
5. Pedidos criados fora da sessão web
Operações enterprise criam pedidos por telefone no admin, importam do ERP, recebem via API de B2B e processam reordens automáticas. Tudo isso entra no Sales do Magento sem sessão de navegador correspondente.
Comparar o total do backoffice com o GA4 sem segmentar a origem do pedido infla a "discrepância" com pedidos que nunca foram mensuráveis pelo analytics.
6. Pagamentos assíncronos e ciclo de status complexo
Pix, boleto, análise antifraude e aprovação manual criam janelas de horas ou dias entre o pedido e a confirmação. O purchase client-side dispara na página de sucesso, antes da aprovação real; pedidos reprovados pelo antifraude continuam contando como receita no GA4.
No sentido inverso, clientes que não retornam à página de sucesso após redirect de gateway somem da medição, mesmo com pagamento aprovado.
7. Credit memo e devoluções sem propagação
O fluxo de devolução do Adobe Commerce (credit memo, RMA) é robusto no backoffice e invisível para o GA4 client-side. Em operações com política de troca generosa, a receita do analytics descola da líquida de forma crescente e silenciosa.
Quanto de discrepância é aceitável entre Adobe Commerce e GA4
Aplicando a régua apenas sobre pedidos originados no site:
| Discrepância de receita | Diagnóstico |
|---|---|
| 0% a 3% | Excelente. Server-side integrado ao ciclo de pedido. |
| 3% a 8% | Saudável. Ajustes em credit memo e antifraude. |
| 8% a 15% | Atenção. Auditoria de extensões e checkout recomendada. |
| 15% a 30% | Crítico. Arquitetura de medição defasada da operação. |
| Acima de 30% | Falha estrutural. Provável migração de frontend sem escopo de medição. |
Como o server-side resolve no Adobe Commerce
O Adobe Commerce oferece o que plataformas SaaS não oferecem: acesso completo ao backend, sistema de eventos (observers), filas de mensagens e APIs para cada transição de status.
A arquitetura de referência:
- •purchase disparado pelo evento de pagamento aprovado no backend, via observer ou webhook para um container GTM Server-Side, com Measurement Protocol. Antifraude reprova? O evento nunca dispara. Pix aprovado de madrugada? Dispara sem navegador.
- •refund automático a partir do credit memo, alinhando o GA4 à receita líquida.
- •Deduplicação por transaction_id entre o evento client-side (mantido para costurar a atribuição da sessão) e o server-side (fonte de verdade da transação).
- •dataLayer de frontend reconstruído para o checkout dinâmico ou para o headless, com eventos de funil escutando o roteamento real da aplicação.
- •Arquitetura de propriedades GA4 documentada para o multi-store, com cross-domain configurado por decisão, não por herança.
Em operações Adobe Commerce migradas para essa arquitetura, a paridade site vs GA4 estabiliza abaixo de 3%, com cada ponto percentual restante explicado por escrito.
O protocolo em 6 etapas
- •Segmentação de origem de pedido: separar site, admin, API e ERP. A régua só vale para pedidos de sessão web.
- •Inventário de tracking: mapear toda extensão, tag e snippet que dispara eventos. Um caminho oficial, o resto desativado.
- •Arquitetura de propriedades: decisão documentada de estrutura GA4 para o multi-store e correção de cross-domain.
- •dataLayer do checkout e do headless: eventos de funil completos escutando a aplicação real, não URLs.
- •Server-side por observers: purchase e refund disparados pelo ciclo de status do pedido, com deduplicação.
- •Monitoramento e governança: dashboard diário de paridade, alerta acima de 5% e checklist de medição incluído no processo de deploy.
Como a Métricas Boss resolve isso?
A Métricas Boss atende operações enterprise em Adobe Commerce e Magento, da auditoria de arquitetura de medição à implementação server-side integrada ao ciclo de pedido, incluindo cenários headless e multi-store.
Se a sua operação cresceu e a medição ficou para trás, conheça o que a Métricas Boss faz e solicite uma auditoria preliminar.
Perguntas frequentes sobre discrepância Adobe Commerce vs GA4
Por que o Magento e o GA4 mostram números diferentes? Pela soma de vazamentos: checkout dinâmico invisível para tags tradicionais, frontends headless sem dataLayer, extensões disparando eventos paralelos, pedidos criados fora do site, pagamentos assíncronos e devoluções que nunca chegam ao GA4.
A migração para headless piora a medição? Piora quando a medição não entra no escopo da migração, o que é a regra do mercado. SPA sem dataLayer reconstruído e sem eventos de roteamento gera discrepância súbita e severa logo após o go-live.
Como medir multi-store do Adobe Commerce no GA4? Com decisão de arquitetura documentada: propriedades separadas por loja, propriedade consolidada com dimensão de store view, ou subpropriedades no GA4 360. O erro não é escolher qualquer uma delas, é não escolher e deixar os domínios se misturarem.
Pedidos de telefone e ERP deveriam aparecer no GA4? Não. Pedidos sem sessão web não são mensuráveis por analytics de site. Eles pertencem ao data warehouse e aos relatórios consolidados, e devem ser excluídos da comparação com o GA4.
O antifraude afeta a receita do GA4? Afeta. O purchase client-side dispara na página de sucesso, antes da análise antifraude. Pedidos reprovados depois continuam somando no GA4. Disparar o purchase pelo evento de aprovação no backend elimina essa distorção.
Server-side funciona em qualquer versão do Magento? A arquitetura por observers e webhooks funciona no Adobe Commerce e no Magento Open Source. O que muda é o esforço de implementação conforme a versão, o nível de customização e o frontend adotado.
Gustavo Esteves
Gustavo Esteves é fundador e CEO da Métricas Boss, já trabalhou dentro de gigantes como B2W. Autoridade na área de Digital Analytics, com mais de 15 anos de experiência e 3 mil projetos atendidos, incluindo gigantes como PUC, Rede D'Or, Globo, Stanley, Médico Sem Fronteiras, Alura, entre outras.
Publicado em 2 de julho de 2026
