Quando o BigQuery é necessário: o que o GA4 apaga, e quem vai sentir falta

A pergunta chega medida em volume, e o volume não decide sozinho.

A frase costuma vir pronta. Com esse volume de acesso, você já precisa do BigQuery. Ou: a empresa cresceu, está na hora de tirar o dado do Google Analytics. Quem diz isso pode estar certo, e o problema é que você não tem como conferir. Ninguém te entregou nada para abrir e olhar.

Repare no que a justificativa faz. Ela mede uma coisa que você não controla, o tamanho, e conclui sobre uma coisa que você paga, a ferramenta. Entre as duas não existe nenhuma etapa em que você possa dizer sim ou não com base no que vê.

O enquadramento é herdado, não inventado por quem repete. Procurei o que está publicado em português sobre a decisão e o eixo é sempre o porte: de um lado empresas pequenas ou em estágio inicial, que ficam no Google Analytics; do outro negócios que precisam analisar milhões de interações, que vão para o BigQuery. É uma escada, e a escada tem um degrau só, que aparece quando você fica grande o bastante.

Encontrei um único material que publica critério de verdade, em forma de três perguntas: você precisa de histórico além de catorze meses, os seus relatórios mostram alerta de amostragem com frequência, você precisa cruzar dados de anúncios com margem real do sistema de vendas. São boas perguntas. Só que em nenhuma das três a resposta possível é não precisa, e nenhum dos textos que eu li diz quando o BigQuery é desnecessário. A lista existe para confirmar, não para separar.

O que segue faz o contrário. É um critério que pode devolver não, e ele parte de três coisas que a sua conta já está te mostrando. Não é tutorial: não tem código, não tem tela de configuração e não ensina a ligar nada. A pergunta aqui é anterior, e é se vale ligar.

Três coisas que o GA4 faz com o seu dado, e onde cada uma aparece na tela.

O GA4 não guarda tudo para sempre, não lê tudo em toda consulta e não separa tudo linha a linha. As três coisas são conhecidas, estão documentadas e cada uma deixa um rastro visível. Abaixo, o que cada uma faz, onde você confere e o que a resposta indica. Os valores citados foram verificados na documentação oficial do Google em 4 de agosto de 2026, e são configurações e cotas de plataforma: eles podem mudar, e o que não muda é onde olhar.

O que ele apaga: a retenção. O GA4 tem uma configuração que define por quanto tempo ele mantém o dado ligado a usuário e a evento antes de apagar automaticamente. Em propriedade padrão as opções são dois meses ou catorze meses, e a exclusão acontece de forma automática, uma vez por mês. Onde conferir: na área de administração da propriedade, nas configurações de dados. O nome exato do menu já mudou algumas vezes; o que você procura é a linha que diz retenção. Se estiver em dois meses, essa é a primeira coisa a resolver, e ela é de graça: mudar para catorze não custa nada e não depende de mim nem de ninguém.

O que essa configuração não atinge, e quase ninguém escreve: a documentação diz explicitamente que a retenção não afeta os relatórios agregados padrão, incluindo dimensões primárias e secundárias. Ou seja, a série histórica de sessões, usuários e eventos por mês continua lá. O que a retenção limita é a análise em nível de usuário e de evento, que é onde vivem as Explorações. É uma diferença grande na prática: o histórico que some não é o do gráfico da tela inicial, é o da pergunta específica que você vai querer fazer daqui a um ano.

O que ele aproxima: a amostragem. Quando uma consulta precisa de mais eventos do que a cota da propriedade permite, o GA4 responde com base em parte dos dados em vez de todos. Em propriedade padrão essa cota é de dez milhões de eventos por consulta. Onde conferir: abra uma Exploração com o período mais longo que você costuma usar e olhe o ícone de qualidade do dado, no topo. Quando há amostragem, ele informa o percentual de dados usado para produzir aquele resultado. Se você nunca viu esse aviso, a amostragem não é o seu problema, e ela não pode ser o motivo da sua decisão.

O que ele agrupa: a linha "(other)". Toda tabela do GA4 tem um limite de linhas. Quando os valores distintos de uma dimensão passam desse limite, a plataforma ordena do mais frequente para o menos e junta a cauda numa linha chamada "(other)". Onde conferir: procure por ela nos seus relatórios, principalmente nos que usam dimensão secundária, filtro ou comparação. A documentação registra que um relatório padrão com uma dimensão só raramente é afetado, e que esses três recursos aumentam bastante a chance. Ela também orienta tratar como dimensão de alta cardinalidade qualquer uma com mais de quinhentos valores, e diz na mesma frase que quinhentos é orientação e não limite.

