Google AnalyticsのUser Explorerは一人の行動を見たあと集計したsegmentで確かめる

Google AnalyticsのUser Explorerは、匿名の一人がsiteやappで行った行動を時系列で見るreportです。使う順序は、最初に集計reportで気になる変化を見つけ、その理由を探すために一人の行動を見ます。その一例を見ただけでpageを変えず、似た行動をする利用者のsegmentを作り、集計した数字へ戻って確かめます。User Explorerは結論を出す画面ではなく、調べる問いを具体的にする画面です。

集計reportは、全体で何が起きたかを教えます。たとえば、特定のlanding pageから問い合わせ完了へ進む割合が下がった、商品pageを多く見た利用者が購入へ進まない、といった変化を見つけられます。しかし、平均や合計だけでは、途中で何を見て離れたのか、同じpageを何度も開いたのか、別の端末やvisitにまたがる傾向があるのかまでは分かりません。User Explorerでは、集計された数字の中にいる匿名の行動を開き、仮説を作ります。

先に集計reportで調べる理由を決める

一人ずつの行動は具体的に見えるため、画面を開くとすぐ理由が分かったように感じます。しかし、一人が何度もpageを開いた理由は、比較検討かもしれませんし、表示の不具合かもしれません。社内の確認、通信の切断、操作のやり直しという場合もあります。一人の行動だけから、すべての利用者が同じ問題を抱えているとは決められません。

User Explorerを開く前に、何を確かめたいかを一文にします。「問い合わせformの途中で離れる人は、確認pageを見ているか」「商品比較pageを三回以上見る人は、どの説明へ戻るか」のように、対象page、行動、確認したい理由を置きます。問いが決まれば、見る期間と比較するgroupも決まります。

説明用の仮例として、資料請求pageの完了数が前月より下がった場合を考えます。まず集計reportで、同じ期間の流入数、資料請求pageの閲覧数、form開始、完了を並べます。そのうえで、formを開いたが完了しなかった匿名の行動をUser Explorerで見ます。利用者が料金pageへ戻っているなら、formの入力欄より先に、料金の説明や条件を確認する仮説ができます。逆に、formを開いた直後に終わる利用者が多く見えたなら、表示や入力条件を調べる仮説ができます。

仮説はまだ答えではありません。料金pageへ戻った一人がいたとしても、ほかの利用者が同じ行動をしているとは限りません。User Explorerで得るのは、「次にどのgroupを集計するか」という手がかりです。修正の理由は、似た行動をするgroupがどれだけあり、どのpageで同じ傾向が出るかを見てから決めます。

一人の行動を会員名簿として扱わない

User Explorerは匿名の個人単位の行動を分析するための機能です。画面に一人ずつの履歴が見えても、読者の氏名、電話番号、問い合わせ内容を集める画面ではありません。自社で持つ顧客dataと結び付けて、誰が何を読んだかを追いかけるために使うと、計測の目的が変わります。

siteを改善するために必要なのは、利用者の名前ではなく、どの説明で迷い、どこで手続きをやめ、何が次の行動を妨げているかです。匿名の行動を見て、pageの説明、form、導線に共通する問題を探します。個人の履歴を読む必要がある仕事と、公開siteの使いにくさを直す仕事を混ぜません。

説明用の仮例として、購入額が大きい利用者の行動を見たい場合を考えます。User Explorerで購入前に商品比較pageを読んでいる傾向が見えたら、その一人の購入履歴を営業の連絡先として使うのではなく、比較pageを見た利用者全体がどのように購入へ進むかを確認します。比較pageの説明が十分か、価格や納期のlinkが見つかるか、同じpageから離れる利用者が多くないかを集計します。改善する対象は匿名の一人ではなく、同じ条件でpageを使う人の体験です。

利用者の行動を扱う以上、何のために見るか、誰がreportを見られるか、画面の内容をどこへ出さないかを決めます。外部の制作会社や広告運用者へ共有する場合も、必要な期間、page、segmentの集計値を先に共有し、個人単位の履歴まで渡す理由があるかを確認します。dataを見られることと、必要な範囲を越えて共有してよいことは別です。

segmentを作って集計reportへ戻る

Googleは、User Explorerで見つけた価値の高い利用者をsegmentにし、ほかのreportへ適用して行動を理解する方法を案内しています。ここで作るsegmentは、一人を複製するためのものではありません。「商品比較pageを見てから料金pageへ進んだ利用者」「資料請求formを開いたが完了していない利用者」のように、確認したい行動条件を持つgroupです。

segmentを作るときは、条件を増やしすぎません。一人の履歴に合わせてpage、時刻、流入元、端末、閲覧回数を細かく重ねると、ほかに同じ利用者がいないsegmentになります。まず、改善の判断に関係する条件だけを残します。料金pageを見たか、formを開始したか、完了したかというように、pageの役割に沿って条件を選びます。

仮例の資料請求pageでは、formを開いた人をsegmentにし、料金pageを見た人と見なかった人で完了率を比べます。差が見えても、すぐ料金pageを長くするとは決めません。期間、流入元、device、formの変更日をそろえます。料金を確認した人がもともと検討度の高い人かもしれないためです。segmentは原因を証明する道具ではなく、次に確認する条件をそろえる道具です。

User Explorerで一人の行動を見たあと、同じ条件のsegmentを作り、Audience、Behavior、Conversionなどの集計reportへ戻ります。そこで共通の傾向が見えれば、pageの説明、linkの位置、formの条件を直す候補になります。傾向が見えなければ、一人の例をそのまま改善案にしません。仮説を捨てることも、余計な修正を増やさないための作業です。

改善前後は同じ条件で比べる

User Explorerから得た仮説をもとにpageを直す場合は、変更前の数字を残します。対象segment、期間、見るpage、完了とみなす行動を決め、変更後も同じ条件で確認します。formの入力項目を減らしたのに、同じ時期に広告の配信先も替えていれば、完了数が変わった理由を分けられません。変更はできるだけ一つにし、ほかに替えたものも記録します。

集計の数字が小さい場合は、一人の行動を増やしても判断が安定しません。問い合わせが月に数件しかないpageでは、前月との比較だけで結論を出さず、利用者の問い合わせ内容、営業日の違い、流入の大きな変化も確認します。User Explorerは細かい行動を見せますが、細かい画面が不確実さを消してくれるわけではありません。

最初の一手は、集計reportで気になる変化を一つ選び、「誰が」ではなく「どのpageで、どの行動が止まったか」という問いへ書き換えることです。その問いに合う匿名の行動をUser Explorerで見て、似た条件のsegmentを作り、集計reportへ戻ります。