Exportação do GSC para o BigQuery

TL;DR — A exportação do GSC para o BigQuery (que o Google chama de exportação de dados em massa) copia automaticamente os 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 dados de cliques e impressões do que a visão reduzida exibida pela interface do Search Console — embora as consultas anonimizadas (ocultas) também continuem ocultas aqui. Há duas ressalvas importantes: ela não traz seus dados antigos (somente os dados do dia em que você a ativa em diante) e exige uma conta de faturamento do Google Cloud, embora exista uma camada de uso gratuito.

O que é

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

Este guia cobre propriedades de sites. As propriedades de plataforma mais novas do Search Console — Instagram, TikTok, X e YouTube — têm relatórios de desempenho, Insights e conquistas, mas a documentação atual de propriedades de plataforma do Google não documenta uma configuração ou um esquema de exportação em massa para o BigQuery. Considere as propriedades de plataforma sem suporte aqui, a menos que o Google exponha a configuração e documente o contrato. No momento, o LinkedIn não é uma propriedade de plataforma compatível.

Abra o relatório de desempenho no Google Search Console e tente exportá-lo. Você vai encontrar um limite rapidamente: a interface restringe a maioria das exportações a cerca de 1 000 linhas e mostra apenas 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 apenas uma pequena fatia dos seus dados reais.

A exportação de dados em massa resolve isso. É uma opção dentro do Search Console que diz: “from now on, send my Performance data to BigQuery every day.” (tradução) «a partir de agora, 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á funcionando, você obtém dados diários não amostrados, sem limite de 1 000 linhas, mantidos pelo tempo que quiser — com uma exceção permanente: as consultas anonimizadas (as que o Search Console oculta por privacidade) continuam aparecendo vazias, assim como na interface. “No row limit” (tradução) «Sem limite de linhas» não significa “every query revealed.” (tradução) «todas as consultas reveladas».

Por que alguém faria isso

Você configuraria isso se quisesse:

• Analise muito mais consultas e páginas do que a interface ou o botão de exportação permitem.
• Mantenha o histórico do Search Console por mais de 16 meses (o Search Console descarta os dados antigos; o BigQuery mantém o que você decidir conservar).
• Combine seus dados do Search Console com outros dados — do Google Analytics, de um rastreamento ou do banco de dados do seu produto — tudo no mesmo lugar.

As duas coisas que você precisa saber antes de começar

1. Não há preenchimento retroativo. Esta é a surpresa mais comum. Ativar a exportação não faz com que seus dados históricos sejam buscados. Ela começa a coletar a partir daquele dia. Se você quer histórico, precisa ativá-la e esperar que ele se acumule.
2. It’s “free” with an asterisk. (tradução) «É “gratuito” com ressalvas.» O BigQuery tem uma camada gratuita, e a maioria dos sites pequenos e médios permanece dentro dela. Ainda assim, você precisa associar uma conta de faturamento do Google Cloud e, se consultar os dados sem cuidado — especialmente apontando um painel ativo para as tabelas brutas — pode acabar com uma cobrança real.

Vale a pena para você?

Sinceramente, a maioria dos sites não precisa disso. Se a interface do Search Console e o conector nativo do Search Console no Looker Studio mostram o suficiente, você terminou — pule a configuração. Recorra à exportação para o BigQuery quando estiver batendo continuamente no limite de 1 000 linhas, precisar de mais de 16 meses de histórico ou quiser manter os dados do Search Console ao lado dos seus outros dados em um armazém. Se esse é o seu caso, mude para a aba Avançado para ver a configuração completa, a mecânica de custos e as primeiras consultas a executar.

TL;DR — A exportação de dados em massa é um despejo diário e não amostrado agendado dos dados de desempenho do Search Console em um conjunto de dados do BigQuery no Google Cloud — sem o limite de exportação de ~1 000 linhas e sem a barreira de retenção de ~16 meses. Ela cria três tabelas (searchdata_site_impression, searchdata_url_impression, ExportLog). A configuração exige um projeto do Google Cloud com faturamento habilitado, as APIs BigQuery e BigQuery Storage ativadas, duas funções do IAM concedidas à conta de serviço de exportação do Google e, depois, Settings → Bulk data export no GSC. Ela não faz preenchimento retroativo, ainda informa consultas anonimizadas como strings vazias e a primeira exportação chega em até ~48 horas. Há uma camada gratuita real, além de cobranças por consulta; a cobrança clássica vem de painéis que consultam tabelas brutas ao vivo. Pense nela como o terceiro degrau: interface → API → exportação em massa.

