Esportazione GSC BigQuery

TL;DR — L’esportazione BigQuery di GSC (Google la chiama esportazione bulk dei dati) copia automaticamente i tuoi dati di Search Console in un database Google Cloud chiamato BigQuery, una volta al giorno, senza limite di righe. È così che ottieni molti più dati su clic e impressioni rispetto alla vista ridotta che mostra l’interfaccia di Search Console — anche se le query anonimizzate (nascoste) restano nascoste anche qui. Due avvertenze da sapere subito: non recupera i tuoi dati storici (solo i dati dal giorno in cui lo attivi, in poi), e richiede un account di fatturazione Google Cloud anche se esiste un livello gratuito.

Cos’è

L’esportazione bulk dei dati di Search Console può inviare dati giornalieri sulle prestazioni a 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 Google documenta tabelle separate per impressioni del sito, impressioni degli URL e log di esportazione, con schema e limiti di aggregazione che contano durante l’analisi. 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

Questa guida copre le proprietà del sito web. Le più recenti proprietà di piattaforma di Search Console per Instagram, TikTok, X e YouTube hanno report su Prestazioni, Approfondimenti e Risultati, ma la documentazione attuale di Google sulle proprietà di piattaforma non documenta una configurazione o uno schema di esportazione bulk BigQuery per esse. Tratta le proprietà di piattaforma come non supportate qui, a meno che Google non esponga l’impostazione e documenti il contratto. LinkedIn non è attualmente una proprietà di piattaforma supportata.

Apri il report Prestazioni in Google Search Console e prova a esportarlo. Ti scontrerai presto con un muro: l’interfaccia limita la maggior parte delle esportazioni a circa 1 000 righe e mostra solo circa gli ultimi 16 mesi di cronologia. Per un sito piccolo va bene. Per un sito grande con decine di migliaia di pagine e un’enorme varietà di query di ricerca, stai vedendo una piccola fetta dei tuoi dati reali.

L’esportazione bulk dei dati risolve questo problema. È un interruttore all’interno di Search Console che dice: “da ora in poi, invia i miei dati sulle prestazioni a BigQuery ogni giorno.” BigQuery è il data warehouse di Google — un posto per archiviare grandi tabelle ed eseguire query su di esse. Una volta che l’esportazione è attiva, ottieni dati giornalieri non campionati senza limite di 1 000 righe, conservati per tutto il tempo che vuoi — con un’eccezione permanente: le query anonimizzate (quelle che Search Console nasconde per la privacy) appaiono ancora vuote, come nell’interfaccia. “Nessun limite di righe” non è la stessa cosa di “ogni query rivelata”.

Perché qualcuno lo fa

Configureresti questo se vuoi:

• Analizzare molte più query e pagine di quanto ti diano l’interfaccia o il pulsante di esportazione.
• Conservare la cronologia di Search Console più a lungo di 16 mesi (Search Console butta via i vecchi dati; BigQuery conserva tutto ciò che conservi tu).
• Unire i tuoi dati di Search Console con altri dati — i tuoi dati di Google Analytics, una scansione, il tuo database di prodotti — tutto in un unico posto.

Le due cose da sapere prima di iniziare

1. Non fa backfill. Questo è l’imprevisto più comune. Attivare l’esportazione non va a prendere i tuoi dati storici. Inizia a raccogliere da quel giorno in poi. Se vuoi la cronologia, devi attivarla e poi aspettare che si accumuli.
2. È “gratuito” con un asterisco. BigQuery ha un livello gratuito, e la maggior parte dei siti piccoli e medi ci sta dentro. Ma devi comunque collegare un account di fatturazione Google Cloud, e se interroghi i dati con noncuranza — specialmente puntando una dashboard live alle tabelle grezze — puoi accumulare una bolletta vera.

Ne vale la pena per te?

Onestamente, la maggior parte dei siti non ne ha bisogno. Se l’interfaccia di Search Console e il connettore Search Console integrato in Looker Studio ti mostrano abbastanza, hai finito — salta la configurazione. Ricorri all’esportazione BigQuery quando colpisci costantemente quel muro di 1 000 righe, quando ti servono più di 16 mesi di cronologia, o quando vuoi che i tuoi dati di Search Console stiano accanto agli altri dati in un warehouse. Se è il tuo caso, passa alla scheda Avanzate per la configurazione completa, i meccanismi di costo e le prime query da eseguire.

TL;DR — L’esportazione bulk dei dati è un dump giornaliero, non campionato e pianificato dei tuoi dati Performance di Search Console in un dataset BigQuery — niente limite di esportazione di ~1 000 righe, niente muro di conservazione di ~16 mesi. Crea tre tabelle (searchdata_site_impression, searchdata_url_impression, ExportLog). Configurazione: un progetto Google Cloud con fatturazione attiva, API BigQuery + BigQuery Storage attive, due ruoli IAM concessi all’account di servizio di esportazione di Google, poi Impostazioni → Esportazione bulk dei dati in GSC. Non esegue il backfill, riporta ancora le query anonimizzate come stringhe vuote, e la prima esportazione arriva entro ~48 ore. Il costo è un vero livello gratuito più addebiti per query per TB — la fattura classica arriva dai dashboard che interrogano le tabelle grezze in tempo reale. Consideralo come il terzo gradino: UI → API → esportazione bulk.

La scala seguente è per le proprietà del sito web. Non è una prova che le proprietà delle piattaforme social o video supportino l’API di Search Console o l’esportazione BigQuery.

Cosa è realmente

L’esportazione bulk è una pipeline pianificata di dati di Search Console in un progetto Google Cloud, non una fonte indipendente di dati di ranking. 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 Le query devono rispettare le tabelle, le chiavi e il comportamento di privacy/aggregazione documentati. 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, un Search Advocate di Google, lo descrive chiaramente: “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.” (traduzione) «Un’esportazione bulk dei dati è un’esportazione giornaliera pianificata dei tuoi dati Performance di Search Console. Include tutti i dati utilizzati da Search Console per generare i report Performance. I dati vengono esportati in Google BigQuery, dove puoi eseguire query SQL per analisi avanzate dei dati o persino esportarli in un altro sistema.» (citato in Search Engine Journal).

