Dado bruto do GA4: por que a MyMetric usa o export para BigQuery, e por que ele precisa estar certo

Quando alguém me pergunta o que a MyMetric faz de diferente das outras ferramentas de dados para e-commerce, a resposta mais curta é esta: a gente trabalha em cima do dado bruto do GA4, e por isso precisa que ele esteja certo.

Parece detalhe técnico. Não é. Define de onde vem cada número do painel, o que dá para responder com ele e onde ele pode estar errado.

Três jeitos de montar um painel de e-commerce

1. Pixel próprio. A ferramenta instala o próprio script na loja e monta uma base paralela ao GA4. Funciona, mas cria um segundo número de visitas e vendas, que não bate com o GA4 nem com o que o Google Ads vê.
2. Ler os relatórios do GA4. A ferramenta puxa do GA4 o que ele já agregou: vendas por origem/meio, sessões por canal. É rápido, mas herda as limitações do relatório e não deixa descer ao nível do evento.
3. Ler o evento bruto do GA4. É o que a MyMetric faz. O GA4 exporta cada evento para o BigQuery, e o HUB é construído em cima dessa tabela.

Comparamos ferramentas que seguem os dois primeiros caminhos no comparativo com Nemu, Solomon, Prax e Biso.

O que é o dado bruto do GA4

Toda propriedade do GA4 pode ser ligada ao BigQuery. A partir daí, o Google grava uma tabela por dia com uma linha por evento: page_view, view_item, add_to_cart, purchase. Cada linha traz o identificador do navegador, o número da sessão, a origem do tráfego, os parâmetros do evento e, na compra, o transaction_id e os itens.

Três detalhes práticos:

• A ligação é gratuita na propriedade padrão. Paga-se o armazenamento e as consultas no BigQuery.
• O export diário tem limite de 1 milhão de eventos por dia na propriedade padrão. O export contínuo (streaming) não tem esse limite, mas é cobrado.
• Não existe passado. O export começa no dia em que é ligado. O histórico de antes fica só nos relatórios do GA4.

Por que o bruto, e não o relatório

• Sem amostragem, sem limite de privacidade, sem (other). Explorações grandes podem ser amostradas, o Google Signals ligado esconde linhas com poucos usuários e dimensões com muitos valores viram (other). No dado bruto, cada evento está lá.
• Cruzamento com o pedido. O transaction_id do GA4 é o número do pedido. No bruto dá para casar cada venda com o pedido da plataforma, e daí com o cancelamento, o cliente novo, o ERP e o marketplace.
• Qualquer modelo de atribuição, inclusive para trás. Com a jornada evento a evento, o HUB recalcula a atribuição como quiser. O Origin Stack (quem capturou o lead leva o crédito; se não houve lead, o primeiro clique; por último, o último) só existe porque o dado é bruto.
• Uma fonte só. O mesmo GA4 que alimenta o Google Ads alimenta o painel. Ninguém precisa explicar por que a ferramenta mostra um número e o GA4 outro.

O lado ruim: bruto também nos erros

O relatório do GA4 às vezes disfarça um problema. O dado bruto não disfarça nada: se a coleta perdeu o evento, ele não está na tabela. Alguns casos de lojas que atendemos (anônimas):

• A tag do navegador não dispara para todo mundo. Numa loja, comparando evento a evento o que o gtag registrava com o que chegava pelo servidor, a tag do navegador perdia 19% das visualizações de produto, quase todas em iPhone dentro do app do Instagram.
• A compra não chega inteira. Numa loja VTEX, o GA4 registra entre 84% e 88% dos pedidos reais, estável há anos.
• Evento quebrado passa meses sem ninguém ver. Numa loja, o add_to_cart ficou sete meses sem ser registrado.
• Venda sem origem. Compra que chega sem o cookie do GA4 entra como (not set): é contada, mas não é atribuída a canal nenhum.

Ferramenta que lê o GA4 sem mexer na coleta herda esses buracos, seja no relatório, seja no bruto. Detalho cada um deles em GA4 x MyMetric.

Por isso a gente conserta a coleta antes de ler

Se o HUB é construído em cima do GA4, deixar o GA4 certo deixa de ser opcional. É o que o Spark faz:

• Eventos pelo servidor. O Spark envia os eventos ao GA4 pelo Measurement Protocol, com os dados vindos da própria plataforma da loja, e não só do gtag.
• A compra sai do webhook do pedido. Não depende da página de obrigado carregar. E pode ir só quando o pedido é pago, então o cancelado não infla a receita.
• Identidade de primeira parte. O coletor roda num subdomínio da loja, com cookie próprio, para que a compra enviada pelo servidor chegue ligada à sessão de quem comprou sempre que esse vínculo existe.
• Conferência contra o pedido. O HUB cruza o GA4 com os pedidos da plataforma, pedido a pedido. O que não está no GA4 aparece, em vez de sumir.

O efeito não fica só no painel. O mesmo envio pelo servidor vai para a API de Conversões do Meta e para conversões offline do Google Ads. Na Gringa, o connect rate no Meta foi de 38,6% para 78,6% depois do Spark (o estudo).

Como saber se o seu GA4 aguenta virar base

1. O export para o BigQuery está ligado? Se não, ligue hoje, mesmo que não vá usar agora: o histórico bruto só começa a contar a partir daí.
2. As transações batem com os pedidos? Compare as transações do GA4 com os pedidos pagos da loja nos últimos 30 dias. Acima de 95% está bom; abaixo de 85%, o GA4 está deixando venda importante de fora.
3. O transaction_id é o número do pedido, e não se repete? Sem isso, não dá para cruzar com a plataforma.
4. Quanto da receita está em (not set)? Se for uma fatia relevante, a compra está chegando sem a sessão.
5. O funil está inteiro? Olhe view_item, add_to_cart e begin_checkout por dia nos últimos meses. Um degrau repentino quase sempre é tag quebrada, não comportamento.

Fontes

• Google: configurar o export do GA4 para o BigQuery (consultado em 11/10/2026)
• Google: Measurement Protocol do GA4 (consultado em 11/10/2026)