Discrepância entre Wbuy e GA4: o guia que não existia (causas e correção)
Pesquise "Wbuy GA4" no Google. O que você encontra é tutorial de colar o Measurement ID no admin e nada mais. Nenhum conteúdo sério sobre por que os números do painel da Wbuy e do GA4 não batem, quanto de diferença é aceitável ou como corrigir.
Enquanto isso, lojistas Wbuy decidem orçamento de mídia com um GA4 que enxerga só parte das vendas, sem saber qual parte.
Esse guia preenche o vazio: as causas da discrepância em plataformas SaaS fechadas como a Wbuy, a régua de diagnóstico e o caminho de correção quando o acesso ao código é limitado.
O que é a discrepância entre Wbuy e GA4
Discrepância entre Wbuy e GA4 é a diferença entre pedidos e receita registrados no painel da Wbuy e os números equivalentes no Google Analytics 4.
O painel registra a operação como ela é. O GA4, na integração padrão, registra o que o navegador do cliente conseguiu reportar. Entre um e outro ficam bloqueadores, pagamentos assíncronos, checkout controlado pela plataforma e eventos que nunca dispararam.
Em plataformas SaaS fechadas de porte similar, as auditorias da Métricas Boss encontram diferenças típicas entre 20% e 35% nas integrações client-side padrão. Não há motivo para a Wbuy fugir desse padrão.
As 6 causas da discrepância na Wbuy
1. Integração nativa limitada ao essencial
A integração padrão via Measurement ID cobre pageview e conversão básica. O funil completo do GA4 (view_item, add_to_cart, begin_checkout, add_payment_info, purchase com array de items) não vem de fábrica.
Sem o funil, o GA4 vira um contador parcial de vendas sem contexto: não responde onde o cliente desiste, quais produtos puxam a jornada nem quais audiências valem remarketing.
2. Checkout controlado pela plataforma
Como toda SaaS fechada, a Wbuy controla o ambiente de checkout. O espaço para scripts próprios é limitado e muda conforme plano e configuração. Quando o purchase depende de um script na página de confirmação e a plataforma restringe o que roda ali, a medição fica refém do que a integração nativa decide enviar.
3. Pix e boleto: a venda que fecha com a aba fechada
O padrão brasileiro de pagamento é o inimigo número um da coleta client-side. O cliente gera o Pix, fecha a aba, paga pelo app do banco. A aprovação acontece minutos ou horas depois, sem nenhum navegador aberto para disparar evento.
Quanto maior o share de Pix e boleto da loja, maior a fatia de vendas invisíveis para o GA4. Em várias operações, essa causa sozinha passa de 15% dos pedidos.
4. Bloqueadores e ITP derrubando a coleta
Adblockers no Chrome e as restrições de cookies do Safari (ITP) impedem a coleta em uma parcela relevante da audiência, com penetração especialmente alta em públicos jovens e em tráfego iOS.
A venda acontece, o painel registra, o GA4 nunca fica sabendo. É perda distribuída, silenciosa e impossível de recuperar depois.
5. UTMs perdidas em links de bio, WhatsApp e social
Operações Wbuy costumam vender forte por Instagram e WhatsApp. Links de bio sem UTM, encurtadores que descartam parâmetros e redirecionamentos intermediários entregam a sessão ao GA4 sem origem.
A venda até aparece, mas como (direct) ou (not set). Para quem analisa canal, o efeito é o mesmo da venda perdida: a mídia que gerou não recebe o crédito.
6. Cancelamentos sem evento de refund
Pedido cancelado ou devolvido no painel da Wbuy não gera refund no GA4 na integração padrão. A receita do analytics permanece bruta e infla com o tempo, distorcendo o ROAS para cima na mesma medida em que as causas anteriores o distorcem para baixo.
Duas distorções em sentidos opostos não se anulam. Se somam em confusão.
Quanto de discrepância é aceitável entre Wbuy e GA4
| Discrepância de receita | Diagnóstico |
|---|---|
| 0% a 3% | Excelente. Coleta server-side ativa. |
| 3% a 8% | Saudável. Ajustes pontuais em refund e UTMs. |
| 8% a 18% | Atenção. Auditoria de coleta recomendada. |
| 18% a 30% | Crítico. Decisão de mídia comprometida. |
| Acima de 30% | Falha estrutural. GA4 não serve como fonte de verdade. |
Antes de aplicar a régua, exclua da comparação pedidos criados fora do site (venda manual, link direto de pagamento sem sessão). A conta justa é site contra site.
O caminho server-side em plataformas fechadas
Em plataformas SaaS com acesso limitado ao código, a estratégia server-side muda de forma, não de essência. Três rotas, em ordem de preferência:
Rota 1: webhooks ou API de pedidos. Se a plataforma expõe notificações de criação e mudança de status de pedido, um container GTM Server-Side as recebe e converte em purchase e refund via Measurement Protocol. É a arquitetura definitiva: o evento nasce da aprovação do pagamento, não do navegador.
Rota 2: polling da API. Sem webhook, um serviço leve consulta a API de pedidos em intervalos curtos, identifica novas aprovações e cancelamentos e dispara os eventos correspondentes. Menos elegante, igualmente eficaz para paridade.
Rota 3: conciliação via BigQuery. No mínimo, uma rotina diária cruza o relatório de pedidos exportado com as transações do GA4, mede a paridade e alimenta o dashboard de monitoramento. Não corrige a coleta, mas acaba com a cegueira sobre o tamanho do problema.
Combinada com a correção do client-side possível (funil de eventos onde a plataforma permite, UTMs padronizadas, deduplicação por transaction_id), a rota 1 ou 2 leva a paridade para menos de 3%, o mesmo patamar das grandes plataformas.
O protocolo em 5 etapas
- •Dimensionamento: comparação pedido a pedido entre painel e GA4 em 90 dias, com share de Pix/boleto e de canais sociais mapeado.
- •Correção client-side possível: funil de eventos no que a plataforma permite, padronização de UTMs em bio, stories e WhatsApp.
- •Integração server-side: webhook ou polling da API de pedidos alimentando o GTM Server-Side com purchase e refund.
- •Deduplicação: transaction_id como chave entre o evento do navegador e o do servidor.
- •Monitoramento: dashboard diário de paridade com alerta acima de 5%.
Como a Métricas Boss resolve isso?
A Métricas Boss implementa medição confiável em plataformas de e-commerce brasileiras, incluindo SaaS fechadas, definindo a rota server-side viável para cada caso e monitorando a paridade de forma contínua.
Se a sua loja Wbuy nunca soube dizer quanto o GA4 perde, conheça o que a Métricas Boss faz e solicite uma auditoria preliminar.
Perguntas frequentes sobre discrepância Wbuy vs GA4
Por que as vendas da Wbuy não aparecem no GA4? Pela combinação de integração nativa limitada, checkout controlado pela plataforma, pagamentos por Pix e boleto aprovados com a aba fechada, bloqueadores de anúncio e UTMs perdidas em links de redes sociais.
Quanto de diferença entre Wbuy e GA4 é normal? Abaixo de 5% é saudável. Entre 8% e 18% pede auditoria. Acima de 18% significa que as decisões de mídia estão sendo tomadas sobre base não confiável.
Colar o Measurement ID no admin da Wbuy é suficiente? Para começar a coletar, sim. Para decidir mídia, não. A integração básica não cobre o funil completo, não captura pagamentos assíncronos e não propaga cancelamentos.
É possível fazer server-side na Wbuy? Sim, pela via da API e das notificações de pedido da plataforma alimentando um GTM Server-Side. Quando webhook não está disponível, o polling da API de pedidos cumpre o mesmo papel de disparar purchase e refund do lado do servidor.
Por que o Pix causa tanta perda de tracking? Porque a aprovação acontece fora do navegador. O cliente gera o código, fecha a aba e paga pelo banco. Nenhum script client-side está rodando no momento em que a venda se concretiza. Só eventos disparados do servidor capturam esse fluxo.
O que fazer primeiro: corrigir a coleta ou medir o tamanho do problema? Medir. Uma conciliação de 90 dias entre painel e GA4 dimensiona a perda, aponta as causas dominantes e evita investir na correção errada.
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
