Ligar a exportação para o BigQuery e entender o que ela não reproduz

Com a análise assistida conferida, sobra a pergunta que a interface não responde: qual foi a receita dos assinantes que entraram por e-mail, compraram um vaso e depois pediram orçamento de paisagismo? A resposta exige cruzar três escopos e uma tabela do HubSpot, e nenhum relatório nativo faz isso.

O custo de não ter os dados brutos aparece em decisão tomada sobre número agregado. A linha (other) esconde a página que importa, o limiar de dados apaga o segmento pequeno, e a retenção de 14 meses corta a coorte que a Verde Vivo queria comparar com o ano anterior. A exportação para o BigQuery entrega cada evento, um por linha, para consultar como se quiser.

Ela também entrega algo que ninguém pediu: um número diferente do da interface para a mesma métrica. Quem liga a exportação sem saber por que os dois divergem passa semanas tentando consertar o que não está quebrado. O capítulo liga a exportação da Verde Vivo e explica cada diferença.

Exportar vale a pena em três situações. Quando a pergunta cruza o GA4 com outra fonte (CRM, plataforma de loja, planilha de custo). Quando o período de análise passa da retenção da propriedade. Quando a granularidade importa: uma pessoa, uma sessão, um pedido, sem agregação nem limiar. Para o relatório semanal de sessões por canal, a interface continua sendo o caminho mais barato.

A configuração fica em Admin, nos vínculos de produto da propriedade. Quem liga precisa de um projeto no Google Cloud com faturamento ativo e permissão para criar recursos nele, além do papel de Editor na propriedade. A região do dataset (o conjunto de tabelas que o Google cria no projeto) é escolhida na hora do vínculo, e convém escolher a mesma região das outras fontes que serão cruzadas, porque consulta entre regiões diferentes não roda.

A escolha que mais pesa é a modalidade. Daily entrega um lote por dia, no meio da tarde no fuso da propriedade. Streaming entrega em minutos, sem garantia de completude, sem a origem de tráfego do novo usuário e da nova sessão, a US$ 0,05 por GB. Fresh Daily existe só no Analytics 360, com lotes ao longo do dia, tipicamente em 60 minutos a partir das 5h, e só para propriedades 360 dos tamanhos Normal e Large.

O teto de 1 milhão de eventos por dia na propriedade padrão é a regra que mais derruba exportação em loja grande. Quando o limite é ultrapassado e a exportação pausa, os dias anteriores não são reprocessados: o buraco fica. Uma propriedade que gera 900 mil eventos num dia comum passa de 1 milhão numa promoção, e perde justamente o dia que mais interessava. Nesse caso, ou o evento supérfluo sai da coleta, ou a modalidade vira streaming, que não tem teto de eventos.

A estrutura que chega ao projeto é um dataset chamado analytics_ seguido do id da propriedade. Dentro dele, uma tabela por dia (events_AAAAMMDD) e a tabela intradiária events_intraday_AAAAMMDD, apagada quando a diária fica pronta. Cada linha é um evento. Os parâmetros ficam aninhados numa coluna de pares chave e valor, os itens do e-commerce ficam noutra coluna aninhada, e as propriedades do usuário numa terceira. As tabelas de usuários têm documentação separada.

Atualização é a parte que surpreende quem monta painel sobre a tabela de ontem. A diária recebe eventos tardios por até dois dias-calendário mais hoje, ou até três dias depois da data do evento, dependendo da página de referência; há um sinal de completude do dia anterior. O Measurement Protocol aceita evento com data de até 72 horas atrás, o que explica parte desses ajustes. Um relatório que fecha o dia às 8h da manhã seguinte lê um número que ainda vai mudar.

As diferenças com a interface têm causa conhecida. A interface aplica atribuição orientada por dados (DDA, o modelo que distribui crédito entre canais por aprendizado), modelagem de eventos-chave e modelagem comportamental, agrega o excedente em (other) e pode amostrar explorações. O BigQuery traz o evento bruto, sem essas adições, inclui os pings sem cookie do Consent Mode e por isso pode mostrar mais usuários ativos do que o relatório modelado.

Filtros de dados agem antes da exportação. Desde 21 de setembro de 2026 a propriedade aceita filtro de hostname do tipo Include, uma lista de domínios autorizados, além do filtro de exclusão que já existia. Filtro ativo apaga permanentemente o evento filtrado: ele não aparece nem no BigQuery. O estado de Teste apenas marca os eventos, e é por ele que se começa. A aplicação leva de 24 a 36 horas.

Armadilha comum: abrir a interface e o BigQuery lado a lado, ver 7 por cento a mais de usuários na exportação e passar uma semana procurando o evento duplicado. A diferença vem da modelagem e dos pings sem cookie, e o caminho certo é documentar a causa, não forçar os dois a baterem. O número que a empresa adota como oficial é uma decisão, escrita, com o motivo.

Na Verde Vivo, Marina ligou a exportação em julho, no projeto que o Caio já usava para a loja. A propriedade gerava cerca de 210 mil eventos por dia, longe do teto de 1 milhão, e a modalidade Daily bastou: o streaming custaria pouco, mas a ausência da origem de tráfego na sessão nova tiraria dele justamente a leitura de aquisição. Ela deixou o Streaming desligado e anotou o motivo no documento da propriedade.

Na primeira semana, o BigQuery mostrou 7 por cento mais usuários ativos que a interface, numa semana em que 21 por cento das sessões negaram consentimento. A conta fechou: os pings sem cookie viraram linhas na exportação e, na interface, viraram modelagem. Marina criou uma regra de fechamento: nenhuma tabela do dia é considerada final antes de três dias, e o painel do mês lê a exportação só depois do dia 4.

O que mudou foi o tipo de pergunta que a Verde Vivo consegue fazer. Antes, a análise parava onde a interface parava. Agora existe uma tabela com cada evento, e a única barreira é escrever a consulta certa.

Abra o dataset analytics_ da sua propriedade e conte quantos dias de tabela events_ existem; se a exportação está ligada há mais de três dias e a tabela de anteontem ainda não apareceu, verifique o teto de eventos e o faturamento do projeto antes de qualquer consulta. O próximo capítulo escreve o SQL que transforma essas linhas em resposta.