Il punto è la scala. L’interfaccia di Search Console limita la maggior parte delle esportazioni a circa 1 000 righe e mostra una finestra mobile di ~16 mesi. L’API di Search Console ti dà di più ma è ancora limitata e soggetta a limiti di frequenza. L’esportazione bulk rimuove completamente il tetto delle righe e ti permette a te di decidere per quanto tempo conservare i dati. La dichiarazione di Google dall’annuncio, come riprodotta da Search Engine Land: “The daily data row limit does not impact this data, so you can extract more data using this method,” (traduzione) «Il limite giornaliero di righe di dati non incide su questi dati, quindi puoi estrarre più dati usando questo metodo», e la funzionalità “could be particularly helpful for large websites with tens of thousands of pages.” (traduzione) «potrebbe essere particolarmente utile per siti web di grandi dimensioni con decine di migliaia di pagine».

Quali dati ottieni: le tre tabelle

Tutto finisce in un dataset il cui nome inizia sempre con searchconsole. Tre oggetti compaiono (Linee guida e riferimento per le tabelle):

1. searchdata_site_impression — “Contains performance data for your property aggregated by property.” Key fields: data_date (“The day on which the data in this row was generated (Pacific Time)”), site_url (domain properties use the sc-domain: prefix), query, is_anonymized_query, country (ISO-3166-1 Alpha-3), search_type (web/image/video/news/discover/googleNews), device, impressions, clicks, and sum_top_position.
2. searchdata_url_impression — “Contains performance data for your property aggregated by URL.” Everything above, plus url (“The fully-qualified URL where the user eventually lands when they click the search result”), is_anonymized_discover, a family of is_[search_appearance_type] boolean flags (e.g. is_amp_top_stories, is_job_listing, is_tpf_faq) so you can slice by rich-result type, and sum_position. This is the granular table most analysis runs on.
3. ExportLog — “A record of what data was saved for that day. Failed exports are not recorded here.” Fields include agenda (currently only SEARCHDATA), namespace (which table was written), data_date, epoch_version (“An integer, where 0 is the first time data was saved to this table” — it increments when Google later revises a day’s data), and 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.

Come configurarlo

Il flusso (Start a new bulk data export):

1. Crea o scegli un progetto Google Cloud con fatturazione attivata. Secondo Google: “Data is subject to Google Cloud storage and query costs, but there is a free usage level.” (traduzione) «I dati sono soggetti ai costi di archiviazione e query di Google Cloud, ma esiste un livello di utilizzo gratuito.» Devi avere la fatturazione attiva anche solo per restare nel livello gratuito.
2. Abilita l’API BigQuery e l’API BigQuery Storage in quel progetto.
3. Concedi l’accesso all’account di servizio di esportazione di Google. Aggiungi search-console-data-export@system.gserviceaccount.com come principal con due ruoli IAM: BigQuery Job User (bigquery.jobUser) e BigQuery Data Editor (bigquery.dataEditor).
4. In Search Console, vai su Impostazioni → Esportazione dati in blocco. Incolla l’ID progetto Cloud (l’ID, non il numero di progetto), scegli un nome del set di dati e scegli una posizione del set di dati. Nota la regola di denominazione: “The dataset name always starts with the string searchconsole, even when you customize it.” (traduzione) «Il nome del set di dati inizia sempre con la stringa searchconsole, anche quando lo personalizzi.» Se imposti una policy di scadenza della partizione sul set di dati dell’esportazione stesso, mantienila a 14 giorni o più — Google documenta un minimo di 14 giorni, e andare più in basso è una causa di errore documentata. Lascia intatto anche lo schema della tabella generato; alterarlo è l’altro modo documentato per rompere l’esportazione (maggiori dettagli nella sezione Risoluzione dei problemi qui sotto).
5. Aspetta. Google dice che il processo di esportazione stesso dovrebbe iniziare entro circa un giorno dall’attivazione. “The first export will happen up to 48 hours after your successful configuration in Search Console,” (traduzione) «La prima esportazione avverrà entro 48 ore dalla configurazione riuscita in Search Console,» e quella prima consegna contiene solo i dati del giorno dell’esportazione — niente di prima della configurazione (vedi la sezione successiva sul mancato backfill). Dopo di che viene eseguita quotidianamente finché non la interrompi.

Un’aspettativa pratica da impostare: i dati di Search Console arrivano con un ritardo di due giorni, quindi il giorno più recente che avrai mai è due giorni fa. Se chiedi un intervallo di 30 giorni, in pratica ottieni circa 28 giorni di dati utilizzabili.

Il problema del mancato backfill

Dillo ad alta voce, perché brucia le persone: attivare l’esportazione non recupera i tuoi dati storici. Inizia dal giorno dell’attivazione e si accumula solo in avanti. Questo è abbastanza comune che il forum della community di Google ha più thread al riguardo — “How to backfill with historical data when Bulk data export is activated” (traduzione) «Come fare il backfill con dati storici quando l’esportazione dati in blocco è attivata» (thread 300051568), thread 255704574 e thread 429248330. Antoine Eripret lo dice senza mezzi termini nel suo approfondimento pratico: “You can’t get historical data: if you activate it today, you’ll have data from today.” (traduzione) «Non puoi ottenere dati storici: se lo attivi oggi, avrai dati da oggi.» Il messaggio è semplice — attivalo il giorno in cui ne senti parlare per la prima volta, anche se non sei ancora pronto ad analizzare nulla, così l’orologio parte.

Quanto costa e come non farsi sorprendere

