今日の問い
そのイベント名から、誰が何をしたのかを説明できますか。
30秒でつかむ
計測は、取れるデータを集めるところから始めません。意思決定に必要な行動を決め、その行動だけをイベントにするところから始めます。
ファネルは、主要タスクを複数のイベントで表したものです。各段階の人数を並べると、どこで次へ進めなくなったかを探せます。
30秒図解 · LESSON 31
絞り込み図
画面遷移ではなく、意味ある行動を測る
目的達成へ近づくイベントだけをファネルへ置きます。
- 対象ページへ到達
- 候補詳細を確認
- 主要操作を実行
- 目的達成
CLUE · 見抜く手掛かり
各イベントが利用者価値を表すか
TRAP · ありがちな罠
取れるログを全部計測する
原則
イベントは、利用者やシステムに起きた一つの出来事です。予約ボタンのような部品名より、appointment_startedのような行動名にすると、画面が変わっても意味が残ります。
一つのイベントには、発生時刻、匿名化した利用単位、結果、必要最小限の文脈を持たせます。何でもパラメータに入れると、分析しづらいうえ、不要な情報を保持することになります。
ファネルは、前のレッスンで作った主要フローから作ります。たとえば、予約開始、条件入力、候補選択、予約完了です。各段階の定義を先に固定し、同じ利用者が一定期間内に順番どおり進んだかを数えます。
離脱率だけでは、画面が悪いとは断定できません。途中で目的を達成した人や、後日戻る人もいます。ファネルは問題の場所を示す警報であり、原因の説明ではありません。 原因は利用者観察やエラー記録と照合します。
計測にはプライバシーの境界を置きます。入力本文、氏名、相談内容は送らず、必要な行動と状態だけを記録します。保存期間、利用目的、アクセス権も計画に含めます。GA4のファネルデータ探索は段階の通過と離脱を見るプラットフォーム機能、NIST Privacy Frameworkは目的とリスクからデータ処理を管理する枠組みとして分けて参照します。
Web、アプリ、サーバー側の行動をイベントとして送信し、既存の自動計測を補うという計測モデルとプライバシー上の注意を支える。
良い例と惜しい例
イベント定義の再利用性
blue_button_clickedを記録する。ボタンの色と配置を変えると、イベントの意味も変わる。appointment_startedを記録し、入口をentry_pointとして分ける。画面が変わっても予約開始を同じ意味で比較できる。良い定義には、発火条件も必要です。表示時ではなく、利用者が予約条件の入力へ進んだ時点など、実装者が迷わない条件まで書きます。
AIへの指示例
目的: 主要タスクの進行と離脱箇所を測れるイベントとファネルを設計する
制約: 個人情報、自由記述、患者情報を送らず、画面部品名ではなく利用者行動で命名する
参照: primary-flow.md、ui-states.md、success-criteria.md
受入条件: イベント名、意味、発火条件、必須パラメータ、送信禁止情報を表にし、主要ファネルの順序と集計期間を示す
確認問題
セルフチェック
1. 予約ファネルで条件入力後の離脱が多いと分かったとき、最も妥当な判断はどれですか。
最終制作へ反映する
イベント辞書と主要ファネル
measurement-plan.mdに、主要タスクのイベント辞書、発火条件、送信禁止情報、ファネル順序、集計期間を追加する。
Acceptance criteria
- 主要イベントが画面部品ではなく利用者行動として命名されている
- 各イベントの発火条件と、送ってはいけない情報が明記されている
今日のまとめ
- イベントは、判断に必要な利用者行動から定義する
- ファネルは離脱箇所を示すが、原因は観察と照合する
- 次は、プロダクト目標をHEARTとGSMで指標へ変換する