Exportação do BigQuery do GSC

TL;DR — A exportação do GSC para BigQuery (o Google chama de exportação de dados em massa) copia automaticamente seus dados do Search Console para um banco de dados do Google Cloud chamado BigQuery, uma vez por dia, sem limite de linhas. É assim que você obtém muito mais dos seus dados de cliques e impressões do que a visão reduzida que a interface do Search Console mostra — embora consultas anonimizadas (ocultas) permaneçam ocultas aqui também. Dois detalhes para saber de antemão: ele não puxa seus dados antigos (apenas dados a partir do dia em que você o ativa, daí em diante), e exige uma conta de faturamento do Google Cloud, mesmo havendo um nível gratuito de uso.

O que é

A exportação de dados em massa do Search Console pode enviar dados diários de desempenho para o BigQuery. Evidence for this claim Search Console bulk data export sends daily performance data to BigQuery in a configured Google Cloud project. Scope: Search Console bulk export; setup, permissions, quotas, and supported properties follow Google's current documentation. Confidence: high · Verified: 2026-07-14 Google: Bulk data export O Google documenta tabelas separadas de impressões por site, impressões por URL e log de exportação, com limites de esquema e agregação que importam durante a análise. Evidence for this claim Bulk export uses site-impression, URL-impression, and export-log tables with documented schemas. Scope: Google's published Search Console export schema; aggregation and privacy handling still affect analysis. Confidence: high · Verified: 2026-07-14 Google: Bulk export tables

Este guia cobre propriedades de site. As propriedades mais recentes de plataforma do Search Console para Instagram, TikTok, X e YouTube têm relatórios de Desempenho, Insights e Conquistas, mas a documentação atual do Google para propriedades de plataforma não documenta uma configuração ou esquema de exportação em massa para BigQuery para elas. Trate as propriedades de plataforma como não suportadas aqui, a menos que o Google exponha a configuração e documente o contrato. O LinkedIn não é atualmente uma propriedade de plataforma suportada.

Abra o relatório de Desempenho no Google Search Console e tente exportá-lo. Você vai bater em uma parede rapidinho: a interface limita a maioria das exportações a cerca de 1 000 linhas, e ela só mostra aproximadamente os últimos 16 meses de histórico. Para um site pequeno, isso é suficiente. Para um site grande com dezenas de milhares de páginas e uma enorme variedade de consultas de pesquisa, você está vendo uma fatia minúscula dos seus dados reais.

A exportação de dados em massa resolve isso. É um interruptor dentro do Search Console que diz: “de agora em diante, envie meus dados de Desempenho para o BigQuery todos os dias.” O BigQuery é o armazém de dados do Google — um lugar para armazenar tabelas grandes e executar consultas nelas. Quando a exportação está em execução, você obtém dados diários não amostrados, sem o limite de 1 000 linhas, mantidos pelo tempo que você quiser — com uma exceção permanente: consultas anonimizadas (aquelas que o Search Console oculta por privacidade) ainda aparecem em branco, assim como na interface. “Sem limite de linhas” não é o mesmo que “todas as consultas reveladas.”

Por que alguém se importa

Você configuraria isso se quiser:

• Analisar muito mais consultas e páginas do que a interface ou o botão de exportação oferecem.
• Manter seu histórico do Search Console por mais de 16 meses (o Search Console descarta os dados antigos; o BigQuery mantém o que você mantiver).
• Combinar seus dados do Search Console com outros dados — seus dados do Google Analytics, um rastreamento, seu banco de produtos — tudo em um só lugar.

As duas coisas para saber antes de começar

1. Ele não faz backfill. Este é o único motivo de surpresa mais comum. Ativar a exportação não vai buscar seus dados históricos. Ele começa a coletar a partir desse dia em diante. Se você quiser histórico, precisa ativá-lo e depois esperar que ele acumule.
2. É “grátis” com um asterisco. O BigQuery tem um nível gratuito, e a maioria dos sites pequenos e médios permanece dentro dele. Mas você ainda precisa anexar uma conta de faturamento do Google Cloud, e se você consultar os dados descuidadamente — especialmente apontando um painel ao vivo para as tabelas brutas — pode gerar uma conta real.

Vale a pena para você?

Sinceramente, a maioria dos sites não precisa disso. Se a interface do Search Console e o conector integrado do Looker Studio para Search Console mostram o suficiente, você está pronto — pule a configuração. Você recorre à exportação do BigQuery quando está batendo consistentemente nesse limite de 1 000 linhas, quando precisa de mais de 16 meses de histórico, ou quando quer seus dados do Search Console ao lado de outros dados em um armazém. Se esse é o seu caso, mude para a aba Avançado para a configuração completa, os custos envolvidos e as primeiras consultas a executar.

TL;DR — A exportação de dados em massa é um despejo diário, sem amostragem e agendado dos seus dados de desempenho do Search Console em um conjunto de dados do BigQuery — sem o limite de exportação de ~1 000 linhas, sem a barreira de retenção de ~16 meses. Ela gera três tabelas (searchdata_site_impression, searchdata_url_impression, ExportLog). Configuração: um projeto do Google Cloud com cobrança ativada, as APIs do BigQuery + BigQuery Storage ativadas, duas funções de IAM concedidas à conta de serviço de exportação do Google e, em seguida, Configurações → Exportação de dados em massa no GSC. Ela não faz backfill, ainda relata consultas anonimizadas como strings vazias, e a primeira exportação chega em ~48 horas. O custo é um nível gratuito real mais cobranças por consulta por TB — a conta clássica vem de dashboards consultando tabelas brutas ao vivo. Pense nisso como o terceiro degrau: interface → API → exportação em massa.

A escada abaixo é para propriedades de site. Não é evidência de que propriedades de plataformas sociais ou de vídeo suportam a API do Search Console ou a exportação do BigQuery.

O que realmente é

