Exportar o GA4 para o BigQuery: como analisar conversões no nível do evento bruto

Os relatórios do GA4 são úteis para o dia a dia, mas têm um teto: são agregados, sujeitos a amostragem e a limites de cardinalidade, e não permitem responder perguntas fora do que a interface prevê. A exportação para o BigQuery derruba esse teto. Ela entrega o dado de evento bruto, no nível de cada hit, permitindo reconstruir conversões, refazer atribuição e cruzar comportamento com dados de negócio via SQL. Este guia explica como a exportação funciona e como usá-la para análise séria de conversões.

Por que exportar para o BigQuery

O relatório pronto do GA4 responde bem a perguntas comuns, mas trava diante de perguntas específicas. Quantos usuários que compraram na primeira sessão voltaram em trinta dias? Qual a receita real por canal usando a minha própria regra de atribuição? Como se comporta uma coorte definida por um evento customizado combinado com um valor de parâmetro? A interface simplesmente não faz isso.

A exportação para o BigQuery resolve porque entrega os dados sem pré-agregação. Cada evento vira uma linha, com todos os seus parâmetros. Sobre esse dado bruto você escreve SQL e responde qualquer pergunta que o dado suportar, sem amostragem, sem limite de cardinalidade da interface, sem depender do que o produto decidiu expor. É a diferença entre consumir o relatório e ter o dado.

Como configurar a exportação

A configuração é feita na administração do GA4, na seção de vínculos com o BigQuery. O fluxo geral:

• Tenha um projeto no Google Cloud com o BigQuery habilitado.
• Vincule a propriedade do GA4 a esse projeto.
• Escolha o tipo de exportação: diária, que entrega uma tabela completa por dia, e streaming, que entrega os eventos continuamente ao longo do dia.
• Selecione os fluxos de dados a exportar e defina se dados de custo e outros serão incluídos.

A exportação diária é suficiente para a maioria das análises. O streaming é útil quando se precisa de dado quase em tempo real, com a ressalva de que ele não passa pelo processamento completo que a exportação diária aplica. Muitas operações usam os dois: streaming para monitorar o dia corrente e a tabela diária como fonte de verdade para análise histórica.

O formato dos dados

O modelo de dados do GA4 no BigQuery é aninhado. Cada linha é um evento, e dentro dela há estruturas repetidas para os parâmetros. Os campos essenciais para trabalhar com conversões:

• event_name: o nome do evento, como purchase, generate_lead ou um evento customizado.
• event_timestamp: o momento do evento, em microssegundos.
• event_params: um array de pares chave-valor com todos os parâmetros do evento, onde ficam value, currency, transaction_id, itens de e-commerce e o que mais o seu data layer enviar.
• user_pseudo_id: o identificador pseudônimo do dispositivo ou navegador.
• user_id: o identificador de usuário, quando você o envia.
• traffic_source e campos de sessão: origem, mídia e campanha, úteis para reconstruir atribuição.
• device, geo e outros: contexto do evento.

A estrutura aninhada exige o uso de UNNEST no SQL para extrair os parâmetros. É o primeiro conceito que quem chega ao GA4 no BigQuery precisa dominar, porque nada de interessante em conversões acontece sem desaninhar o event_params.

Reconstruindo conversões via SQL

Para contar conversões, você filtra os eventos pelo nome e extrai os parâmetros relevantes. A lógica geral de uma análise de compras, descrita em prosa:

• Filtra as linhas cujo event_name corresponde ao evento de conversão desejado, por exemplo purchase.
• Desaninha o event_params para trazer os valores de value e currency para colunas.
• Agrupa por dia, canal ou qualquer dimensão de interesse.
• Soma os valores e conta os eventos para obter volume e receita.

A vantagem sobre o relatório pronto é que cada decisão é sua. Você define o que é uma conversão válida, como tratar duplicidades por transaction_id, qual janela usar, como atribuir crédito. Nada é imposto pela interface.

Para deduplicação, por exemplo, é comum usar o transaction_id como chave e manter apenas uma linha por transação, eliminando compras contadas em dobro por recarregamento da página de confirmação. Esse tipo de limpeza é impossível de fazer no relatório pronto e trivial no SQL sobre o dado bruto.

Atribuição sob medida

Um dos usos mais valiosos da exportação é refazer a atribuição com a regra que faz sentido para o negócio. Como você tem todos os eventos por usuário, com origem e tempo, pode reconstruir a jornada completa e distribuir o crédito da conversão entre os toques como quiser: primeiro clique, último clique, linear, com decaimento temporal ou um modelo próprio.

Isso liberta a análise da atribuição imposta pela plataforma. Em vez de aceitar o que o relatório mostra, você calcula a receita por canal com a lógica que o seu comitê de marketing acordou, e a defende com o dado na mão. Também permite reconciliar com o financeiro usando as suas próprias regras, o que é fundamental quando os números da plataforma e do caixa divergem.

Cruzando com dados de negócio