Il post del blog Google Cloud di Daniel Waisberg e Gaal Yahas vende il lato positivo — “If you have a large website, this solution will provide more queries and pages than the other data exporting solutions” (traduzione) «Se hai un sito web di grandi dimensioni, questa soluzione fornirà più query e pagine rispetto alle altre soluzioni di esportazione dati» 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” (traduzione) «Search Console conserva fino a sedici mesi di dati; usando BigQuery puoi conservare tutti i dati che hanno senso per la tua organizzazione» — ma i meccanismi di costo dipendono da te.

Al momento in cui scrivo, il livello gratuito di BigQuery è circa 10 GiB di archiviazione gratuiti più 1 TiB (~1 TB) di elaborazione query on-demand gratuita al mese; oltre a questo, si parla di circa 6,25 USD USD per TiB elaborato e circa 0,02 USD per GB archiviato al mese (varia in base alla regione e alla classe di archiviazione). I prezzi cambiano, quindi verifica i numeri attuali prima di citarli a qualcuno. La maggior parte dei siti piccoli e medi rimane gratuita o quasi.

Le bollette arrivano da come interroghi, non da quanto traffico hai. Due cose contano:

• Il costo scala con la diversità di query/parole chiave, non con il traffico grezzo. Come dice Trevor Fox nella sua guida completa: “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.” (traduzione) «Il volume di dati è più un fattore della varietà di parole chiave che del volume di ricerca. Un sito con un basso volume di ricerca per molte parole chiave genererà più dati di un sito con molto volume di ricerca per una singola parola chiave.»
• Non collegare una dashboard live alle tabelle grezze. Questa è la classica storia dell’orrore. Antoine Eripret ha documentato Looker Studio che scansiona 23 TB in un solo giorno, circa 115 €, quando collegato direttamente alle tabelle grezze con miliardi di righe. Il post sui suggerimenti di efficienza di BigQuery di Google dice lo stesso in linea di principio: pre-aggregare in tabelle di riepilogo, filtrare sulla partizione di data in una clausola WHERE, evitare SELECT *, impostare avvisi di budget e impostare la scadenza della partizione per eliminare automaticamente le vecchie partizioni.

La soluzione è noiosa ma efficace: materializza i risultati delle tue query in piccole tabelle di riepilogo permanenti secondo una pianificazione e punta le tue dashboard a quelle, non all’esportazione grezza.

Query: le regole che ti mantengono sano (ed economico)

Dalle linee guida sulle query di Google:

• Aggrega sempre. “Data in the tables is not guaranteed to be consolidated by date, URL, site, or any combination of keys.” (traduzione) «I dati nelle tabelle non sono garantiti come consolidati per data, URL, sito o qualsiasi combinazione di chiavi.» Traduzione: otterrai più righe per lo stesso giorno/URL/query, quindi fai sempre SUM() delle tue metriche e GROUP BY delle tue dimensioni. Non trattare mai una singola riga come un numero definitivo.
• Filtra la partizione di data. “A good way to minimize query costs is to use a WHERE clause to limit the date range in the date partitioned table.” (traduzione) «Un buon modo per minimizzare i costi delle query è usare una clausola WHERE per limitare l’intervallo di date nella tabella partizionata per data.»
• Elimina le righe anonimizzate quando vuoi le vere query principali. “An anonymized query is reported as a zero-length string in the table” (traduzione) «Una query anonimizzata viene riportata come stringa di lunghezza zero nella tabella» — quindi aggiungi WHERE query != ''.
• La posizione è a base zero. Entrambe le tabelle memorizzano la posizione a partire da 0, quindi la posizione media è SUM(sum_top_position) / SUM(impressions) + 1 (aggiungi l’1).

Google fornisce query di esempio per le statistiche giornaliere di ricerca web, le principali query mobili per paese, gli URL di Discover per clic, le prestazioni dei rich result FAQ (is_tpf_faq = true) e il monitoraggio delle query di marca tramite REGEXP_CONTAINS. Inizia da quelle.

Gestione e risoluzione dei problemi dell’esportazione

Da Gestire e monitorare le esportazioni di dati in blocco:

• L’arresto non è immediato. Impostazioni → Esportazione dati in blocco → Disattiva esportazione. “Le esportazioni in blocco si fermeranno nelle prossime 24 ore,” quindi un altro giorno di dati potrebbe ancora arrivare dopo che l’hai disattivata.
• Due soglie di errore, non una. “Search Console conserva i dati delle esportazioni fallite per circa una settimana.” E poi: “Search Console smetterà di tentare di esportare i dati per una data specifica dopo circa una settimana di tentativi falliti, e dopo circa un mese di tentativi di esportazione falliti, Search Console interromperà completamente l’esportazione in blocco.” Quindi un problema persistente non salta solo i giorni — dopo circa un mese disattiva l’intera esportazione, e dovresti configurarla di nuovo.
• La trappola del cambiamento di schema (e il limite minimo di scadenza delle partizioni). Se modifichi lo schema di una tabella esportata, interrompi l’esportazione. Google richiede inoltre almeno 14 giorni di scadenza delle partizioni sul dataset di esportazione — se la imposti più breve, l’esportazione può fallire. Lascia stare quelle tabelle; crea invece le tue tabelle derivate. (Altre cause comuni di errore includono il superamento della quota del tuo progetto Cloud e la revoca dell’accesso dell’account di servizio.)
• Usa il report di test. C’è una funzione “Test report” che ti permette di verificare alcuni problemi correggibili — ID progetto/credenziali, autorizzazioni — senza aspettare la prossima esecuzione programmata. Nota che non forza una riesportazione immediata; controlla di nuovo circa 24 ore dopo per confermare che la correzione abbia funzionato.
• Search Console invia email ai proprietari delle proprietà quando iniziano gli errori di esportazione e quando si risolvono, e le Impostazioni mostrano lo stato del tentativo di esportazione più recente.

