【詳細解説】事例から学ぶ!データドリブンSEO実践編【from JADEウェビナー】

5/30のJADE主催セミナー「事例から学ぶ! データドリブンSEO 実践編」で語った内容を講師の山田陸が徹底解説。ウェビナーに参加した方も不参加の方もしっかりと学習できる詳細な書き起こしです。ウェブサイトの課題を特定し解決するためには「一括データエクスポート」を活用した定量的なデータ分析が必要で、加えて活用の注意点についても解説しています。JADEが開発した「Amethyst」というツールにも注目です。

皆さんこんにちは。

三度の飯よりデータ分析が好き、どうも山田陸です。

さすがにそれは嘘でした。ご飯の方が好きです。

 

JADEブログでは主に、みんな大好きSEO分析系の記事を書いています。そろそろデータ分析の人という認知を得られていますかね!?

まだ読んでいない方は是非こちらもお願いしますm(_ _)m

blog.ja.dev

blog.ja.dev

 

今回は、弊社主催のセミナーで先日山田が語ったことを記事化しようと思います。自分で言うのもあれなんですけど、結構好評だったんですよ…

セミナーにご参加いただいた方も、振り返りがてら読んでいただけると嬉しいです。

5/30に開催した「事例から学ぶ! データドリブンSEO 実践編」というセミナーでした

【もくじ】

 

課題を解決するために何を見るか

早速ですが質問です。

「今のあなたが担当しているサイトの課題は何か教えて下さい」

 

 

 

(シンキングタイム)

 

 

 

考えていただきありがとうございます。 皆さんの回答は“定量的な根拠”に基づくものでしたか?それとも長年サイトと向き合ってきた経験や感覚的なものから出てきた回答でしょうか?

 

後者であれば、その経験・感覚が正しいかどうか定量的に確認してみてください。

前者であれば、何かツールを利用して数字を確認しているはずです。そのツールは何でしたか?

Google の検索結果はパーソナライズされていたり、ローカライズされていたりします。つまり、GRC や ahrefs といったサードパーティーツールの順位データは、実態とかけ離れている可能性があります。他のデータソースがない際の競合調査、市場調査の際は強い味方になってくれますが、自社の数値を確認するのであれば、より実態に近いデータを出してくれる Search Console や GA4 をデータソースとしましょう。

 

そんなことを言っておきながら、僕自身は Search Console を見に行く頻度が減ってしまいました。

 

なぜ頻度が減ってしまったのか。

以下がその理由です。

  1. 全てのクエリ/URLデータが見られない
    • Search ConsoleのUI上では1,000件しか見られないという制約がある
  2. クエリとURLが1つのレコードとして格納されていない
  3. 特定のディレクトリのデータを見たい場合、都度フィルタリングが必要

こういった理由で、僕はSearch Consoleを不便だと感じるようになったのです。

今ではサクッと大きな異常がないかどうかを把握するために検索結果のパフォーマンスを見るくらいです。

JADEでは“一括データエクスポート”を見ている

それでは「JADEのコンサルタントは何の数字を見ているのか?」ということになります。

それは、“一括データエクスポート”です。

これは何かというと、BigQuery に Search Console のデータをエクスポートできる機能のことです。具体的なやり方については以下をご覧ください。

developers.google.com

 

これがなぜ便利なのか、大きく3つの理由があります。

  1. 大半のクエリと、全てのURLデータが見られる
  2. クエリとURLが1つのレコードとして格納されている
  3. BigQueryを使ってあらゆる条件のダッシュボードを作成できる

詳しく見ていきましょう。

 

大半のクエリと、全てのURLデータが見られる

これはSearch Consoleを見ない理由でも書いたように、Search Console上では1,000件しか見られないという制約が一括データエクスポートだと無く、全てのURLデータが見られるのです。

どの URL でどれだけの impression があったのかを漏れなく全て確認できます。

クエリだけは例外で、一部のものは個人情報を守る観点から null(匿名クエリ)として隠されています。

しかし、その匿名クエリであったとしても、どの URL で impression / click が発生したのかは確認できるので、どういうクエリだったのかという推察ができます。

 

クエリと URL を1つのレコードとして格納

一括データエクスポートされたデータだと、URLとクエリが1つのレコードとして格納されています。

日毎に URL とクエリの組み合わせの impression / click / 平均順位を確認できるのでこれほど便利なことはないです。

 

BigQuery であらゆる条件のダッシュボードが作成可能

BigQuery で特定の条件で抽出したデータを Looker Studio で簡単にダッシュボード化できます。