A exportação em massa é um pipeline agendado de dados do Search Console para um projeto do Google Cloud, não uma fonte independente de dados de ranqueamento. Evidence for this claim Search Console bulk data export sends daily performance data to BigQuery in a configured Google Cloud project. Scope: Search Console bulk export; setup, permissions, quotas, and supported properties follow Google's current documentation. Confidence: high · Verified: 2026-07-14 Google: Bulk data export As consultas devem respeitar as tabelas, chaves e o comportamento de privacidade/agregação documentados. Evidence for this claim Bulk export uses site-impression, URL-impression, and export-log tables with documented schemas. Scope: Google's published Search Console export schema; aggregation and privacy handling still affect analysis. Confidence: high · Verified: 2026-07-14 Google: Bulk export tables

Daniel Waisberg, um Search Advocate do Google, descreve isso claramente: “A bulk data export is a scheduled daily export of your Search Console performance data. It includes all the data used by Search Console to generate performance reports. Data is exported to Google BigQuery, where you can run SQL queries for advanced data analysis or even export it to another system.” (tradução) «Uma exportação de dados em massa é uma exportação diária agendada dos seus dados de desempenho do Search Console. Ela inclui todos os dados usados pelo Search Console para gerar relatórios de desempenho. Os dados são exportados para o Google BigQuery, onde você pode executar consultas SQL para análise avançada de dados ou até mesmo exportá-los para outro sistema.» (citado no Search Engine Journal).

O ponto é a escala. A interface do Search Console limita a maioria das exportações a cerca de 1 000 linhas e mostra uma janela móvel de ~16 meses. A API do Search Console oferece mais, mas ainda é limitada e com restrição de taxa. A exportação em massa remove o teto de linhas completamente e permite que você decida por quanto tempo reter. A própria linha do Google no anúncio, como reproduzida pelo Search Engine Land: “The daily data row limit does not impact this data, so you can extract more data using this method,” e o recurso “could be particularly helpful for large websites with tens of thousands of pages.” (tradução) «O limite diário de linhas de dados não afeta esses dados, então você pode extrair mais dados usando este método», e o recurso «pode ser particularmente útil para sites grandes com dezenas de milhares de páginas».

Quais dados você obtém: as três tabelas

Tudo chega em um conjunto de dados cujo nome sempre começa com searchconsole. Três objetos aparecem (Diretrizes e referência de tabelas):

1. searchdata_site_impression — “Contains performance data for your property aggregated by property.” (tradução) «Contém dados de desempenho da sua propriedade agregados por propriedade.» Campos-chave: data_date (“The day on which the data in this row was generated (Pacific Time)” (tradução) «O dia em que os dados nesta linha foram gerados (Horário do Pacífico)»), site_url (propriedades de domínio usam o prefixo sc-domain:), query, is_anonymized_query, country (ISO-3166-1 Alpha-3), search_type (web/imagem/vídeo/notícias/discover/googleNews), device, impressions, clicks e sum_top_position.
2. searchdata_url_impression — “Contains performance data for your property aggregated by URL.” (tradução) «Contém dados de desempenho da sua propriedade agregados por URL.» Tudo acima, mais url (“The fully-qualified URL where the user eventually lands when they click the search result” (tradução) «A URL totalmente qualificada onde o usuário finalmente chega ao clicar no resultado da pesquisa»), is_anonymized_discover, uma família de flags booleanas is_[search_appearance_type] (por exemplo, is_amp_top_stories, is_job_listing, is_tpf_faq) para que você possa filtrar por tipo de resultado avançado, e sum_position. Esta é a tabela granular na qual a maioria das análises é executada.
3. ExportLog — “A record of what data was saved for that day. Failed exports are not recorded here.” (tradução) «Um registro de quais dados foram salvos naquele dia. Exportações com falha não são registradas aqui.» Campos incluem agenda (atualmente apenas SEARCHDATA), namespace (qual tabela foi gravada), data_date, epoch_version (“An integer, where 0 is the first time data was saved to this table” (tradução) «Um inteiro, onde 0 é a primeira vez que os dados foram salvos nesta tabela» — ele incrementa quando o Google revisa posteriormente os dados de um dia) e publish_time.

The anonymized-query caveat is the important one. Even here, at the raw level, anonymized queries are not revealed. As Google’s field description puts it, when is_anonymized_query is true the query field “will be a zero-length string.” Their metrics are still aggregated into your totals, but they’re never attributable to a specific term — exactly the same limitation the UI and the API have. This is a big deal at scale: in my Ahrefs study of GSC’s hidden terms, across 146 741 websites and roughly 9 billion clicks, 46,08% of all clicks went to queries Google doesn’t disclose — and that study used the Search Console API, which “allows us to get all of the data—and there’s still a lot missing.” The BigQuery export doesn’t recover any of it. If someone tells you bulk export “finally shows you the hidden queries,” they’re wrong.

Como configurar

O fluxo (Iniciar uma nova exportação de dados em massa):

1. Crie ou escolha um projeto do Google Cloud com cobrança ativada. Segundo o Google: “Os dados estão sujeitos aos custos de armazenamento e consulta do Google Cloud, mas há um nível de uso gratuito.” Você precisa de cobrança ativada mesmo para permanecer no nível gratuito.
2. Ative a API BigQuery e a API de armazenamento do BigQuery nesse projeto.
3. Conceda acesso à conta de serviço de exportação do Google. Adicione search-console-data-export@system.gserviceaccount.com como principal com dois papéis do IAM: BigQuery Job User (bigquery.jobUser) e BigQuery Data Editor (bigquery.dataEditor).
4. No Search Console, vá em Configurações → Exportação de dados em massa. Cole o ID do projeto do Cloud (o ID, não o número do projeto), escolha um nome de conjunto de dados e escolha um local do conjunto de dados. Observe a regra de nomenclatura: “O nome do conjunto de dados sempre começa com a string searchconsole, mesmo quando você o personaliza.” Se você definir uma política de expiração de partição no próprio conjunto de dados da exportação, mantenha-a em 14 dias ou mais — o Google documenta um mínimo de 14 dias, e definir um período menor é uma causa de falha documentada. Deixe o esquema de tabela gerado intacto também; alterá-lo é a outra forma documentada de quebrar a exportação (mais em Solução de problemas abaixo).
5. Aguarde. O Google diz que o processo de exportação em si deve começar em cerca de um dia após a ativação. “A primeira exportação ocorrerá até 48 horas após sua configuração bem-sucedida no Search Console,” e essa primeira entrega contém apenas os dados do dia da exportação — nada de antes da configuração (veja a seção sobre ausência de backfill a seguir). Depois disso, ela é executada diariamente até você interrompê-la.