Dove si colloca: UI → API → esportazione in blocco

Pensa a tre gradini di una scala, ognuno dei quali rimuove un limite che quello sottostante ha raggiunto:

• Esportazione UI — ~1 000 righe, ~16 mesi, nessuna query anonimizzata. Va bene per la maggior parte.
• API Search Console — più righe, ancora limitata e con limiti di frequenza, ancora nessuna query anonimizzata. Buona per estrazioni ad hoc e programmatiche.
• Esportazione dati in blocco — nessun limite di righe, conservazione che controlli tu, dati granulari giornalieri, progettata per data warehousing e join. Ancora nessuna query anonimizzata. Non fa backfill.

E una sfumatura che le guide più vecchie sbagliano: non sei più limitato a una proprietà per progetto Cloud. Google ha successivamente permesso più proprietà in un singolo progetto utilizzando nomi di dataset distinti con prefisso searchconsole_.

E Bing?

Al momento in cui scrivo, non esiste un equivalente nativo. Bing Webmaster Tools non offre un’esportazione in blocco/BigQuery di prima parte — che è esattamente il motivo per cui esiste un mercato di connettori ETL di terze parti (Supermetrics, Improvado, Catchr e altri) per spostare i dati di Bing Webmaster Tools in BigQuery. Se Bing avesse una pipeline nativa, quel mercato non esisterebbe. Detto questo, un connettore non è garantito che replichi lo schema di esportazione di GSC o il comportamento di partizionamento giornaliero campo per campo — controlla l’ambito documentato di qualsiasi connettore prima di assumere la parità. Quindi se vuoi i dati di Bing in BigQuery insieme alla tua esportazione GSC, metti in budget un connettore e verifica cosa consegna effettivamente. (Conferma che questo sia ancora attuale prima di citarlo — il set di funzionalità di Bing può cambiare.)

Per il contesto più ampio su dove si colloca, vedi l’hub Search Engine Tools e i suoi walkthrough di Google Search Console e Bing Webmaster Tools.

Riepilogo AI

Una sintesi della versione Advanced:

• Cos’è: l’esportazione di dati in blocco — un dump giornaliero, non campionato dei dati Performance di Search Console in un dataset BigQuery di Google Cloud. Rimuove il limite di esportazione di ~1 000 righe dell’interfaccia e la sua finestra di conservazione di ~16 mesi.
• Tre tabelle finiscono in un dataset con prefisso searchconsole: searchdata_site_impression (a livello di proprietà), searchdata_url_impression (a livello di URL, con flag is_* per i rich result) e ExportLog (un record di esportazione giornaliero).
• Configurazione: progetto Google Cloud con fatturazione attiva → abilita le API BigQuery e BigQuery Storage → concedi a search-console-data-export@system.gserviceaccount.com i ruoli BigQuery Job User e BigQuery Data Editor → Impostazioni di Search Console → Esportazione dati in blocco → ID progetto, nome del dataset, posizione (mantieni la scadenza della partizione a 14+ giorni) → il processo inizia entro circa un giorno, prima esportazione entro ~48 ore.
• Nessun backfill. Inizia dal giorno di attivazione in poi — non viene recuperato nulla di storico. Questo è il punto di confusione numero uno.
• Ancora nessuna query anonimizzata. Finiscono come stringhe vuote in query; le metriche sono aggregate ma mai attribuibili. Nello studio Ahrefs di Patrick su 146 741 siti e quasi 9 miliardi di clic, ~46% dei clic è andato a query non divulgate — l’esportazione in blocco non le recupera.
• Costo: un vero livello gratuito (circa 10 GiB di storage + 1 TiB di query/mese) ma richiede un account di fatturazione, e il costo scala con la diversità di query/parole chiave, non con il traffico. La fattura classica è una dashboard che interroga le tabelle grezze in tempo reale (un caso documentato: 23 TB / ~€115 in un giorno). Soluzione: materializza tabelle di riepilogo, filtra la partizione di data, evita SELECT *.
• Query: usa sempre SUM()/GROUP BY (le righe non sono pre-consolidate), filtra query != '' per eliminare le righe anonimizzate, e la posizione è zero-based (aggiungi 1).
• Gestione: la disattivazione richiede fino a 24 ore; le esportazioni fallite vengono ritentate per circa una settimana per data, e circa un mese di fallimenti disattiva l’intera esportazione; modificare lo schema di una tabella esportata o impostare la scadenza della partizione sotto i 14 giorni la rompe.
• Bing non ha un equivalente nativo al momento della scrittura — i connettori di terze parti colmano il divario, anche se non corrispondono necessariamente esattamente allo schema dell’esportazione GSC.
• La scala: UI → API → esportazione in blocco, ognuna rimuove un limite.

Documentazione ufficiale

Documentazione di fonti primarie, principalmente dalla Guida di Search Console di Google e dal Google Cloud Blog.

Google — la funzionalità

• Informazioni sull’esportazione in blocco dei dati di Search Console in BigQuery — la panoramica e cosa è incluso/escluso.
• Avvia una nuova esportazione in blocco — il flusso di configurazione: progetto, API, ruoli dell’account di servizio, impostazioni del dataset, ritardo di 48 ore.
• Linee guida e riferimento per le tabelle — lo schema completo per searchdata_site_impression, searchdata_url_impression e ExportLog.
• Linee guida per le query e query di esempio — come aggregare, minimizzare i costi, filtrare le righe anonimizzate e query di esempio pronte.
• Gestisci e monitora le esportazioni in blocco — disattivazione, gestione degli errori, soglie di retry/conservazione e il report di test.

Google — annuncio e inquadramento

• Esportazione in blocco: un modo nuovo e potente per accedere ai tuoi dati di Search Console (Search Central Blog, febbraio 2023) — l’annuncio originale.
• Analizza i dati di ricerca Google con BigQuery (Google Cloud Blog, Daniel Waisberg & Gaal Yahas) — l’inquadramento avanzato/ML.
• Suggerimenti per l’efficienza di BigQuery per le esportazioni in blocco di Search Console (Search Central Blog, giugno 2023) — guida su costi ed efficienza delle query.

