Search Analytics APIへの移行ではCSV取得の停止日と新旧の数字を分けて確認する

Search Analytics APIへ移るときは、新しい取得先を作る前に、旧CSV取得scriptがいつ止まるかを確認する。旧scriptで得ていた数字と、新しいAPIで得る数字を、列名だけで同じ意味だと決めない。まず取得処理を止めずに残し、同じ質問を新旧で出して差を読む。

Googleの案内は、検索query、impression、click、rankingに関する旧CSV download scriptへのaccessを2015年10月20日に終了するとした。旧scriptはdeprecatedになったClientLogin APIを使い、新しいSearch Analytics dataを使わないと説明している。

移行するのはCSVではなく取得の仕組みである

CSVを保存しているだけなら、停止日に困らない。困るのは、毎週CSVを取得してreportへ流し込むscriptである。止まる場所は表計算の集計ではなく、その前にある認証と取得処理になる。

移行の目的は、CSV形式を残すことではない。検索queryや表示回数を、止まらない方法で確認できるようにすることである。APIの結果をCSVへ書き出す形を選ぶことはできるが、旧scriptをそのまま動かし続ける理由にはならない。

新旧の数値を一度に混ぜない

新しいSearch Analytics dataを使わない旧scriptと、新しいAPIの結果には、集計の前提が異なる部分があり得る。数字が変わったときに、検索需要が変わったのか、取得元が変わったのかを分けられなければ、reportの比較は役に立たない。

移行期間には、同じsite、同じ期間、同じqueryの条件を新旧で出す。差があれば、列の名前を合わせて帳尻を合わせるのでなく、取得元と取得日をreportへ残す。古い数字を訂正する必要があるとは限らない。過去に何を使って集計したのかを残す方が、後で説明できる。

最初の作業は、旧scriptの保存先を一つ開き、実行する人、ClientLoginを使う場所、10月20日以降に止まる処理を一行ずつ書き出すことである。APIの設定を始める前に、止まるものを特定する。

次に、新しいAPIで得た結果を、すぐに月次レポートの正本へ流し込まない。別の表か別のシートへ出し、対象サイト、対象期間、検索語の条件、取得日を添える。旧CSVの最終回と新しいAPIの最初の結果を並べて見れば、取得の切替日と数字の違いを説明できる。差があったときに必要なのは、数字をどちらかへ寄せることではなく、違いがどこで生じたかを調べることだ。

移行後も、過去のCSVを捨てる必要はない。それは古い仕組みで作ったレポートの根拠である。ファイル名や保存場所を変えるなら、いつまで旧CSVを使い、いつから新しいAPIの結果を使ったかが分かるようにする。取得方法の変更は、検索の成績そのものが変わったことを意味しない。

停止日までに確かめる順序

1. 旧スクリプトが実行される日時と、CSVの保存先を調べる。
2. ClientLoginを使っている処理と、担当者を特定する。
3. 新しいAPIで、同じ対象サイトと期間の結果を別に取得する。
4. レポートへ使う取得元と切替日を記録する。

この順序なら、APIの設定が終わったと思ったあとで、週次の取得だけが止まる事態を避けやすい。自動化は便利だが、誰がどの処理を動かしているかが分からなければ、停止の案内を受けても直す場所を見つけられない。