Uma expectativa prática a definir: os dados do Search Console chegam com um atraso de dois dias, portanto o dia mais recente que você terá é de dois dias atrás. Peça um intervalo de 30 dias e você efetivamente terá cerca de 28 dias de dados utilizáveis.

A pegadinha da ausência de backfill

Diga em voz alta, porque isso pega as pessoas: ativar a exportação não puxa seus dados históricos. Ela começa no dia da ativação e só acumula para frente. Isso é comum o suficiente para o fórum da comunidade do Google ter vários tópicos sobre isso — “Como fazer backfill com dados históricos quando a exportação de dados em massa é ativada” (tópico 300051568), tópico 255704574 e tópico 429248330. Antoine Eripret coloca isso de forma direta em seu mergulho profundo de praticante: “Você não pode obter dados históricos: se você ativar hoje, terá dados a partir de hoje.” A conclusão é simples — ative no dia em que ouvir falar pela primeira vez, mesmo que você ainda não esteja pronto para analisar nada, para que o relógio comece.

Quanto custa e como não ser surpreendido

A publicação do Google Cloud Blog de Daniel Waisberg e Gaal Yahas vende o lado positivo — “If you have a large website, this solution will provide more queries and pages than the other data exporting solutions” e “Search Console stores up to sixteen months of data; using BigQuery you can store as much data as it makes sense to your organization” — mas a mecânica de custo fica por sua conta.

No momento em que este texto foi escrito, o nível gratuito do BigQuery é de aproximadamente 10 GiB de armazenamento grátis, mais 1 TiB (~1 TB) de processamento de consultas sob demanda grátis por mês; além disso, custa cerca de US$ 6,25 USD por TiB processado e aproximadamente US$ 0,02 USD por GB armazenado por mês (varia conforme a região e a classe de armazenamento). Os preços mudam, então verifique os valores atuais antes de citá-los para alguém. A maioria dos sites pequenos e médios permanece gratuita ou quase gratuita.

As cobranças vêm de como você consulta, não de quanto tráfego você tem. Duas coisas importam:

• O custo aumenta com a diversidade de consultas/palavras-chave, não com o tráfego bruto. Como Trevor Fox diz em seu guia completo: “The volume of data that is more a factor of keyword variety than it is search volume. A site with a low search volume for lots of keywords will generate more data than a site with lots of search volume for a single keyword.”
• Não aponte um painel ao vivo para as tabelas brutas. Esta é a clássica história de terror. Antoine Eripret documentou o Looker Studio varrendo 23 TB em um único dia, cerca de €115, quando conectado diretamente às tabelas brutas com bilhões de linhas. O próprio post de dicas de eficiência do BigQuery do Google diz o mesmo em princípio: pré-agregue em tabelas de resumo, filtre na partição de data em uma cláusula WHERE, evite SELECT *, defina alertas de orçamento e defina a expiração de partição para excluir automaticamente partições antigas.

A solução é chata, mas eficaz: materialize os resultados das suas consultas em pequenas tabelas de resumo permanentes, em um agendamento, e aponte seus painéis para essas, não para a exportação bruta.

Consultas: as regras que mantêm você são (e barato)

Das diretrizes de consulta do Google:

• Sempre agregue. “Data in the tables is not guaranteed to be consolidated by date, URL, site, or any combination of keys.” Tradução: você receberá várias linhas para o mesmo dia/URL/consulta, então sempre use SUM() nas suas métricas e GROUP BY nas suas dimensões. Nunca trate uma única linha como um número final.
• Filtre a partição de data. “A good way to minimize query costs is to use a WHERE clause to limit the date range in the date partitioned table.”
• Remova linhas anonimizadas quando quiser as principais consultas reais. “An anonymized query is reported as a zero-length string in the table” — então adicione WHERE query != ''.
• A posição é baseada em zero. Ambas as tabelas armazenam a posição começando em 0, então a posição média é SUM(sum_top_position) / SUM(impressions) + 1 (adicione o 1).

O Google fornece consultas de exemplo para estatísticas diárias de pesquisa na web, principais consultas móveis por país, URLs do Discover por cliques, desempenho de rich results de FAQ (is_tpf_faq = true) e rastreamento de consultas de marca via REGEXP_CONTAINS. Comece por elas.

Gerenciando e solucionando problemas da exportação

De Gerenciar e monitorar exportações de dados em massa:

• A interrupção não é instantânea. Configurações → Exportação de dados em massa → Desativar exportação. “As exportações em massa serão interrompidas nas próximas 24 horas”, então mais um dia de dados pode ainda chegar depois que você desativar.
• Dois limites de falha, não um. “O Search Console retém dados de exportações com falha por cerca de uma semana.” E então: “O Search Console parará de tentar exportar dados para uma determinada data após cerca de uma semana de tentativas falhas, e após cerca de um mês de tentativas de exportação falhas, o Search Console interromperá a exportação em massa completamente.” Portanto, um problema contínuo não apenas pula dias — após cerca de um mês, ele desliga toda a exportação, e você teria que configurá-la novamente.
• A armadilha da mudança de esquema (e o piso de expiração de partição). Se você alterar o esquema de uma tabela exportada, você quebra a exportação. O Google também exige pelo menos 14 dias de expiração de partição no conjunto de dados de exportação — defina um período mais curto e a exportação pode falhar. Deixe essas tabelas em paz; crie suas próprias tabelas derivadas. (Outras causas comuns de falha incluem exceder a cota do seu projeto Cloud e revogar o acesso da conta de serviço.)
• Use o relatório de teste. Há um recurso “Relatório de teste” que permite verificar certos problemas corrigíveis — ID do projeto/credenciais, permissões — sem esperar pela próxima execução agendada. Observe que ele não força uma reexportação imediata; verifique novamente cerca de 24 horas depois para confirmar que a correção foi aplicada.
• O Search Console envia e-mails aos proprietários da propriedade quando os erros de exportação começam e quando são resolvidos, e as Configurações mostram o status da tentativa de exportação mais recente.

Onde se encaixa: UI → API → exportação em massa