Prezzi

• Prezzi di BigQuery — il livello gratuito attuale e le tariffe per TB/GB (verifica prima di citare; cambiano).

Citazioni dalla fonte

Dichiarazioni pubbliche di Google. Quando una pagina viene renderizzata tramite JavaScript e resiste alla verifica automatizzata, la citazione è tratta da copertura secondaria verbatim ed è segnalata di seguito.

Google — cos’è

• “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.” (traduzione) «Pianifica un’esportazione giornaliera dei dati sulle prestazioni di Search Console in BigQuery, dove puoi eseguire query complesse sui tuoi dati o esportarli in un servizio di archiviazione esterno.» — Guida di Search Console di Google. Vai alla citazione
• “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.” (traduzione) «Un’esportazione di dati in blocco è un’esportazione giornaliera pianificata dei dati sulle prestazioni di Search Console. Include tutti i dati utilizzati da Search Console per generare i report sulle prestazioni. I dati vengono esportati in Google BigQuery, dove puoi eseguire query SQL per analisi avanzate o addirittura esportarli in un altro sistema.» — Daniel Waisberg, Search Advocate, Google. Vai alla citazione

Google — lo schema

• “Contains performance data for your property aggregated by property.” (su searchdata_site_impression) e “Contains performance data for your property aggregated by URL.” (su searchdata_url_impression). (traduzione) «Contiene i dati sulle prestazioni della tua proprietà aggregati per proprietà.» e «Contiene i dati sulle prestazioni della tua proprietà aggregati per URL.» Vai alla citazione
• “The user query. When is_anonymized_query is true, this will be a zero-length string.” (traduzione) «La query dell’utente. Quando is_anonymized_query è true, questa sarà una stringa di lunghezza zero.» Vai alla citazione

Google — interrogazione

• “Data in the tables is not guaranteed to be consolidated by date, URL, site, or any combination of keys.” (traduzione) «I dati nelle tabelle non sono garantiti come consolidati per data, URL, sito o qualsiasi combinazione di chiavi.» Vai alla citazione
• “A good way to minimize query costs is to use a WHERE clause to limit the date range in the date partitioned table.” (traduzione) «Un buon modo per ridurre al minimo i costi delle query è usare una clausola WHERE per limitare l’intervallo di date nella tabella partizionata per data.» Vai alla citazione

Google — gestione dell’esportazione

• “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.” (traduzione) «Search Console conserva i dati delle esportazioni non riuscite per circa una settimana.» e «Search Console smetterà di tentare di esportare i dati per una data specifica dopo circa una settimana di tentativi falliti, e dopo circa un mese di tentativi di esportazione falliti, Search Console interromperà completamente l’esportazione in blocco.» Vai alla citazione

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.” (traduzione) «Conserva i dati per tutto il tempo che vuoi. Search Console conserva fino a sedici mesi di dati; usando BigQuery puoi conservare tutti i dati che hanno senso per la tua organizzazione.» Vai alla citazione

Esportazione di massa vs. API vs. UI vs. connettore Looker Studio: quale dovrei usare?

Parti dal limite che stai effettivamente raggiungendo, non da ciò che sembra più potente. La maggior parte delle persone che hanno configurato l’esportazione BigQuery non ne avevano bisogno.

D1. Stai raggiungendo un limite reale nell’interfaccia di Search Console? (Il limite di esportazione di ~1 000 righe, o il muro di cronologia di ~16 mesi, o devi unire GSC con altri dati.)

• No → fermati. L’UI (e il connettore nativo di Search Console di Looker Studio per le dashboard) è sufficiente. Non assumerti un warehouse di cui non hai bisogno.
• Sì → continua.

D2. Hai bisogno di un warehouse permanente e giornaliero di dati completi, o solo di un’estrazione più grande una tantum / programmatica?

• Una tantum o programmatica (uno script, un’integrazione, un’esportazione approfondita occasionale) → usa l’API di Search Console. Più dell’UI, nessun BigQuery da eseguire, ma comunque limitata/rate-limited e ancora senza query anonimizzate.
• Pipeline giornaliera permanente che metterai in warehouse e unirai con altri dati → continua.

D3. Ti senti a tuo agio con un progetto Google Cloud, un account di fatturazione attivo e scrivere SQL (o avere qualcuno che lo faccia)?

• No → riconsidera. Un’esportazione non gestita più una dashboard su tabelle grezze è il modo in cui arrivano le bollette a sorpresa. O chiedi aiuto o resta sul connettore API/Looker Studio.
• Sì → configura l’esportazione di dati di massa. Attivala ora (ricorda: nessun backfill) e pianifica di materializzare tabelle di riepilogo piuttosto che interrogare quelle grezze in tempo reale.

D4. Hai specificamente bisogno delle query anonimizzate/nascoste suddivise?

• Sì → nessuna di queste le fornisce. Esportazione di massa, API e UI sopprimono tutte le query anonimizzate a livello di query. Adatta l’obiettivo; i dati non esistono per essere ottenuti da Google.

La versione in una riga: non stai raggiungendo un limite → UI/Looker Studio; estrazioni ad hoc o codificate → API; warehouse permanente su larga scala → esportazione di massa; query nascoste → nessuno può dartele.

Checklist di configurazione per l’esportazione di dati di massa

Procedi dall’alto verso il basso; ogni passaggio è prerequisito del successivo.