A escada abaixo é para propriedades de sites. Ela não é evidência de que propriedades de plataforma social ou de vídeo oferecem suporte à API do Search Console ou à exportação para o BigQuery.

O que ela 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 classificação. Evidência desta afirmação Search Console bulk data export sends daily performance data to BigQuery in a configured Google Cloud project. Escopo: Search Console bulk export; setup, permissions, quotas, and supported properties follow Google's current documentation. Confiança: alta · Verificado: 2026-07-14 Google: Bulk data export As consultas devem respeitar as tabelas, chaves e regras documentadas de privacidade e agregação. Evidência desta afirmação Bulk export uses site-impression, URL-impression, and export-log tables with documented schemas. Escopo: Google's published Search Console export schema; aggregation and privacy handling still affect analysis. Confiança: alta · Verificado: 2026-07-14 Google: Bulk export tables

Daniel Waisberg, Search Advocate do Google, descreve isso de forma direta: “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 ou até exportá-los para outro sistema.» (citado no Search Engine Journal).

A questão é 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 continua limitada e sujeita a limites de taxa. A exportação em massa remove totalmente o teto de linhas e permite que você decida por quanto tempo conservar os dados. A própria frase do Google no anúncio, reproduzida pelo Search Engine Land: “The daily data row limit does not impact this data, so you can extract more data using this method,” (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 “could be particularly helpful for large websites with tens of thousands of pages.” (tradução) «poderia ser particularmente útil para sites grandes com dezenas de milhares de páginas.»

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

Tudo chega a um conjunto de dados cujo nome sempre começa com searchconsole. Três objetos aparecem (diretrizes e referência das 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 principais: data_date (“The day on which the data in this row was generated (Pacific Time)”; (tradução) «O dia em que os dados desta linha foram gerados (Horário do Pacífico)»), site_url (as propriedades de domínio usam o prefixo sc-domain:), query, is_anonymized_query, country (ISO-3166-1 Alpha-3), search_type (web/image/video/news/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, além de 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 segmentar por tipo de resultado avançado, e sum_position. Esta é a tabela granular usada na maior parte das análises.
3. ExportLog — “A record of what data was saved for that day. Failed exports are not recorded here.” (tradução) «Um registro dos dados salvos naquele dia. Exportações com falha não são registradas aqui».) Os 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 em que 0 é a primeira vez que os dados foram salvos nesta tabela» — ele aumenta quando o Google revisa posteriormente os dados de um dia) e publish_time.

A ressalva das consultas anonimizadas é a mais importante. Mesmo aqui, no nível bruto, as consultas anonimizadas não são reveladas. Como diz a descrição de campo do Google, quando is_anonymized_query é true, o campo query “will be a zero-length string.” (tradução) «será uma string de comprimento zero». As métricas ainda são agregadas aos seus totais, mas nunca são atribuídas a um termo específico — exatamente a mesma limitação da interface e da API. Isso importa muito em escala: no meu estudo da Ahrefs sobre termos ocultos do GSC, em 146 741 sites e aproximadamente 9 bilhões de cliques, 46,08 % de todos os cliques foram para consultas que o Google não divulga — e o estudo usou a API do Search Console, que “allows us to get all of the data—and there’s still a lot missing.” (tradução) «permite obter todos os dados — e ainda falta muita coisa». A exportação do BigQuery não recupera nada disso. Se alguém disser que a exportação em massa “finally shows you the hidden queries,” (tradução) «finalmente mostra as consultas ocultas», está errado.

Como configurar

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

1. Crie ou escolha um projeto do Google Cloud com faturamento habilitado. Segundo o Google: “Data is subject to Google Cloud storage and query costs, but there is a free usage level.” (tradução) «Os dados estão sujeitos a custos de armazenamento e consulta do Google Cloud, mas existe um nível de uso gratuito».) Você precisa manter o faturamento ativado mesmo para ficar dentro da camada gratuita.
2. Ative a BigQuery API e a BigQuery Storage API 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 duas funções do IAM: BigQuery Job User (bigquery.jobUser) e BigQuery Data Editor (bigquery.dataEditor).
4. No Search Console, acesse Settings → Bulk data export. Cole o ID do projeto do Cloud (o ID, não o número do projeto), escolha um nome de conjunto de dados e uma localização do conjunto de dados. Observe a regra de nome: “The dataset name always starts with the string searchconsole, even when you customize it.” (tradução) «O nome do conjunto de dados sempre começa com a string searchconsole, mesmo quando você o personaliza».) Se 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 um valor menor é uma causa documentada de falha. Deixe o esquema das tabelas geradas intacto; alterá-lo é outra forma documentada de quebrar a exportação (mais detalhes em Solução de problemas abaixo).
5. Espere. O Google diz que o processo de exportação deve começar em cerca de um dia após a ativação. “The first export will happen up to 48 hours after your successful configuration in Search Console,” (tradução) «A primeira exportação ocorrerá até 48 horas após a configuração bem-sucedida no Search Console») e a primeira entrega contém apenas os dados do dia da exportação — nada anterior à configuração (veja a próxima seção sobre não haver preenchimento retroativo). Depois disso, ela funciona diariamente até você interrompê-la.