Pense em três degraus de uma escada, cada um removendo um limite que o degrau abaixo atingiu:

• Exportação pela UI — cerca de 1 000 linhas, cerca de 16 meses, sem consultas anônimas. Suficiente para a maioria.
• API do Search Console — mais linhas, ainda limitada e com limite de taxa, ainda sem consultas anônimas. Boa para extrações ad hoc e programáticas.
• Exportação de dados em massa — sem limite de linhas, retenção que você controla, dados granulares diários, feita para armazenamento e junções. Ainda sem consultas anônimas. Não faz backfill.

E uma nuance que guias mais antigos erram: você não está limitado a uma propriedade por projeto Cloud mais. O Google posteriormente permitiu várias propriedades em um único projeto usando nomes de conjuntos de dados distintos com prefixo searchconsole_.

E o Bing?

No momento em que escrevo, não há equivalente nativo. O Bing Webmaster Tools não oferece uma primeira parte BigQuery/exportação em massa — que é exatamente por isso que existe um mercado de conectores ETL de terceiros (Supermetrics, Improvado, Catchr e outros) para mover dados do Bing Webmaster Tools para o BigQuery. Se o Bing tivesse um pipe nativo, esse mercado não existiria. Dito isso, um conector não é garantido de replicar o esquema de exportação do GSC ou o comportamento de partição diária campo por campo — verifique o escopo documentado de qualquer conector antes de assumir paridade. Então, se você quiser dados do Bing no BigQuery junto com sua exportação do GSC, reserve um orçamento para um conector e verifique o que ele realmente entrega. (Confirme se isso ainda é atual antes de citá-lo — o conjunto de recursos do próprio Bing pode mudar.)

Para o contexto mais amplo sobre onde isso se encaixa, veja o hub Search Engine Tools e seus tutoriais sobre Google Search Console e Bing Webmaster Tools.

Resumo de IA

Uma visão condensada da versão Avançada:

• O que é: a exportação de dados em massa — um despejo diário, sem amostragem e agendado dos dados de Performance do Search Console em um conjunto de dados do Google Cloud BigQuery. Ela remove o limite de exportação de ~1 000 linhas da interface e sua janela de retenção de ~16 meses.
• Três tabelas chegam em um conjunto de dados com prefixo searchconsole: searchdata_site_impression (nível de propriedade), searchdata_url_impression (nível de URL, com sinalizadores is_* de rich results) e ExportLog (um registro de exportação diário).
• Configuração: projeto do Google Cloud com cobrança ativada → ative as APIs do BigQuery + BigQuery Storage → conceda a search-console-data-export@system.gserviceaccount.com os papéis BigQuery Job User e BigQuery Data Editor → Configurações do Search Console → Exportação de dados em massa → ID do projeto, nome do conjunto de dados, local (mantenha a expiração da partição em 14+ dias) → o processo começa em cerca de um dia, primeira exportação em ~48 horas.
• Sem backfill. Começa a partir do dia da ativação — nada histórico é puxado. Este é o ponto nº 1 de confusão.
• Ainda sem consultas anônimas. Elas chegam como strings vazias em query; as métricas são agregadas, mas nunca atribuíveis. No estudo de um mês de Patrick com 146 741 sites e quase 9 bilhões de cliques, ~46% dos cliques foram para consultas não divulgadas — a exportação em massa não as recupera.
• Custo: um nível gratuito real (aproximadamente 10 GiB de armazenamento + 1 TiB de consulta/mês), mas precisa de uma conta de cobrança, e o custo escala com a diversidade de consultas/palavras-chave, não com o tráfego. A conta clássica é um dashboard consultando tabelas brutas ao vivo (um caso documentado: 23 TB / ~€115 em um dia). Correção: materialize tabelas de resumo, filtre a partição de data, evite SELECT *.
• Consultas: sempre use SUM()/GROUP BY (as linhas não são pré-consolidadas), filtre query != '' para descartar linhas anônimas, e a posição é baseada em zero (adicione 1).
• Gerenciamento: a desativação leva até 24 horas; exportações com falha tentam novamente por ~uma semana por data, e ~um mês de falhas desliga toda a exportação; alterar o esquema de uma tabela exportada ou definir expiração de partição abaixo de 14 dias quebra isso.
• Bing não tem equivalente nativo até o momento — conectores de terceiros preenchem a lacuna, embora não necessariamente correspondam exatamente ao esquema da exportação do GSC.
• A escada: interface → API → exportação em massa, cada uma removendo um limite.

Documentação oficial

Documentação de fonte primária, principalmente da Ajuda do Google Search Console e do Google Cloud Blog.

Google — o recurso

• Sobre a exportação de dados em massa dos dados do Search Console para o BigQuery — a visão geral e o que está incluído/excluído.
• Iniciar uma nova exportação de dados em massa — o fluxo de configuração: projeto, APIs, papéis da conta de serviço, configurações do conjunto de dados, atraso de 48 horas.
• Diretrizes e referência de tabelas — o esquema completo para searchdata_site_impression, searchdata_url_impression e ExportLog.
• Diretrizes de consulta e consultas de exemplo — como agregar, minimizar custos, filtrar linhas anônimas e consultas de exemplo prontas.
• Gerenciar e monitorar exportações de dados em massa — desativação, tratamento de erros, limites de nova tentativa/retenção e o relatório de teste.

Google — anúncio e enquadramento

• Exportação de dados em massa: uma nova e poderosa maneira de acessar seus dados do Search Console (Search Central Blog, fev. 2023) — o anúncio original.
• Analise dados de pesquisa do Google com o BigQuery (Google Cloud Blog, Daniel Waisberg & Gaal Yahas) — o enquadramento avançado/ML.
• Dicas de eficiência do BigQuery para exportações de dados em massa do Search Console (Search Central Blog, jun. 2023) — orientação sobre custo e eficiência de consulta.

Preços

• Preços do BigQuery — o nível gratuito atual e as tarifas por TB/GB (verifique antes de citar; elas mudam).

Citações da fonte

Declarações oficiais do Google. Quando uma página é renderizada via JavaScript e resiste à verificação automatizada, a citação é obtida por meio de cobertura secundária verbatim e sinalizada abaixo.

