Google AnalyticsのRelease Notesは画面の変更と自社の計測変更を分けて記録する

Google AnalyticsのRelease Notesは、製品側で何が変わったかを確認する資料である。自社サイトの計測コード、フィルタ、広告、ページを誰かが変えた記録ではない。数字に変化が出たときは、Google Analyticsの変更と自社の変更を別々に残してから原因を調べる。

Googleの案内は、Google Analyticsの新機能や変更をRelease Notesへまとめるとしている。管理画面に見慣れない項目が出たとき、まずこの記録で製品変更かどうかを確認できる。

製品の変更だけでは数字の理由にならない

レポートの見た目が変わった日と、訪問数が変わった日は同じとは限らない。ページを公開した日、広告URLを変えた日、フィルタを追加した日も、数字を読む条件になる。製品側の変更を知ることと、その変更が自社の数字に影響したと確かめることは別である。

仮に、担当者が新しいレポートを見つけた日に流入数も変わったとしても、それだけでGoogle Analyticsの更新を原因にしない。先に計測設定とサイトの変更日を調べる。原因が分からない状態で過去の数字を作り直すより、何を確認したかを残す方が次の比較に役立つ。

Release Notesは、数字を説明する答えではない。調査の入口である。月次レポートを作る人は、数字が大きく動いた月だけでも、製品変更と自社変更を別の欄へ記録しておくとよい。

数字が動いた日付を一枚の記録に集める

記録は、難しい書式にする必要がない。日付、変わったこと、誰が変えたか、確認した数値を一行ずつ残せばよい。重要なのは、Google Analyticsの製品変更と、自社で行った作業を同じ欄に混ぜないことである。

たとえば、月の途中で問い合わせフォームを直し、同じ月にGoogle Analyticsの画面も変わったとする。問い合わせ完了の数が変わったなら、まずフォームを直した日と計測タグを確認する。そのうえでRelease Notesを見て、同じ指標の定義や集計方法に変更があるかを確かめる。製品側の案内を読んだだけで、フォームの修正を調べずに済ませてはいけない。

このように記録しておけば、翌月に別の担当者がレポートを読むときも、数字だけを見て推測する必要がない。担当者の記憶に頼る運用は、引継ぎのときに最も失われやすい。数字の説明に必要な変更記録は、レポート本体と同じくらい残しておく価値がある。

調査の順序を決めてから数字を見る

数字が変わったときは、最初に比較する期間と指標をそろえる。次に自社の更新記録を見て、設定、広告、ページのどれが変わったかを確認する。そのあとでRelease Notesを確認し、製品側の変更が関係しそうかを判断する。この順序なら、画面の変化と事業の変化を一つの理由にまとめずに済む。

原因を一回で特定できないこともある。その場合は、「フォームを更新した」「フィルタを変更していない」「Release Notesに関連する変更を見つけられなかった」のように、確認済みの事実を残す。分からないことを推測で埋めるより、次の月に比較できる記録を残す方が、運用の負担を減らす。