Analytics de busca para decisão executiva · Capítulo 16 de 19 · 33 min
Aprovar a infraestrutura de dados com teto de custo
Aprove o projeto de dados de busca com teto mensal, regra de expiração e alerta de consumo escritos antes da primeira fatura.
Este capítulo faz parte do curso gratuito Analytics de busca para decisão executiva.
Quem assina o pedido de um projeto de dados de busca costuma receber um número simpático. O time técnico estima algo entre trinta e cem dólares por mês, mostra que existe um nível gratuito e o executivo aprova sem discussão, porque o valor é menor que o café do andar. Seis meses depois a linha na fatura de nuvem já não cabe na rubrica de miudezas, e a explicação chega em vocabulário que ninguém da mesa domina.
A decisão que esse pedido esconde é a de preservação. Exportar dados de busca e de site para armazenamento próprio começa na data em que a exportação é ativada, e nada anterior a essa data entra. Ativar cedo é decisão de negócio, não tarefa técnica: cada mês de atraso é um mês de histórico que a empresa nunca vai ter, mesmo que compre a ferramenta mais cara do mercado depois. O módulo "Ler o Search Console sem cair nos seus limites" tratou do teto de dezesseis meses na interface. A exportação é a única forma de guardar mais tempo, e ela não olha para trás.
O projeto de dados barato do primeiro mês vira a fatura crescente do sexto, e a causa quase sempre é uma configuração que ninguém marcou. O volume de dados raramente explica o salto. O que explica é a ausência de três decisões que cabem numa reunião de vinte minutos: até onde a conta pode crescer, quanto tempo o dado bruto fica guardado e quem valida a consulta antes de alguém decidir com base nela. As três saem daqui prontas para aprovar.
Glossário rápido
Armazém de dados (data warehouse)
Banco onde a empresa junta dados de várias origens para consultar com SQL. No ecossistema Google, é o BigQuery. Você paga por dois eixos separados: o que fica guardado e o que é lido a cada consulta.
Exportação em massa (bulk data export)
Ligação automática que despeja os dados brutos do Search Console dentro do armazém, todo dia. Diferente da API, ela não tem limite de linhas e preserva o histórico por conta da empresa.
Partição
Fatia diária de uma tabela. Consultar uma tabela particionada por data custa menos, porque o sistema lê só os dias pedidos em vez da tabela inteira.
Expiração de partição
Prazo após o qual cada fatia diária é apagada sozinha. O mínimo aceito é de 14 dias. Sem esse prazo configurado, a tabela guarda tudo desde a ativação e a conta de armazenamento sobe todo mês.
TiB (tebibyte)
Unidade de volume processado usada na cobrança de consulta. Um TiB tem cerca de 10% a mais de bytes que um TB decimal, e a diferença aparece na fatura de quem calculou o orçamento com a unidade errada.
Cota por tokens
Orçamento de chamadas de uma API. Cada consulta consome tokens conforme o peso, e não conforme a contagem simples de requisições. Estourar a cota derruba painéis, sem aviso prévio para quem os lê.
Text-to-SQL
Tradução automática de uma pergunta em português para uma consulta SQL. Funciona bem em base pequena e documentada; erra bastante em base corporativa com centenas de colunas.
Correção de um erro que circula em tutorial antigo e apareceu na versão anterior deste curso: a exportação em massa do Search Console não traz dezesseis meses retroativos. Ela começa do zero na data da ativação, e a primeira carga leva até 48 horas para aparecer. Três outros detalhes decidem se o projeto funciona ou trava no primeiro mês. A exportação cria duas tabelas de nomes fixos, searchdata_site_impression e searchdata_url_impression. As consultas anonimizadas ficam de fora, o que significa que a soma da exportação não bate com a soma da interface, e isso não é defeito de configuração. Alterar o esquema das tabelas quebra a exportação, que passa a falhar em silêncio até alguém reparar na lacuna.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
A armadilha de custo mais comum não tem nada de sofisticado. A exportação é gratuita para ligar, e é por isso que quase ninguém pergunta o que acontece depois de ligada. Sem expiração de partição, cada dia exportado se soma ao anterior e nunca sai. No mês um, a tabela tem trinta fatias diárias. No mês doze, tem trezentas e sessenta e cinco, todas cobradas, quase todas nunca consultadas.
O conserto é de dois minutos e vale por anos
- Defina expiração no dado bruto, entre 14 e 90 dias conforme a auditoria que a empresa precisa sustentar.
- Grave o agregado que interessa numa tabela própria, sem expiração, porque agregado ocupa uma fração do bruto.
- Registre quem aprovou cada prazo, para que a decisão sobreviva à troca de fornecedor ou de analista.
A segunda armadilha aparece do outro lado, na exportação do GA4, e é pior porque não custa dinheiro. Ela custa dado.
Em propriedade padrão do GA4, a exportação diária tem teto de 1 milhão de eventos por dia. Estourar o teto uma vez não derruba nada. Estourar de forma consistente pausa a exportação diária, e os dias perdidos não são reprocessados. O buraco fica no histórico para sempre. Sites com pico sazonal, campanha de mídia ou lançamento de produto atravessam esse teto justamente na semana cujo dado vale mais. A exportação por streaming não tem esse limite, mas gera custo proporcional ao volume, o que troca um risco por outro. Quem decide precisa escolher qual dos dois quer.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Onde a conta de nuvem nasce, e o que perguntar em cada linha
| Eixo de cobrança | Como funciona | O que aprovar antes de começar | Onde verificar o valor vigente |
|---|---|---|---|
| Consulta sob demanda | Cobra por volume lido a cada execução, com uma faixa mensal gratuita. Consulta mal escrita lê a tabela inteira e cobra por isso. | Teto mensal com alerta de orçamento e obrigação de filtrar por data em toda consulta agendada | cloud.google.com/bigquery/pricing |
| Armazenamento ativo | Cobra por GB guardado no mês corrente. É o eixo que cresce sozinho quando não há expiração de partição. | Prazo de expiração do dado bruto e tabela separada para o agregado que fica | cloud.google.com/bigquery/pricing |
| Armazenamento de longo prazo | Tabela sem modificação por 90 dias migra para uma faixa mais barata, sem intervenção. Metade do preço do ativo. | Nada a aprovar, mas serve de argumento contra reescrever tabela histórica por hábito | cloud.google.com/bigquery/pricing |
| Consulta a dados fora do Google Cloud | Ler dados hospedados em outra nuvem custa por volume, numa faixa mais cara que a consulta padrão. | Decisão explícita de manter ou mover a origem, com o diferencial de preço declarado no pedido | cloud.google.com/bigquery/pricing |
Regra desta casa: leve para a reunião de aprovação a captura da tabela oficial com a data do acesso, e não o número copiado de um curso.
Fonte: Estrutura de cobrança do Google BigQuery. Os valores por TiB e por GB não são impressos aqui de propósito: preço de nuvem muda sem aviso amplo e material de treinamento envelhece antes da tabela oficial.
Há um terceiro limite que não aparece na fatura e derruba painel
A API de dados do GA4, que alimenta o Data Studio (antigo Looker Studio) e qualquer painel montado por integração, opera por um sistema de tokens. Cada consulta consome tokens conforme o peso, com categorias separadas para relatório padrão, tempo real e funil. Em conta padrão, a Central de Ajuda do Google Analytics descreve até 200.000 tokens por propriedade ao dia e 40.000 por hora, com cotas maiores no GA4 360, e mantém página nativa de histórico de consumo que permite auditar quem gastou o quê antes de culpar o fornecedor do painel (support.google.com/analytics/answer/15560170, consultado em 24/07/2026, sem data de publicação explícita).
Painéis montados entre 2022 e 2024 passaram a falhar com mais frequência desde que a fiscalização da cota ficou mais rígida, relatada a partir de novembro de 2025. A causa costuma ser a mesma em todos: o painel pede dados de trinta dias, quebrados por seis dimensões, atualizando a cada carregamento de página. Cada gestor que abre a aba queima cota do dia inteiro. O conserto é reduzir a granularidade e agendar extrações, o que sai mais barato que migrar de ferramenta.
Quem pode fazer a pergunta também mudou
Perguntar em linguagem natural dentro do próprio armazém deixou de ser promessa. O Google Cloud anunciou em 30 de junho de 2026, no blog oficial (cloud.google.com/blog/products/data-analytics/conversational-analytics-in-bigquery-now-ga), a disponibilidade geral do Conversational Analytics no BigQuery: um agente escreve o SQL a partir da pergunta, roda previsão e detecção de anomalia com funções nativas e mostra as fontes e os passos do raciocínio. A dependência de um analista disponível deixa de ser o gargalo de toda dúvida simples. A ressalva precisa vir junto, e ela é grande.
Gerar SQL com modelo de linguagem: benchmark contra base real
91,2%
acerto em benchmark acadêmico
base pequena, esquema limpo, perguntas conhecidas
21%
acerto em consultas reais de empresa
bases com centenas de colunas, modelo puro sem camada semântica
77,22%
acerto fim a fim em sistema agêntico
com camada semântica dedicada, em 90 casos empresariais
Fonte: arXiv, 2026, Beyond Text-to-SQL: An Agentic LLM System for Governed Enterprise Analytics APIs (arxiv.org/html/2605.21027)
Três checagens de vocabulário antes de aprovar uma proposta técnica. A primeira: a plataforma do Google Cloud para treinar e exportar modelos deixou de se chamar Vertex AI e passou a ser Gemini Enterprise Agent Platform, anunciada em 22 de abril de 2026 no Cloud Next e migrada por completo em 21 de maio de 2026. Os endpoints de API continuaram estáveis, então o custo da mudança é só de vocabulário. Proposta de 2026 que ainda usa o nome antigo foi copiada de material velho, e vale perguntar o que mais veio junto. A segunda: o caminho oficial para enviar eventos de servidor para servidor deixou de ser o Measurement Protocol, que a documentação do Google declara em modo de manutenção desde a última entrada de changelog, em 17 de fevereiro de 2026. O sucessor indicado é a Data Manager API, lançada para eventos de servidor em 07/05/2026 segundo as notas de versão do GA4, o que coloca a migração no planejamento do trimestre. A terceira: se a proposta citar um sistema de geração de SQL com número de acerto espetacular em teste de referência, exija a fonte primária do fabricante. Um sistema divulgado por blogs agregadores em junho de 2026 com 80,04% de acerto não tem confirmação em página oficial do Google, e por isso fica fora deste curso.
Para o time técnico: o que vai no ticket de implantação
Quais tabelas a exportação do Search Console cria e o que fazer com elas
Duas tabelas de nome fixo: searchdata_site_impression, agregada por propriedade, e searchdata_url_impression, quebrada por URL. As consultas anonimizadas ficam fora das duas, então a soma nunca vai bater com a interface do Search Console. Não altere o esquema. Qualquer coluna adicionada ou tipo modificado quebra a exportação, que passa a falhar sem alarme até alguém notar a lacuna nos dados.
Quais papéis a conta de serviço precisa receber
A conta search-console-data-export@system.gserviceaccount.com precisa dos papéis BigQuery Job User e BigQuery Data Editor no projeto de destino. Sem os dois, a configuração é aceita e a exportação nunca roda. A primeira carga leva até 48 horas, então não abra incidente antes desse prazo.
Que política de expiração configurar
O mínimo aceito é de 14 dias. A recomendação prática é expirar o bruto entre 30 e 90 dias, conforme a auditoria que a empresa precisa sustentar, e gravar o agregado diário numa tabela própria sem expiração. O agregado ocupa uma fração do bruto e responde a quase toda pergunta recorrente.
Que limitação existe ao exportar modelo de previsão
Modelos de série temporal do tipo ARIMA_PLUS não podem ser exportados para o Model Registry, ao contrário de regressão, árvores boosted, k-means, PCA e TensorFlow. Quem planejou servir a previsão fora do armazém precisa saber disso antes de escolher o tipo de modelo, e não depois. A documentação do Google registra a restrição em docs.cloud.google.com/bigquery/docs/managing-models-vertex.
Como o GA4 exportado conta sessão
Cada evento é uma linha. Um único carregamento de página pode gerar dezenas de linhas, entre rolagem, clique e engajamento. Contar sessão exige distinguir session_id, e contar visualização exige filtrar o evento page_view. Somar linhas dá um número maior e errado, que costuma aparecer no primeiro painel montado por quem não conhece o esquema.
O projeto de dados está pronto para aprovação
Cinco perguntas que o patrocinador do projeto responde antes de assinar. Cada dimensão vai de 0 (não existe) a 4 (definido, escrito e com dono). Some e leia a faixa. Um projeto abaixo de oito não deveria começar, porque a primeira surpresa vai chegar como fatura, não como aviso.
Existe valor máximo aprovado, alerta de orçamento ativo e uma pessoa que recebe o aviso.
Prazo definido em dias, com o agregado que fica gravado em tabela separada.
Alguém sabe quantos eventos o site gera por dia no pico e o que acontece se passar de 1 milhão.
Toda consulta que vira número de reunião passa por revisão de quem entende do dado.
Uma pessoa responde pelo projeto e olha a fatura numa cadência definida.
O projeto vai crescer sem freio. Antes de qualquer linha de código, fixe teto de custo, prazo de expiração e nome do responsável. As três decisões cabem numa reunião e evitam a conversa desagradável do sexto mês.
Verificação rápida
O time apresenta o pedido: exportação do Search Console e do GA4 ligadas, custo estimado em US$ 40 por mês, começo na semana que vem. Qual pergunta muda o projeto antes de você aprovar?
Guia prático: ligar a exportação em massa e saber quando a API basta. A exportação em massa grava todo dia, no BigQuery, as linhas do relatório de Desempenho sem o teto de mil linhas da tela, exceto as consultas anonimizadas. A API do Search Console é a outra porta: entrega até 25.000 linhas por chamada, com paginação, e serve bem para extrações pontuais ou sites pequenos.
Como escolher entre as duas
| Situação | Exportação em massa | API Search Analytics
| Histórico | Começa no dia da configuração | Até 16 meses para trás
| Volume | Todas as linhas, exceto consultas anonimizadas | As principais linhas, sem garantia de todas
| Custo | Armazenamento e consulta no BigQuery | Gratuita, com cota de uso
| Uso típico | Catálogo grande e série diária | Recorte pontual e sites menores

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Configurar a exportação em massa com teto de custo desde o primeiro dia
Nove passos entre o Google Cloud e o Search Console. Quem executa é o time técnico; quem aprova confere os passos 7 a 9.
Passo 1: No Google Cloud, escolha o projeto com faturamento e ative BigQuery e BigQuery Storage
Em APIs e serviços, APIs e serviços ativados. Sem faturamento, a exportação não roda.
Deu certo quando: As duas APIs aparecem como ativadas no projeto.
Passo 2: Em IAM e administrador, permita acesso à conta de serviço do Search Console
Principal: search-console-data-export@system.gserviceaccount.com. Funções: Usuário de jobs do BigQuery e Editor de dados do BigQuery.
Deu certo quando: A conta aparece na lista de permissões com as duas funções.
Erro comum: Dar só uma das funções. A configuração é aceita e a exportação nunca grava.
Passo 3: No Search Console, abra Configurações, Exportação de dados em massa
Cole o ID do projeto, e não o número do projeto. Os dois aparecem na página de configurações do Google Cloud.
Deu certo quando: O formulário aceita o ID sem mensagem de erro.
Erro comum: Colar o número do projeto, que tem só dígitos.
Passo 4: Defina o nome do conjunto de dados e o local
O padrão é searchconsole. Com várias propriedades no mesmo projeto, cada uma precisa de um nome próprio, sempre começando por searchconsole.
Deu certo quando: O nome segue o padrão da casa, por exemplo searchconsole_loja.
Erro comum: Escolher o local sem pensar. Ele não muda com facilidade depois da primeira exportação.
Passo 5: Clique em Continuar e espere até 48 horas pela primeira carga
A carga traz os dados do dia da exportação em diante. Não há histórico anterior.
Deu certo quando: Aparecem as tabelas searchdata_site_impression e searchdata_url_impression.
Erro comum: Abrir incidente no primeiro dia. Se houver erro, o Search Console tenta de novo no dia seguinte.
Passo 6: Não altere o esquema das tabelas
A documentação avisa que mudança de esquema, como acrescentar coluna, faz a exportação falhar.
Deu certo quando: Quem precisa de coluna nova cria uma visão em cima da tabela.
Passo 7: Defina a validade das partições no mesmo dia
Catorze dias ou mais, conforme a política de retenção aprovada. Sem isso, a tabela cresce para sempre.
Deu certo quando: A tabela mostra o prazo de validade de partição configurado.
Erro comum: Deixar para depois e descobrir o custo de armazenamento só na fatura de seis meses.
Passo 8: Crie alerta de orçamento no projeto
Em Faturamento, Orçamentos e alertas, com aviso em 50%, 90% e 100% do teto mensal aprovado.
Deu certo quando: O responsável recebe o e-mail de teste do alerta.
Passo 9: Escreva toda consulta com filtro de data
As tabelas são particionadas por data_date. Consulta sem filtro de data lê a tabela inteira e paga por isso.
Deu certo quando: A estimativa de bytes processados, antes de rodar, cai para uma fração do tamanho da tabela.
No fim você tem: Exportação diária ativa, partições com validade, alerta de orçamento e uma regra simples para quem escreve consulta: sempre com data.
-- Cliques, impressões e posição média por página nos últimos 28 dias,
-- só busca na Web, lendo apenas as partições do período.
SELECT
url,
SUM(clicks) AS cliques,
SUM(impressions) AS impressoes,
SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
SAFE_DIVIDE(SUM(sum_position), SUM(impressions)) + 1 AS posicao_media
FROM `seu_projeto.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
AND DATE_SUB(CURRENT_DATE(), INTERVAL 3 DAY)
AND search_type = 'WEB'
GROUP BY url
ORDER BY cliques DESC
LIMIT 500;Duas regras da API que evitam número errado
A página de referência da consulta Search Analytics, atualizada em 11/08/2026, diz que o limite por chamada vai de 1 a 25.000 linhas, com 1.000 como padrão, e que a API devolve as principais linhas, sem garantia de todas. Para passar de 25.000, pagine com startRow. O parâmetro dataState aceita final, só dados consolidados, all, que inclui dados recentes, e hourly_all, para quebra por hora. O relatório de IA Generativa não sai pela API; ele continua em exportação manual pela tela.
Antes de assinar o próximo projeto de dados, exija por escrito o teto mensal, a regra de expiração das tabelas e o alerta de orçamento configurado. Confira na primeira fatura se o gasto ficou abaixo do teto e se o alerta disparou para alguém com nome, e não para uma caixa de e-mail coletiva.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- Cobre no relatório os números certos e ignore o restosugerido pelo grafoApresenta o conceito “BigQuery”, usado em “Aprovar a infraestrutura de dados com teto de custo”.
- Desenhar o plano de mensuração que vai do lead à receitasugerido pelo grafoApresenta o conceito “SQL”, usado em “Aprovar a infraestrutura de dados com teto de custo”.
- Descubra como a IA escolhe quem citarsugerido pelo grafoApresenta o conceito “LLM”, usado em “Aprovar a infraestrutura de dados com teto de custo”.
- CursoPython: Programação do Zerosugerido pelo grafo9 capítulos de “Analytics de busca para decisão executiva” usam conceitos apresentados em “Python: Programação do Zero”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- SEO ProgramáticoMedir a cauda do acervo com Search Console e BigQueryExaminar conexões de Medir a cauda do acervo com Search Console e BigQuery
- Google Analytics 2027Ligar a exportação para o BigQuery e entender o que ela não reproduzExaminar conexões de Ligar a exportação para o BigQuery e entender o que ela não reproduz
- Search Console para decisãoDeclare o que o dado esconde antes que alguém chame de erroExaminar conexões de Declare o que o dado esconde antes que alguém chame de erro
- Gestão de Projetos GEOGarantir acesso aos dados ao trocar de fornecedorExaminar conexões de Garantir acesso aos dados ao trocar de fornecedor
Voltar ao capítulo anterior: Priorizar onde colocar o próximo real
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.
Capítulos vizinhos em Analytics de busca para decisão executiva
- 14Calcular o custo de aquisição sem inflar o orgânico
- 15Priorizar onde colocar o próximo real
- 16Aprovar a infraestrutura de dados com teto de custo
- 17Escolher e negociar ferramentas sem ser pautado pelo fornecedor
- 18Definir quem vê o quê e quem responde pelo número