概要
Supershipグループ Advent Calendar 2025の17日目の記事になります。
- イベントログは計測したい指標から逆算して設計しましょう
初めまして。
Supershipで検索事業のデータ基盤業務に従事しております、 @frtn と申します。
普段の業務としてロギング内容の設計をするのですが、これの考え方は弊社のサービスに限らず広く適用できると考え、アドベントカレンダーを機に棚卸しをすることになりました。
どなたかのたすけになると幸いです。
はじめに
事業としてwebページを運用していると、避けて通れないのは実績の改善です。
真っ当に改善をするには現状把握がとても大切になります。
このとき、適切な現状把握を助けるためには、適切な計測内容を設計する必要があります。
本稿では、この適切な計測内容についての考え方の初歩をまとめます。
本稿の内容を踏まえた実践の一例として、Google Analyticsのカスタムイベントを設計する際に活用できます。
https://support.google.com/analytics/answer/12229021?sjid=16566482884798627723-NC
基本編: ターゲット指標から収集する情報を組み立てる
私たちは検索事業を提供している都合から、説明にも検索を用います。
具体的には通販サイトの商品検索を考えます。
検索結果ページの改善を求められているとします。
ページ改善にも色々あるんですが、今回は商品検索の順位改善をターゲットにします。
ふんわりした表現に言い換えると、みんなの求めてる商品が検索結果の上位に出てくると商品を探す平均時間が短くなって嬉しいですねという方向性での改善を目指します。
ここで、みんなの求めている商品をどのような数値で表すかの定義を考えましょう。
例えば、下記のような指標が考えられます。
- サービス利用者が閲覧した回数の多い商品（以下閲覧回数）
- サービス利用者が検索結果ページで選択した回数の多い商品（以下選択回数）
- サービス利用者が購入した回数の多い商品（以下購入回数）
指標が決まったら、次にユーザ行動の計測内容について考えます。
大きく分けて下記の2点を決める必要があります。
- どのタイミングで計測するか
- どのようなデータを計測するか
これらは計算したい指標が決まると自ずと決まります。
例えば、先ほど挙げた指標ではそれぞれ下記のようになります。
| 計測タイミング | 計測データの一例 | |
|---|---|---|
| 閲覧回数 | 商品ページ表示時 | 商品ID, 時間, ページ遷移元の情報 |
| 選択回数 | 検索結果選択時 | 商品ID, 時間, 同時に表示されていた商品情報 |
| 購入回数 | 商品購入時 | 商品ID, 時間, 同時購入数 |
最後に実装です。
計測する指標が決まったので、後はwebページ内で計測タイミングに該当する箇所で計測データに該当する内容のイベントログを取得します。
一例として、閲覧回数の計測を考えます。
サイト内回遊経由で商品ID ABC123 を閲覧した場合のログは、下記のように組み立てられます。
{
"event_type" : "page_view",
"timestamp" : 1234567890,
"item_id" : "ABC123",
"reference" : "internal"
}
※ 選択回数や購入回数の場合にどのようなログを組み立てるとよいのかは読者への課題とします
この情報をGoogle Analyicsのイベントパラメータにセットすることで、期待する情報をイベントログとして収集します。
このようにしっかりと計測内容を設計することで、後段でのイベントログ分析が非常に実施しやすくなります。
応用編: 計測情報をアップデートする
イベントログの設計は最初から完璧なものが作れるわけではありません。
実際には、webページの成長に応じて要件が拡張されていきます。
そのような場合の考え方も同じで、基本編と同様のステップを実施します。
一例として、これまではみんなの求めている商品、つまり人気商品という視点で指標を設計していましたが、新たに不人気商品という視点で指標を設計したくなったケースを考えます。
基本編と同様に、どのような数値で表すかの定義を考えます。
今回は少し複雑ですが、選択回数をベースに選択されなかった割合とします。
具体的には下記の計算で求めることができます。
選択されなかった割合 = 1 - 選択された割合 = 1 - \frac{選択回数}{検索表示回数}
次に、検索表示回数と選択回数の計測タイミングと計測データを考えます。
このふたつは別々に取得することでシンプルに設計することができます。
| 計測タイミング | 計測データの一例 | |
|---|---|---|
| 検索表示回数 | 検索結果表示時 | 表示された商品IDの一覧, 時間 |
| 選択回数 | 検索結果選択時 | 選択した商品ID, 時間 |
最後に、それぞれの指標を計測するデータ構造を設計し実装します。
例えば下記のようになります。
{
"event_type" : "impression",
"timestamp" : 1234567890,
"items" : ["ABC123", "DEF456", "GHI789"],
"query_id" : "RRRRRRRR-RRRR-4RRR-rRRR-RRRRRRRRRRRR"
}
{
"event_type" : "click",
"timestamp" : 1234567890,
"item_id" : "DEF456",
"query_id" : "RRRRRRRR-RRRR-4RRR-rRRR-RRRRRRRRRRRR"
}
このように、基本編と比較すると、取得するイベントログの種類もイベントログ内の情報も増えています。
一般に計測したい指標はサービスの成長とともに増えていくもので、それに合わせてイベントログの設計も拡張していく必要があります。
このことは一つ大きな示唆があり、ある程度一般的な指標は一通り計算できるよう先回りしてイベントログを設計することが大切であり、ここにwebページ運用の経験が生きてきます。
補足です。
どのwebページにも関連するような計測指標は、Google Analyticsなどの計測ツール側で事前に定義してくれていたりもします。
ぜひ活用しましょう。
https://support.google.com/analytics/answer/9234069?sjid=16566482884798627723-NC
結論
- イベントログは計測したい指標から逆算して設計しましょう
おわりに
今回はイベントログの設計について、最初の一歩についてまとめました。
今回触れた内容は結論だけ見ると自明よりではありますが、実際には意外とうっかりしまいがちです。
そのため定期的に振り返ったり見直したりしましょう。
また今後、実務で発生するような、より踏み込んだ話についてもまとめる予定です。