Uma expectativa prática: os dados do Search Console chegam com um atraso de dois dias, portanto o dia mais recente disponível será sempre o de dois dias atrás. Se você solicitar um intervalo de 30 dias, na prática obterá cerca de 28 dias de dados utilizáveis.

A armadilha de não haver preenchimento retroativo

Diga isso em voz alta, porque muita gente se dá mal: ativar a exportação não traz seus dados históricos. Ela começa no dia da ativação e só acumula dados dali em diante. Isso é tão comum que o fórum da comunidade do Google tem vários tópicos sobre o assunto — “How to backfill with historical data when Bulk data export is activated” (tradução) «Como fazer backfill de dados históricos quando a exportação de dados em massa é ativada») (tópico 300051568), tópico 255704574 e tópico 429248330. Antoine Eripret é direto em seu aprofundamento prático: “You can’t get historical data: if you activate it today, you’ll have data from today.” (tradução) «Você não pode obter dados históricos: se ativar hoje, terá dados a partir de hoje». A conclusão é simples: ative-a no dia em que ouvir falar dela, mesmo que ainda não esteja pronto para analisar nada, para começar a contar o tempo.

Quanto custa e como não ser surpreendido

A publicação do Google Cloud Blog de Daniel Waisberg e Gaal Yahas destaca os benefícios — “If you have a large website, this solution will provide more queries and pages than the other data exporting solutions” (tradução) «Se você tem um site grande, esta solução fornecerá mais consultas e páginas do que as outras soluções de exportação») 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” (tradução) «O Search Console armazena até dezesseis meses de dados; usando o BigQuery, você pode armazenar tantos dados quanto fizer sentido para sua organização») — mas a mecânica dos custos fica por sua conta.

Até o momento desta redação, a camada gratuita do BigQuery é de aproximadamente 10 GiB de armazenamento gratuito, mais 1 TiB (~1 TB) de processamento de consultas sob demanda gratuito por mês; além disso, custa cerca de 6,25 USD por TiB processado e aproximadamente 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 números 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 tem. Duas coisas importam:

• O custo aumenta com a diversidade de consultas/palavras-chave, não com o tráfego bruto. Como Trevor Fox explica 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.” (tradução) «O volume de dados depende mais da variedade de palavras-chave do que do volume de pesquisa. Um site com pouco volume de pesquisa para muitas palavras-chave gerará mais dados do que um site com muito volume de pesquisa para uma única palavra-chave».)
• Não aponte um painel ativo para as tabelas brutas. Esta é a história clássica de terror. Antoine Eripret documentou o Looker Studio examinando 23 TB em um único dia, cerca de €115, quando conectado diretamente às tabelas brutas com bilhões de linhas. A própria publicação do Google sobre eficiência do BigQuery diz o mesmo em princípio: pré-agregue em tabelas de resumo, filtre a partição de data em uma cláusula WHERE, evite SELECT *, configure alertas de orçamento e use expiração de partições para excluir partições antigas automaticamente.

A solução é sem graça, mas eficaz: materialize os resultados das consultas em pequenas tabelas de resumo permanentes segundo um cronograma e aponte seus painéis para elas, não para a exportação bruta.

Consultas: as regras para manter a sanidade (e o custo baixo)

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) «Não há garantia de que os dados nas tabelas estejam consolidados por data, URL, site ou qualquer combinação de chaves».) Isso significa que você receberá várias linhas para o mesmo dia/URL/consulta; portanto, sempre use SUM() nas métricas e GROUP BY nas 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.” (tradução) «Uma boa forma de minimizar os custos de consulta é usar uma cláusula WHERE para limitar o intervalo de datas na tabela particionada por data».)
• Descarte linhas anonimizadas quando quiser consultas reais. “An anonymized query is reported as a zero-length string in the table” (tradução) «Uma consulta anonimizada é informada como uma string de comprimento zero na tabela») — portanto, acrescente WHERE query != ''.
• A posição começa em zero. As duas tabelas armazenam a posição começando em 0, então a posição média é SUM(sum_top_position) / SUM(impressions) + 1 (some 1).

