フレームワーク活用ガイドひとことで言うと#
ユーザーの行動（クリック・購入・検索など）を1つ1つの「イベント」として記録・構造化し、行動パターンを分析する手法。ページビューだけでは見えない**「ユーザーが実際に何をしているか」**を定量的に把握し、プロダクト改善の根拠にできる。
押さえておきたい用語#
- イベント（Event / イベント）
- ユーザーが行った1つの行動を表すデータレコードのこと。「ボタンをクリックした」「商品をカートに入れた」「検索した」など、時刻・ユーザーID・行動内容を含むログとして記録する。
- イベントプロパティ（Event Property / イベント プロパティ）
- イベントに付随する属性情報を指す。「カートに追加」イベントなら、商品名・価格・カテゴリ・数量などがプロパティにあたる。プロパティが豊富なほど深い分析ができる。
- イベントタクソノミー（Event Taxonomy / イベント タクソノミー）
- イベントの命名規則と分類体系である。チーム全体で統一しないと、同じ行動が別名で記録されたり、逆に異なる行動が同じ名前で混在したりして、分析が成立しなくなる。
- セッション（Session / セッション）
- ユーザーの一連の行動を時間的にまとめたひとかたまりの活動単位。一般に30分間の非活動で区切る。イベント分析ではセッション内のイベント列から行動パターンを読み解く。
イベント分析の全体像#
こんな悩みに効く#
- 新機能をリリースしたが、実際にどのくらい使われているかわからない
- ユーザーがどこで離脱しているか、ページビューだけでは特定できない
- イベントトラッキングを入れたが、データがバラバラで分析できない
基本の使い方#
分析のすべての土台になるのが命名規則と分類体系。チーム全体で統一する。
命名規則の推奨フォーマット: object_action
product_viewed（商品を閲覧した）cart_item_added（カートに追加した）checkout_completed（購入を完了した）search_executed（検索を実行した）
各イベントには必須プロパティを定義:
| イベント | 必須プロパティ |
|---|---|
| product_viewed | product_id, category, price |
| cart_item_added | product_id, quantity, price |
| checkout_completed | order_id, total_amount, item_count |
トラッキングプラン（スプレッドシートで十分）にすべてのイベント定義を記録し、エンジニア・PM・アナリストで共有する。
設計したイベントを実際に計測開始する。
- 自動トラッキング: ページビュー、クリック、スクロールなど汎用的な行動
- 手動トラッキング: ビジネス固有の重要行動（購入、申し込み、特定機能の利用など）
実装後は必ず検証:
- すべてのイベントが正しく発火しているか（開発者ツールで確認）
- プロパティの値が正しく記録されているか（null や空文字がないか）
- ユーザーIDが正しく紐づいているか（匿名→ログイン後の接続）
検証を怠ると、数ヶ月分のデータが使い物にならない事態になりかねない。
データが蓄積されたら、目的に応じた分析パターンを使う。
頻度分析 — まず全体像を把握
- 各イベントの発生回数・ユニークユーザー数を集計
- 「よく使われている機能」と「ほとんど使われていない機能」を特定
シーケンス分析 — 行動の流れを把握
- コンバージョンに至ったユーザーの行動パスを抽出
- 「検索 → 商品閲覧 → カート追加」が多いのか「おすすめ → 商品閲覧 → カート追加」が多いのか
ファネル分析 — ボトルネックを特定
- 主要な行動ステップの通過率を計算
- 「カート追加 → 購入完了」の**離脱率が65%**なら、決済フローに問題がある可能性
セグメント比較 — 差異を発見
- 継続ユーザー vs 離脱ユーザーの行動を比較
- 「初回ログインから3日以内に○○機能を使ったユーザーは、30日後の継続率が2.4倍高い」
分析結果をそのままにしない。改善仮説に変換する。
例: 「カート追加 → 購入完了の離脱率が65%」という発見から:
- 仮説1: 送料表示が遅い → 送料を商品ページに事前表示する
- 仮説2: 決済方法が少ない → ○○Payを追加する
- 仮説3: カート画面のUIが複雑 → ステップ数を減らす
仮説に優先順位をつけ、A/Bテストで検証する。イベント分析は「問題発見」には強いが、「原因特定」には仮説と検証が必要。
具体例#
MAU 120万人のレシピアプリ。レシピ保存数は月間850万回と好調だが、実際に「作った」ボタン（cook_completed イベント）を押したユーザーは月18万人しかいなかった。保存しただけで満足している、いわゆる「積みレシピ」状態。
シーケンス分析で「保存後に作った」ユーザーの行動を調べると、**72%**が「保存翌日にプッシュ通知を開いた」経路を通っていた。一方、保存しただけのユーザーへの通知は配信されていなかった。
「保存24時間後にリマインド通知を送る」施策をA/Bテストで検証。処理群の調理完了率が**8.2% → 14.7%に改善し、DAUも+6%**増加。「保存」と「調理」という2つのイベントを分けて追跡していたからこそ、この課題が見えた。
3ヶ月かけて開発したダッシュボード機能。リリース後1ヶ月のイベントデータを見ると、dashboard_viewed（ダッシュボード表示）は4,200回あったが、dashboard_widget_added（ウィジェット追加）は280回、dashboard_shared（共有）はわずか23回だった。
ファネル分析で「表示 → ウィジェット追加 → 共有」の通過率を計算すると、表示から追加への離脱率が93%。セグメント比較で追加に至ったユーザーを分析すると、88%がオンボーディングチュートリアル（tutorial_completed）を完了していた。チュートリアル未完了ユーザーの追加率はわずか2%。
チュートリアルを初回表示時に強制ではなく「やってみる」ボタンで誘導する形に変更し、チュートリアル完了率が**15% → 52%に向上。ウィジェット追加率も6.7% → 22%**に改善した。イベントの「深さ」を測ることで、機能のどのレイヤーで止まっているかが一目瞭然になる。
1日の来客数3,500人の地域スーパー。POSデータはあるが「何が売れたか」しかわからず、「お客さんが店内でどう動いているか」は把握できていなかった。
カートに取り付けたビーコンで位置データを収集し、「棚前で10秒以上滞留した」をイベント（shelf_browsed）として定義。商品カテゴリ・滞留時間・その後の購入有無をプロパティに設定した。
2週間のデータで分析した結果、惣菜コーナーでの滞留率は45%と高いのに購入率は12%。シーケンス分析で「惣菜コーナー → レジ」の間に68%のユーザーが「飲料コーナーに立ち寄る」ことがわかり、惣菜の隣に飲料を配置する売場変更を実施。惣菜の購入率が12% → 19%、飲料のついで買いが**+340個/日増加し、客単価が+85円**上昇した。
やりがちな失敗パターン#
- タクソノミーなしでイベントを追加し続ける — 開発者がそれぞれの命名で実装すると、
add_cart、cart_add、addToCartが混在する。分析時にデータを統合できず、蓄積した数ヶ月分のログが使えないという事態に陥る。最初にトラッキングプランを作る手間を惜しまない - イベントを入れすぎてノイズだらけになる — 「とりあえず全部取っておこう」と100種類以上のイベントを入れると、分析の焦点がぼやける。まずは10〜20個のコアイベントに絞り、仮説に基づいて段階的に追加する
- 「何が起きたか」の分析で止まる — イベントデータは「事実」を教えてくれるが「理由」は教えてくれない。「離脱率が高い」とわかっても「なぜ離脱するのか」は、ユーザーインタビューやA/Bテストで別途検証する必要がある
まとめ#
イベント分析は、ユーザーの行動を構造化されたイベントログとして記録し、頻度・シーケンス・ファネル・セグメントの4つの視点で分析する手法。すべての土台はイベントタクソノミーの設計にあり、ここを怠ると後からデータを活用できない。分析で見つけた課題は「なぜ」を検証するところまでセットで進めることで、プロダクト改善の確度が格段に上がる。