Três sinais, três verificações, nenhuma delas exigindo acesso técnico ou ajuda de fornecedor. Se os três vierem limpos, guarde isso: é a metade do critério.

O critério é a perda: o que some, quando some, e quem vai precisar depois.

A pergunta quanto dado eu tenho não tem resposta útil, porque não existe número a partir do qual a conta muda. Os três sinais da seção anterior têm limiares diferentes, medem coisas diferentes e aparecem em momentos diferentes. Volume não é um eixo, são três, e eles não se movem juntos.

A pergunta que funciona tem três partes, nessa ordem. O que vai sumir. Alguma informação que hoje existe vai deixar de existir, ou vai deixar de ser separável. Nomeie qual: o comportamento por usuário além do prazo de retenção, o detalhe que está caindo dentro do "(other)", o número exato que a amostragem está aproximando.

Quando vai sumir. Essa é a parte que muda a decisão e é a que ninguém faz. Retenção é um prazo: se a sua propriedade está em catorze meses, você sabe a data em que o dado de hoje deixa de estar disponível para análise em nível de usuário. Se você começou a medir direito em março, o março deste ano sai do alcance em maio do ano que vem. Isso é uma data no calendário, não uma sensação de urgência.

Quem vai precisar. A pergunta final não é técnica. Existe alguém que, numa data que você consegue nomear, vai fazer uma pergunta que só esse dado responde? Comparar dois anos de comportamento de quem comprou. Entender a jornada de quem virou cliente seis meses depois da primeira visita. Cruzar o que aconteceu no site com a margem que aquela venda deu. Se você não consegue formular a pergunta, ainda não há perda: há um dado que vai sumir e ninguém iria procurar.

É isso que substitui o eixo de tamanho. Uma empresa pequena com um ciclo de venda de oito meses tem perda datada e real. Uma empresa grande que decide tudo com o relatório de aquisição do mês pode não ter nenhuma. O tamanho não sabe disso, e o calendário sabe.

Cinco motivos chegam embrulhados no mesmo pedido, e três já têm dono.

Quando alguém pede BigQuery, quase sempre está pedindo cinco coisas ao mesmo tempo sem separá-las. Elas têm remédios diferentes, e três delas não são resolvidas por ele.

Preservar histórico. Este é o motivo genuíno, e é o único em que a exportação faz exatamente o que se espera dela: o evento sai do GA4, vai para outro lugar e fica lá pelo tempo que você quiser. O contorno: confira antes se a perda é mesmo a sua. Se a pergunta que você quer fazer daqui a dois anos cabe nos relatórios agregados padrão, a retenção não vai apagá-la, e não há o que preservar.

Unir fontes. Este já tem dono, e o dono não é o BigQuery. Combinar o dado do site com vendas, financeiro, estoque e cadastro é o que uma estrutura de painel faz, e ela lê o GA4 direto, sem intermediário. O que muda no acompanhamento quando as fontes passam a conversar dentro de um modelo só. O contorno: o BigQuery entra quando o volume ou o preparo que essa união exige não cabe no modelo do painel, e isso é uma constatação de quem já tentou montar, não uma previsão de quem ainda vai.

Transformar o dado. Reclassificar, corrigir categorias, criar um cálculo que a ferramenta não tem. Quase sempre isso pertence ao modelo do painel, que é onde as regras de negócio moram. Quando a transformação precisa acontecer antes, sobre um volume grande de evento bruto, aí é assunto de banco. O contorno: se a regra ainda está em discussão entre as áreas, nenhum lugar resolve. Uma definição que ninguém acordou vira uma versão diferente em cada ferramenta.

Automatizar a análise. Fazer a mesma leitura toda semana sem alguém repetir o trabalho é agendamento e atualização, e não depende de o dado estar no BigQuery. O contorno: se o que trava é reunir a informação antes de analisar, o problema é o anterior, não este.

