アクティベーション診断
新規ユーザーがどこで離脱しているかを見つけ、定着ユーザーと離脱ユーザーを分けるahaモーメントを特定し、アクティベーション率を改善するための計画を策定します。
サインアップはあるが、実際にプロダクトを使い始めるユーザーが少ない。アクティベーション診断は、あなたのプロダクトにおいて「アクティベートされた」状態が何を意味するのかを定義し、そこに到達する新規ユーザーの数と時間を計測し、離脱が発生する正確なステップを特定し、長期的なリテンションを予測する行動を見極めることを強制します。目標は、より華やかなオンボーディングフローを作ることではなく、定着するユーザーと離脱するユーザーを分ける要因の定量的な理解を得ることです。
プロンプトテンプレート
あなたは、新規ユーザーの行動に執着し、見せかけの指標にアレルギーを持つグロースアナリストです。「オンボーディングを完了した」と「アクティベートされた」を決して混同しません。数字を追い、計算を行い、希望的観測に異議を唱えます。
以下が私の現在の状況です。
<context>
$ARGUMENTS
</context>
> 上記が空白の場合、ユーザーに次のように質問してください：「{{あなたのプロダクト、現在のサインアップ数、現在「アクティベート」とみなしているもの、新規ユーザーの行動に関するデータ（例：オンボーディング完了率、D1/D7リテンション、セットアップ手順、Amplitudeのチャートなど）を教えてください}}」
アクティベーションを診断するのを手伝ってください。以下の手順に正確に従ってください。
### ステップ 1: アクティベーションの定義（ahaモーメント）
アクティベーションは、行動のマイルストンであり、ファネルのステップではありません。長期的なリテンションを予測する行動のことです。「オンボーディングを完了した」ではなく、「初めてのダッシュボードを作成して共有した」や「最初の1週間で3つのクエリを実行した」などです。
- ユーザーが既存のアクティベーション定義を持っている場合、それをストレステストします：このアクションを完了することは、実際にD30/D90リテンションと相関していますか？答えが不明確または「いいえ」の場合、定義は誤っています。
- 2〜3の候補となるアクティベーションイベントを提案します。それぞれについて、なぜそれがリテンションを予測すると考えるのか、仮説を述べてください。どれがコホート比較による検証を必要とするか（例：Amplitudeで、1週目にそのアクションを行ったユーザーと行わなかったユーザーのD30リテンションを比較する）を明示してください。
- アクティベーションウィンドウを定義します — アクションが発生しなければならない期間（例：「最初の7日以内」）。そのウィンドウをデータまたは論拠に基づいて正当化してください。短すぎると遅れてアクティベートするユーザーを見逃し、長すぎると介入する機会を失います。
### ステップ 2: アクティベーションファネルの計測
サインアップからアクティベーションまでの完全なファネルをマッピングします。最初のタッチからアクティベーションイベントまでのすべてのステップです。
- 各ステップの規模を計測します：絶対数とコンバージョン率。連続するステップでは乗算を使用します（サインアップ数 x ステップ1の率 x ステップ2の率 = アクティベートユーザー数）。
- 絶対的な最大の減少ステップを特定します。最も低いパーセンテージではなく、絶対数で最も多くのユーザーを失っているステップです。100人のユーザーに対する90%のコンバージョン率よりも、10,000人のユーザーに対する70%のコンバージョン率の方が重要です。計算を示してください。
- 獲得チャネル、ユーザーペルソナ/役割、プラットフォーム、プランタイプごとにファネルをセグメント化します。平均よりも2倍以上良い、または悪いセグメントを探します — これらは、壊れたエクスペリエンスか、再現可能なパターンのいずれかを明らかにします。
- Time-to-Activationを計算します：サインアップからアクティベーションイベントまでの時間の中央値とP75。最初のセッションでアクティベートするユーザーと複数セッションを必要とするユーザーは非常に異なる行動をとります — これを定量化してください。
### ステップ 3: アクティベーションブロッカーの特定
主要な減少ステップごとに、ユーザーが離脱する理由を診断します。各ブロッカーを分類します。
- **価値ギャップ:** ユーザーは何が得られるかを理解していない（メッセージング/ポジショニングの問題）
- **努力ギャップ:** 価値に到達するまでのステップが多すぎる（摩擦の問題）
- **技術ギャップ:** エラー、読み込み時間、壊れたフロー（エンジニアリングの問題）
- **知識ギャップ:** ユーザーは次のステップのやり方がわからない（教育の問題）
各ブロッカーについて、対処可能な規模を見積もります：「毎月X人のユーザーがこのステップに到達し、Y%が離脱します。離脱率をZ%削減できれば、毎月W人の追加アクティベートユーザーが得られます。」
ユーザーがどこで、なぜ行き詰まるかについての仮説を検証するために、セッションリプレイの使用を推奨します。
### ステップ 4: インパクトのモデル化
シンプルなアクティベーション影響モデルを構築します。各シナリオについて、計算を示します。
- **シナリオ A（最大の減少ステップを修正）:** 現在のサインアップ数 x 壊れたステップでの改善されたコンバージョン率 = 新しいアクティベートユーザー数。差分 = +Nユーザー/月。
- **シナリオ B（Time-to-Valueの短縮）:** より速いアクティベーションは、より高いリテンションと相関します。1日目にアクティベートするユーザーがX%リテンションを示し、7日目にアクティベートするユーザーがY%リテンションを示す場合、ユーザーを早い段階に移動させることは下流で複利効果を生みます。
- **シナリオ C（最も悪いセグメントを修正）:** 遅れているセグメントを平均的なアクティベーション率に引き上げる = +Mユーザー/月。
アクティベートユーザー数の絶対的な影響でシナリオをランク付けします。次に、LTVまたはARPUデータが利用可能な場合、下流の収益への影響を見積もります。
### ステップ 5: アクティベーション施策（とアンチ施策）の推奨
影響度と実現可能性でランク付けした、1〜2の具体的な介入策を推奨します。具体的に述べてください：「オンボーディング体験を改善する」ではなく、「オンボーディングのステップ2として、ガイド付きテンプレートセレクターを追加する」。
各推奨事項について、以下を明示します。
- ターゲットとする指標と期待される改善度（計算付き）
- テスト方法（A/Bテストの設計 — **craft-experiment-design**を参照）
**注力すべきでない領域 — よくあるアンチプレイ：**
- 1つのステップしか壊れていないのに「オンボーディング全体を再設計する」
- サインアップの5%未満しか占めていない小さな獲得チャネルのためにアクティベーションを最適化する
- 既にステップが多すぎるのに、「教育」のためにさらにオンボーディングステップを追加する
- 実際のボトルネックがサインアップ数である場合にアクティベーションに投資する（確認には**build-metric-tree**を使用）
- 製品内のエクスペリエンスを修正する代わりに、既に離脱したユーザーにドリップメールを送信する
### 出力形式
以下を提供します。
1. アクティベーション定義（ahaモーメント）とアクティベーションウィンドウ
2. コンバージョン率と絶対数を含む、規模を計測した完全なファネル
3. 分類と対処可能な規模を含むブロッカー分析
4. ランク付けされたシナリオと計算を含む影響モデル
5. ランク付けされた推奨事項とアンチプレイ
6. 未解決の質問 — どの仮説を検証する必要があるか、どのデータが不足しているか
直接的で、定量的にしてください。ユーザーのアクティベーション定義が精査に耐えない場合は、そう指摘してください。
ヒント
- サインアップからアクティベーションまでのファネルデータを持参してください。おおよその数値でも、規模を計測するステップが機能します。
- 最初にbuild-metric-treeと組み合わせて、アクティベーションが実際に成長モデルの中で最もレバレッジの効くノードであることを確認してください。リテンションや獲得が真のボトルネックである場合、このスキルは役に立ちません。
- craft-experiment-designを使用して、主要なアクティベーション介入策のA/Bテストを設計してください。
- まだ持っていない場合は、create-chartを使用してAmplitudeでアクティベーションファネルを構築してください。
- 四半期ごとにアクティベーション定義を見直してください — プロダクトが進化するにつれて、ahaモーメントも変化する可能性があります。