Google — o que é

• “Schedule a daily export of your Search Console performance data to BigQuery, where you can run complex queries over your data or export it to an external storage service.” (tradução) «Agende uma exportação diária dos dados de desempenho do Search Console para o BigQuery, onde você pode executar consultas complexas sobre seus dados ou exportá-los para um serviço de armazenamento externo.» — Google Search Console Help. Ir para a citação
• “A bulk data export is a scheduled daily export of your Search Console performance data. It includes all the data used by Search Console to generate performance reports. Data is exported to Google BigQuery, where you can run SQL queries for advanced data analysis or even export it to another system.” (tradução) «Uma exportação de dados em massa é uma exportação diária agendada dos dados de desempenho do Search Console. Ela inclui todos os dados usados pelo Search Console para gerar relatórios de desempenho. Os dados são exportados para o Google BigQuery, onde você pode executar consultas SQL para análise avançada de dados ou até exportá-los para outro sistema.» — Daniel Waisberg, Search Advocate, Google. Ir para a citação

Google — o esquema

• “Contains performance data for your property aggregated by property.” (em searchdata_site_impression) e “Contains performance data for your property aggregated by URL.” (em searchdata_url_impression). (tradução) «Contém dados de desempenho da sua propriedade agregados por propriedade.» e «Contém dados de desempenho da sua propriedade agregados por URL.» Ir para a citação
• “The user query. When is_anonymized_query is true, this will be a zero-length string.” (tradução) «A consulta do usuário. Quando is_anonymized_query é verdadeiro, esta será uma string de comprimento zero.» Ir para a citação

Google — consultas

• “Data in the tables is not guaranteed to be consolidated by date, URL, site, or any combination of keys.” (tradução) «Não é garantido que os dados nas tabelas sejam consolidados por data, URL, site ou qualquer combinação de chaves.» Ir para a citação
• “A good way to minimize query costs is to use a WHERE clause to limit the date range in the date partitioned table.” (tradução) «Uma boa maneira de minimizar os custos de consulta é usar uma cláusula WHERE para limitar o intervalo de datas na tabela particionada por data.» Ir para a citação

Google — gerenciando a exportação

• “Search Console retains data from failed exports for about a week.” e “Search Console will stop trying to export data for a given date after about a week of failed attempts, and after about a month of failed export attempts, Search Console will stop the bulk export entirely.” (tradução) «O Search Console retém dados de exportações com falha por cerca de uma semana.» e «O Search Console deixará de tentar exportar dados para uma determinada data após cerca de uma semana de tentativas com falha, e após cerca de um mês de tentativas de exportação com falha, o Search Console interromperá a exportação em massa completamente.» Ir para a citação

Google Cloud Blog — Daniel Waisberg & Gaal Yahas

• “Store data as long as you want. Search Console stores up to sixteen months of data; using BigQuery you can store as much data as it makes sense to your organization.” (tradução) «Armazene dados pelo tempo que quiser. O Search Console armazena até dezesseis meses de dados; usando o BigQuery, você pode armazenar quantos dados fizerem sentido para a sua organização.» Ir para a citação

Exportação em massa vs. API vs. interface vs. conector do Looker Studio — qual devo usar?

Comece pelo limite que você está realmente atingindo, não pelo que parece mais poderoso. A maioria das pessoas que configurou a exportação para o BigQuery não precisava dela.

P1. Você está atingindo um limite real na interface do Search Console? (O limite de exportação de ~1 000 linhas, ou o limite de histórico de ~16 meses, ou você precisa unir o GSC com outros dados.)

• Não → pare. A interface (e o conector nativo do Looker Studio para o Search Console para dashboards) é suficiente. Não assuma um data warehouse que você não precisa.
• Sim → continue.

P2. Você precisa de um data warehouse permanente e diário com todos os dados — ou apenas de uma extração maior pontual / programática?

• Pontual ou programática (um script, uma integração, uma exportação profunda ocasional) → use a API do Search Console. Mais do que a interface, sem BigQuery para gerenciar, mas ainda com limites e restrições de taxa, e ainda sem consultas anônimas.
• Fluxo diário permanente que você vai armazenar e unir com outros dados → continue.

P3. Você se sente confortável com um projeto do Google Cloud, uma conta de cobrança ativa e escrever SQL (ou ter alguém que escreva)?

• Não → reconsidere. Uma exportação não gerenciada com um dashboard sobre tabelas brutas é como as cobranças surpresa acontecem. Ou busque ajuda ou continue com a API/conector do Looker Studio.
• Sim → configure a exportação de dados em massa. Ative-a agora (lembre-se: não há backfill), e planeje materializar tabelas de resumo em vez de consultar as brutas em tempo real.

P4. Você precisa especificamente das consultas anônimas/ocultas detalhadas?

• Sim → nenhuma dessas opções entrega isso. Exportação em massa, API e interface suprimem consultas anônimas no nível da consulta. Ajuste o objetivo; esses dados não existem para serem obtidos do Google.

A versão em uma linha: não está atingindo um limite → interface/Looker Studio; extrações ad hoc ou via código → API; data warehouse permanente em escala → exportação em massa; consultas ocultas → ninguém pode te dar isso.

Checklist de configuração da exportação de dados em massa

Trabalhe de cima para baixo; cada etapa condiciona a próxima.

• Ativei a exportação hoje, mesmo que ainda não esteja pronto para analisar (sem preenchimento retroativo — o relógio começa na ativação).
• Existe um projeto do Google Cloud com cobrança ativada (a cobrança é necessária até para o nível gratuito).
• API BigQuery ativada nesse projeto.
• API de armazenamento do BigQuery ativada nesse projeto.
• search-console-data-export@system.gserviceaccount.com adicionado como principal com BigQuery Job User (bigquery.jobUser).
• A mesma conta de serviço recebeu BigQuery Data Editor (bigquery.dataEditor).
• No Search Console → Configurações → Exportação de dados em massa, colei o ID do projeto do Cloud (o ID, não o número).
• Escolhi um nome de conjunto de dados (ele começará com searchconsole) e um local do conjunto de dados.
• Se defini expiração de partição no conjunto de dados de exportação, mantive em 14 dias ou mais — menos que isso quebra a exportação.
• Deixei o esquema da tabela gerada inalterado (crie tabelas derivadas em vez disso).
• Aguardei até 48 horas pela primeira exportação (o processo em si deve começar em cerca de um dia) e depois confirmei que os dados chegaram (verifique ExportLog e as duas tabelas searchdata_*).
• Defini um alerta de orçamento no Google Cloud para que uma consulta descontrolada não te surpreenda.
• Defini expiração de partição nas suas tabelas derivadas se você não precisar de retenção ilimitada.
• Criei painéis com base em tabelas de resumo materializadas, não nas tabelas de exportação brutas.