Querer aprender. Existe o caso em que tudo funciona, nada se perde, ninguém tem pergunta sem resposta, e alguém quer o BigQuery mesmo assim. É legítimo e vale a pena: entender como o dado bruto é estruturado muda a forma de olhar qualquer relatório. Só não é projeto, não é urgência e não deve ser vendido como necessidade. O caminho para isso é a próxima seção, e ele é barato.

A rota barata tem teto, e ele aparece justamente onde o volume é grande.

A exportação do GA4 para o BigQuery não é uma coisa só. São duas rotas, com comportamentos e custos diferentes, e a diferença entre elas quase nunca aparece nos textos que recomendam a ligação.

A exportação diária envia, uma vez por dia, os eventos do dia anterior. É a rota padrão e é a que quase todo mundo quer. Em propriedade padrão, ela tem um teto de um milhão de eventos por dia. A documentação diz o que acontece quando esse teto é ultrapassado de forma consistente: a exportação diária é pausada, e os dias anteriores não são reprocessados. Editores e administradores da propriedade recebem aviso por e-mail cada vez que o limite é excedido. Existem filtros para reduzir o que sai e continuar abaixo do teto.

Leia essa frase de novo com o argumento de venda ao lado. O BigQuery é apresentado como a resposta para quem tem muito dado, e a rota gratuita dele para de funcionar exatamente quando o dado passa de um certo ponto, sem recuperar o que ficou para trás. Isso não desaconselha ligar. Desaconselha ligar por causa do volume, sem saber por qual rota, e é o quarto sinal que você pode conferir: se você já exporta, o aviso chega no e-mail de quem administra a propriedade; se ainda não exporta, o número de eventos por dia está no seu próprio relatório.

A exportação em streaming envia os eventos do dia corrente em poucos minutos e não tem limite de eventos. Em compensação, ela é cobrada por volume de dado transferido. É a rota de quem precisa de leitura no mesmo dia, e é uma escolha de operação, não um brinde que vem junto.

Sobre o custo, o que dá para dizer com honestidade é por onde ele entra, e não quanto vai dar. Ele entra em três lugares: o armazenamento do que fica guardado, o processamento de cada consulta que alguém roda, e o volume transferido se a rota for a de streaming. O ponto que costuma surpreender é o segundo. Quem consulta paga, e um painel que atualiza sozinho todo dia é alguém consultando todo dia. A documentação do Looker Studio diz isso sem rodeio: o BigQuery é um produto pago e o acesso a ele exige uma conta de faturamento.

Existe um caminho sem cartão de crédito, o modo de avaliação do BigQuery, com uma faixa de uso gratuita de armazenamento e de consulta por mês. Ele serve para aprender, e é o que eu recomendo para o quinto motivo da seção anterior. Só que ele tem uma regra que precisa ser dita junto: tudo o que você criar ali expira automaticamente em sessenta dias. Tabelas, visualizações, partições. O caminho gratuito é justamente o único que não cumpre o motivo mais citado para adotar, que é preservar histórico.

Falta a parte que nenhuma fonte comercial que eu li menciona: alguém mantém isso depois. A tabela de um dia continua sendo atualizada por até três dias após a data dos eventos, então o dado de ontem ainda não é definitivo e qualquer leitura construída em cima precisa saber disso. A conexão com o Power BI existe e é oficial, com importação e consulta direta, e a Microsoft publica em português a lista de limitações conhecidas dela, incluindo uma troca de driver em andamento. Nada disso é impeditivo. É trabalho recorrente, e ele entra na conta antes da assinatura, não depois.

Exportar não conserta. O que sai é o dado coletado, sem o resto.

Este é o mal-entendido mais caro do assunto, e ele é fácil de desfazer porque a resposta está publicada pelo próprio Google. O argumento que circula diz que a interface esconde e a exportação revela, e que o dado bruto é o dado verdadeiro. A documentação diz outra coisa.

Antes de o dado chegar aos relatórios, o Google Analytics acrescenta processamento a ele. Modelagem, atribuição de tráfego, sinais de identificação de usuário, previsão. A exportação para o BigQuery trabalha com o dado coletado, o que foi enviado do navegador ou do aplicativo, e não contém a maior parte dessas adições. Não é uma versão mais limpa do mesmo número. É outra camada, anterior.