• Attivata l’esportazione oggi stesso, anche se non sei ancora pronto ad analizzare (nessun backfill: l’orologio parte dall’attivazione).
• Esiste un progetto Google Cloud con fatturazione abilitata (la fatturazione è richiesta anche per il piano gratuito).
• API BigQuery abilitata in quel progetto.
• API BigQuery Storage abilitata in quel progetto.
• search-console-data-export@system.gserviceaccount.com aggiunto come principal con BigQuery Job User (bigquery.jobUser).
• Allo stesso account di servizio è stato concesso BigQuery Data Editor (bigquery.dataEditor).
• In Search Console → Impostazioni → Esportazione dati in blocco, incollato l’ID del progetto Cloud (l’ID, non il numero).
• Scelto un nome del dataset (inizierà con searchconsole) e una posizione del dataset.
• Se si imposta la scadenza della partizione sul dataset di esportazione, mantenerla a 14 giorni o più — una durata più breve interrompe l’esportazione.
• Lasciato lo schema della tabella generata invariato (crea invece tabelle derivate).
• Atteso fino a 48 ore per la prima esportazione (il processo stesso dovrebbe iniziare entro circa un giorno), poi verificato che i dati siano arrivati (controlla ExportLog e le due tabelle searchdata_*).
• Impostato un avviso di budget in Google Cloud così una query fuori controllo non può sorprenderti.
• Impostata la scadenza della partizione sulle tabelle derivate se non serve una conservazione illimitata.
• Creata dashboard su tabelle di riepilogo materializzate, non sulle tabelle di esportazione grezze.

Errori e miti da evitare

“Attivandola, i miei vecchi dati vengono recuperati.” No. L’esportazione parte dal giorno di attivazione e accumula solo in avanti — nulla di precedente viene incluso. È la domanda più frequente sul forum della community di Google su questa funzionalità. Attivala appena ne vieni a conoscenza così la cronologia inizia a costruirsi.

“L’esportazione BigQuery finalmente mi mostra le query nascoste/anonimizzate.” No. Le query anonimizzate arrivano come stringhe vuote in query; i loro clic e le impressioni sono inclusi nei totali ma mai attribuiti a un termine — come nell’interfaccia e nell’API. Nel mio studio Ahrefs, circa il 46% dei clic è andato a query che Google non divulga, e persino l’API — che “ci permette di ottenere tutti i dati” — non è riuscita a farle emergere. L’esportazione in blocco non cambia nulla qui.

“È completamente gratuito.” In parte vero. Esiste un vero piano gratuito, ma richiede un account di fatturazione attivo, e query inefficienti possono comportare costi. “Gratuito” vale solo se interroghi in modo efficiente.

“Più traffico significa una bolletta BigQuery più alta.” Non proprio — il costo dipende più dalla diversità di query/parole chiave che dal volume grezzo di clic. Un sito con traffico moderato e una grande varietà di long-tail può generare più dati di un sito ad alto traffico con poche query concentrate.

Puntare una dashboard live alle tabelle grezze. L’errore più costoso in assoluto. Un caso documentato ha visto Looker Studio scansionare 23 TB in un giorno (~115 €) collegato direttamente a tabelle grezze con miliardi di righe. Soluzione: materializza tabelle di riepilogo su base programmata e punta le dashboard a quelle; filtra la partizione della data in una clausola WHERE; mai SELECT *.

Modificare lo schema di una tabella esportata, o impostare una scadenza della partizione troppo breve. Alterare searchdata_site_impression, searchdata_url_impression o ExportLog interrompe l’esportazione. Lo stesso vale se si imposta la scadenza della partizione del dataset di esportazione al di sotto del minimo di 14 giorni di Google. Crea invece le tue tabelle derivate, lascia gli originali intatti e dai alla politica di scadenza sul dataset grezzo un margine di 14+ giorni.

“Questo sostituisce l’API Search Console.” Strumenti diversi per lavori diversi. L’API è per estrazioni ad hoc e programmatiche; l’esportazione in blocco è un flusso giornaliero continuo per data warehousing e join.

Presumere di poter esportare solo una proprietà per progetto. Obsoleto. Google ha successivamente permesso più proprietà in un unico progetto Cloud tramite nomi di dataset distinti con prefisso searchconsole_.

Un framework per progettare l’esportazione prima che progetti la tua bolletta

1. Inizia dalla domanda, non dal magazzino. Usa l’interfaccia per una risposta rapida, l’API Search Analytics per estrazioni programmatiche limitate e l’esportazione in blocco solo quando hai bisogno di una cronologia giornaliera persistente, di join o di più righe di quelle che gli altri livelli forniscono.

2. Rispetta la granularità della tabella. searchdata_site_impression risponde a domande a livello di proprietà; searchdata_url_impression aggiunge la dimensione URL. Le righe non sono garantite come pre-consolidate, quindi ogni analisi dovrebbe scegliere deliberatamente le dimensioni e aggregare i campi di clic, impressioni e posizione.

3. Rendi obbligatori i filtri di partizione. Richiedi un intervallo data_date in ogni query. Il costo segue i byte scansionati e una dashboard senza limiti su tabelle grezze può scansionare la stessa cronologia ripetutamente.

4. Separa i livelli grezzo, modellato e di presentazione. Mantieni invariate le tabelle di esportazione di Google, crea tabelle di riepilogo pianificate per domande ricorrenti e punta Looker Studio o un’altra dashboard su quei riepiloghi. Le modifiche allo schema delle tabelle di esportazione possono interrompere la pipeline di consegna.

5. Gestisci la pipeline come dati di produzione. Monitora ExportLog, i byte delle query, i fallimenti dei lavori pianificati e la freschezza. L’esportazione non ha backfill, quindi i giorni mancanti sono un incidente operativo, non qualcosa che l’attivazione può riparare in seguito.

Problemi comuni dell’esportazione in blocco di GSC

Il report di test fallisce durante la configurazione

Sintomo: Search Console rifiuta il progetto o il dataset prima dell’attivazione. Causa probabile: la fatturazione o le API BigQuery richieste non sono abilitate, l’ID progetto è sbagliato o l’account di servizio dell’esportazione di Search Console non dispone di BigQuery Job User e BigQuery Data Editor. Correzione: correggi questi prerequisiti, esegui di nuovo il report di test e attiva solo dopo che ha avuto successo.

