onboarding-cro について
登録から継続利用までの導入体験を改善する、プロダクト・グロース・マーケティングチーム向けのフレームワークです。アクティベーションの定義と価値実感までの時間短縮を軸に、フロー設計や停滞ユーザーの再活性化、実験を扱います。
主な機能
- 01アクティベーションイベントと指標の定義
- 02導入フローと空状態の設計
- 03価値実感までの時間短縮
- 04アプリ内通知とメールの連携
- 05停滞ユーザーの再活性化策
- 06導入実験の設計
活用シーン
- 01登録後の離脱箇所の分析
- 02新規ユーザーの活性化経路の設計
- 03設定未完了ユーザーへの再アプローチ
- 04導入フロー変更のテスト
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ borghei/ claude-skills --skill onboarding-croインストール後、Claude Code で/onboarding-croを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
scripts/activation_funnel_analyzer.pyonboarding_checklist_scorer.pyttv_estimator.py詳細
オンボーディングのコンバージョン率最適化
アクティベーションの定義、価値実現までの時間のエンジニアリング、フローの設計、空の状態の設計、複数チャネルの連携、利用が停滞したユーザーの再エンゲージメント、実験設計を網羅した、本番環境向けのユーザーオンボーディング最適化フレームワークです。サインアップから製品の習慣的な利用に至るまでの重要な期間に焦点を当てています。
目次
- 初期評価
- アクティベーション定義フレームワーク
- オンボーディングフローの設計
- 価値実現までの時間のエンジニアリング
- 空の状態の設計
- 製品タイプ別のオンボーディングパターン
- 複数チャネルの連携
- 利用が停滞したユーザーの再エンゲージメント
- オンボーディングチェックリストの設計
- ツールチップとツアーの設計
- 指標と測定
- 実験フレームワーク
- 成果物
- 関連スキル
まず確認すること
オンボーディングを設計する前に、次の情報を確認します。不明な点や曖昧な点があれば、推測せずに質問してください。
- 製品タイプ — B2B SaaS、B2C アプリ、マーケットプレイス、コンテンツプラットフォーム(オンボーディングパターンを決定します)
- アクティベーションイベント(アハモーメント) — 30 日後の継続率と相関するアクション(フロー全体が目指すものを定義します)
- 現在のアクティベーション率とユーザーの離脱箇所 — ベースラインと、改善すべきファネルの最大のボトルネック
- 1 日目/7 日目/30 日目の継続率 — 優先度と、問題がオンボーディングにあるのか、プロダクト・マーケット・フィットにあるのかを判断します
中断ルール:成果物に最も大きく影響する 2~3 点だけを質問してください。ユーザーが「とにかく草案を作って」と言った場合は、そのまま進め、成果物の冒頭に前提を列挙してください。
初期評価
必要なコンテキスト
| 質問 | 重要な理由 |
|---|---|
| 製品タイプは何ですか?(B2B SaaS、B2C アプリ、マーケットプレイス、コンテンツプラットフォーム) | オンボーディングパターンを決定します |
| 中核となる価値提案は何ですか? | アハモーメントで実証すべき内容を定義します |
| サインアップ直後に何が起こりますか? | 現在の初回利用体験を特定します |
| 30 日後の継続率と最も相関するアクションは何ですか? | アクティベーションイベントを定義します |
| ユーザーはどこで離脱していますか?(利用可能であればファネルデータ) | 最大のボトルネックを特定します |
| 現在のアクティベーション率はどのくらいですか? | 改善のベースラインとなります |
| 1 日目/7 日目/30 日目の継続率はどのくらいですか? | 優先度を判断するための背景情報となります |
アクティベーション定義フレームワーク
アハモーメントを見つける
アハモーメントとは、完了するとユーザーの継続率が大幅に高まる特定のアクションです。機能のことではなく、ユーザーが中核的な価値を体験する瞬間です。
特定方法:
- コホート比較: 90 日後も継続しているユーザーと、離脱したユーザーを比較します。継続ユーザーが最初の 7 日間に行い、離脱ユーザーが行わなかったアクションは何ですか?
- 相関分析: 候補となる各アクションについて、1 週目にそのアクションを完了したことと、30 日目に継続していることの相関を算出します。
- タイミング分析: 継続ユーザーはこのアクションをいつ完了しますか?(1 日目? 3 日目? 7 日目?)
アクティベーションイベントの例
| 製品タイプ | アクティベーションイベント | これが効果的な理由 |
|---|---|---|
| プロジェクト管理 | プロジェクトを作成し、チームメンバーを1人招待する | コラボレーションによって乗り換えコストが生まれます |
| 分析ツール | トラッキングを設定し、最初のレポートを表示する | 自分のデータを見ることが価値につながります |
| デザインツール | 最初のデザインを作成し、エクスポートまたは共有する | 成果物によって価値が実感されます |
| CRM | 連絡先をインポートし、最初のアクティビティを記録する | データへの投資によってロックインが生まれます |
| マーケットプレイス | 最初の取引を完了する | 取引によって価値が提供されます |
| コンテンツプラットフォーム | 3件以上の情報源をフォローし、5件以上のコンテンツを利用する | パーソナライズによって習慣が促進されます |
| コミュニケーションツール | 最初のメッセージを送り、返信を受け取る | 双方向の価値によってアクティベーションが実現します |
アクティベーション指標の構造
Activation Rate = Users who reach activation event / Total signups
(within first N days)
Target: 40-60% activation within 7 days for B2C
25-40% activation within 14 days for B2B
オンボーディングフローの設計
フロータイプの選択
| アプローチ | 最適な対象 | リスク | 対策 |
|---|---|---|---|
| プロダクトファースト(製品画面に直接移動) | シンプルな製品、B2C、モバイルアプリ | 何もない状態に圧倒される | サンプルデータを事前に入力する |
| ガイド付きセットアップ(ウィザード) | 設定が必要な製品 | 価値を得る前に手間が増える | 最大3~5ステップに抑える |
| バリューファースト(結果をすぐに表示) | デモデータがある製品 | パーソナライズされていると感じられない可能性がある | 可能であればユーザーのデータを使う |
| テンプレートファースト | クリエイティブ/生産性ツール | 選択肢が多すぎて決められない | 最初に使えるテンプレートを3~5個厳選する |
| 動画チュートリアル | 複雑なB2B製品 | ユーザーが動画をスキップする | 90秒以内にする |
最初の30秒ルール
どのフロータイプを選ぶ場合でも、製品画面に移動してから30秒以内に、ユーザーが次のことをできるようにする必要があります。
- 次に行うことが1つだけ明確にわかる(選択肢を5つ表示しない)
- 製品が自分のために何をしてくれるのかを理解できる
- 先に進むための道筋が見える(行き止まりがない)
フロー設計の原則
| 原則 | 実装 |
|---|---|
| セッションごとに目標を1つにする | 最初のセッションでは、アハ体験に到達することだけに集中します |
| 説明するのではなく、実際に操作してもらう | チュートリアルを見るのではなく、ユーザー自身が操作します |
| 進捗によってモチベーションを高める | 進捗状況(チェックリスト、進捗バー、お祝いの表示)を見せます |
| 複雑さは後回しにする | 高度な設定や機能は、アクティベーション後に表示します |
| いつでも終了できるようにする | ユーザーはオンボーディングのどの要素もスキップまたは閉じることができます |
| 状態を記憶する | ユーザーが離れてから戻ってきた場合、中断したところから再開します |
価値実感までの時間の最適化
価値実感までの時間(TTV)短縮フレームワーク
TTVとは、サインアップからユーザーが製品の中核的な価値を体験するまでの経過時間です。短いほど良いです。
| ボトルネック | 検出方法 | 解決策 | 予想されるTTV短縮率 |
|---|---|---|---|
| 利用前にセットアップが必要 | セットアップ中にユーザーが離脱する | 必須のセットアップ手順を減らし、デフォルトを使用する | 30~50% |
| データ待ち | データが届くまで価値を得られない | サンプル/デモデータをすぐに提供する | 40~60% |
| チームメンバー待ち | 価値を得るにはコラボレーションが必要 | まず個人で価値を得られるようにし、その後チームでの利用に移行する | 20~40% |
| インテグレーションが必要 | ツールを接続しないと機能しない | 代替手段として手動入力を用意する | 30~50% |
| 学習曲線 | クイックウィンを得るには製品が複雑すぎる | テンプレートを使って最初の操作をガイドする | 20~30% |
| 承認/検証が必要 | メール認証、管理者の承認 | 最初の価値を得た後に検証を行う | 40~60% |
クイックウィンの設計
最初の3分以内に「クイックウィン」を実現できるよう、オンボーディングを設計します。
- 製品が提供できる、最もシンプルで価値のある成果を特定する
- 可能な場合は入力項目にあらかじめ値を設定する
- 選択を最小限にする(スマートなデフォルトを使う)
- 成果を祝う(「最初の[X]を作成しました!」)
- 次のステップをすぐに表示する
空状態の設計
空状態はオンボーディングの機会であり、行き止まりではありません。画面が空であれば、どこであってもユーザーをアクティベーションへ導く機会になります。
空状態の構成要素
┌─────────────────────────────────────┐
│ │
│ [Illustration or Preview] │ Show what this will look like with data
│ │
│ What this section does │ 1 sentence, benefit-focused
│ │
│ [Primary CTA: Create First X] │ Single clear action
│ │
│ Or try with sample data → │ Low-friction alternative
│ │
└─────────────────────────────────────┘
空の状態に関するルール
| ルール | 良い例 | 悪い例 |
|---|---|---|
| 最終状態を見せる | サンプルデータを使ったプレビュー | 完全に空白の画面 |
| CTA は 1 つにする | 「最初のプロジェクトを作成」 | 「詳細を見る」+「動画を見る」+「ドキュメントを読む」 |
| 価値を説明する | 「チームの進捗を 1 つの画面で確認できます」 | 「プロジェクトが見つかりません」 |
| サンプルデータを用意する | 「サンプルデータで試す」リンク | ゼロからの作成を強制する |
プロダクトの種類別オンボーディングのパターン
B2B SaaS
Signup → Setup Wizard (3-5 steps) → First Value Action → Team Invite → Deep Setup
├── Company info ├── Template selection ├── Email invites
├── Role/goal selection ├── Quick configuration └── Permissions
└── Integration connect └── First output created
主要指標: サインアップから最初のチームコラボレーションまでの時間
マーケットプレイス/両面市場
Signup → Complete Profile → Browse/Discover → First Transaction → Repeat Loop
├── Photo/avatar ├── Curated feed ├── Guided first action
├── Preferences ├── Search + filters └── Transaction completion
└── Verification └── Saved/bookmarked
主要指標: サインアップから最初の取引完了までの時間
モバイルアプリ(B2C)
Install → Permission Requests → Quick Win → Push Notification Setup → Habit Loop
├── Location (if needed) ├── Core action ├── Value-based ask
├── Notifications ├── Immediate result └── Frequency choice
└── Camera/contacts └── Celebration
主要指標: 1 日目の継続率
コンテンツ/メディアプラットフォーム
Signup → Interest Selection → Personalized Feed → First Engagement → Social Connection
├── Topic picks ├── Curated content ├── Read/watch/listen
├── Creator follows ├── Algorithmic mix └── Like/save/share
└── Format preferences └── Notification prefs
主要指標: 最初の 14 日間における週あたりのセッション数
複数チャネルの連携
メール+アプリ内の対応表
| トリガー | アプリ内のアクション | メールのアクション | タイミング |
|---|---|---|---|
| サインアップ完了 | 最初のステップを示すウェルカム画面 | CTA を 1 つに絞ったウェルカムメール | 即時 |
| ステップ 1 完了 | ステップ 2 を表示 | --(各ステップでメールを送らない) | 即時 |
| 24 時間経過、オンボーディング未完了 | 常時表示のバナー/チェックリスト | 「セットアップを完了しましょう」メール | サインアップから 24 時間後 |
| 72 時間経過、アクティベーション未達 | おかえりなさいモーダル | 「できることをご紹介します」メール | サインアップから 72 時間後 |
| アクティベーション達成 | お祝いモーダル+次の機能 | お祝いメール+次のステップ | 即時 |
| 7 日目、機能の発見 | 状況に応じたツールチップ | 「ご存じでしたか?」機能紹介メール | 7 日目 |
| 14 日目、エンゲージメント低下 | -- | ユースケースの例を使った再エンゲージメント | 14 日目 |
メールのデザインルール
- 各メールの CTA は 1 つだけにし、プロダクトへの再訪を促します
- すでに取った行動に基づいてパーソナライズします(すでに完了した操作を求めないでください)
- メールは短く保ちます(本文は 150 語未満)
- 件名には、一般的な「[Product] へようこそ」ではなく、具体的な次のステップを示します
停滞ユーザーの再獲得
停滞ユーザーの定義
| 停滞状態 | 基準 | 再獲得の優先度 |
|---|---|---|
| 始めていない | サインアップ後、一度も再ログインしていない | 中(ICP が合っていない可能性があります) |
| オンボーディングが途中 | セットアップ手順を 1~2 個完了した後、停止した | 高(労力を費やしたものの、壁にぶつかっています) |
| アクティブだがアクティベーション未達 | 3 回以上ログインしたが、アハ体験に至っていない | 最高(利用意欲はあるものの、行き詰まっています) |
| アクティベーション済みだが離脱傾向 | アハ体験に至った後、利用が減少している | 高(オンボーディングではなく、継続率の問題です) |
再獲得の施策
| 停滞状態 | 施策 1 | 施策 2 | 施策 3 |
|---|---|---|---|
| 始めていない | 「[X] を設定しました」メール | あらかじめ入力済みのアカウント | -- |
| オンボーディングが途中 | 「続きから再開しましょう」メール | 残りの手順を簡略化 | ライブサポートを提供 |
| アクティブだがアクティベーション未達 | アプリ内のガイド付きウォークスルー | 「同じようなユーザーは [X] をしています」という提案 | 価値の高いユーザーには担当者から連絡 |
| アクティベーション済みだが離脱傾向 | 機能紹介メール | ユーザーのワークフローに基づく利用のヒント | エンタープライズ顧客には CSM から連絡 |
人によるフォローアップのトリガー
価値の高いアカウント(エンタープライズ、高 ACV)の場合、次の条件に該当したら担当者から連絡します。
- ユーザーがオンボーディングで 48 時間を超えて停滞している
- ユーザーが 1 回のセッション中にヘルプドキュメントを 3 回以上閲覧する
- ユーザーが同じ操作を 2 回以上開始して中断する
- 初回のアクティベーション後、ユーザーのエンゲージメントスコアがしきい値を下回る
オンボーディングチェックリストの設計
チェックリストを使う場面
- 十分な価値を得る前に複数のセットアップ手順が必要な場合
- 発見すべき機能が複数あるプロダクト
- ユーザー自身がオンボーディングを進めるセルフサービス型の B2B プロダクト
- 「セットアップ完了」の状態が明確なプロダクト
チェックリストのベストプラクティス
| ルール | 実装 |
|---|---|
| 3~7項目 | 3項目未満ではチェックリストにする価値がありません。7項目を超えると、ユーザーを圧倒してしまいます。 |
| 価値の高い順に並べる | 最も効果の大きいアクションを先頭にします |
| すぐにできる項目から始める | 最初の項目は60秒未満で完了できるようにします |
| 進捗を表示する | プログレスバー、または「5項目中3項目完了」のカウンターを表示します |
| 完了済みの項目にチェックを入れる | ユーザーがすでに実行した項目は、完了済みとしてマークします |
| 完了を祝う | アニメーション、紙吹雪、「これで準備完了です!」というメッセージなどを表示します |
| いつでも閉じられるようにする | 「後で行う」オプションを用意します。ユーザーを決して行き詰まらせないでください。 |
| 常に表示しつつ、操作を妨げない | 操作を妨げるモーダルではなく、サイドバーのウィジェットやダッシュボードのカードとして表示します |
チェックリスト項目の設計
各項目には、次の内容を含めます。
- 明確なアクションラベル(「連絡先をインポートする」)
- 重要な理由(「やり取りを追跡できるようにするため」)
- 推定所要時間(「所要時間は約2分です」)
- CTA ボタン(「今すぐインポート」)
ツールチップとツアーの設計
ツールチップ/ツアーを使用する場面
- 機能が自明ではない複雑な UI
- ユーザーが見落とす可能性のある高度な機能
- メジャーアップデート後に変更された UI
- 特定の順序で見つける必要がある機能
ツアーのベストプラクティス
| ルール | 実装 |
|---|---|
| ツアーは最大3~5ステップ | 5ステップを超えると、ユーザーが閉じてしまいます |
| いつでも閉じられるようにする | すべてのステップに「ツアーをスキップ」を表示します |
| 再訪ユーザーには繰り返さない | ツアーの完了を記録し、二度と表示しません |
| 実際の UI 要素を強調表示する | 説明対象の要素にスポットライト効果を適用します |
| アクションを促す内容にする | 「ここをクリックしてプロジェクトを作成します」とし、「ここにプロジェクトが表示されます」とはしません |
| 段階的に進める | 1日目に基本ツアーを表示し、7日目に高度な機能のツアーを表示します |
指標と測定
主要な指標
| 指標 | 計算式 | 目標 |
|---|---|---|
| アクティベーション率 | アクティベーションに到達したユーザー数 / サインアップ総数 | B2C:40~60%、B2B:25~40% |
| アクティベーションまでの時間 | サインアップからアクティベーションイベントまでの所要時間の中央値 | B2C:1日未満、B2B:7日未満 |
| オンボーディング完了率 | すべてのステップを完了したユーザー数 / サインアップ総数 | 60%超 |
| 1日目の継続率 | サインアップ翌日に再訪したユーザー数 / サインアップ総数 | 40%超 |
| 7日目の継続率 | サインアップから7日後にアクティブなユーザー数 / サインアップ総数 | 25%超 |
| 30日目の継続率 | サインアップから30日後にアクティブなユーザー数 / サインアップ総数 | 15%超 |
| チェックリスト完了率 | すべての項目を完了したユーザー数 / チェックリストを見たユーザー数 | 50%超 |
ファネル分析テンプレート
Signup 100%
├── First login 85% (-15% never return)
├── Setup step 1 70% (-15% drop during setup)
├── Setup step 2 55% (-15% setup friction)
├── First value action 40% (-15% blank slate / confusion)
├── Activation event 30% (-10% incomplete value delivery)
└── Day-7 return 20% (-10% no habit formed)
絶対数で最も大きな離脱が発生しているステップの最適化に注力します。
実験フレームワーク
影響の大きい実験
| 実験 | 仮説 | 指標 |
|---|---|---|
| セットアップのステップを減らす | ステップ数を減らすと完了率が上がる | アクティベーション率 |
| サンプルデータを事前入力する | 何もない状態への不安を軽減する | 価値につながる最初のアクションまでの時間 |
| オンボーディングチェックリストを追加する | 進捗を可視化すると完了率が上がる | オンボーディング完了率 |
| メール認証を後回しにする | 価値を得る前の障壁を取り除く | アクティベーションまでの時間 |
| 役割/目標に応じてパーソナライズする | 関連性の高い経路によってアクティベーション率が上がる | セグメント別アクティベーション率 |
影響が中程度の実験
| 実験 | 仮説 | 指標 |
|---|---|---|
| ウェルカム動画とテキストの比較 | プロダクトによって動画が効果を高める場合も、低下させる場合もある | アクティベーション率と最初の画面での滞在時間 |
| チェックリストの順序を変更する | 価値を優先した順序にすると完了率が上がる | チェックリスト完了率 |
| ガイド付きツアーと自力での探索の比較 | ツアーは複雑なプロダクトに役立つ | 機能の利用率 |
| オンボーディング中のアプリ内チャット | リアルタイムのサポートにより停滞が減る | 停滞率、アクティベーション率 |
成果物
| 成果物 | 形式 | 説明 |
|---|---|---|
| アクティベーション定義ドキュメント | 構造化された定義 | アハ体験、アクティベーションイベント、成功指標、測定計画 |
| オンボーディングフロー図 | ステップごとのフロー | 離脱ポイントと判断分岐を含む登録後のフロー |
| チェックリスト仕様 | 項目ごとの設計 | アクション、根拠、所要時間、CTAを含む3~7項目 |
| メールトリガーマップ | トリガー/タイミング/目標の表 | 各オンボーディングメールの条件と内容 |
| 空の状態のコピー | 画面ごとの設計 | 各空の状態のイラストの説明、見出し、本文、CTA |
| 実験バックログ | 優先順位付きの表 | 期待される効果と工数で順位付けしたテスト案 |
| 停滞ユーザー向けプレイブック | 判断ツリー | 検出基準、復帰施策、エスカレーションルール |
関連スキル
- signup-flow-cro — ユーザーがプロダクトに入る前の登録フローを最適化する際に使用します。Onboarding-croは登録完了後から始まります。
- paywall-upgrade-cro — オンボーディングがアップグレードのタイミングにつながる場合に使用します。アハ体験に到達する前にペイウォールを表示しないでください。
- churn-prevention — ユーザーがアクティベーション後にチャーンする場合に使用します。アクティベーションに至っていない場合、問題はチャーンではなくオンボーディングにあります。
- page-cro — 登録前のマーケティングページがボトルネックであり、登録後のユーザー体験が原因ではない場合に使用します。
ツールリファレンス
1. activation_funnel_analyzer.py
目的: オンボーディングのアクティベーションファネルを分析し、最大の離脱ポイントを特定して、各ステップの改善による効果を推定します。
python scripts/activation_funnel_analyzer.py funnel_data.json
python scripts/activation_funnel_analyzer.py funnel_data.json --json
| フラグ | 必須 | 説明 |
|---|---|---|
funnel_data.json | はい | ファネルのステップ名とユーザー数を含むJSONファイル |
--json | いいえ | 結果をJSON形式で出力します |
2. onboarding_checklist_scorer.py
目的: オンボーディングチェックリストの設計を、ベストプラクティス(項目数、順序、クイックウィン、進捗表示)に照らして評価します。
python scripts/onboarding_checklist_scorer.py checklist.json
python scripts/onboarding_checklist_scorer.py checklist.json --json
| フラグ | 必須 | 説明 |
|---|---|---|
checklist.json | はい | チェックリストの項目とそのプロパティを含むJSONファイル |
--json | いいえ | 結果をJSON形式で出力します |
3. ttv_estimator.py
目的: オンボーディングのステップに基づいて価値実現までの時間(TTV)を推定し、短縮または削除できるボトルネックを特定します。
python scripts/ttv_estimator.py onboarding_steps.json
python scripts/ttv_estimator.py onboarding_steps.json --json
| フラグ | 必須 | 説明 |
|---|---|---|
onboarding_steps.json | はい | オンボーディングのステップ、推定所要時間(分)、要件を含むJSONファイル |
--json | いいえ | 結果をJSON形式で出力します |
トラブルシューティング
| 問題 | 考えられる原因 | 解決策 |
|---|---|---|
| アクティベーション率がB2Bで25%、B2Cで40%を下回る | アハ体験に到達するまでに時間がかかりすぎている | ttv_estimator.pyを実行してTTVのボトルネックを特定し、5分以内に最初の価値を届けることを目指します |
| ユーザーがオンボーディングを完了しても7日目に戻ってこない | オンボーディングが価値ではなく、セットアップにつながっている | 最初のセッションで設定だけでなく、意味のある成果を得られるようフローを再構成します |
| オンボーディングチェックリストの完了率が50%を下回る | 項目が多すぎるか、最初の項目が複雑すぎる | 3~7項目に減らし、60秒以内に完了できる簡単な達成項目から始めます。onboarding_checklist_scorer.pyを使用して評価します |
| 登録者の40%以上が停滞している | 白紙状態の問題、または次のステップが不明確 | データを事前に入力したサンプルと、空の状態のCTAを追加します。24時間後と72時間後に停滞ユーザー向けの復帰メールを送信します |
| 1日目のリテンション率が30%を下回る | 初回利用時の体験に行き詰まる箇所や混乱がある | 30秒ルールを適用します。30秒以内に、ユーザーが次に行うことを1つだけ確認でき、その価値を理解し、次に進む手段を得られるようにします |
| オンボーディングメールの開封率が低い | 件名が汎用的、または送信タイミングが適切でない | 次の具体的なステップに触れるよう件名をパーソナライズします。固定スケジュールではなく、トリガーに基づくタイミングで送信します |
| チームへの招待率が低い | 価値を実感する前に招待ステップが置かれている | ユーザーがまず個人でコアバリューを体験した後に、チームへの招待を促します |
成功基準
- B2B では14日以内のアクティベーション率が30~40%(B2Cでは40~60%)
- Time-to-first-value が5分未満(ttv_estimator.py で確認)
- オンボーディング完了率が60%超
- 1日目の継続率が40%超
- 7日目の継続率が25%超
- 利用が停滞しているユーザー向けの再開促進メールで、再アクティベーション率が10%以上
- オンボーディングチェックリストのスコアが、onboarding_checklist_scorer.py による評価で70以上
対象範囲と制限事項
- 対象範囲: アクティベーションの定義、オンボーディングフローの設計、価値実現までの時間の設計、空の状態の設計、チェックリストの設計、ツールチップ/ツアーの設計、メールの連携、利用が停滞しているユーザーへの再開促進、実験の設計
- 対象範囲外: サインアップ/登録フロー(signup-flow-cro を使用)、マーケティングページの最適化(page-cro を使用)、長期的な継続戦略、機能開発
- データへの依存: 最良の結果を得るには、ファネル分析(ステップごとの離脱データ)が必要です。これがない場合、最適化は経験則に基づきます
- 製品タイプが重要: B2B SaaS、マーケットプレイス、モバイルアプリ、コンテンツプラットフォームでは、オンボーディングのパターンが根本的に異なります。製品タイプに適したパターンを使用してください
- 万能な解決策はありません: 製品が価値を提供しない場合、どれだけオンボーディングを最適化しても継続率は改善しません。まずプロダクト・マーケット・フィットを検証してください
連携ポイント
- signup-flow-cro -- オンボーディング開始前の登録フローを最適化します。引き継ぎのタイミングは、アカウント作成が正常に完了した直後です
- churn-prevention -- ユーザーがアクティベーション後に離脱する場合、課題はオンボーディングから継続へと移ります。アクティベーション後の離脱には churn-prevention を使用してください
- paywall-upgrade-cro -- アップグレードの案内は、アハ体験に到達した後にのみ表示してください。初回のオンボーディング中にペイウォールを表示してはいけません
- page-cro -- ボトルネックがマーケティングページにあり、ユーザーがサインアップしていない場合は、オンボーディングを最適化する前にページを最適化してください
- customer-success-manager -- エンタープライズアカウントでは、人による支援を伴うオンボーディングがプロダクト主導のフローを補完します。CS チームはアクティベーション指標を監視してください