Erros e mitos a evitar

“Ativar isso preenche meus dados antigos retroativamente.” Não. A exportação começa a partir do dia da ativação e só acumula para frente — nada anterior é puxado. É a pergunta mais frequente no fórum da comunidade do Google sobre esse recurso. Ative no momento em que souber dele para que o histórico comece a ser construído.

“A exportação do BigQuery finalmente me mostra as consultas ocultas/anônimas.” Não. Consultas anônimas chegam como strings vazias em query; seus cliques e impressões são somados aos totais, mas nunca atribuídos a um termo — igual à interface e à API. Em meu estudo da Ahrefs, cerca de 46% dos cliques foram para consultas que o Google não divulga, e até a API — que “nos permite obter todos os dados” — não conseguiu revelá-las. A exportação em massa não muda nada aqui.

“É completamente gratuito.” Parcialmente verdade. Existe um nível gratuito real, mas ele exige uma conta de cobrança ativa, e consultas ineficientes podem gerar cobranças. “Gratuito” só se mantém se você consultar com eficiência.

“Mais tráfego significa uma conta maior do BigQuery.” Não exatamente — o custo escala mais com a diversidade de consultas/palavras-chave do que com o volume bruto de cliques. Um site de tráfego modesto com grande variedade de cauda longa pode gerar mais dados do que um site de alto tráfego com poucas consultas concentradas.

Apontar um painel ao vivo para as tabelas brutas. O erro mais caro de todos. Um caso documentado viu o Looker Studio escanear 23 TB em um dia (~€115) conectado diretamente a tabelas brutas com bilhões de linhas. Correção: materialize tabelas de resumo em um agendamento e aponte os painéis para elas; filtre a partição de data em uma cláusula WHERE; nunca use SELECT *.

Editar o esquema de uma tabela exportada ou definir uma expiração de partição muito curta. Alterar searchdata_site_impression, searchdata_url_impression ou ExportLog quebra a exportação. O mesmo vale para definir a expiração de partição do conjunto de dados de exportação abaixo do mínimo de 14 dias do Google. Crie suas próprias tabelas derivadas, deixe as originais intactas e dê qualquer política de expiração no conjunto de dados bruto 14+ dias de margem.

“Isso substitui a API do Search Console.” Ferramentas diferentes para trabalhos diferentes. A API é para extrações ad hoc e programáticas; a exportação em massa é um pipeline diário contínuo para armazenamento e junções.

Presumir que você só pode exportar uma propriedade por projeto. Desatualizado. O Google posteriormente permitiu várias propriedades em um projeto do Cloud via nomes de conjuntos de dados distintos com prefixo searchconsole_.

Um framework para projetar a exportação antes que ela projete sua conta

1. Comece pela pergunta, não pelo warehouse. Use a interface para uma resposta rápida, a API Search Analytics para extrações programáticas limitadas e a exportação em massa apenas quando você precisar de um histórico diário contínuo, junções ou mais linhas do que os outros níveis fornecem.

2. Respeite o grão da tabela. searchdata_site_impression responde a perguntas no nível da propriedade; searchdata_url_impression adiciona a dimensão da URL. As linhas não são garantidamente pré-consolidadas, então toda análise deve escolher deliberadamente as dimensões e agregar os campos de cliques, impressões e posição.

3. Torne os filtros de partição obrigatórios. Exija um intervalo de data_date em toda consulta. O custo segue os bytes escaneados, e um dashboard sem limites contra tabelas brutas pode escanear o mesmo histórico repetidamente.

4. Separe as camadas bruta, modelada e de apresentação. Mantenha as tabelas de exportação do Google inalteradas, crie tabelas de resumo agendadas para perguntas recorrentes e aponte o Looker Studio ou outro dashboard para esses resumos. Edições de esquema nas tabelas de exportação podem quebrar o pipeline de entrega.

5. Opere o pipeline como dados de produção. Monitore ExportLog, bytes de consulta, falhas de trabalhos agendados e atualização. A exportação não tem backfill, então dias ausentes são um incidente operacional, não algo que a ativação possa reparar depois.

Problemas comuns na exportação em massa do GSC

O relatório de teste falha durante a configuração

Sintoma: o Search Console rejeita o projeto ou conjunto de dados antes da ativação. Causa provável: cobrança ou as APIs necessárias do BigQuery não estão habilitadas, o ID do projeto está errado ou a conta de serviço da exportação do Search Console não tem BigQuery Job User e BigQuery Data Editor. Correção: corrija esses pré-requisitos, execute novamente o relatório de teste e ative somente após ele ter sucesso.

Nenhuma tabela ou novas linhas aparecem

Sintoma: o conjunto de dados existe, mas os dados de exportação esperados estão ausentes. Causa provável: a primeira entrega ainda está pendente, o nome/localização do conjunto de dados está errado, a exportação foi desativada ou falhas estão se acumulando. Correção: aguarde a janela de entrega inicial e depois inspecione ExportLog e o status da exportação em massa do Search Console. Corrija o pipeline em vez de recriar o conjunto de dados, porque a ativação não faz backfill de datas anteriores.

Os totais da consulta parecem duplicados ou inflados

Sintoma: cliques ou impressões excedem o total do Search Console para o mesmo escopo. Causa provável: linhas brutas de exportação foram tratadas como já consolidadas, ou dados de grão de site e URL foram misturados. Correção: escolha um grão de tabela, filtre um search_type, agrupe pelas dimensões pretendidas e faça SUM() nos campos de métrica antes de comparar totais.

A posição média está um a menos

