Search Consoleのクリックが実数の5%に。ページ×クエリ集計で匿名化クエリが落ちた話

おはようございます。まさきんです。

このブログの週報で、検索クリックが28日間で「7件」と出ていました。ページ単位で見直すと実際は145件です。原因は集計の組み方にあったので、同じ罠を踏まないように実務メモとして残しておきます。

※記事公開時点の情報です。最新の条件は公式サイトでご確認ください。

何が起きたのか

このブログには、毎週自動で届く分析レポートがあります。Search Console と GA4 の数字を集めて、先週との差を並べる仕組みです。

ある週、その週報の検索クリックが28日間で「7件」でした。記事は毎週増えていて、検索の表示も伸びていた時期です。さすがに少なすぎると感じました。

そこで Search Console の画面で、同じ期間をページ単位で見てみました。合計は145件です。7件は実数の約5%しかありません。

アクセスが落ちたのではなく、集計の不具合でした。数字を見て「今週は検索が弱いな」と結論を出す前でよかったと思います。

原因はページ×クエリの足し算

週報のスクリプトは、Search Console のデータを page と query の組み合わせで取っていました。その行を全部足して「検索クリックの合計」にしていたんです。

一見すると、ページごと・クエリごとの内訳を全部足せば合計になりそうです。ところが Search Console では、そうなりません。

クエリの中には「匿名化クエリ」があります。この分は query を含む表には1行も出てきません。なので、足し算の時点でその分が消えていました。

匿名化クエリとは

匿名化クエリは、プライバシー保護のために表から省かれるクエリです。Google の Search Central ブログで説明されています。目安は「2〜3か月の間に数十人を超えるユーザーが検索していないもの」とされています。

実際の検索語は表示されません。一方で、グラフの合計にはこの分も含まれます。ただし、クエリでフィルタした場合は合計からも外れます。

公式ブログには分かりやすい例がありました。内訳のクエリを足すと450クリックです。一方で全体の合計は550クリックでした。差の100は匿名化クエリの分というわけです。

小さなサイトほど差が大きいかもしれない

匿名化の基準は「検索した人数」です。なので、細かい検索語で少しずつ読まれるサイトほど匿名化の割合が高くなりそうです。

このブログは、まさにそのタイプでした。一つひとつの検索語は少なく、細かい言い回しで読まれています。その結果、クリックの大半が匿名化クエリ側にあったのだと思います。

5%しか残らないのは極端に見えます。ただ、個人ブログや立ち上げ直後のサイトでは珍しくないのかもしれません。

合計がずれる理由を整理する

Search Console の数字が合わない理由は、匿名化だけではありません。公式ヘルプとブログで確認できたものを表にしました。

僕の週報で効いていたのは、ほぼ一番上です。とはいえ、他の理由も重なるとさらに読みにくくなります。

プロパティ単位とページ単位の違い

Search Console には、集計の仕方が2つあります。プロパティ単位(byProperty)と、ページ単位(byPage)です。

公式ヘルプによると、グラフの合計はプロパティ単位です。同じクエリで自分のサイトが複数表示されても、表示回数は1回と数えます。

一方で、表を「ページ」でまとめるとページ単位の集計になります。同じ検索結果に2ページ出れば、それぞれに表示回数が付きます。なので、ページ別の合計はグラフの合計より大きくなることがあります。

API のリファレンスには、page でまとめたり絞ったりする場合は byProperty を選べないとあります。その場合は auto を指定するよう案内されています。

API の行数上限にも注意

Search Analytics API の rowLimit は、既定値が1,000行です。指定できる範囲は1〜25,000行で、それ以上は startRow でページ送りします。

API で取れる上限は「1日・1サイト・検索タイプごとに50,000行」です。Search Central ブログでそう説明されています。Looker Studio のコネクタも同じ上限だそうです。

また、API のリファレンスには「すべての行を返す保証はない」という趣旨の注記があります。上位の行が返ってくる前提で使うのがよさそうです。

一方で、query や URL を含まない取り方なら全データが返るとされています。国やデバイス別などがこれにあたります。合計を取るなら、ここも覚えておきたいポイントですね。

表示回数・CTR・掲載順位の定義

週報で数字を語る前に、指標の意味もそろえておきます。公式ヘルプの定義をまとめると次のとおりです。

平均掲載順位は、1回の検索で複数表示されても一番上の順位だけを使います。1つの指標だけで判断せず、組み合わせて読むのが大事だと思います。

週報で直したこと

原因がわかったので、週報の組み立てを変えました。やったことは3つです。

1. 主役を「GSC のページ単位の検索成績」と「GA4 の流入元」の2つにした
2. 前後30PV未満のカテゴリは、増減を語らないルールにした
3. 新着記事と既存記事を分けて見るようにした

1つ目は、今回の不具合そのものへの対策です。合計は query を含めずに取り、記事ごとの成績はページ単位で見ます。クエリ別の表は、どんな言葉で読まれているかを眺める材料に下げました。

2つ目は、小さな数字で騒がないためのルールです。数件の差で「伸びた」「落ちた」と書くと、次の判断がぶれやすくなります。

3つ目は、新着の伸びと既存記事の変化を混ぜないためです。合計だけ見ていると、どちらが効いたのか分からなくなりますね。

「見えていない数字」は家計にもある

今回の件で思ったのは、合計を下から積み上げると漏れに気づけないということです。上から全体を見て、内訳と突き合わせる。これで初めて差が見えました。

家計の固定費も似ています。明細を1行ずつ見ても、全体の支出と比べないと抜けに気づきにくいものです。スマホ代のように毎月自動で落ちる支出は、一度まとめて見直してみるのもいいかもしれません。