Search Console だと、都度条件をフィルタリングして、確認して……という工程を踏まなければなりません。Looker Studio だったら事前に仕込んでおけば、一括データエクスポート(Search Console)という1次情報をデータソースとしたダッシュボードを、毎日サクッと見たい条件で確認できます。

JADEのコンサルタントに聞いても、おそらくみんな一様に「Search Console よりも、一括データエクスポートをソースとしたデータを見ている」と回答するはずです。

それくらい、見られるデータの量 / データの見やすさ / データの扱いやすさが段違いに良いのです。

一括データエクスポートを使ってデータ分析

こういったデータ基盤があるからこそできる、オススメのデータ分析をご紹介します。どのサイトにも役立つと思われるものを用意しましたので、ぜひ真似してみてください。

  1. サイトを細分化して各数値を把握する
  2. title改修のクイックウィン施策
  3. ユニークURL/ユニーククエリを把握する

サイトを細分化し各数値を把握

皆さんは Search Console でサイト全体の平均順位を見ていますか? 平均順位が上がっていれば嬉しいし、下がっているとドキッとしますよね。けれど、その一喜一憂も今日で終わりにしましょう。

なぜ Search Console のサイト全体の平均順位ではダメなのか? それは、以下の2つを考慮しなければいけないからです

  • 特定のページタイプだけ異常に順位が高いケースが存在するから
  • Google がセクション単位で評価する術を持っているから

特定のページタイプだけ異常に順位が高いケースが存在する

皆さんのサイトには、全く同じようなコンテンツしか存在しないわけではないと思います。きっと、リストページのようなものもあれば、詳細ページのようなものもあれば、記事コンテンツのようなものあるのではないでしょうか。そして記事コンテンツの中でも、グルメ系のものもあれば、観光スポット系を取り扱ったものもあればと多種多様ではないでしょうか?

それらをそれぞれでグループ化した時に全部同じ平均順位ということはありえないのではないかと思います。ビジネス的には「このページの流入が取れたほうがCVRが良い」とかありますよね?であれば、サイト全体の各数値を評価するのではなく、適切なサイズで各数値を評価すべきだと考えます。

 

Google がセクション単位で評価する術を持っている

先日、ジョン・ミューラーが「ディレクトリ単位で機能するシグナルも存在する」という話をしていましたが、これは間違いないと思われます。

JADE では数十万の検索クエリをモニタリングしているのですが、特定のディレクトリだけ上昇・下落というのをよく見かけます。これも全体の動きを Search Console で見ているだけでは何も分からないわけです。

たとえば、

  • 全体としてはクリック数が下降トレンドにある
  • 細かく分析をしてみると、実はAというディレクトリは上昇トレンドにいる
  • しかしBというディレクトリが猛烈にクリック数を減らしている
  • 全体としてはマイナスのように見える

というケースもありえます。

Search Console で全体の動きを見ていても全体として上がった・下がったは分かっても、どこが上がっているのか、下がっているのかが分からないから、施策も打てないわけです。

 

クエリ種×ページタイプ別で最強のダッシュボードを

では、どういうダッシュボードを作れば良いのでしょうか?オススメは、「クエリ種×ページタイプ別のダッシュボード」を作成してモニタリングすることです。

まずはクエリ種別で分けてみましょう。どんなサイトでも必ず作ってほしいのは指名/非指名/匿名クエリ分けです。

指名はその名前の通り、「皆さんのサイトを見たい」という意図のクエリです。非指名は指名以外のクエリ、そして匿名クエリは前述したように個人情報の保護等の観点から見ることができないクエリです。匿名クエリはその性質上毎月安定して impression が発生していない、つまり検索回数が多くないものが匿名化されることが多いです。ですので、匿名クエリが多い場合はロングテール系のキーワードで検索されていることが多いのかもしれません。

他にも前述したように皆さんのビジネスにおいて大事な検索クエリも入れておきましょう。
たとえばグルメサイトであれば、飲み放題系のページのCVRが高いから「飲み放題」を含むクエリ、賃貸サイトであれば間取り系のクエリを取っておきたいから、「3LDK」「1LDK」を含むクエリなど、サイトごとによってモニタリングすべきクエリは変わるはずです。

 

もう一つはページタイプ別です。

Googleはディレクトリ単位で評価する術を持っていると書きましたが、それに合わせたモニタリング環境も必須です。

下は賃貸サイトをモデルにしたデモ画面ですが、赤枠のところを見ていただくとマンション / アパート / 戸建てというグループを割り振っています。これは、マンション系のページだけの数値 、アパート系のページだけの数値、戸建て系のページだけの数値と分けているわけです。