Sintoma: uma posição calculada é consistentemente um a menos do que a expectativa da interface. Causa provável: os valores de posição da exportação são baseados em zero. Correção: agregue o numerador da posição com as impressões correspondentes e converta para a exibição familiar baseada em um somente na camada de apresentação.

Um dashboard de repente fica caro

Sintoma: bytes processados e cobranças de consulta aumentam mesmo sem aumento de tráfego. Causa provável: o dashboard está escaneando tabelas brutas no nível de URL sem filtro de partição. Correção: inspecione os bytes antes de executar, adicione um predicado data_date limitado, materialize o resumo diário necessário e aponte o dashboard para essa tabela menor.

Prove que a exportação em massa funciona após a configuração ou uma mudança no pipeline

Confirme que o Search Console pode gravar no projeto

Teste a executar — Execute Configurações → Exportação de dados em massa → Relatório de teste após alterar o projeto, as APIs ou as funções do IAM. Resultado esperado — o Search Console informa que o destino é válido. Interpretação de falha — a configuração do projeto/API ou as funções da conta de serviço de exportação ainda estão erradas. Janela de monitoramento — imediata. Gatilho de reversão — não ative nem alterne o destino de exportação de produção enquanto o teste falhar.

Confirme uma entrega diária completa

Teste a executar — Verifique ExportLog para a data_date mais recente esperada e, em seguida, consulte ambas as tabelas de impressões para essa mesma partição. Resultado esperado — o log registra a entrega e as tabelas de site/URL contêm linhas para a data em que a propriedade teve atividade. Interpretação de falha — a exportação está atrasada ou falhou; um resultado vazio não é backfill histórico. Janela de monitoramento — Permita a defasagem de dados documentada e a janela inicial de exportação antes de declarar falha. Gatilho de reversão — Pause qualquer lançamento de relatório downstream se sua data mais recente estiver ausente ou apenas uma tabela obrigatória chegou.

Confirme que uma consulta modelada reconcilia

Teste a executar — Execute a nova consulta de resumo para uma data e tipo de pesquisa fixos e, em seguida, compare seus cliques e impressões totais com um agregado direto da mesma partição bruta. Resultado esperado — os totais correspondem na mesma granularidade e filtros. Interpretação de falha — o modelo está descartando linhas, contando dimensões em dobro ou misturando a granularidade de site e URL. Janela de monitoramento — Imediata após a consulta terminar. Gatilho de reversão — Mantenha os dashboards no resumo anterior até que o novo modelo reconcilie.

Confirme a proteção de custo

Teste a executar — Visualize os bytes processados para a consulta de produção com seu filtro data_date pretendido. Resultado esperado — a varredura é limitada às partições solicitadas e é consistente com a linha de base estabelecida pela equipe para esse relatório. Interpretação de falha — a poda de partições está ausente ou um join expandiu a varredura. Janela de monitoramento — Antes de cada mudança de consulta agendada ou de dashboard. Gatilho de reversão — Não implante uma versão cuja varredura estimada exceda materialmente a linha de base aprovada sem uma mudança explicada no volume de dados.

Consultas iniciais

Estas seguem as próprias regras do Google: agregue tudo (as linhas não são pré-consolidadas), filtre a partição de data para controlar o custo e lembre-se de que a posição é baseada em zero. Substitua yourproject.searchconsole pelo seu conjunto de dados.

Principais consultas reais (linhas anonimizadas removidas), últimos 28 dias

SELECT
  query,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
  SUM(sum_top_position) / SUM(impressions) + 1 AS avg_position
FROM `yourproject.searchconsole.searchdata_site_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
                    AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)   -- 2-day data lag
  AND query != ''                                                 -- drop anonymized rows
GROUP BY query
ORDER BY clicks DESC
LIMIT 100;

Principais páginas de destino por cliques (tabela de nível de URL)

SELECT
  url,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions
FROM `yourproject.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
                    AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)
GROUP BY url
ORDER BY clicks DESC
LIMIT 100;

Desempenho de rich results de FAQ (um sinalizador de rich result na tabela de URL)

SELECT
  url,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions
FROM `yourproject.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
                    AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)
  AND is_tpf_faq = TRUE
GROUP BY url
ORDER BY impressions DESC;

Materialize um resumo diário para que os dashboards nunca toquem nas tabelas brutas

CREATE OR REPLACE TABLE `yourproject.searchconsole_derived.daily_query_summary`
PARTITION BY data_date AS
SELECT
  data_date,
  query,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions
FROM `yourproject.searchconsole.searchdata_site_impression`
WHERE query != ''
GROUP BY data_date, query;

A cost-control habit: verify how many bytes a query will scan before you run it, using the dry-run flag in the bq CLI — a free way to catch an accidental full-table scan.

bq query --use_legacy_sql=false --dry_run \
  'SELECT SUM(clicks) FROM `yourproject.searchconsole.searchdata_url_impression`
   WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)'
# Prints the estimated bytes to be processed without running (or billing for) the query.

Exportação do GSC para BigQuery — folha de referência

Configuração rápida

As três tabelas

Regras de consulta

• Sempre SUM() + GROUP BY — as linhas não são pré-consolidadas.
• WHERE query != '' para descartar linhas anonimizadas.
• Filtrar data_date (a partição) para reduzir custo.
• avg_position = SUM(sum_top_position)/SUM(impressions) + 1 (base zero, adicione 1).
• Nunca SELECT *.

Fatos rápidos

• Sem backfill — os dados começam na ativação, apenas para frente.
• Consultas anonimizadas permanecem ocultas (string query vazia) — igual à UI/API.
• Atraso de dois dias nos dados mais recentes.
• Desativação leva até 24 horas (mais um dia pode chegar).
• Limites de falha: ~1 semana de nova tentativa por data → ~1 mês de falhas interrompe a exportação inteira.
• Piso de expiração de partição: mínimo de 14 dias no conjunto de dados de exportação; menos que isso quebra.
• Nome do conjunto de dados sempre começa com searchconsole.
• Múltiplas propriedades por projeto: use nomes de conjuntos de dados distintos com prefixo searchconsole_.
• Nível gratuito (verifique o atual): ~10 GiB de armazenamento + ~1 TiB de consulta/mês, depois ~$6,25 USD/TiB.
• Bing: sem equivalente nativo — conector de terceiros necessário.

Prompts para revisar trabalhos com GSC BigQuery

Auditar uma consulta quanto à correção e custo

Cole os esquemas das tabelas, o SQL, seu propósito e o escopo de data/tipo de pesquisa. Peça ao modelo para retornar o SQL corrigido e uma breve explicação, depois verifique a saída no BigQuery antes de agendá-la.

You are reviewing a Google Search Console bulk-export query in BigQuery.

Goal: [the question this query should answer]
Table grain and schemas: [paste the relevant site or URL table fields]
SQL: [paste the query]
Required date range and search_type: [paste them]

Check for: a missing data_date partition filter; failure to aggregate raw rows;
site-grain and URL-grain mixing; incorrect handling of zero-based position;
anonymized-query handling; joins that duplicate metrics; and unnecessary bytes
scanned. Return: (1) each issue, (2) corrected Standard SQL, (3) a reconciliation
query, and (4) assumptions that require human verification. Do not invent fields.

Projetar uma camada de relatórios segura

Cole as perguntas que o dashboard deve responder e o esquema real. Espere uma proposta de granularidade de tabela resumida e plano de validação, não uma implantação pronta para uso inventada.

Design a modeled reporting layer for this GSC BigQuery bulk export.

Business questions: [paste the questions]
Available tables and schemas: [paste them]
Refresh cadence: [daily/weekly]
Required dimensions: [page, query, country, device, search type, etc.]

Propose: the smallest useful summary-table grain; partitioning and clustering;
a scheduled-query sequence; freshness and reconciliation checks; and which dashboard
questions should stay in the UI or API instead. Preserve raw export tables unchanged.
Flag any requirement the supplied schema cannot support, especially requests for
disclosed anonymized queries. Do not invent benchmarks, fields, or backfill.

Ferramentas em torno da exportação

• Google BigQuery — onde os dados chegam; execute SQL, agende consultas e crie modelos de BigQuery ML nele.
• Controles de custo do BigQuery — alertas de orçamento do Google Cloud, limites de bytes por consulta e o sinalizador bq --dry_run para estimar o tamanho do escaneamento antes de executar.
• Looker Studio — para dashboards, mas construa-os em tabelas resumidas materializadas, não na exportação bruta. (O Looker Studio também tem um conector nativo do Search Console que não precisa de BigQuery — muitas vezes suficiente por si só.)
• Google Search Console — a fonte; a exportação pela UI e o relatório de Performance são a linha de base que a exportação em massa estende.
• Search Console API — o degrau intermediário quando você precisa de mais do que a UI, mas não de um warehouse permanente.
• Conectores ETL de terceiros (Supermetrics, Improvado, Catchr e outros) — como você obteria dados do Bing Webmaster Tools no BigQuery, já que o Bing não tem exportação nativa.

Recursos que valem seu tempo

Meus escritos relacionados

• Quase metade dos cliques do GSC vão para consultas anônimas — meu estudo da Ahrefs (146 741 sites, ~9 bilhões de cliques) mostrando que 46,08% dos cliques vão para consultas que o Google não divulga. Diretamente relevante: a exportação do BigQuery também não recupera nenhuma delas.
• O guia do iniciante para SEO técnico — onde o Search Console e o trabalho de análise de dados se encaixam no panorama geral.

Minhas palestras / posts

• Sobre extrair mais dos dados do GSC — um passo a passo para extrair mais dos dados do Search Console (por meio dos recursos de GSC da própria Ahrefs), parte da mesma linha “há mais aqui do que a interface mostra” da exportação do BigQuery.

Da indústria

• Google Search Console adiciona exportações diárias de dados em massa para o BigQuery (Search Engine Land, Barry Schwartz) — a cobertura do anúncio, com o texto original do Google citado verbatim.
• Google explica como usar a exportação de dados em massa do Search Console (Search Engine Journal, Matt G. Southern) — a descrição do recurso em linguagem simples por Daniel Waisberg.
• Comece com consultas do GSC no BigQuery (Search Engine Journal) — um ponto de partida prático para consultas.
• Google Search Console para BigQuery: o guia completo (Trevor Fox) — a origem do enquadramento de custo “variedade de palavras-chave, não volume de pesquisa”.
• Adeus, amostragem! Obtenha dados mais completos do GSC com o BigQuery (Advanced Web Ranking, Sam Torres) — noções básicas de configuração e controle de custos.
• Como consultar dados do Google Search Console no BigQuery (Analytics Mania, Julius Fedorovicius) — passo a passo completo, incluindo a defasagem de dados de dois dias.
• Como usar seus dados do GSC no BigQuery como um profissional (Antoine Eripret) — o mergulho técnico profundo, incluindo a história de terror de custo de 23 TB / ~€115 e a realidade de não haver backfill.

Estatísticas que valem citar

• ~46% dos cliques do GSC vão para consultas não divulgadas. Do meu estudo da Ahrefs de 146 741 sites e aproximadamente 9 bilhões de cliques: 46,08% dos cliques foram para consultas que o Google anonimiza — uma limitação que a exportação do BigQuery compartilha com a interface e a API.
• Um painel ao vivo em tabelas brutas varreu 23 TB em um dia (~€115). O caso documentado de Antoine Eripret sobre por que você materializa tabelas de resumo em vez de consultar diretamente a exportação bruta. Fonte
• Defasagem de dados de dois dias. “Google Search Console data is available with a two-day delay, so the most recent data available will always be from two days prior” — (tradução) «Os dados do Google Search Console estão disponíveis com um atraso de dois dias, portanto os dados mais recentes disponíveis sempre serão de dois dias antes» — portanto, um intervalo de 30 dias retorna ~28 dias de dados utilizáveis. Fonte
• Camada gratuita (verifique — os preços mudam): aproximadamente 10 GiB de armazenamento + 1 TiB de processamento de consultas por mês grátis, depois cerca de $6,25 USD/TiB processados. Fonte

Teste-se: Exportação do GSC para BigQuery

Cinco perguntas rápidas sobre a exportação de dados em massa. Escolha uma resposta para cada uma e depois confira.

Registro de alterações