あなたのダッシュボードは、リリースが成功したと言っている。サインアップが入った、ログインが増えた、チームは安心した。
すると2週間が過ぎる。サポートチケットは減ったが、製品がうまく動いているからではない。ただ、ユーザーは戻ってこない。少数のパワーユーザーだけが活発に活動している。新規アカウントの多くは静かにしている。アクセスを提供しただけだった。
そのギャップ ユーザー採用メトリクス ユーザー採用メトリクスは、ユーザーが価値を得、戻り、製品を日常のルーチンに組み込むかどうかを判断するために使用されます。これは、ユーザーが製品を使用することの重要性を強調するためです。
製品チームにとって、これは通常、製品のリリースが紙上では良好に見えますが、実際には弱いときに現れます。コラボレーションツールは、多くのアカウントの作成を得るかもしれませんが、ユーザーが最初のプロジェクトを作成したり、チームメンバーを招待したり、後で戻ったりするのはごくわずかです。モバイルアプリはダウンロードを得るかもしれませんが、ユーザーがオンボーディングを完了したり、製品が有用になる最初のアクションを完了したりするのはごくわずかです。もし、自分がそのような不一致に長い間見ているのであれば、すでに正しい質問をしていることになる。
より良いアプローチは、採用をアクセスから習慣までの旅として捉えることです。これは、ユーザーが製品を理解し始めたとき、最初の結果を得たとき、そして繰り返し行動を取ったときを観察することです。オンボーディング、活性化、そしてアプリユーザー体験の改善に取り組むチームは、同じことを発見することがよくあります。ユーザーの最初の成功は、ユーザーの最初のログインよりも重要です。 目次 導入
サインアップを超えて真の採用
- ユーザー採用メトリクス8つを解説
- 採用の簡単な方法
- 採用を効果的に測定・トラッキングする方法
- メトリクスを解釈し、基準を設定する
- ユーザーレベルとアカウントレベル採用の基本的な理解
- 採用ダッシュボードの作成と行動の実行
- AIとオートメーションを用いた採用メトリクスの未来
導入から真の採用まで
多くのチームは、店が歩客の数を数えるように成功を測定している。多くの訪問者がいることは、すべてうまくいっていることを意味する。が、製品は、人が一度訪問したことによって勝つことはない。製品は、ユーザーが意味のある行動を完了し、繰り返すことを意味する。
採用メトリクスが存在するのは、その理由だ。粗いアクイジションの焦点を、製品の価値に関する行動的な視点に置き換えたからだ。有用な質問は、「アカウントを作成した人はいくついるか?」ではなく、「製品が有用なほど戻ってきた人はいくついるか?」
実用的なルール: メトリクスがユーザーの価値に接続していない場合、それは採用を改善するのに役立たない可能性が高い。
プロジェクト管理アプリを考えてみよう。ログインするのは、ジムのロビーに入ったことと同じだ。実際に運動したことはない。最初のプロジェクトを作成し、タスクを割り当て、翌日更新する。そういった行動は、採用が始まっていることを示している。
通常、3種類の質問が最も重要だ。
- 価値の発見: 初めての有意義なアクションを完了したか?
- 繰り返し行動: 初めての成功の後、戻ってきたか?
- ワークフローの適合度: 使用が好奇心から定期的なものに拡大したか?
このガイドの残りの部分は、上記の質問に基づいて構築されています。オンボーディングがうまくいっているかどうかを知らせるメトリクスもあります。製品が習慣形成に成功したかどうかを知らせるメトリクスもあります。B2B チームにとって、もっと難しい質問に答えるための高度なメトリクスもあります。1 人の人物が製品を採用したか、顧客アカウント全体が採用したか?
8 つの不可欠なユーザー採用メトリクスを解説
採用の簡単な方法
採用の最も簡単なアナロジーは、ジムの会員権です。会員登録は採用ではありません。初めてのトレーニングに参加することは採用に近いですが、毎週戻ってくることは、ジムが誰かの生活の一部になったことを証明します。
同様の論理はソフトウェアにも当てはまります。 ClickLearn のユーザー採用メトリクスの概要によると、採用は、目標世帯のうち、有意義な使用マイルストーンに到達した割合として定義されることが多いが、単に新規登録数やログイン数ではありません。 採用率 = (新規アクティブユーザー / 総ユーザー) × 100 そして 機能採用率 = (機能を使用するユーザー / 総アクティブユーザー) × 100.
コアユーザー採用指標の概要
| 指標 | 式 | 何が示唆されているか |
|---|---|---|
| アクティブ化 | 製品マイルストーンによって異なる | ユーザーが最初の実際の価値を得たかどうか |
| DAU/MAU | 毎日有効ユーザー数 / 月間有効ユーザー数 | ユーザーが 1 か月以内に何回訪問するか |
| リテンション | リターンウィンドウによって異なる | ユーザーが初めて使用した後も何度も利用するか |
| チーン | 失敗の定義によって異なる | ユーザーが製品を使用をやめる数 |
| スティックネス | DAU/MAU でよく測定される | ユーザーが製品を定期的に使用するか |
| 機能採用 | 機能を使用するユーザー数 / 総有効ユーザー数) × 100 | 特定の機能が実際に重要かどうか |
| 価値を得るまでの時間 | サインアップから最初の価値の瞬間までの時間 | ユーザーが意味のある結果を得るまでの時間 |
| 採用率 | (新規有効ユーザー数 / 総ユーザー数) × 100 | アクセスから有効使用に移行したユーザーの数 |
採用率を忠誠心と関連付けるチームにとって、比較することで役立つのは、 アプリユーザーの保持パターン. 採用はユーザーを価値に導きます。保持は、そこに残っているかどうかを示します。
各メトリクスが実際に何を伝えているのか
活性化 活性化はユーザーがスタートラインを越えたかどうかを判断する指標です。ノートアプリでは最初のノートを作成すること、Slackではメッセージを送信することなど、具体的なフォーマットは製品によって異なりますが、原則は同じです。最初のアクションを選択してください。
DAU/MAU DAU/MAUは1日あたりのアクティブユーザー数と1か月あたりのアクティブユーザー数を比較する指標です。多くの月間ユーザーが毎日アクティブである場合、製品は定期的に使用されている可能性があります。
保持率 保持率は、初期期間後にユーザーが戻ってくるかどうかを判断する指標です。製品は初期の印象が良かったものの、後で有用ではない場合もあります。
脱落率 脱落率は、ユーザーがアクティブをやめたかどうかを判断する指標です。脱落率は有用ですが、主な制御装置ではありません。脱落率が上昇するまでの原因は、活性化や価値提供の初期段階にすでに存在することが多いためです。
脱落率を追跡することは重要ですが、脱落率を説明する指標にエネルギーを費やすことが重要です。
粘着度 粘着度はDAU/MAUとよく議論される指標です。多くのチームでは、2つの用語をほぼ同義語として使用します。実際の考え方は簡単です。粘着度の高い製品は、ユーザーがリマインダーなしで頻繁に訪問することができる製品です。
機能採用 特定機能の使用率を測定します。ワークフロー作成ツール、ファイル共有ツール、承認フローなどをリリースした場合、このメトリックは、有効なユーザーがそれを使用しているかどうかを示します。前のソースから得られた式は明確です。 (機能を使用するユーザー / 総有効ユーザー) × 100.
価値到達時間 ユーザーが最初の意味のある結果に到達するまでにかかる時間を測定します。このメトリックは、オンボーディングのフリクションを明らかにします。ユーザーが製品が役に立つように感じる前に、設定ステップが必要な場合、採用は早期に停滞します。
採用率 採用率は、ユーザーが有効に活発になるのではなく、単に登録しただけかどうかを尋ねるビッグピクチャです。そのため、登録のみではありません。より強力なビジネスメトリックです。
良い作業ルールは、メトリックを単独で読むのではなく、ペアすることです。
- 活性化 + 価値到達時間 オンボーディングが有効な最初の勝利に導くかどうかを示します。
- DAU/MAU + 保持率 使用が浅いものか、習慣的なものかを示します。
- 機能採用 + チャーン ユーザー採用度を効果的に測定して追跡する方法
ユーザー採用度を効果的に測定して追跡する方法
イベントのインストルメンテーションから始めましょう
採用度の測定は、ダッシュボードを開く前に始まります。採用度の測定は、どのユーザーの行動が追跡する価値があるかを決定するときから始まります。
Amplitude、Mixpanel、Heap、PostHog、Google Analyticsを使用している場合は、すべて同じ決定が必要です。ユーザーの行動を追跡する価値があるかどうかを決定するときに、製品イベントを価値に基づいて定義する必要があります。 “プロジェクトを作成しました”、「招待を送信しました」、「テンプレートを適用しました」、「レポートをエクスポートしました」などのイベントは有用です。ただし、「ページを表示しました」などのイベントはよくありません。
イベントの設定は簡単です。
- エントリイベント: サインアップ、初回ログイン、オンボーディングの開始
- 価値イベント: 初回プロジェクトの作成、初回ファイルのアップロード、初回ワークフローの完了
- コンテキスト: Capgo Builder / ネイティブクラウドビルド製品ページ。役割: 短いUIラベルまたはナビゲーションアイテム。メッセージキー `native_build_builder_credit_first` (ネイティブビルドビルダークレジットファースト)。 習慣イベント:
チームは、変更がマイルストーンを改善するかどうかをテストするために、制御されたロールアウトを使用します。 フィーチャーフラグシステムは、オンボーディングコピー、デフォルト設定、UIの変更の影響を分離するのに役立ちます。 ステージドリリースを実験しているチームの場合、このガイドは実践的な補完です。 フィーチャーフラグの実装方法のガイドです。 コホートを使用して時間の変化を確認する
コホート分析は、自分自身を欺くことなく変化を確認する最も明確な方法です。 ユーザーをすべてのユーザーとしてまとめるのではなく、開始日や受け取ったエクスペリエンスによってグループ化します。
次のような質問に答えることができます。
新しいオンボーディングを表示したユーザーは、完了率が高かったですか?
- リデザイン後のアカウントは、再度利用することができましたか?
- 新しいプランの層は、自社サービスユーザーとどのように異なりましたか?
- コホートを使用しないと、採用のイメージが曖昧になります。 既存のパワーユーザーは、新しいユーザーに影響を与える問題を隠すことができます。 上昇するトップラインメトリックは、弱いリリースを健康なものとして見せかけることができます。
オペレーターの視点:
価格、パッケージング、コアワークフローの変更など、オンボーディングの変更の度に、開始日によって行動を比較してください。 コホート分析は、自分自身を欺くことなく変化を確認する最も明確な方法です。
パスをマップする
フンネルはユーザーが動きを止める場所を示します。ユーザー採用の問題はほとんどが不思議なものではありません。特定のステップで発生します。
ほとんどの製品の採用フンネルは次のようになります。
- 到着: サイトやアプリを訪問したとき
- アカウント作成: サインアップ
- 初回使用: コンテキスト:Capgo Builder /ネイティブクラウドビルド製品ページ。役割:短いUIラベルまたはナビゲーションアイテム。メッセージキー`native_build_builder_credit_first` (ネイティブビルドビルダークレジットファースト)。
- 初回の主なアクションを完了 重要アクション完了:
- 繰り返し利用: 彼らはまたそれをもう一度行う
ファンナルの見た目だけを美しくすることではない。失敗する手順を特定することだ。多くのユーザーが登録するが、初回利用者が少ない場合、オンボーディングが問題である。初回利用者に到達したが、再び戻らない場合、製品は理解できるが魅力がない可能性がある。
メトリクスを解釈し、基準を設定する
コンテキストは孤立した数字よりも重要
単独のメトリクスは誤解を招く可能性がある。製品の仕事を考慮することで、良い解釈が始まる
日次計画アプリと月次報告ツールは異なる利用パターンを持つ。チームワークを含むコラボレーション製品と、ソロユーティリティアプリは異なる。チームが「数字は良いのか？」と尋ねる場合、有用な答えは「どのような行動のために良いのか？」であることが多い
ただし、1つの基準は特に重要になってきた。Stonlyによるユーザー採用メトリクスの議論によると、 DAU/MAU比率は広く使用される粘着度の測定値であり、 は広く使用される粘着度の測定値であり、 は 50% DAU/MAU ratio は平均ユーザーが製品を開く頻度を表します 1 か月に 30 日のうち 15 日 なので、チームは習慣形成の代わりに一時的な使用を判断するために使用します
注意: スティッキネスを慎重に使用する
スティッキネスは、広範囲にわたる浅い使用と深い関与を区別するため、強力です。製品は多くのユーザーを持つかもしれませんが、ほとんどのユーザーがほとんど戻らない場合、製品は弱いと考えられます。
しかし、スティッキネスは単独の判断ではありません。保持率と行動の質と組み合わせると、より有用になります。DAU/MAUが上昇しながら、有意義なアクションが平らな場合、ユーザーはアプリを開くだけかもしれません。スティッキネスが低いが、製品が自然に時々使用される場合、指標は単に使用ケースを反映している可能性があります。
なぜなら、パフォーマンス解釈には製品のコンテキスト、リリース履歴、ユーザー体験の質が含まれるからです。改善を続けるチームは アプリのパフォーマンス最適化 よく、高速なロードタイムと遅延の少ないアプリは、繰り返し使用をサポートすることがよくありますが、指標はユーザーが達成するものと一緒に読まなければなりません。
内部ベンチマークが最も適切な基準です
外部基準は、方向性を得るために役立ちます。内部基準は、決定を下すために役立ちます。
製品の変更前の後続のコホートを比較してください。オンボーディングを完了したユーザーとオンボーディングをスキップしたユーザーを比較してください。異なるプランのアカウントや異なるセットアップパスのアカウントを比較してください。 その比較は、作業が行動を変えたかどうかを教えてくれます。
実用的基準システムは、以下を含みます:
- 基準点: 変更前の現在の行動
- 予想される動き: 実験が成功した場合に変化するべきメトリック
- 決定ルール: 実験が失敗した場合に取るべき行動
メトリックが動いたときは、ユーザーの行動が変化したかどうかを尋ねてください。動かないときは、製品の変更が価値の実際の源に触れたかどうかを尋ねてください。
ベースラインから脱却する User-Level vs Account-Level Adoption
なぜチーム製品が盲点を作り出すのか
多くのB2Bチームにとって、ここに共通の落とし穴が存在します。健康な採用数値が、弱いアカウントを隠している場合があります。
Gainsightの採用測定の議論は、B2B環境におけるものです。 採用測定の一般的なガイドラインでは、主にアクティベーション、DAU/MAU、価値到達までの時間、機能採用について説明していますが、どの時点でユーザー毎、またはアカウント毎の採用を測定すべきかは明確に述べていません。
この区別は重要です。ユーザー毎の採用は、個人がどれだけ関与しているかを示します。一方、アカウント毎の採用は、顧客組織が製品をワークフローに組み込んでいるかどうかを示します。
幅と深さを一緒に追跡する
大きな企業が購入した販売プラットフォームを考えてみましょう。1人のオペレーションズリードが毎日ログインし、レポートを作成し、製品を愛している場合、 アカウントは活発に見えます。しかし、誰も他の人が使用していない場合、ロールアウトはまだ弱いままです。もしもそのチャンピオンが去った場合、アカウントは突然リスクにさらされます。
より良いモデルは、両方を追跡することです。
- 幅の採用: アカウント内でどれだけの人々がアクティブであるか
- 深さの採用: どれだけ意味を持つにあたって、人々が製品を使用しているか
- セグメンテーション: ロール、プラン、または用途による採用の差異
特に多人数の製品では、特に重要です。アカウントは機能の使用を示すことができますが、チーム全体に広がることはできません。逆もあります。多くのユーザーがログインするかもしれませんが、深くはありません。
実際の方法は、1つの巨大な平均ではなく、アカウントをセグメントでレビューすることです。チームは、 プランとチャンネルをセグメントすることによって、より良好な視野を得ることがよくあります。次に、ロールベースの使用を上に重ねることができます。目的は、1人の熱心なチャンピオンを真の組織的採用と混同しないことです。強力なB2Bロールアウトは、拡散と実質的なものを示すことがよくあります。1つだけでは不安定です。
採用ダッシュボードの作成と行動
有用なダッシュボードは、ユーザーが価値を達成し、繰り返し、そしてアカウント内で使用の拡散を示す短い物語を伝えるものです。
https://__CAPGO_KEEP_0__.app からのスクリーンショット
ほとんどの製品チームにとって、ダッシュボードは、次の小さな行動指標に焦点を当てるべきです。
活性化の傾向:
- Activation trend: 新規ユーザーが最初の意味のあるマイルストーンに到達するか?
- 価値時間の傾向: 最初の成功への道が短くなっているか、混雑しているか?
- 保持ビュー: 最初の勝利後、ユーザーが戻るか?
- 機能採用ビュー: 重要な機能が活発なユーザーによって使用されているか?
- アカウント採用スライス: チームが幅広く採用しているか、使用が集中しているか?
ダッシュボードにはセグメンテーションが必要です。新規ユーザーと既存ユーザー。自社サービスと企業向け。個人ユーザーとアカウント。そうでない場合、平均値は物語を平らにします。
メトリクスを製品の決定に変換する
各メトリクスは特定の反応を引き起こすべきです。アクティベーションが弱い場合、オンボーディングを強化し、セットアップのフリクションを削除してください。価値時間が遅い場合、ユーザーがコアの結果を確認する前に必要なステップを減らしてください。機能採用が低い場合、問題は発見、関連性、ワークフローのフィットかもしれません。
リリースのスピードはここで重要です。製品チームは、迅速なフィードバックループを通じて学習します。AmplitudeやMixpanelなどのツールを使用すると、ユーザーの行動を読むことができます。配信ツールを使用すると、ユーザーの行動に基づいて変更をテストできます。モバイルとクロスプラットフォームのチームでは、 Capgo JavaScript、CSS、設定、コピー、資産の更新をアプリストアのレビューを待たずに配信するオプションは、Capgoにプルリクエストを送信することです。
アプリの採用問題を観察し、修正をテストするサイクルを短縮することができます。
ワークフローの後半では、デモ映像がチームが何が変わり、どのように変わり、という点で一致することができます。
- 実践的な運用リズムは次のようになります。
- ダッシュボードを週に1回確認します。
- 1つの採用のボトルネックを特定します。
- 1つの焦点を置いた変更を配信します。
- 次のコホートと前のコホートを比較します。
行動に基づいて、または意見に基づいて変更を取り消すか維持します。
採用の作業が管理できるようになるのは、測定と製品の行動の間で安定したループを作ることです。採用のメトリクスをすべて一度に追うのではなく、
AIは、採用の意味を複雑にすることを始めている。伝統的なユーザー採用メトリクスでは、人間がログインし、行動をとり、戻ることを前提としている。 しかし、このモデルは、AIエージェントがコンテンツを書き、ワークフローをトリガー、タスクを自動的に完了する場合に不安定になる。
As Userpilotの「採用測定の変更」を書いたものの 注目すべきのは、より新しいガイドラインが「人間vs. AIエージェント」という問題を指摘していることである。実際の問題は簡単で、DAU/MAU、セッションの長さ、最初のキーアクションまでの時間などのメトリクスは、自動化によってではなく、人間が価値を実現するのではなく、自動化によって行われた活動の場合でも、より強力に見えるようになる。
チームは、よりきれいなAttributionが必要になる。誰がタスクを開始したか? AIは何をサポートしたか? どれが完全に自律だったか? これらの区別は、自動化が正常な製品使用の一部になるにつれて、より重要になる。北の星は同じままだ。 人間と組織が実際の、繰り返し価値を得ているかどうかを測定する。ただし、人間がすべてのアクションを実行したと仮定することはもうできない。
If your team ships Capacitor or Electron apps and wants a tighter loop between adoption analysis and product changes, Capgo is worth a look. It lets teams deliver code and content updates quickly, target specific release channels, and monitor rollout behavior so product, engineering, and support can respond faster when adoption stalls.