A consequência prática aparece no primeiro dia. Os números do BigQuery vão divergir dos da interface, por desenho, e a divergência não é erro de ninguém. Quem liga esperando finalmente ver o número certo ganha um segundo número para conciliar, e agora tem duas fontes para explicar em reunião em vez de uma.

Isso leva ao caso em que ligar piora a situação. Se o que te incomoda hoje é que o número não bate, exportar não resolve: a coleta continua a mesma, e o que sai é o mesmo problema com mais detalhe e mais lugares para procurá-lo. A ordem correta é diagnosticar antes, e existe uma pergunta anterior que separa erro de configuração de diferença que nunca foi para bater. Como saber se a sua coleta está de pé, antes de exportar qualquer coisa.

Vale desfazer uma confusão entre as duas leituras, porque o mesmo elemento da tela aparece nas duas. O ícone de qualidade do dado sinaliza mais de uma coisa. Quando há estimativa de comportamento de quem recusou cookies, ele avisa que existe estimativa ali e não informa quanto do número é estimado. Quando há amostragem, ele informa o percentual de dados usado para produzir o resultado. As duas leituras estão corretas, são situações distintas, e é o texto ao lado do ícone que diz qual delas é a sua.

O resumo é curto. O BigQuery preserva e disponibiliza o que foi coletado. Ele não melhora a coleta, não decide nada por ninguém, não substitui o painel nem a leitura, e guardar mais dado não é o mesmo que decidir melhor.

Quatro respostas possíveis, e o que fazer com cada uma delas.

Junte o que você conferiu: a configuração de retenção, o ícone de qualidade do dado, a linha "(other)", o volume diário de eventos e a pergunta que alguém vai fazer no futuro. O cruzamento dessas cinco observações cai em um de quatro lugares.

Não precisa. Nenhum dos três sinais aparece, e você não consegue formular a pergunta futura que só o dado bruto responderia. Isso não é um estágio anterior de nada: é a situação em que o GA4 padrão está entregando o que se espera dele. O que fazer agora: confira se a retenção está em catorze meses e siga. Revisite quando alguma coisa mudar de verdade, não pelo calendário.

Pode precisar, e a data é esta. A perda existe e ainda não aconteceu. Você consegue nomear a pergunta e consegue nomear o mês em que o dado necessário sai do alcance. Este é o resultado mais valioso dos quatro, porque ele separa preservar de construir. O que fazer agora: garantir que o dado passe a ser guardado antes daquela data. Não é preciso ter o painel pronto, nem a análise desenhada, nem saber consultar. Guardar vem primeiro, e o resto pode esperar o problema aparecer.

Já precisa. A perda já aconteceu, ou a pergunta já não tem resposta possível com o que está disponível. Alguém já procurou um dado e ele não estava lá. O que fazer agora: além de ligar a exportação, decidir a rota, quem mantém, e o que vai ler o que for guardado. Ligar sem responder essas três coisas produz um depósito de eventos que ninguém abre, com custo de armazenamento rodando.

Ainda falta diagnosticar. Você desconfia do que o GA4 mostra, ou não sabe dizer se a coleta está registrando o que importa. Aqui a resposta não é BigQuery em nenhuma versão, porque a exportação carrega o defeito adiante. O que fazer agora: resolver a coleta primeiro. É a única das quatro em que agir sobre o BigQuery agora deixa você em situação pior do que ficar parado.

Falta dizer o que eu ganho em cada uma. Duas terminam em trabalho meu: quem já precisa contrata a exportação e o que vem depois dela, quem precisa diagnosticar contrata a revisão da medição. As outras duas não geram projeto nenhum. Repare na ordem em que as quatro aparecem acima: a que não me dá nada vem primeiro, e isso não é acaso de redação. O que fica configurado numa implementação de GA4, quais acessos são necessários e em que condições a ligação com o BigQuery entra no escopo.

Onde isto para de valer. As cinco observações indicam uma direção, não fecham um diagnóstico: elas dizem onde olhar com força suficiente para você defender ou revisar a hipótese em voz alta antes de gastar. Não estimam custo, esforço nem prazo. E não dispensam olhar a propriedade por dentro, que é onde a configuração real aparece. Elas também dependem de a plataforma continuar se comportando como está documentado hoje: cotas, prazos e limites são do Google e mudam sem me consultar. Se você ler isto daqui a um ano, os lugares de conferir continuam os mesmos, e os números merecem uma segunda olhada na fonte.