O Google fornece consultas de exemplo para estatísticas diárias da pesquisa na web, principais consultas em dispositivos móveis por país, URLs do Discover por cliques, desempenho de resultados avançados de FAQ (is_tpf_faq = true) e acompanhamento de consultas de marca via REGEXP_CONTAINS. Comece por elas.

Gerenciar e solucionar problemas da exportação

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

• Interromper não é instantâneo. Settings → Bulk data export → Deactivate export. “Bulk exports will stop in the next 24 hours,” (tradução) «As exportações em massa serão interrompidas nas próximas 24 horas»), então mais um dia de dados pode chegar depois que você desativá-la.
• São dois limites de falha, não um. “Search Console retains data from failed exports for about a week.” (tradução) «O Search Console mantém os dados de exportações com falha por cerca de uma semana».) E depois: “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 deixará de tentar exportar dados de uma determinada data após cerca de uma semana de tentativas malsucedidas e, após cerca de um mês de tentativas malsucedidas, interromperá totalmente a exportação em massa».) Portanto, um problema prolongado não apenas pula dias — depois de ~um mês ele desliga toda a exportação, e você terá de configurá-la novamente.
• A armadilha de mudar o esquema (e o limite de expiração da partição). Se você alterar o esquema de uma tabela exportada, quebrará a exportação. O Google também exige pelo menos 14 dias de expiração de partição no conjunto de dados da exportação — definir um período menor pode causar falha. Deixe essas tabelas intactas e crie suas próprias tabelas derivadas. (Outras causas comuns incluem exceder a cota do projeto do Cloud e revogar o acesso da conta de serviço.)
• Use o Test report. Há um recurso “Test report” que permite verificar alguns problemas corrigíveis — ID/credenciais do projeto e permissões — sem esperar a próxima execução agendada. Ele não força uma nova exportação imediata; verifique novamente cerca de 24 horas depois para confirmar a correção.
• O Search Console envia e-mails aos proprietários quando começam e quando resolvem erros de exportação, e Settings mostra o status da tentativa de exportação mais recente.

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

Pense em três degraus de uma escada, cada um removendo um limite atingido pelo degrau abaixo:

• Exportação pela interface — ~1 000 linhas, ~16 meses, sem consultas anonimizadas. Suficiente para a maioria.
• API do Search Console — mais linhas, ainda limitada e sujeita a limites de taxa, e ainda sem consultas anonimizadas. Boa para extrações pontuais e programáticas.
• Exportação de dados em massa — sem limite de linhas, retenção sob seu controle, dados diários granulares, feita para armazenamento e combinações. Ainda sem consultas anonimizadas. Não faz backfill.

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

E o Bing?

Até o momento desta redação, não existe equivalente nativo. O Bing Webmaster Tools não oferece uma exportação própria para BigQuery/em massa — exatamente por isso 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 pipeline nativo, esse mercado não existiria. Ainda assim, não há garantia de que um conector reproduza campo a campo o esquema ou o comportamento de partição diária da exportação do GSC — verifique o escopo documentado de qualquer conector antes de presumir equivalência. Se quiser dados do Bing no BigQuery ao lado da exportação do GSC, reserve verba para um conector e verifique o que ele realmente entrega. (Confirme se isso continua atual antes de citar: os recursos do Bing podem mudar.)

Para o contexto mais amplo de onde isso se encaixa, consulte o hub de Ferramentas de mecanismos de busca e seus guias sobre o Google Search Console e o Bing Webmaster Tools.

Resumo de IA

Uma síntese condensada da versão Advanced:

