Discrepância entre Tray e GA4: as causas que ninguém documenta (e como corrigir)
Loja na Tray vendendo bem, relatório do GA4 dizendo o contrário. O gestor abre os dois painéis lado a lado e os números parecem de empresas diferentes.
Na Tray, essa confusão tem um agravante que quase nenhuma outra plataforma tem: o backoffice mistura vendas do site com vendas de marketplace. Quem compara o total do admin com o GA4 está comparando duas operações diferentes e chamando a diferença de erro.
Esse artigo separa o que é fronteira de medição do que é tracking quebrado de verdade, mapeia as causas específicas da Tray e mostra o caminho para uma medição confiável.
O que é a discrepância entre Tray e GA4
Discrepância entre Tray e GA4 é a diferença entre pedidos e receita registrados no admin da Tray e os números equivalentes no Google Analytics 4.
Parte dessa diferença é estrutural: a Tray é um hub que centraliza vendas do site próprio e de marketplaces integrados (Mercado Livre, Amazon, Shopee, Magalu). Pedidos de marketplace entram no admin sem nunca gerar uma sessão no seu site. O GA4 não tem como enxergar o que não aconteceu no site.
A outra parte é técnica e corrigível: falhas de coleta client-side que fazem vendas do próprio site sumirem do analytics.
Primeiro passo: separar site de marketplace
Antes de qualquer diagnóstico, filtre no admin da Tray apenas os pedidos com origem no site próprio. A comparação justa é:
Pedidos do site (Tray) vs transações do GA4.
Em operações com forte presença em marketplace, esse filtro sozinho explica metade da "discrepância" que assustava a diretoria. O restante é onde mora o problema real.
As 6 causas técnicas da discrepância na Tray
1. Checkout em subdomínio com cross-domain mal configurado
O checkout da Tray tradicionalmente roda em subdomínio próprio da plataforma ou em estrutura separada do domínio principal. Sem configuração correta de cross-domain no GA4 e no GTM, a passagem da loja para o checkout quebra a sessão.
O sintoma clássico: transações atribuídas a (direct) ou ao próprio domínio como referral, e campanhas pagas que "não convertem" no GA4 enquanto o Gerenciador de Anúncios mostra o contrário.
2. Camada de dados incompleta ou ausente
A Tray não entrega, por padrão, um dataLayer estruturado com o funil completo de e-commerce no formato GA4 (view_item, add_to_cart, begin_checkout, add_payment_info, purchase com items completos).
Implementações que dependem do que a plataforma expõe nativamente acabam com funil truncado: o purchase até chega, mas sem os passos anteriores, os relatórios de funil e as audiências de remarketing ficam inutilizáveis.
3. Página de confirmação que nem sempre carrega
O purchase client-side depende do cliente chegar à página de pedido confirmado. Pagamentos por Pix e boleto, redirecionamentos de gateway e clientes que fecham a aba após pagar interrompem esse fluxo.
A venda existe no admin. O evento nunca disparou. Em lojas com share alto de Pix, essa causa isolada passa de 15% dos pedidos.
4. Scripts de tema e apps conflitando
O ecossistema de temas e integrações da Tray permite múltiplos pontos de injeção de script. É comum encontrar lojas com a tag nativa do GA4, um GTM instalado pela agência anterior e um app de marketing disparando eventos próprios, todos ao mesmo tempo.
O resultado varia entre purchase duplicado, sessões fragmentadas e eventos com parâmetros conflitantes. Antes de adicionar qualquer coisa, o trabalho é remover.
5. UTMs perdidas em fluxos de redirecionamento
Links de campanhas que passam por encurtadores, redirecionamentos de domínio ou pelo fluxo de login perdem parâmetros de UTM pelo caminho. O GA4 recebe a sessão sem origem e classifica como direto.
A venda aparece, mas na linha errada. Para quem analisa canal, é discrepância; tecnicamente, é atribuição destruída.
6. Cancelamentos e devoluções invisíveis para o GA4
O ciclo de pedido da Tray (aguardando pagamento, aprovado, cancelado, devolvido) vive no admin. A coleta client-side registra o purchase no momento da confirmação e nunca mais atualiza. Pedidos cancelados continuam somando receita no GA4.
Receita inflada de um lado, vendas perdidas do outro: as duas distorções coexistem e às vezes se mascaram mutuamente.
Quanto de discrepância é aceitável entre Tray e GA4?
Aplicando a régua somente sobre pedidos do site próprio:
| Discrepância de receita (site vs GA4) | Diagnóstico |
|---|---|
| 0% a 3% | Excelente. Server-side com webhooks ativo. |
| 3% a 8% | Saudável. Ajustes em refund e cross-domain. |
| 8% a 18% | Atenção. Auditoria de coleta recomendada. |
| 18% a 30% | Crítico. Mídia sendo decidida com base falsa. |
| Acima de 30% | Falha estrutural de coleta. |
Como o server-side resolve na Tray?
A Tray disponibiliza API e notificações de pedido que permitem arquitetura server-side: um container GTM Server-Side recebe as notificações de mudança de status e converte em eventos GA4 via Measurement Protocol.
Na prática:
- •O purchase dispara quando o pagamento é aprovado no servidor, cobrindo Pix, boleto e todo cliente que nunca voltou à página de confirmação.
- •Cancelamento e devolução viram refund automático, alinhando o GA4 à receita líquida real.
- •A dependência do checkout em subdomínio diminui, porque o evento crítico deixa de morar no navegador.
- •Adblocker e ITP param de derrubar a coleta de compra.
Combinado com a correção do client-side (cross-domain, dataLayer de funil, limpeza de scripts), o resultado em auditorias da Métricas Boss é discrepância de site abaixo de 3%, com marketplace medido separadamente pela régua correta.
O protocolo em 5 etapas
- •Segmentação de origem: separar pedidos de site e de marketplace no admin. A régua só vale para o site.
- •Auditoria e limpeza client-side: inventário de todas as tags ativas (nativa, GTM, apps), remoção de duplicidades, correção de cross-domain do checkout.
- •dataLayer de funil completo: implementação dos eventos de e-commerce no padrão GA4 com parâmetros de items.
- •Server-side com notificações da Tray: purchase e refund disparados por mudança de status de pedido, com deduplicação por transaction_id.
- •Monitoramento: dashboard diário de paridade site vs GA4 e alerta automático acima de 5%.
Como a Métricas Boss resolve isso?
A Métricas Boss audita e implementa infraestrutura de medição em plataformas brasileiras de e-commerce, incluindo a arquitetura server-side completa para lojas Tray, do diagnóstico ao monitoramento contínuo.
Se a sua operação Tray compara admin com GA4 e desiste de entender a diferença, conheça o que a Métricas Boss faz e solicite uma auditoria preliminar.
Perguntas frequentes sobre discrepância Tray vs GA4
Por que o GA4 mostra menos vendas que o admin da Tray? Primeiro, porque o admin da Tray soma pedidos de marketplaces que nunca passaram pelo site. Segundo, por falhas técnicas de coleta: checkout em subdomínio quebrando sessão, purchase dependente de página de confirmação que nem sempre carrega, scripts conflitantes e bloqueadores.
Vendas de Mercado Livre e Shopee deveriam aparecer no GA4? Não. Marketplaces são operações fora do seu site, sem sessão rastreável. Eles devem ser medidos por relatórios próprios ou por um data warehouse que consolide canais, nunca comparados diretamente com o GA4 do site.
Quanto de diferença entre Tray e GA4 é aceitável? Comparando apenas pedidos do site próprio: abaixo de 5% é saudável, acima de 18% é crítico. Se a comparação incluir marketplace, o número não significa nada.
A Tray tem dataLayer pronto para o GA4? Não no formato completo do funil de e-commerce GA4. A implementação profissional exige construir a camada de dados no tema ou alimentar os eventos via server-side.
Server-side funciona na Tray? Funciona. As notificações de pedido da plataforma permitem disparar purchase e refund do servidor via Measurement Protocol, cobrindo Pix, boleto e clientes que não retornam à página de confirmação.
Pedido cancelado continua contando no GA4? Na integração client-side padrão, sim. O GA4 registra o purchase e nunca fica sabendo do cancelamento. A propagação de refund via webhook server-side é o que mantém a receita do GA4 alinhada à receita líquida.
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