O BigQuery é um data warehouse, então o dado do GA4 pode conviver com outras tabelas: o CRM, o ERP, a base de custos de mídia, o cadastro de clientes. Isso abre análises que nenhum relatório de analytics faz sozinho:

• Juntar a conversão online com o desfecho real do lead no CRM, medindo qualidade, não só volume.
• Cruzar receita reconhecida do ERP com o comportamento que a precedeu, ligando marketing a caixa.
• Calcular LTV por canal de aquisição, combinando o primeiro toque com a receita acumulada ao longo do tempo.
• Trazer o custo de mídia e computar ROAS real sobre a receita reconhecida.

Esse cruzamento é onde a mensuração deixa de ser um painel de vaidade e vira instrumento de decisão de negócio.

Sessões e o desafio de reconstruí-las

Uma diferença marcante do GA4 no BigQuery é que a sessão não vem pronta como uma linha; ela precisa ser reconstruída a partir dos eventos. O GA4 registra o identificador de sessão como um parâmetro do evento, o ga_session_id, junto do número da sessão. Para analisar comportamento por sessão — quantas sessões terminaram em conversão, qual a duração até a compra, quantos passos até o checkout — é preciso agrupar os eventos por usuário e por identificador de sessão.

Isso dá trabalho, mas também dá liberdade. Você define o que é uma sessão para o seu negócio, como tratar timeouts, como lidar com usuários que atravessam a meia-noite. Em vez de aceitar a definição de sessão embutida na interface, você a modela conforme a realidade da operação. Para análises de funil de conversão, essa reconstrução é o que permite medir com precisão quantas sessões passaram por cada etapa e onde os usuários abandonaram.

O mesmo raciocínio vale para jornadas que cruzam dispositivos: com um user_id consistente, é possível costurar sessões de aparelhos diferentes sob o mesmo usuário, algo que o relatório pronto trata de forma limitada e que no dado bruto se torna uma questão de SQL bem escrito.

Frescor do dado e reconciliação

Um ponto operacional importante é o momento em que o dado fica disponível. A exportação diária entrega a tabela do dia anterior algumas horas após o fim do dia, já processada. O streaming entrega ao longo do dia, mas sem o processamento completo, o que significa que a tabela de streaming e a diária do mesmo período podem não bater exatamente. Entender essa diferença evita a armadilha de comparar as duas fontes e concluir, erradamente, que há um bug.

Para relatórios oficiais e reconciliação com o financeiro, a prática recomendada é usar a tabela diária como fonte de verdade, deixando o streaming para monitoramento do dia corrente. A reconciliação entre a contagem do BigQuery, a da interface do GA4 e a do sistema transacional deve considerar que cada camada tem suas regras de processamento, e pequenas diferenças são esperadas; o que importa é que não haja divergências grandes e inexplicadas, que sinalizariam quebra no pipeline de coleta.

Cuidados de custo e governança

O BigQuery cobra por armazenamento e por processamento de consulta. Sobre bases grandes, consultas mal escritas podem custar caro. Alguns princípios:

• Aproveite o particionamento por data das tabelas do GA4, filtrando sempre pelo intervalo de datas para não varrer a base inteira.
• Selecione apenas as colunas necessárias, evitando trazer o evento inteiro quando só precisa de alguns campos.
• Materialize resultados intermediários em tabelas agregadas quando a mesma análise roda com frequência.
• Controle o acesso ao dataset, já que o dado bruto contém informação sensível de comportamento e, se houver user_id, de identidade.

Sobre governança, vale lembrar que o dado exportado carrega o comportamento detalhado dos usuários. O tratamento precisa respeitar o consentimento e a base legal sob a LGPD, e o acesso deve ser restrito a quem tem necessidade legítima.

Erros comuns

Armadilhas frequentes ao trabalhar com o GA4 no BigQuery:

• Esquecer o UNNEST: tentar ler event_params como coluna simples e não achar os valores.
• Não deduplicar por transaction_id: inflar receita com compras contadas em dobro.
• Ignorar o particionamento: varrer meses de dados sem filtro de data e explodir o custo.
• Somar streaming e diária sem cuidado: as duas fontes têm processamento diferente e podem divergir.
• Confundir user_pseudo_id com usuário único: o mesmo usuário em vários dispositivos gera vários pseudo ids.
• Tratar o dado bruto como público: falta de controle de acesso a informação sensível.

Conclusão

Exportar o GA4 para o BigQuery é o passo que transforma analytics de painel em plataforma de análise. O dado de evento bruto, sem amostragem e sem os limites da interface, permite reconstruir conversões com as suas regras, refazer atribuição sob medida e cruzar comportamento com o dado de negócio que está no CRM e no ERP. O custo desse poder é técnico — desaninhar parâmetros, escrever SQL correto, controlar consumo e acesso — mas o retorno é uma mensuração que responde às perguntas reais do negócio, e não apenas às que o relatório pronto antecipou.