Nessuna tabella o nuove righe appaiono

Sintomo: il dataset esiste, ma i dati di esportazione attesi sono assenti. Causa probabile: la prima consegna è ancora in sospeso, il nome/posizione del dataset è sbagliato, l’esportazione è stata disattivata o i fallimenti si stanno accumulando. Correzione: attendi la finestra di consegna iniziale, poi ispeziona ExportLog e lo stato dell’esportazione in blocco di Search Console. Correggi la pipeline piuttosto che ricreare il dataset, perché l’attivazione non esegue il backfill delle date precedenti.

I totali delle query sembrano duplicati o gonfiati

Sintomo: i clic o le impressioni superano il totale di Search Console per lo stesso ambito. Causa probabile: le righe grezze dell’esportazione sono state trattate come già consolidate, o i dati a livello di sito e URL sono stati mescolati. Correzione: scegli una granularità di tabella, filtra un search_type, raggruppa per le dimensioni previste e usa SUM() sui campi delle metriche prima di confrontare i totali.

La posizione media è sbagliata di uno

Sintomo: una posizione calcolata è costantemente di uno inferiore rispetto all’aspettativa dell’interfaccia. Causa probabile: i valori di posizione dell’esportazione sono a base zero. Correzione: aggrega il numeratore della posizione con le impressioni corrispondenti, poi converti alla visualizzazione a base uno familiare solo nel livello di presentazione.

Una dashboard diventa improvvisamente costosa

Sintomo: i byte elaborati e gli addebiti delle query aumentano anche se il traffico non è aumentato. Causa probabile: la dashboard sta scansionando tabelle grezze a livello di URL senza un filtro di partizione. Correzione: ispeziona i byte prima di eseguire, aggiungi un predicato data_date limitato, materializza il riepilogo giornaliero necessario e punta la dashboard su quella tabella più piccola.

Verifica che l’esportazione in blocco funzioni dopo la configurazione o una modifica alla pipeline

Conferma che Search Console possa scrivere nel progetto

Test da eseguire — Esegui Impostazioni → Esportazione dati in blocco → Report di test dopo aver modificato il progetto, le API o i ruoli IAM. Risultato atteso — Search Console segnala che la destinazione è valida. Interpretazione del fallimento — la configurazione del progetto/API o i ruoli dell’account di servizio dell’esportazione sono ancora sbagliati. Finestra di monitoraggio — Immediata. Trigger di rollback — Non attivare o cambiare la destinazione di esportazione di produzione mentre il test fallisce.

Conferma una consegna giornaliera completa

Test da eseguire — Controlla ExportLog per la data_date prevista più recente, poi interroga entrambe le tabelle delle impressioni per quella stessa partizione. Risultato atteso — il log registra la consegna e le tabelle sito/URL contengono righe per la data in cui la proprietà ha avuto attività. Interpretazione del fallimento — l’esportazione è in ritardo o è fallita; un risultato vuoto non è un backfill storico. Finestra di monitoraggio — Consenti il ritardo dati documentato e la finestra di esportazione iniziale prima di dichiarare il fallimento. Trigger di rollback — Metti in pausa qualsiasi rilascio di report a valle se la sua data più recente manca o è arrivata solo una delle tabelle richieste.

Conferma che una query modellata riconcilia

Test da eseguire — Esegui la nuova query di riepilogo per una data fissa e un tipo di ricerca, poi confronta i suoi clic e impressioni totali con un’aggregazione diretta della stessa partizione raw. Risultato atteso — i totali corrispondono allo stesso livello di granularità e filtri. Interpretazione del fallimento — il modello sta eliminando righe, contando due volte le dimensioni, o mescolando la granularità di sito e URL. Finestra di monitoraggio — Immediata dopo che la query finisce. Trigger di rollback — Mantieni le dashboard sul riepilogo precedente finché il nuovo modello non riconcilia.

Conferma il guardrail sui costi

Test da eseguire — Anteprima dei byte elaborati per la query di produzione con il suo filtro data_date previsto. Risultato atteso — la scansione è limitata alle partizioni richieste e coerente con la baseline stabilita dal team per quel report. Interpretazione del fallimento — manca il partition pruning o un join ha ampliato la scansione. Finestra di monitoraggio — Prima di ogni modifica a query pianificata o dashboard. Trigger di rollback — Non distribuire una versione la cui scansione stimata supera materialmente la baseline approvata senza una modifica spiegata del volume di dati.

Query iniziali

Queste seguono le regole di Google: aggrega tutto (le righe non sono pre-consolidate), filtra la partizione di data per controllare i costi, e ricorda che la posizione è zero-based. Sostituisci yourproject.searchconsole con il tuo dataset.

Query reali principali (righe anonimizzate rimosse), ultimi 28 giorni

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;