• O que é: a exportação de dados em massa — um despejo diário e não amostrado programado dos dados de desempenho do Search Console em um conjunto de dados do Google Cloud BigQuery. Ela remove o limite de exportação da interface de ~1 000 linhas e sua janela de retenção de ~16 meses.
• Três tabelas chegam a um conjunto de dados com prefixo searchconsole: searchdata_site_impression (nível da propriedade), searchdata_url_impression (nível de URL, com flags de resultados avançados is_*) e ExportLog (um registro da exportação diária).
• Configuração: projeto do Google Cloud com faturamento ativado → ative as APIs BigQuery e BigQuery Storage → conceda à conta de serviço de exportação search-console-data-export@system.gserviceaccount.com as funções BigQuery Job User e BigQuery Data Editor → Search Console Settings → Bulk data export → ID do projeto, nome do conjunto de dados e localização (mantenha a expiração da partição em 14 dias ou mais) → o processo começa em cerca de um dia, e a primeira exportação chega em até ~48 horas.
• Sem preenchimento retroativo. Ela começa no dia da ativação — nenhum dado histórico é extraído. Este é o ponto de confusão nº 1.
• Ainda sem consultas anonimizadas. Elas chegam como strings vazias em query; as métricas são agregadas, mas nunca podem ser atribuídas a uma consulta. No estudo de um mês de Patrick na Ahrefs, com 146 741 sites e quase 9 bilhões de cliques, cerca de ~46 % dos cliques foram para consultas não divulgadas — a exportação em massa não as recupera.
• Custo: existe uma camada gratuita real (aproximadamente 10 GiB de armazenamento + 1 TiB de consultas por mês), mas é necessária uma conta de faturamento, e o custo aumenta com a diversidade de consultas/palavras-chave, não com o tráfego. A conta clássica vem de um painel que consulta tabelas brutas ao vivo (um caso documentado: 23 TB / ~€115 em um dia). Solução: materialize tabelas de resumo, filtre a partição de data e evite SELECT *.
• Consultas: sempre use SUM()/GROUP BY (as linhas não são pré-consolidadas), filtre query != '' para descartar linhas anonimizadas, e lembre que a posição começa em zero (some 1).
• Gerenciamento: a desativação leva até 24 horas; exportações com falha são repetidas por cerca de uma semana para cada data, e cerca de 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 a interrompe.
• Bing não tem equivalente nativo até o momento desta redação — conectores de terceiros preenchem a lacuna, mas não necessariamente reproduzem exatamente o 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 fontes primárias, principalmente da Ajuda do Google Search Console e do Google Cloud Blog.

Google — o recurso

• Sobre a exportação 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 em massa — o fluxo de configuração: projeto, APIs, funções da conta de serviço, configurações do conjunto de dados e atraso de 48 horas.
• Diretrizes e referência das tabelas — o esquema completo de searchdata_site_impression, searchdata_url_impression e ExportLog.
• Diretrizes de consulta e consultas de exemplo — como agregar, reduzir custos, filtrar linhas anonimizadas e usar consultas prontas.
• Gerenciar e monitorar exportações em massa — desativação, tratamento de erros, limites de repetição/retenção e o Test report.

Google — anúncio e contexto

• Exportação em massa: uma maneira nova e avançada de acessar seus dados do Search Console (Search Central Blog, fev. 2023) — o anúncio original.
• Analisar dados da Pesquisa Google com o BigQuery (Google Cloud Blog, Daniel Waisberg e Gaal Yahas) — o contexto avançado/de ML.
• Dicas de eficiência do BigQuery para exportações em massa do Search Console (Search Central Blog, jun. 2023) — orientação sobre custos e eficiência das consultas.

Preços

• Preços do BigQuery — a camada gratuita atual e as tarifas por TB/GB (verifique antes de citar; elas mudam).

Citações da fonte

Declarações registradas do Google. Quando uma página é renderizada por JavaScript e resiste à verificação automatizada, a citação é obtida por cobertura secundária literal 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) «Programe 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.» — Ajuda do Google Search Console. 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 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.” (tradução) «Contém dados de desempenho da sua propriedade agregados por propriedade.» (em searchdata_site_impression) e “Contains performance data for your property aggregated by URL.” (tradução) «Contém dados de desempenho da sua propriedade agregados por URL.» (em searchdata_url_impression). 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 é true, 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 há garantia de que os dados nas tabelas estejam 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 forma 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 — gerenciamento da exportação

• “Search Console retains data from failed exports for about a week.” (tradução) «O Search Console mantém os dados de exportações com falha por cerca de uma semana.» 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 deixará de tentar exportar dados de uma determinada data após cerca de uma semana de tentativas malsucedidas e, após cerca de um mês de tentativas malsucedidas, interromperá totalmente a exportação em massa.» Ir para a citação

Google Cloud Blog — Daniel Waisberg e 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 os dados pelo tempo que quiser. O Search Console armazena até dezesseis meses de dados; usando o BigQuery, você pode armazenar a quantidade de dados que fizer sentido para 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ê realmente está enfrentando, não pelo que parece mais poderoso. A maioria das pessoas que configurou a exportação do BigQuery não precisava dela.

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

• Não → pare. A interface (e o conector nativo do Search Console do Looker Studio para painéis) é suficiente. Não assuma um armazém de dados de que você não precisa.
• Sim → continue.

P2. Você precisa de um armazém diário e contínuo de dados completos — ou apenas de uma extração única/programática maior?