他にもリストページ / 詳細ページ / コンテンツページという分け方もできるでしょうし、詳細ページの中で詳細 - TOP / 詳細 - 口コミ / 詳細 - メニューなどの分類もできると思います。

サイト内に存在するページタイプをできる限り分類できると良いでしょう。

最後にこれらクエリ種別とページタイプ別をかけ合わせます。

クエリ種別の分類は、ユーザーがどういう意図の検索を行っているかに基づいた分類です。僕たちでコントロールできるものではありません。

一方でページタイプ別の分類は、サイト側がどういうコンテンツを持っているかの分類です。皆さんは何かしらの意図を持ってコンテンツを作っているはずです。このコンテンツはこういうクエリを検索しているユーザーに出したいと考えていますよね。

これらをかけ合わせることで、ユーザーの検索に対して適切なコンテンツを返せているのかを判断でき、そしてそれらの表示回数やクリック数、平均順位などを正確に把握できます。

下のスクリーンショットは、デモサイトにおけるページタイプが「マンション・アパート」のリストページ、そして都道府県や、市区町村などのクエリを含むものとかけ合わせたダッシュボードです。

これを見るといろんな気づきが得られます。

 

 

気づき1:路線名のクエリと、駅名のクエリだと駅名のクエリの方が表示回数は多い。けれどもクリック数は路線名の方が多い。これはCTRに差分があって、平均順位に大きな乖離があるな。駅の平均順位が低いのは何でだろう。

👇

地方の駅とかだとコンテンツ量が少なくて順位が低かったりするな。今後の戦略として地方の物件情報をより集めるようにしよう。そして駅名だと粒度が粗いことが分かった。地方の駅名と東京の駅名とかで分けてモニタリングしよう。

気づき2:都道府県のクエリはCTR0.5%か、マンション・アパート×駅よりも平均順位が若干高いのにCTRが低いな何でだろう。

👇

️確認してみたら都道府県系のクエリではマンションとかアパート系のリストページを求めるものではなく、エリアごとの家賃相場とかのほうが需要が大きいんだ。そこにリストページが出ていてもクリックは取れないよな。よし都道府県の家賃相場コンテンツを用意しよう。

こういった発見とアクションが生まれるはずです。しかし、ただSearch Consoleを眺めているだけではこういった発見をするのはかなり難しいのではないかと思います。

こういった適切な粒度で切り分けて、並べてモニタリングできるから気付けるものです。それは、一括データエクスポートの情報量と、それを自在に加工できる環境が揃ってこそできる分析手法なのです。

ぜひ皆さんも同じような分析をしてみてください。実はものすごいお宝クエリが眠っているかもしれません。

 

title 改修のクイックウィン施策

なぜ title 改修なのか

皆さんは SEO 施策の効果が現れるまで長い時間を要すると思っていませんか? もちろん、何の変数を改善するための施策かによって、効果が見えるまでに多くの時間を必要とする場合があります。

けれども、title 改修は SEO 施策の中でも比較的早く効果が見える施策かもしれません。

「えー今どき title 改修? 意味あるの?」

と思った方いらっしゃいませんか。

検索結果を頻繁に確認している方であれば、こういうケースに遭遇したことあるかもしれません。

「あれ? この title 不自然なところで途切れている…?」

「あれ? この title 短く省略されている…?」

特に冒頭に【】を付けた title にしていたりすると、Google によって省略されてしまっていたりするケースがあります。title 後半部分にサイト名とかを付けていて、そこがまるっと消えていたりしませんか? 詳しくは Google のドキュメントをご確認ください。

developers.google.com

こういう意図しない title が出てしまっている場合、表示順位に見合わない CTR になっていることがあります。

またこういう title の書き換わりが起こっていなかったとしても、自分たちが期待していたクエリとは違うところで多くの表示回数と順位が取れている。そして、絶妙にその title が対象ユーザーに刺さっていなくて CTR が思うような数字ではないということもあります。

そんなとき、title ひとつ変えるだけですぐにclick数の増加に繋げることができたりするわけです。

そんな title 改修にも使えるのが「一括データエクスポート」のデータです。もちろん Search Console でもできないことは無いですが、より多くのクエリを見ることができるので、精度の高い title 改修を行えます。

 

どうやってやるのか

以下の手順でやってみてください。

  1. URLとクエリの組み合わせの表示回数を降順で並べる
  2. 表示順位とCTRが見合っていないものを見つける
  3. 該当クエリで検索した際にどういう検索結果になっているかを確認する
    1. 他ページと比べてタイトルが魅力的ではない → タイトル改修
    2. Googleによるタイトル書き換えが発生している → タイトル改修

