Export do GA4 para o BigQuery: passo a passo e os erros que custam caro

Se eu pudesse dar um único conselho para quem tem loja e usa o GA4, seria este: ligue o export para o BigQuery hoje. Mesmo que ninguém vá consultar agora.

O motivo é simples. O export não traz passado. O dado bruto, evento por evento, começa a ser gravado no dia em que você liga. Quem liga daqui a um ano vai ter um ano a menos de histórico bruto. Já expliquei por que a MyMetric usa esse dado como base; este texto é o lado prático.

Antes de ligar

• Use um projeto do Google Cloud com faturamento. No sandbox do BigQuery (sem cartão), as tabelas expiram em 60 dias. Você liga, esquece e perde o histórico do mesmo jeito.
• Escolha bem a região. A localização do conjunto de dados é definida na ligação. Trocar depois exige desfazer o vínculo, recriar o conjunto na região nova e vincular de novo (ou replicar o conjunto), com risco de buraco nos dados. Se os outros dados da empresa estão em US, por exemplo, deixe o GA4 lá também: consultas que cruzam regiões diferentes não funcionam.
• Permissões. Quem liga precisa ser editor (ou mais) na propriedade do GA4 e proprietário (OWNER) do projeto no Google Cloud.

Passo a passo

1. No GA4, vá em Administrador > Vinculações de produtos > Vinculações do BigQuery e clique em Vincular.
2. Escolha o projeto do Google Cloud e a região dos dados.
3. Escolha os fluxos de dados (normalmente o fluxo da web da loja).
4. Marque a frequência: Diária, Streaming ou as duas.
5. Se quiser a tabela de usuários, marque também a exportação de dados do usuário.
6. Envie. A primeira tabela aparece no dia seguinte, num conjunto chamado analytics_<número da propriedade>.

Diário ou streaming?

Para a maioria das lojas, o diário basta. O streaming vale quando alguém precisa do dia de hoje (um painel em tempo real, um alerta que não pode esperar) ou quando a loja passa do limite de 1 milhão de eventos por dia. Se a propriedade passa do limite com frequência, o Google pausa o export diário e não reprocessa os dias perdidos. Por isso vale olhar o volume antes.

A tabela de ontem não tem hora para chegar

Dois detalhes que derrubam muito painel:

• O horário muda sem aviso. O Google diz que a tabela costuma chegar no começo da tarde, no fuso da propriedade, mas nos clientes que atendemos ela aparecia de manhã. A partir de 6 de outubro de 2026, passou a chegar por volta das 15h (horário de Brasília). Todo processo que rodava num horário fixo de manhã passou a não encontrar o dia anterior, e alguns painéis ficaram parados até a gente ajustar a janela.
• A tabela pode mudar depois de criada. Segundo o Google, eventos que chegam atrasados são incluídos por até três dias depois da data deles.

O jeito certo de consumir é: verificar se a tabela de ontem existe antes de rodar, tentar de novo ao longo do dia e reprocessar sempre os últimos três dias.

Os erros que mais custam nas consultas

• Consultar events_* sem filtrar _TABLE_SUFFIX. O BigQuery lê todas as tabelas, de todos os dias, e cobra por isso. Sempre filtre o intervalo.
• Misturar fuso. O event_date (e o nome da tabela) segue o fuso da propriedade. O event_timestamp é em UTC, em microssegundos. Agrupar por hora usando o timestamp sem converter desloca o dia.
• Contar sessão errado. Sessão é a combinação de user_pseudo_id com o parâmetro ga_session_id. Contar só o ga_session_id junta sessões de pessoas diferentes.
• Somar compra duplicada. O mesmo transaction_id pode aparecer mais de uma vez: tag do navegador e servidor mandando a mesma compra, recarga da página de obrigado. Conte pedidos com COUNT(DISTINCT ecommerce.transaction_id) e confira se a receita bate com a loja.
• Esquecer que os parâmetros ficam aninhados. Cada parâmetro está dentro de event_params e precisa de UNNEST, com o tipo certo (string_value, int_value, double_value).

Uma consulta de partida, com sessões e pedidos por dia, já com os cuidados acima:

SELECT
  event_date,
  COUNT(DISTINCT CONCAT(user_pseudo_id, '-',
    CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING))) AS sessoes,
  COUNT(DISTINCT IF(event_name = 'purchase', ecommerce.transaction_id, NULL)) AS pedidos
FROM `seu-projeto.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
                        AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
GROUP BY event_date
ORDER BY event_date

E se eu já perdi o histórico?

O evento bruto do passado não volta. O que dá para recuperar são os números agregados, pela Data API do GA4. Fizemos isso para uma loja que ligou o export em setembro de 2026: puxamos de 2022 em diante, um pedido por dia para não cair em amostragem, e gravamos numa tabela ao lado do export.

Duas armadilhas desse caminho:

• A API devolve os valores crus do GA4, como (direct), (none) e (not set). Se o resto do seu pipeline já trata isso como "direto" ou vazio, o histórico da API não encaixa até alguém normalizar. No nosso caso, mais de 1 milhão de sessões diretas caíam em "Outros".
• Troca de UTM no meio da série. Se a agência mudou o padrão de marcação (por exemplo, de ig / paid para meta / cpc), o histórico mostra um canal desabando e outro nascendo. É só nome.

Quanto custa

O export diário é gratuito; o streaming entra na conta do BigQuery. O armazenamento de uma loja média costuma ser barato. O que pesa é consulta: no modelo sob demanda, o BigQuery cobra por volume lido, com uma faixa gratuita por mês. Filtrar datas e selecionar só as colunas necessárias resolve quase todo o custo. Confira os valores atuais na página de preços do BigQuery.

Veja também (not set) no GA4 e Tag quebrada no GA4.

Fontes

• Google: configurar o export do GA4 para o BigQuery (consultado em 12/10/2026)
• Google: esquema do export do GA4 para o BigQuery (consultado em 12/10/2026)
• Google Cloud: preços do BigQuery (consultado em 12/10/2026)
• Google: Data API do GA4 (consultado em 12/10/2026)