Google Analyticsの定例reportは数字を並べず次に変えるpageを一つ決める

Google Analyticsの定例reportは、アクセス数を多く並べるために作るものではありません。見た数字から、次に確認するpageまたは直す操作を一つ決めるために作ります。数字を増やしても、誰が何を変えるかが決まらなければ、reportは記録で終わります。

Google Analytics Solutions Blogの2016年4月19日の記事は、reportを事業上の判断につなぐには、訪問者数やgoal、event conversionのような数字を、参照元や日付などの条件と組み合わせて読む必要があると説明しています。数字の増減だけで結論を急がず、どのpageで何が起きたかまで確認します。

定例reportを作る時間は、数字を集める時間より、数字の意味をそろえる時間に使います。訪問者数が増えたという報告を受けても、どのpageを読んだ人か、何を知ろうとして来た人か、事業側が受けられる問い合わせにつながる人かが分からなければ、次の作業を決められません。すべての指標を一枚に集めるより、今月判断したい問いを一つ選びます。

たとえば「問い合わせが減った」という問いなら、全siteのsessionを先に眺めません。問い合わせpageへの到達が減ったのか、formを開く人が減ったのか、送信完了が減ったのか、広告や検索から来る人が変わったのかを分けます。数字の差は原因ではありません。どこを確認するかを決める入口です。

期間と対象が違う数字は同じ表で比べない

前月より訪問者が増えたという数字だけでは、何が増えたか分かりません。広告、検索、紹介、mailから来た人をまとめると、どの施策を続けるか判断できないからです。

定例reportでは、まず比べる条件を固定します。

たとえば、検索から料金pageへ来る人が増えたのに問い合わせが増えない場合、最初に見るのは全siteの平均ではありません。料金pageに必要な条件が書かれているか、問い合わせへのlinkが分かるかを確認します。

期間をそろえるときは、日数だけを合わせればよいわけではありません。休業日、campaignの開始日、mail配信、価格の変更、formの不具合など、訪問者の行動へ影響する出来事を並べます。今月は月初から月末、前月は途中までというように比べると、数字が変わっても何が違うのか分かりません。比較する日付と、途中で行った変更をreportの近くへ残します。

流入元を分ける場合も、名称が似ているものを勝手に一つの成果にしません。検索、広告、mail、他siteからのlinkでは、訪問者が持っている期待が違います。広告から来た人は広告文で約束した内容を確かめ、検索から来た人は検索語への答えを探します。同じ料金pageを見ても、次に直すべきものが広告文なのかpage本文なのかは、流入条件を見なければ分かりません。

reportの最後に一つの判断を書く

定例reportには、数字の下に「次にすること」を一つ書きます。複数の課題が見つかっても、その週に直せるものを一つ選びます。担当と期限がない改善案は、次回のreportでも同じ文章になりやすいためです。

この表の「次にすること」は、実績ではありません。確認または修正するための仮の判断です。変更後は、同じ条件で数字を見直し、予想どおりだったかを確かめます。

一つに絞るのは、ほかの問題を無視するためではありません。予算、時間、確認できる人には限りがあるため、その週に責任を持って確かめられる作業を選ぶためです。課題が三つ見つかったなら、残り二つも消さずに次回の候補として記録します。ただし、同じ週に三つのpageと広告文を同時に直すと、次のreportでどの変更を見直せばよいか分からなくなります。

「次にすること」には、作業だけでなく完了の見方を添えます。料金pageの導線を読むなら、誰がいつまでに読むか、どのlinkとformを確認するかを書きます。keywordを見直すなら、どのcampaignのどの検索語句を対象にするかを書きます。担当と確認条件がなければ、改善案は次の会議で同じ文言を繰り返すだけになります。

reportの受け手が事業側で、操作する人が制作側や広告担当の場合は、数字と依頼内容を分けて渡します。「訪問者が増えた」だけでは、制作側は何を直すべきか判断できません。対象page、流入元、利用者が次にしてほしい行動、画面で確認したい箇所を添えます。解析を任せても、事業の目的を決める責任まで渡さないようにします。

Secondary dimensionは理由を探すために使う

Google Analyticsでは、reportへSecondary dimensionを加えると、pageと参照元、pageとdeviceのように、二つの条件を重ねて見られます。使う前に、何を確かめたいかを決めます。

「どの流入元の人が料金pageを見たか」を知りたいなら、pageを主にして参照元を重ねます。「広告から来た人がどのpageを読んだか」を知りたいなら、参照元を主にしてpageを重ねます。画面に出せる組み合わせを試すのではなく、判断したい問いに合わせて選びます。

Secondary dimensionを使う前には、一つ目の条件だけで何が分かっているかを確認します。料金pageの訪問が減っていることが分かれば、次に参照元を重ねて、どの入口が変わったかを見ます。最初から多くの条件を重ねると、数字が細かくなりすぎて、増減が通常の揺れなのか判断しにくくなります。問いに答えるために必要な二つ目だけを選びます。

pageとdeviceを比べる場合も、mobileが少ないという数字だけでlayoutを直す理由にはなりません。mobileで料金pageを開いた人が、本文を読めずに離れているのか、問い合わせformまで進んでいるのか、そもそも広告や検索から来ていないのかを分けます。数値を見てから実際のpageを開き、説明、画像、menu、formを確認します。Google Analyticsのreportは画面の不具合を自動で直すものではありません。

定例reportを続けるなら、毎回同じ基準日、流入元の分類、page名、行動の定義を使います。途中でgoalやeventの数え方を変えたなら、以前の数字と単純に比べず、変更した日を明記します。数字の見え方を変えたことと、利用者の行動が変わったことを分けるためです。

最初のreportで決めるのは、全siteを改善する計画ではありません。検索または広告から人を受けているpageを一つ選び、そのpageで利用者が知りたいこと、次にしてほしいこと、確認する数字を一組にします。次回は同じ条件で見直し、変えたことが目的へ近づいたかを確かめます。

最初の一手は、次の定例reportで見るpageを一つ選ぶことです。そのpageで訪問者が知りたいことと、次にしてほしい行動を書き出せば、必要な数字を絞れます。