結論：PRDの計測は「Ahaを一意にし、TTV分布（p50/p95）で遅延の正体を掴む」ことから始めます。
ダッシュボードが毎朝揺れると、会議はたちまち感覚論に逆戻りします。なぜなら、数値の信頼がなければ合意は積み上がらないからです。そこで本稿では、Aha一意化の作法、TTV（p50/p95）を“分布”で見る理由、イベント命名と属性、検証のガードレールを物語とテンプレで固定します。
なぜ「Aha一意化」から始めるのか
効果検証の母数はAha達成者です。ここが揺れると、改善幅の評価が歪みます。それは、Ahaが二重発火／未発火／計測タイミングのズレを起こしやすい領域だからです。まず「Ahaの完了条件を文で書く→UIの完了トーストに紐づけて一意に発火→QAで重複を禁止」の順で固めます。
- 文で定義：対象／行動／完了条件（例：初回の法人管理者が「チーム作成」を完了し、完了トーストが表示）
- UIフック：完了トースト表示時のみ
achieve_ahaを発火 - QAルール：1操作＝1発火（一意性の自動テストを追加）
TTVを“平均”で見ない理由
平均は外れ値に引っ張られ、現実を曖昧にします。分布の中心（p50）と遅い裾（p95）を並べると、改善の当て先が具体化します。それは、p95が遅延の山＝サポート負荷や離脱の源泉を映すからです。よってPRDでは「起点・終点・計算」を固定し、分布でモニタします。
【TTV定義】
起点：view_entry（入口画面の描画）
終点：achieve_aha（完了トースト表示）
計算：TTV = t(achieve_aha) - t(view_entry)
目標：p50 = __分 / p95 = __分（p95は警告閾値を設定）
イベント設計：命名・属性・粒度の基準
ログは「少なく、欠けなく」。過剰なイベントは復旧不能なノイズを生みます。ここでは“3＋α”の原則で、入口・主要行動・Ahaに、離脱捕捉を少数だけ添えます。これは、何を見て何を捨てるかを前もって決め、意思決定の速度を守るためです。
【最小イベント表 v1.5】
| event_name | trigger | props |
|-------------------|-------------------------|--------------------------------------|
| view_entry | 入口画面表示 | segment, device, source |
| click_primary_cta | 主要CTAクリック | step, ui_variant |
| input_error | バリデーションエラー | field_name, error_type |
| wait_over_n | n秒超の待機（例：5s） | step, duration |
| achieve_aha | Aha達成（完了トースト） | session_length, steps |
| return_next_day | 翌日活性 | |
- 命名は英小文字＋スネーク：
view_entry,achieve_aha - 属性は“比較に使うものだけ”：
segment/device/sourceは残すが、推測再構成できる冗長属性は削る - 重複発火の禁止：UI側で排他・計測側でデデュープ
テンプレ：PRDに貼る「計測仕様」
【計測仕様 v1.2（PRD貼付用）】
目的：Aha一意化とTTV分布で改善の当て先を固定
Aha定義：＿＿＿＿（対象／行動／完了条件）
TTV：起点=view_entry／終点=achieve_aha／p50=__分／p95=__分
イベント：
- view_entry（props: segment, device, source）
- click_primary_cta（props: step, ui_variant）
- input_error（props: field_name, error_type）
- wait_over_5s（props: step, duration）
- achieve_aha（props: session_length, steps）
- return_next_day（props: ー）
品質チェック（毎朝）：
- Aha母数の日次整合（±3%以内）
- p95が警告閾値（目標+20%）を超えたらアラート
- 離脱トップ3（error/wait）をSlack通知
責任者：＿＿＿＿
更新頻度：1時間
具体例を丁寧に読む：数値が“静かにズレる”ときの直し方
例1｜Aha率が日ごとに揺れる：二重発火の罠
症状は“昨日だけ妙に良い”。調べると、完了トースト前後で別経路のachieve_ahaが発火していました。修正はUIの排他＋計測側の一意制御（aha_idを生成）。以後、Aha率は±1%以内で安定。
例2｜p50は改善、p95が重い：遅延の正体は「説明の長さ」
入力項目削減でp50は短縮。ただ、p95の尾が残る。セッションを再生すると、長文ガイドを読み込むユーザーが一定比率で存在。対処は「一文の目的＋折りたたみ」。結果、p95が2.1分短縮。これは、遅延の原因が処理速度ではなく認知負荷だったからです。
例3｜D1が伸びない：Aha定義の見直しで回復
当初のAhaが「設定完了」。翌日の戻りが弱いまま。インタビューで“最初の成果確認”が動機だと再確認し、Ahaを「成果カード初回表示」へ移動。導線をそこに合わせると、D1は+11pt。定義を正すと、ダッシュボードの山は自然に動きます。
ダッシュボード：毎朝5分で“どこが詰まっているか”を見る
“見える化”の目的は意思決定を速くすること。タイルは目的に直結する最小構成で十分です。それは、余分なグラフが意思決定を遅らせるからです。
- タイル1：Aha到達率（前日／7日移動平均）
- タイル2：TTV p50/p95（p95アラート：目標+20%）
- タイル3：離脱トップ3（
input_error／wait_over_5s） - タイル4：入口別Aha率（招待リンク／アプリ内ボタン）
会議運用：揉めずに決める台本
「Ahaは一意に観測できているか？（QA結果）
p95の山は“入力／待ち／理解”のどれに由来するか？
今週、p95を2分削るにはどのレバーを引くか？」アンチパターン：やってはいけない計測
- 目的のないイベント乱造（復旧不能なノイズ）
- AhaをUI外の非同期で計測（未達でも“達成済み”に化ける）
- 平均だけで判断（p95の山が見えない）
- “便利そうな属性”の付けすぎ（ジョイン地獄）
u-note：意思決定の順路を固定する
Aha→TTV→翌日活性の順で見ると意思決定が速くなります。詳しくはKPI設計と運用ガイドへ。
関連記事
FAQ
- Q. Ahaを二つ置いてもいいですか？
- A. 最初は一つに。複数Ahaは学習の焦点をぼかします。成熟後にサブAhaを追加してください。
- Q. p95が安定しません。
- A. 起点・終点の揺れ（入口混在／Ahaの非一意）を疑ってください。入口を一つに固定し、Ahaは完了トースト連動で一意化します。
- Q. 属性はどこまで付けますか？
- A. 比較に使うものだけ（segment/device/source）。“いつか使うかも”は切ります。
▼有料note（直リンク）
コメント