• Extração única ou programática (um script, uma integração, uma exportação profunda ocasional) → use a API do Search Console. Mais dados que a interface, sem BigQuery para operar, mas ainda limitada por cotas/limites de taxa e ainda sem consultas anonimizadas.
• Pipeline diário contínuo que você vai armazenar e combinar com outros dados → continue.

P3. Você se sente confortável com um projeto do Google Cloud, uma conta de faturamento ativa e escrevendo SQL (ou tendo alguém que faça isso)?

• Não → reconsidere. Uma exportação sem gerenciamento e um painel sobre tabelas brutas são a receita para cobranças inesperadas. Busque ajuda ou fique com a API/conector do Looker Studio.
• Sim → configure a exportação de dados em massa. Ative-a agora (lembre-se: não há preenchimento retroativo) e planeje materializar tabelas de resumo em vez de consultar tabelas brutas ao vivo.

P4. Você precisa especificamente separar as consultas anonimizadas/ocultas?

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

A versão em uma linha: se não está enfrentando um limite → interface/Looker Studio; extrações pontuais ou codificadas → API; armazém contínuo em escala → exportação em massa; consultas ocultas → ninguém pode fornecê-las.

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

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

• Ativei a exportação hoje, mesmo que ainda não esteja pronto para analisar (não há preenchimento retroativo — o relógio começa na ativação).
• Existe um projeto do Google Cloud com faturamento ativado (o faturamento é necessário mesmo para a camada gratuita).
• A BigQuery API está ativada nesse projeto.
• A BigQuery Storage API está ativada nesse projeto.
• A conta de serviço search-console-data-export@system.gserviceaccount.com foi adicionada como principal com a função BigQuery Job User (bigquery.jobUser).
• A mesma conta de serviço recebeu a função BigQuery Data Editor (bigquery.dataEditor).
• No Search Console → Settings → Bulk data export, colei o ID do projeto do Cloud (o ID, não o número).
• Escolhi um nome do conjunto de dados (ele começará com searchconsole) e uma localização do conjunto de dados.
• Se defini a expiração de partições no conjunto de dados da exportação, mantive-a em 14 dias ou mais — um período menor interrompe a exportação.
• Deixei o esquema da tabela gerada inalterado (crie tabelas derivadas).
• Esperei até 48 horas pela primeira exportação (o processo deve começar em cerca de um dia) e confirmei que os dados chegaram (verifique ExportLog e as duas tabelas searchdata_*).
• Configurei um alerta de orçamento no Google Cloud para que uma consulta descontrolada não cause uma surpresa.
• Defini a expiração de partições nas tabelas derivadas caso não precise de retenção ilimitada.
• Criei painéis sobre tabelas de resumo materializadas, não sobre as tabelas brutas da exportação.

Erros e mitos a evitar

“Turning it on backfills my old data.” (tradução) «Ativar isso faz o preenchimento retroativo dos meus dados antigos.» Não. A exportação começa no dia da ativação e só acumula dali em diante — nada anterior é incluído. É a pergunta mais frequente sobre esse recurso no fórum da comunidade do Google. Ative-a assim que souber dela para começar a construir o histórico.

“BigQuery export finally shows me the hidden/anonymized queries.” (tradução) «A exportação para o BigQuery finalmente mostra as consultas ocultas/anonimizadas.» Não. Consultas anonimizadas chegam como strings vazias em query; seus cliques e impressões são incorporados aos totais, mas nunca atribuídos a um termo — assim como na interface e na API. No meu estudo da Ahrefs, ~46 % dos cliques foram para consultas que o Google não divulga, e até a API — que “allows us to get all of the data” (tradução) «permite obter todos os dados» — não conseguiu revelá-las. A exportação em massa não muda isso aqui.

“It’s completely free.” (tradução) «É totalmente gratuito.» Parcialmente verdade. Há uma camada gratuita real, mas ela exige uma conta de faturamento ativa, e consultas ineficientes podem gerar cobrança. “Free” (tradução) «Gratuito» só é verdade se você consultar com eficiência.

“More traffic means a bigger BigQuery bill.” (tradução) «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 com tráfego modesto e uma variedade enorme de cauda longa pode gerar mais dados que um site de alto tráfego com um punhado de consultas concentradas.

Apontar um painel ativo para as tabelas brutas. O erro mais caro de todos. Um caso documentado viu o Looker Studio examinar 23 TB em um dia (~€115) conectado diretamente a tabelas brutas com bilhões de linhas. Solução: materialize tabelas de resumo em um cronograma 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 curta demais. Alterar searchdata_site_impression, searchdata_url_impression ou ExportLog interrompe a exportação. O mesmo acontece ao definir a expiração de partição do conjunto de dados da exportação abaixo do mínimo de 14 dias do Google. Crie suas próprias tabelas derivadas, deixe as originais intactas e dê a qualquer política de expiração no conjunto de dados bruto uma margem de 14+ dias.