自作の集計でやりがちな落とし穴

ここからは、自作の週次レポートや API・BigQuery 一括エクスポートで GSC を見ている人向けです。僕が踏んだものも含めて並べます。

• page×query の行を足して、サイト全体の合計にしている
• クエリで絞った数字と、絞らない数字を同じ表で比べている
• ページ別の合計と、グラフの合計が合わないのを不具合と思っている
• rowLimit を指定せず、既定の1,000行だけで集計している
• 直近2〜3日のまだ固まっていない数字で、先週と比べている

BigQuery の一括エクスポートにも注意があります。公式ヘルプでは、匿名化クエリは is_anonymized_query という列で区別されます。その行の query 列は空(null)になるそうです。

また、テーブルはプロパティ単位とURL単位の2つに分かれています。query で集計して空の行を外すと、同じように合計が小さくなるはずです。合計を出すときは、query で絞らずに集計するのが無難かもしれません。

向いている見方・向いていない見方

どの数字をどんな目的で使うかを、ざっくり分けておきます。

• 向いている: サイト全体の推移はプロパティ単位の合計で見る
• 向いている: 記事ごとの成績は page 単位で見る
• 向いている: クエリ別の表は「どんな言葉で読まれているか」の傾向に使う
• 向いていない: クエリ別の行を足して、全体の合計にする
• 向いていない: 数件の差を、増減の根拠にする

個人的には、合計と内訳を別の取り方で出すのが一番安心だと感じています。分析の仕事でも、数字の出どころを説明できることが大事だと思います。データ分析に必要な「通訳力」の話にも近いかもしれません。

始める前に確認すること

• 週報の合計クリックが query を含む取り方になっていないか
• Search Console の画面の合計と週報の合計を一度突き合わせたか
• API の rowLimit と startRow を指定しているか
• aggregationType を目的に合わせて選んでいるか
• 直近2〜3日の未確定データを比較に使っていないか
• 小さなカテゴリの増減を語るルールを決めているか

よくある質問

Q. 匿名化クエリの分は、あとから見られますか?

実際の検索語は表示されません。Search Central ブログでは、プライバシー保護のために省かれると説明されています。合計に含まれている分として、差から推し量るしかなさそうです。

Q. 画面の合計とクエリ別の表の合計、どちらが正しいですか?

用途によります。サイト全体のクリック数なら、グラフの合計のほうが実態に近いはずです。クエリ別の表は、匿名化の分が入っていない内訳として見るのがよいと思います。

Q. ページ別の合計がグラフの合計より大きいのはなぜ?

集計の仕方が違うためです。ページ単位では、同じ検索で複数ページ出るとそれぞれ数えます。グラフはプロパティ単位なので1回と数えます。

Q. API で週報を作るなら、どう取るのがいいですか?

合計は query を含めずに取るのが安全です。記事ごとの数字は page だけで取り、aggregationType は auto にします。クエリ別は別の呼び出しで取り、合計とは混ぜないようにしています。

Q. Looker Studio でも同じことが起きますか?

Looker Studio のコネクタも、API と同じ行数上限だと説明されています。出典は Search Central ブログです。匿名化の仕組みも共通なので、クエリを含む表の合計は小さく出るかもしれません。

Q. BigQuery の一括エクスポートなら全部取れますか?

行数上限の影響は受けないと、公式ブログで説明されています。ただ、匿名化クエリは query 列が空になります。クエリで集計すると、やはりその分は見えなくなります。

Q. 30PV未満のカテゴリを語らないのはなぜですか?

数が少ないと、たまたまの増減に振り回されやすいからです。数件の差で方針を変えると、判断がぶれてしまいます。僕の週報では、しきい値を決めて機械的に外すようにしました。

参考にした公式情報

• Performance report (Search results): Overview and basic setup(Search Console ヘルプ)
• Performance report (Search results): Troubleshooting data discrepancies(Search Console ヘルプ)
• What are impressions, position, and clicks?(Search Console ヘルプ)
• Table names and location(Search Console ヘルプ・一括データエクスポート)
• Search Analytics: query(Search Console API リファレンス)
• A deep dive into Search Console performance data filtering and limits(Search Central ブログ)
• Bulk data export: a new and powerful way to access your Search Console data(Search Central ブログ)

まとめ

Search Console のデータは、取り方しだいで合計が大きく変わります。僕の週報では、page×query の足し算で145件が7件になっていました。

合計は query を含めずに取る。記事の成績は page 単位で見る。クエリ別の表は傾向を眺める材料にする。この3つを押さえるだけでも、読み違いはかなり減ると思います。

仕組みが分かると、数字の見え方も少し変わりますね。自作の週報を使っているなら、一度だけ画面の合計と突き合わせてみてください。

似た「記録上は合っているのに実態がずれていた」話として、「解約完了」と書いたサブスクが課金され続けていた話も置いておきます。固定費を見直すなら、固定費見直しの始め方も参考になるかもしれません。

本記事にはアフィリエイト広告を含みます。当サイトのリンクを経由して商品・サービスへお申し込みいただいた場合、提携先企業から成果報酬を受け取ることがあります。 また、運営者は楽天グループに所属する社員であり、紹介プログラムを通じた報酬を受け取る場合があります。記事内容・評価は広告の有無にかかわらず、運営者の実体験と調査に基づき作成していますが、 上記の関係性をご理解のうえお読みください。詳しくは免責事項・アフィリエイト表記をご覧ください。

楽天モバイルの通信エリア・電波状況について気になることがある方は、公式の電波改善・調査依頼フォームからご相談いただけます。