この流れの中で1つ注意をしていただきたいことがあります。

それはこの3番の確認をした際に、

title の書き換えが起こっていないか、競合ページと比べて魅力的な title になっているかどうかを確認し、変えるべきであると判断した際には title 改修を行うわけですが、

このとき title 改修することで既に取れているクエリの CTR を悪化させ、トータルで見た時にクリック数を毀損してしまう可能性があります。

1,2の手順でどのクエリの、どの URL に改善ポテンシャルがあるかを見出したあとは、そのURL が他にどういうクエリでクリックが取れているのかを必ず確認するようにしてください。

変更後の title でも既に取れているクエリでクリックを取ることができそうかどうかを考えていただきたいです。

この時に膨大なクエリデータを見ることができる一括データエクスポートが役に立ちます。

ユニークURL数・ユニーククエリ数の把握

ユニークURL数・ユニーククエリ数とは何か

ある Search Console プロパティのユニークURL数とは、1つのURLが複数のクエリで出ていることは考慮せずに、1本のURLは1つとしてカウントしたものです。

下の例では、 https://example.com/chintai/new というURLが3つのクエリで表示されていますが、それらクエリは考慮せずURL数=1としてカウントするのがユニークURL数です。

ユニーククエリ数は、その逆です。

1つのクエリで複数の URL が出ていることは考慮せず、そのサイトが出ている固有のクエリの数を数えるというカウント方法です。

同じく下の例を見ると、[jade] というクエリで複数のURLが出ているわけですが、それらURL数は考慮せずにクエリ数=1としてカウントするのがユニーククエリ数です。

指名検索の場合、複数のURLが出るケースがあるかと思います。

たとえば、ユニーククエリ数に対してユニークURL数がやたら多い場合、指名検索が多い可能性が考えられます。

 

なぜプロパティのユニークURL数 ・ユニーククエリ数を把握する必要があるのか?

プロパティに対するユニークURL・ユニーククエリの定義を理解いただいた上で、なぜこれらの数を把握すると良いことがあるのかをお伝えします。ここで、またまた皆さんに考えていただきたいことがあります。

「クリック数が減ったらどうやって調査しますか?」

皆さんはこういうとき、表示回数(Impression数)と CTR を確認しませんか?確認した結果、表示回数が減っていることがわかった、としましょう。しかし、順位下落か? と思って見てみると、順位は落ちていないとしましょう。(ちなみにこのとき Search Console 全体で見てはダメですよ? しつこいようですが、最初にお伝えしたクエリ種×ページタイプのダッシュボードで確認するようにしてください。)

表示回数は落ちているけれど順位は落ちていない…ということはつまり!!

インデックスが落ちているんだ!!

…となるのはちょっと気が早いです。

その前に、ユニークURL数とユニーククエリ数を調べてみましょう。

ユニークURL数が下落してしまった場合の原因を考えてみましょう。もちろんインデックスがされなくなったという可能性はあります。しかし、インデックスはされているけれど、検索結果に出すほどではないと評価されなくなってしまって出なくなるということも考えられます。後者の場合、インデックス率は落ちていないのに表示だけされなくなり、表示回数が下落します。

ユニーククエリ数はどうでしょうか。これが下落している場合、可能性の一つとして季節トレンドが挙げられます。特定のクエリの需要がなくなってしまうケースです。あるいは、特定のクエリにおける評価が落ちてしまって、表示されなくなったということも考えられます。

表示回数が落ちることの要因として、もちろん順位やインデックス率も大事な変数ではあるのですが、他にも

  • インデックスされているけれど、出なくなってしまったケース
  • 季節トレンドなどで検索クエリの需要が消えてしまったケース

なども考えられるのです。

これらを把握するために役立ってくれるのがユニーククエリとユニークURLです。繰り返しになってしまいますが、限られたクエリ・URLしか見ることができない Search Console では、容易にはこれを把握することができません。

一括データエクスポートのデータ量があって初めてできる分析なのです。

 

一括データエクスポート使用の際の注意点

ここまで読んでいただいて、「よし!うちも一括データエクスポートを活用しよう!」と思っていただけていたらとても嬉しいです。

そんな皆さんに合わせてお伝えしておかなければいけないことがあります。

それは一括データエクスポートを使うためにはいろいろと準備やコストがかかるということです。

大きく3つの注意点を書き出してみました。

  1. BigQueryにしかエクスポートができないので、BigQueryの使用が必須
  2. データを出すのにSQLの知識が必要
  3. ダッシュボードとして管理するためには別途BIツールとの接続が必要

BigQueryの使用が必須

この一括データエクスポートは、Google Cloud Platform の BigQueryにしかエクスポート先を設定することができません。BigQuery を使えば良い話ではあるのですが、BigQuery は無料で使うことができません。BigQuery を使うには大きく2つのコストがかかります。

  • データのストレージコスト
  • データ抽出をするためのクエリコスト

1つ目はストレージコストです。データを溜めていけばいくほどコストが大きくなります。一括データエクスポートは前述したように全てのクエリやURLデータをエクスポートできます。ゆえに、規模の大きいサイトであればあるほどこのコストも次第に無視できないものになります。

2つ目はクエリコストです。この BigQuery はデータを抽出するにあたって SQL というものを記述します。この SQL を記述してデータを抽出するごとにコストがかかるのです。もちろんコストを抑えるための SQL の書き方というのはあるのですが、それを理解し意識してクエリを書いてデータ抽出ができるマーケターはそんなに多くないかと思います。スキャン量の大きいSQLを書いて回し続けて、思わぬ金額を請求されてしまうということもありえます。ストレージコストよりもはるかに、クエリコストの方を注意しなければなりません。

 

SQLの知識が必要

上にも書きましたが、データを抽出したいといって簡単に出すことができるわけではありません。SQLを書かなければデータを出すことができないわけです。さらにデータが出せれば何でも良いんでしょ、と付け焼き刃のSQLを書いていると、思わぬクエリコストがかかってきます。

 

別途BIツールとの接続が必要

SQL を書くことができない人だけではなく、誰もが見られるダッシュボードとして整備するためには、何かしらのBIツールとの接続が必須になってくると思います。データを抽出し、それをBIツールに繋げて、ビジュアライズする。この過程が必要です。

このBIツールにお金をかけたくないということであれば、Google が提供している Looker Studio を利用することができます。弊社でも元々ダッシュボードは全て Looker Studio で作成していたのですが、表示されるまでの時間がめちゃくちゃかかる…重いのです。開くたびにクエリが回るのでクエリコストもかかってきます。

一括データエクスポートを利用するにはこういった注意点があります。

もう会社で BigQuery を使っているし、SQLの知識もあるし、BIツールも Looker Studio じゃなくて別のBIツール使っているよ! とかであれば、今すぐに上記の分析を再現できると思いますので、是非やってみてください!

 

ここまで読んでいただき、ありがとうございました!

一括データエクスポートを活用し、皆さまのサイトのSEOが上手くいくことを願っています!

 


ここから先は以下のような方向けのコンテンツになっています。

  • BigQuery はあまり詳しくない or 触ったことがない
  • SQL の知識はあまり無い or 知らない
  • 有料で使っているBIツールが無い

上記に当てはまる方はもう少しだけお付き合いいただけると幸いです。

JADE の社員が全員上記の条件を満たしているわけではないです。

  • BigQuery にほぼ触れたことがない社員もいます。
  • SQL を満足に書ける社員はごく僅かです。
  • Looker Studio への不満は全員が持っています!

でも、一括データエクスポートが無いと、データドリブンな SEO の仕事はできないんです!

だったらツール作っちゃえば良くない? ということで作ったのが“Amethyst(アメジスト)”です。

ja.dev

Amethyst のすごいところは沢山あるのですが、大きく以下が挙げられます。

  • BigQuery を使用する際のストレージコスト / クエリコストは一切かからない
  • SQL が書けなくても、高度なデータ抽出が可能
  • BIツールに繋げずに、Amethyst 内でビジュアライズが可能。しかも表示速度がめちゃくちゃ早い

こういったコスト/スキル/表示速度の欠点を全て潰したのが、Amethyst です。

※ちなみに上記のスライドに度々写っているUIは Amethyst です。↓これとか

本題は Amethyst の話ではないので、ここらへんで終わりにしたいと思います。

今日の分析やってみたいけれど環境がないなという方、Amethyst ちょっと興味があるなという方がいらっしゃれば、下記から資料請求できるのでぜひご活用ください!

https://share.hsforms.com/1NGaTa83VRLiuL-suOkDKGAcphvf

最初から話を聞いてみたいという方がいれば以下ページの下部からお願いします。

ja.dev

今だけこの記事を書いた山田が皆さまのサイトを拝見して、Amethyst の使い方などを無料で相談にのることをお約束しますので、希望があればおっしゃってください!

ではでは、良いSEOライフを!