“This replaces the Search Console API.” (tradução) «Isso substitui a API do Search Console.» Ferramentas diferentes para trabalhos diferentes. A API serve para consultas pontuais e programáticas; a exportação em massa é um fluxo diário contínuo para armazenamento e junções.

Supor que você só pode exportar uma propriedade por projeto. Desatualizado. Mais tarde, o Google permitiu várias propriedades no mesmo projeto do Cloud por meio de nomes distintos de conjuntos de dados com o prefixo searchconsole_.

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

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

2. Respeite a granularidade da tabela. searchdata_site_impression responde a perguntas no nível da propriedade; searchdata_url_impression adiciona a dimensão de URL. Não há garantia de que as linhas estejam pré-consolidadas, portanto toda análise deve escolher deliberadamente as dimensões e agregar os campos de cliques, impressões e posição.

3. Torne obrigatórios os filtros de partição. Exija um intervalo de data_date em toda consulta. O custo acompanha os bytes examinados, e um painel sem limites sobre tabelas brutas pode examinar 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 painel para esses resumos. Alterações de esquema nas tabelas de exportação podem interromper o pipeline de entrega.

5. Opere o pipeline como dados de produção. Monitore ExportLog, os bytes das consultas, falhas de jobs agendados e atualização. A exportação não faz preenchimento retroativo, então dias ausentes são um incidente operacional, não algo que a ativação possa corrigir depois.

Problemas comuns da exportação em massa do GSC

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

Sintoma: o Search Console rejeita o projeto ou o conjunto de dados antes da ativação. Causa provável: o faturamento ou as APIs BigQuery necessárias não estão habilitados, o ID do projeto está errado ou a conta de serviço de exportação do Search Console não tem BigQuery Job User e BigQuery Data Editor. Solução: corrija esses pré-requisitos, execute novamente o Test report e ative somente depois que ele for aprovado.

Nenhuma tabela ou linha nova aparece

Sintoma: o conjunto de dados existe, mas os dados esperados da exportação 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 as falhas estão se acumulando. Soluçã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 preenchimento retroativo de datas anteriores.

Os totais de consultas parecem duplicados ou inflados

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

A posição média está um abaixo

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

Um painel fica repentinamente caro

Sintoma: os bytes processados e as cobranças de consulta aumentam embora o tráfego não tenha mudado. Causa provável: o painel está examinando tabelas brutas no nível da URL sem filtro de partição. Solução: inspecione os bytes antes de executar, adicione um predicado data_date limitado, materialize o resumo diário necessário e aponte o painel 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 consegue gravar no projeto

Teste a executar — Execute Settings → Bulk data export → Test report depois de alterar o projeto, as APIs ou as funções do IAM. Resultado esperado — o Search Console informa que o destino é válido. Interpretação da 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 rollback — não ative nem altere o destino da exportação de produção enquanto o teste falhar.

Confirme uma entrega diária completa

Teste a executar — Verifique em ExportLog o data_date esperado mais recente e depois consulte ambas as tabelas de impressões para a 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 da falha — a exportação está atrasada ou falhou; um resultado vazio não é preenchimento retroativo histórico. Janela de monitoramento — permita o atraso de dados documentado e a janela de exportação inicial antes de declarar falha. Gatilho de rollback — pause a publicação de qualquer relatório downstream se a data mais recente estiver ausente ou apenas uma tabela obrigatória tiver chegado.

Confirme que uma consulta modelada reconcilia

Teste a executar — Execute a nova consulta de resumo para uma data fixa e um tipo de pesquisa, depois compare seus cliques e impressões totais com uma agregação direta da mesma partição bruta. Resultado esperado — os totais coincidem na mesma granularidade e com os mesmos filtros. Interpretação da falha — o modelo está descartando linhas, contando dimensões em duplicidade ou misturando granularidades de site e URL. Janela de monitoramento — imediatamente após a conclusão da consulta. Gatilho de rollback — mantenha os painéis no resumo anterior até que o novo modelo seja reconciliado.

Confirme a proteção de custos