Pagine di destinazione principali per clic (tabella a livello 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;

Prestazioni dei rich result FAQ (un flag rich result sulla tabella 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;

Materializza un riepilogo giornaliero così le dashboard non toccano mai le tabelle raw

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;

Un’abitudine di controllo dei costi: verifica quanti byte una query andrà a scansionare prima di eseguirla, usando il flag di dry-run nella CLI bq — un modo gratuito per evitare una scansione accidentale dell’intera tabella.

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.

Esportazione GSC BigQuery — cheat sheet

Configurazione in sintesi

Le tre tabelle

Regole per le query

• Usa sempre SUM() + GROUP BY — le righe non sono pre-consolidate.
• WHERE query != '' per eliminare le righe anonimizzate.
• Filtra data_date (la partizione) per ridurre i costi.
• avg_position = SUM(sum_top_position)/SUM(impressions) + 1 (base zero, aggiungi 1).
• Mai SELECT *.

Fatti rapidi

• Nessun backfill — i dati iniziano all’attivazione, solo in avanti.
• Query anonimizzate restano nascoste (stringa query vuota) — come UI/API.
• Ritardo di due giorni sui dati più recenti.
• Disattivazione richiede fino a 24 ore (potrebbe arrivare un altro giorno).
• Soglie di errore: ~1 settimana di nuovi tentativi per data → ~1 mese di errori interrompe l’intera esportazione.
• Limite minimo di scadenza partizione: minimo 14 giorni sul dataset di esportazione; meno lo rompe.
• Nome del dataset inizia sempre con searchconsole.
• Più proprietà per progetto: usa nomi di dataset distinti con prefisso searchconsole_.
• Livello gratuito (verifica attuale): ~10 GiB di archiviazione + ~1 TiB di query/mese, poi ~$6,25 USD/TiB.
• Bing: nessun equivalente nativo — è richiesto un connettore di terze parti.

Prompt per revisionare il lavoro GSC BigQuery

Controlla una query per correttezza e costi

Incolla gli schemi delle tabelle, la SQL, il suo scopo e l’ambito di date/tipo di ricerca. Chiedi al modello di restituire la SQL corretta e una breve spiegazione, poi verifica l’output in BigQuery prima di pianificarla.

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.

Progetta un livello di reporting sicuro

Incolla le domande a cui la dashboard deve rispondere e lo schema reale. Aspettati una granularità proposta per la tabella di riepilogo e un piano di validazione, non una distribuzione pronta all’uso inventata.

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.

Strumenti attorno all’esportazione

• Google BigQuery — dove arrivano i dati; esegui SQL, pianifica query e costruisci modelli BigQuery ML su di esso.
• Controlli dei costi BigQuery — avvisi di budget di Google Cloud, limiti di byte per query e il flag bq --dry_run per stimare la dimensione della scansione prima di eseguire.
• Looker Studio — per le dashboard, ma costruiscile su tabelle di riepilogo materializzate, non sull’esportazione grezza. (Looker Studio ha anche un connettore nativo per Search Console che non richiede affatto BigQuery — spesso sufficiente da solo.)
• Google Search Console — la fonte; l’esportazione UI e il report Performance sono la base che l’esportazione in blocco estende.
• API Search Console — il gradino intermedio quando ti serve più della UI ma non un warehouse permanente.
• Connettori ETL di terze parti (Supermetrics, Improvado, Catchr e altri) — come otterresti i dati di Bing Webmaster Tools in BigQuery, poiché Bing non ha un’esportazione nativa.

Risorse che meritano il tuo tempo

I miei scritti correlati

• Quasi la metà dei clic di GSC va a query anonime — il mio studio Ahrefs (146 741 siti, ~9 miliardi di clic) che mostra come il 46,08% dei clic vada a query che Google non divulga. Direttamente rilevante: l’esportazione BigQuery non recupera nemmeno uno di questi.
• La guida per principianti alla SEO tecnica — dove si collocano Search Console e il lavoro di analisi dei dati nel quadro più ampio.

I miei interventi / post

• Come ottenere di più dai dati di GSC — una guida per estrarre di più dai dati di Search Console (tramite le funzionalità GSC di Ahrefs), parte dello stesso filone “c’è più di quanto mostri l’interfaccia” dell’esportazione BigQuery.

Dal settore

• Google Search Console aggiunge esportazioni di dati bulk giornaliere a BigQuery (Search Engine Land, Barry Schwartz) — la copertura dell’annuncio, con le parole originali di Google citate testualmente.
• Google spiega come usare l’esportazione bulk dei dati di Search Console (Search Engine Journal, Matt G. Southern) — la descrizione in linguaggio semplice di Daniel Waisberg della funzionalità.
• Inizia con le query GSC in BigQuery (Search Engine Journal) — un punto di partenza pratico per le query.
• Google Search Console a BigQuery: la guida completa (Trevor Fox) — l’origine della cornice di costo “varietà di keyword, non volume di ricerca”.
• Addio campionamento! Ottieni dati GSC più completi con BigQuery (Advanced Web Ranking, Sam Torres) — nozioni di base su configurazione e controllo dei costi.
• Come interrogare i dati di Google Search Console in BigQuery (Analytics Mania, Julius Fedorovicius) — guida approfondita che include il ritardo di due giorni sui dati.
• Come usare i tuoi dati GSC in BigQuery come un professionista (Antoine Eripret) — l’approfondimento tecnico, inclusa la storia dell’errore di costo di 23 TB / ~€115 e la realtà del mancato backfill.

Statistiche da citare

• ~46% dei clic di GSC va a query non divulgate. Dal mio studio Ahrefs su 146 741 siti web e circa 9 miliardi di clic: il 46,08% dei clic è andato a query che Google anonimizza — una limitazione che l’esportazione BigQuery condivide con l’interfaccia e l’API.
• Una dashboard live su tabelle grezze ha scansionato 23 TB in un giorno (~€115). Il caso documentato di Antoine Eripret sul perché materializzare tabelle di riepilogo invece di interrogare direttamente l’esportazione grezza. Fonte
• Ritardo di due giorni sui dati. “Google Search Console data is available with a two-day delay, so the most recent data available will always be from two days prior” (traduzione) «I dati di Google Search Console sono disponibili con un ritardo di due giorni, quindi i dati più recenti disponibili saranno sempre di due giorni prima» — quindi un intervallo di 30 giorni restituisce circa 28 giorni di dati utilizzabili. Fonte
• Livello gratuito (verifica — i prezzi cambiano): circa 10 GiB di storage + 1 TiB di elaborazione query al mese gratuiti, poi circa 6,25 USD USD/TiB elaborati. Fonte

Mettiti alla prova: esportazione GSC BigQuery

Cinque domande rapide sull’esportazione bulk dei dati. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche