本文へ移動
リライトレーダーRewrite Radar
メニュー

公開

サーチコンソールのBigQueryエクスポートは必要?過去データと費用の注意点

サーチコンソールのデータが16か月で消えると知り、BigQueryへ保存すべきか迷っている方へ。一括エクスポートは過去に遡らず、設定した当日から蓄積します。Google Cloudの支払い設定と課金の注意点、個人ブログで本当に必要になる3つの条件を解説します。

この記事のまとめ

Search Console の一括データ エクスポート(BigQuery への書き出し)は「今日から貯める」仕組みで、過去には遡りません。最初のエクスポートに入るのは当日のデータで、公式ヘルプも過去を見るには別の手段を使うよう案内しています。だから設定が1日遅れるごとに、1日ぶん失います。ただしGoogle Cloud の支払い設定が必要で無料枠を超えると料金が発生するため、個人ブログで要るのは16か月を超えて貯めたい・クエリ×ページを大量に扱いたい・記事が1,000本を超えているのどれかに当てはまるときだけです。

Search Console のデータは過去16か月ぶんしか残りません(Google公式ヘルプに「Search Console では、過去 16 か月間のデータが保持されます」とあります。アナリティクス ヘルプ側のページで確認した記述です)。 それを知ると、たいてい次に「消える前に貯めておけないのか」と考えます。

そこで見つかるのが「一括データのエクスポート」という機能です。ところが設定画面まで進むと、Google Cloud プロジェクト、支払い情報、BigQuery、SQL と並んでいて、そこで止まります。

判断に必要なことを先に書きます。この機能は「今日から貯める」仕組みで、過去には遡りません。だから「やるかどうか」より「いつやるか」のほうが結果を左右します。そのうえで、個人ブログのほとんどには要りません。要る条件も含めて書きます。

なお、いま手元にあるCSVで直す記事を決めるだけなら、この機能は関係ありません。

次に直す記事を自分のデータで調べる

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

一括データ エクスポートとは何か

一括データ エクスポートとは、Search Console のパフォーマンスデータを、1日1回あなたのBigQueryへ書き出し続ける機能です。公式ヘルプによれば、作られるテーブルは3つです。

テーブル中身
searchdata_site_impressionプロパティ別に集計されたデータ
searchdata_url_impressionURL別に集計されたデータ
ExportLog成功したエクスポートごとの記録(失敗は記録されない)

ここがCSVとの最大の違いです。searchdata_url_impression にはURLとクエリが同じ行に入っています。画面から落とすCSVでは、この2つはつながりません。

CSVでクエリとページがつながらない理由と、つながらないまま進める手順はサーチコンソールのクエリとページの違いに書いています。

いちばん大事なこと — 過去には遡らない

Search ConsoleのBigQuery一括エクスポートは設定当日から1日1回蓄積し、過去へ遡らないことと必要条件を示す図解

※図の「要る条件」は代表的な2つです。3つ目(記事が1,000本を超えている)は後半で説明します。

設定しても、設定より前のデータは1日ぶんも入りません。公式ヘルプの記述はこうです。

Search Console で設定を適切に行うと、最大 48 時間以内に最初のエクスポートが行われます。最初のエクスポートには、当日のデータが含まれます。
(中略)
初期設定に先立って過去のデータを確認するには、Search Console API またはレポートを使用します。
— Google公式ヘルプ

「16か月で消える前に貯めておきたい」が動機なら、ここが結論を決めます。いま画面に見えている16か月ぶんは、この機能では救えません。救えるのは今日から先だけです。

言い換えると、迷っている期間そのものが損失になります。1か月迷えば1か月ぶん、貯まらないまま消えていきます。「いつか必要になるかもしれない」と思っているなら、判断を先送りするほど選択肢が減るタイプの機能です。

16か月の保持が実際に何を制約するか(前年と丸ごと並べられるのは約4か月まで)は検索ボリュームの季節変動を見分ける3手順に書きました。

設定に必要なもの

公式の手順を要約すると、Google Cloud 側とSearch Console側に分かれます。

  1. Google Cloud プロジェクトの支払い情報を設定し、BigQuery を有効にする。具体的には BigQuery API と BigQuery Storage API の2つ
  2. Search Console に書き込み権限を渡す。search-console-data-export@system.gserviceaccount.com というサービスアカウントに、「BigQuery ジョブユーザー」と「BigQuery データ編集者」の2つのロールを付ける
  3. Search Console の[設定]→[一括データのエクスポート]で、プロジェクトIDを入れる。公式は「プロジェクト番号ではない」とわざわざ注記しています
  4. データセット名と場所を決める。既定は searchconsole。 名前を変える場合も「常に文字列 searchconsole で始めます」。場所は後から変えるのが難しいと明記されています

料金について、公式が書いているのはここまでです。

無料枠がありますが、無料の割り当てを超えてストレージやクエリを使用すると、料金が発生します。
— Google公式ヘルプ

いくらかかるかは、サイトの規模と貯める期間で変わります。金額を約束できる書き方はできないので、支払い情報の登録が要る機能だという前提だけ持っておいてください。公式はパーティションに有効期限を設定すること(テーブル全体ではなく)を勧めています。設定しなければ既定でテーブルは永続的に保持されます。

BigQueryに貯めたあとに待っている3つの手間

入れたら画面が増えるわけではありません。BigQueryに入るのは表であって、レポートではありません。読むときに必ずぶつかるものが3つあります。

1. 平均掲載順位が、そのままでは入っていない

公式のスキーマに入っているのは0を最上位とする順位の値(プロパティ別のテーブルではその合計)で、平均掲載順位そのものではありません。しかも列名がテーブルで違います。URL別の searchdata_url_impression はsum_position、プロパティ別の searchdata_site_impression はsum_top_position です。公式ヘルプは計算式を明記しています。

SELECT
  url,
  SUM(clicks) AS clicks,
  SUM(impressions) AS impressions,
  SUM(sum_position) / SUM(impressions) + 1 AS avg_position
FROM searchconsole.searchdata_url_impression
GROUP BY url

最後の +1 を忘れると、順位が1つずつずれます。どちらの列も0が最上位だからです。テーブルを取り違えると「Unrecognized name」で止まるので、そこだけ気をつけてください。

そもそも平均掲載順位が何の平均なのかは平均掲載順位とはに書いています。

2. 同じキーの行が何度も入るので、必ず集計が要る

公式ヘルプの記述です。

パフォーマンス データは Search Console によって徐々に蓄積されるため、テーブル行には同じキーが繰り返し登録されます。このデータは、テーブルにエクスポートする前に圧縮されません。そのため、ほぼ毎回すべての指標を集計する必要があります。
— Google公式ヘルプ

1行を見て「このページのクリック数」と読むことはできません。必ず GROUP BY で足してから読むことになります。

3. 匿名化されたクエリは、行としては残る

検索された回数が少ないクエリは、公式によれば「クエリを行ったユーザーのプライバシーを保護するため、クエリ フィールドは null になります」。 ただし is_anonymized_query というブール値のフラグが付くので、「伏せられた行がどれだけあるか」は数えられます。

画面やCSVでは伏せられたぶんは見えなくなるだけなので、ここは数少ない「BigQueryのほうが分かること」です。

伏せられるクエリの仕組みと、内訳を足しても合計に届かない理由はサーチコンソールの合計が合わないに書いています。

要るか要らないかの判定

次の3つのどれにも当てはまらないなら、いまは要りません。

条件要る理由
16か月を超えて貯めたい画面もCSVも過去16か月まで。2年目・3年目の同じ時期と比べたいなら、貯めるしかない
クエリ×ページを大量に扱いたいsearchdata_url_impression にURLとクエリが同じ行で入る。CSVではつながらない
記事が1,000本を超えている画面からのエクスポートは表が1,000行で切れる。一括エクスポートはその上限の外にある

画面からのエクスポートにかかる1,000行の上限と、それが判定に影響するかどうかはサーチコンソールのCSVエクスポート手順に書いています。

逆に、次のどれかに当てはまるなら見送っていいと思います。

  • SQLを書く予定がない。入れても読めません
  • 支払い情報を登録したくない。設定の前提条件です
  • 今週どの記事を直すかを決めたいだけ。それはCSV1枚で足ります
  • まだ記事が少なく、表示回数が2桁で止まっている。貯めても中身が薄いままです

この見送りリストの3つ目——「今週どの記事を直すかを決めたいだけ」——に当てはまるなら、支払い設定もSQLも要りません。いま手元にあるCSV1枚で足ります。

直す記事と作業内容を決める

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

「いつか使うかもしれないから、とりあえず設定だけしておく」は、この機能に限っては合理的です。過去に遡れない以上、設定だけ先にしておけば、必要になったときには貯まっているからです。ただし課金が発生しうる状態を放置することになるので、有効期限の設定だけは一緒にやってください。

よくある質問

設定すると、過去16か月ぶんも入りますか

入りません。公式ヘルプは「最初のエクスポートには、当日のデータが含まれます」と書き、「初期設定に先立って過去のデータを確認するには、Search Console API またはレポートを使用します」と案内しています。いま見えている16か月ぶんを残したいだけなら、パフォーマンスレポートをそのままエクスポートして手元に保存しておけば足ります(ただし表は1,000行が上限なので、記事数がそれを超えるサイトでは全URLは残せません)。 一括エクスポートの設定とは別の作業なので、両方やって困ることはありません。

無料で使えますか

無料枠はありますが、無料とは言い切れません。公式ヘルプは「無料枠がありますが、無料の割り当てを超えてストレージやクエリを使用すると、料金が発生します」と書いています。設定の前提としてGoogle Cloud プロジェクトの支払い情報が必要です。かかる量はサイトの規模と貯める期間によって変わります。

エクスポートが止まっていたら、その日のデータはどうなりますか

放置すると失われます。公式ヘルプによれば、権限エラーのような一時的でないエラーが起きた場合、Search Console は約1週間にわたって再試行してから、その日のデータの保存を停止します。アクセスを直せば、そこから先のぶんは再開されます。

テーブルに列を足してもいいですか

足さないでください。公式ヘルプに「テーブル スキーマは変更しないでください(列の追加など)。スキーマを変更すると、エクスポートは失敗します」と明記されています。有効期限を設定する場合も、テーブル全体ではなくパーティションに設定することが勧められています。

Looker Studio(現Data Studio)につなぐのと、どちらがいいですか

目的が違います。ダッシュボードのコネクタは「見る」ための道具で、設定した日より前のデータもSearch Consoleが持っている範囲で表示できます。一括エクスポートは「貯める」ための道具で、過去には遡れない代わりに16か月を超えて残せます。どちらも「直す記事」を出す機能ではありません。コネクタで何が出て何が出ないかはサーチコンソールをLooker Studioにつなぐと何が分かるかにまとめました。

まとめ

  • 一括データ エクスポートは1日1回、BigQueryへ書き出し続ける機能。テーブルはsearchdata_site_impression / searchdata_url_impression / ExportLog の3つ
  • 過去には遡らない。最初のエクスポートに入るのは当日ぶんで、公式は過去を見るにはAPIかレポートを使うよう案内している。迷っている期間がそのまま損失になるので、必要になりそうなら設定だけ先にしておく手はある(その場合はパーティションの有効期限を一緒に設定する)
  • 設定にはGoogle Cloud の支払い情報が要る。無料枠はあるが、超えると料金が発生すると公式に明記がある
  • 貯めたあとの手間は3つ。平均掲載順位は自分で計算する(URL別なら SUM(sum_position)/SUM(impressions) + 1。プロパティ別は列名が sum_top_position)、同じキーの行が重複するので必ず集計が要る、匿名化クエリはフラグ付きの行として残る
  • 要るのは16か月を超えて貯めたい・クエリ×ページを大量に扱いたい・記事が1,000本を超えているのどれか。SQLを書く予定がないなら、入れても読めない
  • CSVでは取れないURL×クエリが同じ行で取れるのが、CSVとの最大の違い

ここから先は、私が作ったツールの話です。

リライトレーダーは、いま手元にあるCSV1枚から、直す記事の順番を出すためのツールです。貯める機能はありません。 Search Console のエクスポートをZIPのまま落として貼るだけで、掲載順位4.0〜20.5位・表示回数100回以上のページだけを拾い、改善余地スコアの大きい順に並べます。Google Cloud の設定もSQLも要りません。判定と候補3記事の改善余地スコアの確認、そのうち1記事分の診断カードまでは無料で、残りの診断カードが2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(送るのは、診断カードを出すときは選んだ1ページのURL・数値・入力したキーワード、「ページタイトルを取得する」を押したときは判定に出たページのURL最大10件です)。

⚠️ ただし、向かない人がいます。この記事のようにデータを長期で貯めたい人には向きません。貼ったCSVはブラウザの中で処理されるだけで、履歴として残りません。年をまたいだ比較や、クエリ×ページの大量集計が目的なら、一括エクスポートのほうが確実です。表示回数が2桁で止まっているサイトでは、判定に出るページがそもそもありません。

Search ConsoleのZIPで無料判定する

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

この記事の内容をツールにしています

Search Console の「ページ」CSVを貼ると、改善余地のある記事を順番に出します。 判定とご自分の記事1件分の診断カードは無料です。ログイン不要。CSVファイルはアップロードせず、ブラウザ内で解析します。

リライトレーダーで無料診断する

関連する記事

この記事を書いた人

みやこし

ブログのリライトで「どの記事を直すか」を数字で決めるSEOライター向けツールを作っています。 掲載順位ごとの平均クリック率、AI Overviewによるクリック減の補正、タイトルの直し方など。

noteQiitaZenn

ブログの一覧に戻る