Teste a executar — Visualize os bytes processados para a consulta de produção com seu filtro data_date pretendido. Resultado esperado — a varredura fica limitada às partições solicitadas e é consistente com a referência estabelecida pela equipe para esse relatório. Interpretação da falha — a eliminação de partições está ausente ou uma junção ampliou a varredura. Janela de monitoramento — antes de cada mudança em consulta agendada ou painel. Gatilho de rollback — não implante uma versão cuja varredura estimada exceda materialmente a referência 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 estão pré-consolidadas), filtre a partição de data para controlar custos 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 no nível da 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 resultados avançados de FAQ (uma flag de resultado avançado 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 painéis 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;

Um hábito de controle de custos: verifique quantos bytes uma consulta examinará antes de executá-la, usando a flag dry-run na CLI bq — uma forma gratuita de detectar uma varredura acidental da tabela inteira.

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 o BigQuery — folha de consulta rápida

Configuração de relance

As três tabelas

Regras de consulta

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

Fatos rápidos

• Sem preenchimento retroativo — os dados começam na ativação e avançam somente dali.
• Consultas anonimizadas permanecem ocultas (string query vazia) — o mesmo que na interface/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 tentativas por data → ~1 mês de falhas interrompe a exportação inteira.
• Piso de expiração da partição: mínimo de 14 dias no conjunto de dados da exportação; um período menor a interrompe.
• 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_.
• Camada gratuita (verifique a atual): ~10 GiB de armazenamento + ~1 TiB de consultas/mês, depois ~6,25 USD/TiB.
• Bing: nenhum equivalente nativo — é necessário um conector de terceiros.

Prompts para revisar o trabalho do GSC no BigQuery

Audite uma consulta quanto à correção e ao custo

Cole os esquemas das tabelas, o SQL, sua finalidade e o escopo de data/tipo de pesquisa. Peça ao modelo que retorne SQL corrigido e uma explicação curta; 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.

Projete uma camada segura de relatórios

Cole as perguntas que o painel precisa responder e o esquema real. Espere uma proposta de granularidade da tabela de resumo e um plano de validação, não uma implantação pronta para executar fabricada.

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 do BigQuery ML nele.
• Controles de custo do BigQuery — budget alerts do Google Cloud, limites de bytes por consulta e a flag bq --dry_run para estimar o tamanho da varredura antes da execução.
• Looker Studio — para painéis, mas crie-os sobre tabelas de resumo materializadas, não sobre a exportação bruta. (O Looker Studio também tem um conector nativo do Search Console que não precisa do BigQuery — muitas vezes ele basta sozinho.)
• Google Search Console — a fonte; a exportação pela interface e o Performance report são a referência que a exportação em massa amplia.
• Search Console API — o degrau intermediário quando você precisa de mais que a interface, mas não de um armazém contínuo.
• Conectores ETL de terceiros (Supermetrics, Improvado, Catchr e outros) — como obter dados do Bing Webmaster Tools no BigQuery, já que o Bing não tem exportação nativa.

Recursos que valem seu tempo

Meus textos relacionados

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

Minhas falas / posts

• Como extrair mais dos dados do GSC — um passo a passo para extrair mais dos dados do Search Console (por meio dos próprios recursos do GSC da Ahrefs), parte do mesmo fio condutor de que “there’s more here than the UI shows” (tradução) «há mais aqui do que a interface mostra» que a exportação do BigQuery.

Do setor

• O 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 a formulação original do Google citada literalmente.
• 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 a usar consultas do GSC no BigQuery (Search Engine Journal) — uma consulta inicial prática.
• Google Search Console para BigQuery: o guia completo (Trevor Fox) — a origem do enquadramento de custo “keyword variety, not search volume” (tradução) «variedade de palavras-chave, não volume de pesquisa».
• Chega de amostragem! Obtenha dados mais completos do GSC com o BigQuery (Advanced Web Ranking, Sam Torres) — fundamentos 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 o atraso de dados de dois dias.
• Como usar seus dados do GSC no BigQuery como um profissional (Antoine Eripret) — o mergulho técnico, incluindo o caso de horror do custo de 23 TB / ~€115 e a realidade de não haver preenchimento retroativo.

Estatísticas que vale citar

• ~46% dos cliques do GSC vão para consultas não divulgadas. Do meu estudo da Ahrefs com 146 741 sites e aproximadamente 9B 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 ativo conectado às tabelas brutas examinou 23 TB em um dia (~€115). Caso documentado por Antoine Eripret que mostra por que você deve materializar tabelas de resumo em vez de consultar a exportação bruta diretamente. Fonte
• Atraso de dois dias nos dados. “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 ficam disponíveis com um atraso de dois dias, portanto os dados mais recentes disponíveis serão sempre 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 gratuitamente, depois cerca de 6,25 USD/TiB processado. Fonte

Teste seus conhecimentos: exportação do GSC para o BigQuery

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

Registro de alterações