Search Analytics APIは検索語、ページ、国、端末を質問ごとに分けて取得する

Search Analytics APIを使う前に、「どの検索語がクリックされたか」「どのページが検索から読まれたか」のように、答えたい質問を一つ決めます。検索語、ページ、国、端末を最初から一つの表へ詰め込む必要はありません。

まず、取得できる最新の日付を確認します。次に、上位の検索語またはページを一種類だけ出力します。同じ条件を保存して繰り返せるところまで作れば、画面から数字を転記する作業を減らせます。

API実装より先に一つの質問を決める

Search Analytics APIの発表では、検索performanceのdataを自社のappやtoolへ取り込めると案内しています。利用例には、取得できる最新日、クリック数が多い検索語、上位ページ、特定の国における上位検索語、その国でmobile端末に絞った上位検索語があります。

これらは、同じ数字を別の見せ方にしたものではありません。質問に応じて、集計する対象と条件が変わります。

最初の出力は一行で説明できるものにします。「先週取得できる最新日までの、クリック数が多い検索語10件」のように、対象、期間、並べる基準、件数を記録してください。

最新の取得可能日を先に確認する

APIを毎日動かしても、実行日と同じ日までdataが用意されているとは限りません。取得処理の最初に、どの日付までdataが存在するかを確認します。

最新日を確かめずに固定日付で表を作ると、まだdataがない日を減少として扱うおそれがあります。数字がゼロなのか、取得対象の日付がまだ用意されていないのかを分けてください。

保存する表には、検索performanceの対象期間だけでなく、APIを実行した日時と取得できた最新日も残します。担当者が変わっても、どの時点のdataを使った表かを確認できます。

検索語とページは別の質問として出力する

検索語の上位10件は、利用者がどの言葉で検索したかを見る表です。ページの上位10件は、どのURLが検索から読まれたかを見る表です。行の意味が違うため、一つの列へ混ぜません。

たとえば、検索語の表は記事企画やtitleの確認に使えます。ページの表は、検索流入が集まるURLを見つけ、内容、内部link、問い合わせへの経路を調べる入口になります。ただし、上位にあることだけで原因や成果は決まりません。

検索語の変化を調べる場合も、APIが返す順位表だけで結論を出さず、同じ期間と条件で比較します。検索需要、検索結果の変化、page内容の変更などを分けて調べる必要があります。

国と端末は必要な質問にだけ加える

国や端末で絞ると、全体の表では見えにくい違いを確認できます。一方、条件を増やすほど表は細かくなり、少ないdataを大きな傾向として読み違えやすくなります。

「特定の国のmobile検索を確認する理由」が決まっていなければ、まずsite全体の検索語またはページを出します。全体を把握した後で、対象地域やmobile対応など、実際に判断する作業へつながる条件だけを追加してください。

APIで多くの表を自動生成することと、必要な判断が増えることは同じではありません。定期的に見る担当者、異常とみなす条件、確認後の作業まで決まらない表は、保存するだけで終わります。

実装を委託しても質問と出力を所有する

program作成を制作会社へ依頼する場合は、API接続だけを発注しないでください。対象site、答えたい質問、期間、出力する単位、保存先、実行頻度を一組で渡します。

接続処理と定期実行を委託しても、何を測るか、誰が読むか、取得したdataをどこへ残すかはsite側の運用責任です。program本体、認証に必要な設定、実行手順、出力形式も受け取り、委託先が変わっても同じ取得を再現できる状態にします。

最初の一手は、取得できる最新日を確認し、その日までを対象にクリック数が多い検索語10件だけを出すことです。検索語の表を保存できたら、同じ期間の上位ページを別の表として追加してください。