Google AnalyticsのUnique Eventsは同じ操作を繰り返した回数と分けて読む
公開日: 執筆:佐藤
資料のダウンロードや問い合わせ先の表示では、イベントの総数だけを見ても、どれだけの訪問で操作されたかは分かりません。Google AnalyticsのUnique Eventsは、一つのセッションで同じEvent Category、Action、Labelの組合せを最初に受け取ったときだけ一件として数えます。Total Eventsは、同じ操作を何度行ってもすべて数えます。操作の回数と、少なくとも一度操作したセッションを分けて読むことが必要です。
この二つは、どちらか一方が正しい数字ではありません。知りたいことが違います。リンクが何回押されたかを確かめるならTotal Eventsを使います。資料を一度でも開こうとした訪問がどの程度あったかを知りたいならUnique Eventsを使います。
二つの数字が示すものを先に分ける
| 数字 | 数えるもの | 答えられる問い |
|---|---|---|
| Total Events | 送信されたイベントの回数 | 操作は何回起きたか |
| Unique Events | 一つのセッションで最初に受け取った同じイベント | 少なくとも一度操作したセッションはいくつあったか |
説明用の仮例として、料金表PDFのリンクを考えます。一人がリンクを二度押せば、Total Eventsは二回です。同じセッションで、同じCategory、Action、Labelを送っていれば、Unique Eventsは一回です。リンクを押した回数と、リンクを使ったセッションを同じ数字として扱わないことが出発点になります。
Total EventsがUnique Eventsより大きいとき、直ちに計測の失敗とはいえません。利用者が資料を見直した、画像を何度も拡大した、動画を再生し直したという操作が含まれるからです。一方で、同じクリックを二重に送る設定になっていても差は大きくなります。数字の差を見つけたら、先に操作の性質を考え、それから送信設定を確認します。
反対に、二つの数字がほとんど同じ場合も、利用者が一度しか操作していないと断定しません。操作を繰り返しにくいページかもしれませんし、同じsessionで二回目以降を送らない実装になっているかもしれません。数字の形だけで利用者の行動を決めず、実際のpageを開き、同じ操作を二度行った場合にどのeventが送られるかを確認します。
一回の操作と一度以上の利用を混同しない
たとえば、問い合わせ電話番号を表示するボタンを押した回数を見て、問い合わせの見込みを比べる場合を考えます。ボタンを一人が三回押したとしても、三件の問い合わせがあったわけではありません。表示の操作をためらった、番号を控えようとして見直した、画面を戻ったという場合もあります。
この場面では、二つの数字を並べると判断が変わります。Unique Eventsが増えていれば、少なくとも一度は番号を見ようとしたセッションが増えています。Total Eventsだけが大きく増え、Unique Eventsがほとんど変わらないなら、同じセッションでの繰り返しが増えています。画面が分かりにくいのか、同じ操作を二重に送っているのかを、実際のページと設定で確かめます。
ただし、Unique Eventsは利用者の人数ではありません。これはセッション内の同じイベントを一度として数える指標です。端末を替えた場合や、別のセッションになった場合まで一人としてまとめるものではありません。問い合わせの件数や売上を知りたいときは、イベント数だけで結論を出さず、問い合わせ完了や取引の記録と分けて確認します。
イベントを目標に使う場合は、操作が完了したことと、事業の成果になったことも分けます。資料PDFのdownloadは、資料を求めた操作を示しますが、資料を読んだことや問い合わせにつながったことまでは示しません。電話番号の表示も、電話がつながったこととは別です。eventを増やすためにbuttonを目立たせる前に、その数字を何の判断に使うかを決めます。
Category、Action、Labelを途中で変えない
Unique Eventsは、Event Category、Action、Labelの組合せで同じイベントかどうかを判断します。そのため、同じPDFへのリンクでも、あるページではActionを「download」、別のページでは「PDF」と送れば、別のイベントとして数えられます。ページごとにLabelを変えることにも目的が必要です。
| 確かめたいこと | Category | Action | Label |
| — | — | — |
| 資料の種類ごとの利用 | document | download | 料金表PDF |
| ページごとの利用 | document | download | 設置ページ名 |
| 問い合わせ先の表示 | contact | show | 電話番号 |
表は説明用の仮例です。三つの値に何を入れるかは、報告で何を比べるかに合わせて決めます。同じ操作をまとめて見たいのに、ページ名をActionへ入れて毎回変えると、操作の合計が分かりにくくなります。反対に、資料ごとの差を見たいのに、すべて同じLabelへ送れば、どの資料が使われたかを後から分けられません。
名前を途中で変える場合は、いつから何を変えたかを残します。たとえばActionをdownloadから別の語へ替えると、同じ資料を見ていてもreport上では別のeventになります。新しい名前を使い始めた後に以前の数字と合計すると、操作が増えたのか定義が増えたのか分かりません。eventの命名を直す作業と、以前の期間との比較を同じ表に混ぜません。
設定を外部へ任せる場合も、何を一件と数えるかは事業側で決めます。実装担当者はイベントを送れます。しかし、資料を一回開いたセッションを知りたいのか、何度開かれたかを知りたいのかは、業務上の問いによって違います。報告を受け取る前に、二つの問いを決めておく方が、後から数字へ意味を足さずに済みます。
数字を比べる前に行う確認
- 一つの操作を選び、操作回数と一度以上の利用のどちらを知りたいかを書く。
- Category、Action、Labelに入れる値を決め、同じ操作では同じ組合せを送る。
- 実際のページで一度操作し、同じクリックを二重に送る設定がないか確認する。
- 同じ期間、同じページ、同じイベントについてTotal EventsとUnique Eventsを並べる。
- 差が大きい場合は、利用者の繰り返しと送信設定の二つを分けて調べる。
最初に見るべきなのは、数字の多さではありません。その数字が何を一件としているかです。Total EventsとUnique Eventsを同じ表に置けば、操作が増えたのか、操作したセッションが増えたのかを分けて考えられます。
報告する際は、Total EventsとUnique Eventsのどちらを使ったかを列名のまま残します。「資料利用が増えた」とだけ書くと、操作回数が増えたのか、利用したsessionが増えたのかが分かりません。数字の横に対象期間、eventの組合せ、知りたかった問いを添えると、次に読む人も同じ意味で比較できます。
関連記事

