Google Seach Console API×Treasure Data×re:dashでつくるSEOダッシュボード

はじめまして。Livesenseアドベントカレンダーその2の4日目を担当します、inagakkieです。
お仕事は主にSEOを担当しています。はじめての投稿に指が若干震えてます。

今回は、最近取り組んでいるSEO×ダッシュボード自動化のお話です。
複数のKPIを１枚のダッシュボードにまとめるプロジェクトの中から、最も汎用性が高そう＆エンジニアの協力が非常に貴重だったSeach Console APIを使ったものをピックアップします。
私はエンジニアではないので細かな技術のお話への踏み込みはできませんが、
・何をやったか
・なぜやったか
・どのようにやったか
を簡単にご紹介したいと思います。
その前に、この取組そのものに協力してもらったり、ご自身のまとめ情報の引用を快諾してくださった社内のエンジニアに心からの感謝を。

# 何をやったか - まずは完成形
![graph.png](https://qiita-image-store.s3.amazonaws.com/0/146324/7e5ab89e-46b0-dddc-ad1a-742736204d48.png)

このグラフには、

- Impressions（Google検索結果への表示回数）
- Clicks　　　（Google検索結果のクリック数）
- CTR　　　　（クリック数/表示回数）
- Position　　（Googleへの平均表示順位）

という、SEOでチェックする最も基本的なKPIがこの1枚に収まっています。
データソースはGoogle Search Console API。
Google Search ConsoleはGoogleの無料サービスで、Google検索結果への表示回数がチェックできる唯一のツールです。

# なぜやったか - Search Consoleの検索アナリティクスでは出来ないこと
Search Consoleでも、ウェブアプリ上で上記項目のグラフ描画は可能です。
ただし、任意性の不足や作業コストなど、KPI観測の観点でいくつかの欠点があります。それらを克服すべく行ったこの取組のポイントは、下記の3つです。

1. **デバイス別・ディレクトリ別**のグラフである
2. **任意の期間**でグラフ化できる
3. **自動更新**される

これらが満たせることで、KPI集計の手作業の時間の削減や、細やかなデータ変化をより早く察知できるようになり、リスク回避やPDCAの回しやすさに繋がります。

### 1.デバイス別・ディレクトリ別であること
特にポータルサイトなどのSEOを行う際、粒度の違うページ群（例えば商品詳細と商品一覧）は分けて計測したいもの。
ディレクトリ別で可視化できることはとても大切です。
Search Consoleのウェブアプリ上でもデバイス別の絞込みやURLでの絞込みを行うことができますが、毎回同じ絞込みをかけるポチポチした手作業が面倒だったり、絞込みの条件が限定されている（正規表現一致が使えない等）ためURLの体系によっては取りたいデータに絞り込めなかったりします。
それに対しSearch Console APIではAND条件でURLの指定が行えるため、取りたいデータを正しく取り出すことができます。

### 2.任意の期間でグラフ化できること
Search Sonsoleのウェブアプリ上で取得可能なデータは直近90日分に限定されています。
通年変化の観測や、昨年との比較などは、手元にデータを残さなければ行なえません。
ウェブアプリからCSVでデータのダウンロードも可能ですが、定期的にダウンロードし続けるなんて大変ですよね。
それに対し、SQLクエリでグラフ描画期間を指定しているため、可視化期間の任意性が格段に増しました。

### 3.自動更新される
はい。言うまでもないですね。

# どのようにやったか
さて、お待たせしました。ここが最も大切ですね。
タイトルにもある通り、今回は3つのツールを掛け合わせてダッシュボードをつくってもらいました。

## 使ったツールとその役割

1. **Google Search Console API**...言わずもがな、データソースです。 
2. **Treasure Data**　　　　　　 ...APIから取得したデータの蓄積を担当。
3. **re:dash**　　　　　　　　　 ...グラフ描画・ダッシュボード機能。

Treasure Dataもre:dashも、以前から社内で使われていたツールです。
Google Search Console APIは代替不可能ですが、残りの2つはデータ蓄積・グラフ描画の機能を持つほかのツールでももちろん良いでしょう。

## 構成
![system.png](https://qiita-image-store.s3.amazonaws.com/0/146324/39ba09ba-7193-0062-85c9-b81d44bdc2e9.png)
構成は上の図のとおり、です。
（要求だけ相談して作っていただいたため、それぞれがどんな役割を果たしているかくらいしか把握していません^^;）
データを取り出すページ群のルールとページ群名を決め（例：URLに"list","stations"を含む）、APIから日別・ページ群別にデータを取り出してTreasureDataに格納したものを、re:dashでグラフ描画しています。
今回の構成で社内的に嬉しいポイントは、Treasure Dataもre:dashも以前から使われていたツールのため馴染みがあることと、SQLで取り扱えること。
グラフ描画の期間を変更したり、蓄積したデータの中から取り出す項目を変更するくらいの些細な変更であれば非エンジニアでも取り回しが効くようになり、非常にありがたい構成です。

## Search Console APIで取得可能なデータ
APIの技術的なドキュメントについては、[Googleの公式](https://developers.google.com/webmaster-tools/v3/)をご覧ください。
Search Consoleで閲覧できる情報の中から、以下のものが取得可能です。

- Search Analytics （この記事のダッシュボードで利用したデータです）
- Sitemaps
- Sites
- URL Crawl Errors Counts
- URL Crawl Errors Samples

クロール関連では、エラーについては取得できますが、クロールページ数やGoogleが検知しているダウンロード時間はAPIからは取得できません。

### Search Analytics
Search Analytics（ウェブアプリ上の検索アナリティクス）では、今回のダッシュボードで取得した
Google検索結果の表示回数・クリック数・CTR・順位を、様々な絞込方法で取得できます。
GUIではこんなパネルで操作し、APIでも同種の絞込項目が使えます。
![search_analytics.png](https://qiita-image-store.s3.amazonaws.com/0/146324/4c43a1d7-6371-c462-294f-3a16bcb7d71b.png)

どんなデータがどんな形で取得できるか具体的に見てみたい場合には、
https://developers.google.com/webmaster-tools/v3/searchanalytics/query
でテスト実行してみると良いでしょう。

# おわりに
情報が十分かどうか、いささか不安ですがご紹介は以上です。

Qiitaで”SEO”と検索すると「嫌い」「忘れたい」「めんどくさい」「しばらく考えなくてもよい」など、寂しい言葉が散見されます。笑
SEO、確かにめんどくさく感じることも多いですよね。
ですが、流入データよりもずっと大きなデータを扱ったり、Googleの技術を推測したり、検索キーワードからは普段直接接することのない心の声が確かに聞こえてくるなど、少し関わりを増すだけで意外な面白いポイントも見つかるかもしれません。

SEOは計測項目やツールが非常に多く、また自動化しにくいため、小さく見えるものでも自動化すると、きっとSEO担当者は小躍りして喜びます。
世界のどこかでエンジニアからSEO担当者へ、ダッシュボードのクリスマスプレゼントが届くことを願って。
ここまでお付き合いいただいた方へ、お読みいただきありがとうございました。

明日は[shinfkd](http://qiita.com/shinfkd)兄さんですね。
お楽しみに！