測定対象を戦略化して決定する
アプリが組織または Microsoft Teams ストアで配布された後、ユーザーがアプリと対話する方法を追跡することが重要です。 アプリ ユーザーの増加に伴い、アプリのインストール数が関連するメトリックではない可能性があります。
Teams アプリを開発するときに監視するデータ、メトリック、イベントの種類を計画することが重要です。 製品の North Star メトリックは、ビジネスに関連するメトリック、コア ユーザー アクション、および主要なイベントの適切なセットを確立する際にガイドします。
エコシステムで長期的な持続可能性を実現するには、アプリで新しいユーザーの成長が良好である必要があります。 2 つ目の属性は、エンゲージメントとリテンション期間です。 ユーザーはアプリに戻り、その中の価値を見つけて使用し続ける必要があります。 最後に、3 つ目の品質は収益です。 アプリは、支払う意思があるユーザーに十分な価値を提供する必要があります。 アプリは、プラットフォームで長期的に成功するために、これらの 3 つの品質をすべて持っている必要があります。 これらの 3 つの品質のいずれかがアプリに存在しない場合、プラットフォームで成功する確率は低くなります。
インストルメンテーション戦略では、これらの 3 つの品質にわたって製品を測定する必要があります。
アプリのイベントを監視する
この記事では、HEART フレームワークを使用して、ソリューションの監視を検討する必要があるメトリックとイベントの代表的なセットを示しましょう。 次の一覧は網羅的なものではなく、ビジネスと製品に関連する追加のインストルメンテーションを追加することをお勧めします。
導入
目標: アプリの探索を開始し、ファネルの正常なトップを維持できる新しいユーザーを取得します。 新しいアプリの検出と導入は、次のいずれかの方法で行われます。
- ユーザーが独自にアプリを検索してインストールします。
- ユーザーが別のユーザー (タブまたはアダプティブ カード) によってチャット、会議、またはチャネルで共有されている場合、アプリにつまずきます。
- 管理者はユーザー用にアプリをインストールし、アプリからウェルカム メッセージが送信されます。
導入を改善するように設計されたインストルメンテーションは、アプリとその機能の検出可能性の向上を目指す必要があります。 既存のユーザーがコラボレーション スコープでアプリの使用を開始すると、新しいユーザーの間でアプリを検出する可能性が高くなります。 たとえば、チャネルまたは会議タブの追加、チャネルへのボットの追加、グループ チャットでのメッセージング拡張カードの共有などです。
ヒント
- コラボレーション スコープでのアプリの使用状況と、コラボレーションスコープまたは会議スコープでアプリの機能を検出するのにかかった時間を測定します。 使用量が少ない場合や時間がかかった場合は、アプリやマーケティングの取り組みによって、上記の機能をより適切にソーシャル化します。
- 全体的な導入の測定は開始するのが適切ですが、プラットフォームの機能と機能レベルで導入を測定します。
| メジャー | 分析情報 |
|---|---|
| • R1、R7、R14、R28 日でアプリをインストールしているユーザー。 • # サインイン (アプリにサインインがある場合)。 |
• アプリ レベルの導入は、テナント、リージョン、セグメントで分類されます。 • Microsoft Entra プロファイルに基づいてユーザーをセグメント化します。 • テナントと組織名でセグメント化します。 |
| • 最初の使用にかかった平均時間 (タブ、ボット、アダプティブ カード、会議をクリック)。 | • 機能レベルの導入を測定するために、機能またはプラットフォームの機能レベルでレポートします。 |
| • 最初の検出の機能拡張ポイント。 • 最初の検出のスコープ。 |
• データを使用して、エンド ユーザーによってアプリを検出するために最も使用される機能拡張ポイントとスコープを測定します。 |
| • アプリのインストールにつながるリンクの展開の割合。 | • アプリのインストール、検出後に関心のあるユーザー。 |
| •コラボレーションスコープにアプリを追加するのにかかった平均時間 - チャネル、グループチャット、会議。 | • アプリ内での使用状況の侵入。 |
| • コラボレーション スコープでアプリを追加するユーザーの割合。 | • ウイルス性の可能性、つまり、新しいユーザーによる有機的な発見と使用の可能性を判断するのに役立ちます。 |
| • チャネルまたはグループ チャットにアプリを追加した後にアプリを構成するユーザーの割合。 | • アプリがインストール日に構成されていない場合は、次の週にユーザーがアプリを構成する可能性が 5% です。 |
エンゲージメントとタスクの成功
目標: アプリ内でコア アクションを完了する魅力的な品質ユーザーの数を増やします。
コア アクションは、ビジネスの中心であり、North Star に直接貢献する、そのユーザー アクションとして定義されます。 たとえば、IT チケット ソリューション プロバイダーの場合、主要なユーザー アクションは、問題を検索する手順を含む "チケットの作成" であり、エスカレーションはユーザー体験ファネルの重要なビジネス イベントであり、ユーザーをコア アクションに向けて推進します。
エンゲージメントは、ユーザーとアプリの間の相互作用の強度と深さを測定する予定です。 エンゲージメントの強度は、ユーザーがアプリを使用している量 (たとえば、アプリで実行されたコア アクションの数) を測定します。 対話の深さは、ユーザーが操作したさまざまなプラットフォーム機能、スコープ、アプリ機能の数を測定します。
ヒント
- エンゲージメントと使用状況は、アプリ全体レベルだけでなく、個々のアプリの機能と機能レベルでも測定することが重要です。 ビジネスに関与するユーザーを定義する主要なアクションと主要なビジネス イベントを決定します。 アプリにサインインまたは表示するだけでは、質の高いエンゲージメントではない可能性があります。
- コア アクションはビジネスに固有であり、製品の North Star に関連付けられている 1 つのコア アクションが必要です。 2 ~ 3 個を超えるコア アクションはありません。
- 重要なビジネス イベントは、ユーザーがコア アクションの実行に向けて行う可能性のある補助アクションです。 重要なビジネス イベントは、理想的なユーザー体験を行っているユーザーの数に関するファネル ビューを準備し、ドロップオフが多いポイントを決定するのに役立ちます。
| メジャー | 注釈 |
|---|---|
| • # アプリ ユーザー (R7、R14、R28)。 – DAU と MAU。 • # アプリ ユーザーの近似曲線。 |
• アプリと機能レベルのエンゲージメント • Microsoft Entra プロファイルに基づいてユーザーをセグメント化します。 • クライアント別のレポート - デスクトップ、Web、モバイル。 • テナントと組織名でセグメント化します。 • 製品機能別のセグメント化 (機能レベルでのアクティブ ユーザー)。 |
| • Teams アプリで主要な機能を使用するユーザーの割合と、Web アプリまたはネイティブ アプリで同じ機能を使用しているユーザーの割合。 | • Teams アプリ内で機能を使用することの検出可能性、使いやすさ、価値を示します。 •アプリの機能レベルでレポート。 |
| • #, % users using the app across different scopes (R28)。 | • エンゲージメントの浸透。 • スコープ別のレポート。 •機能によってドリルダウンする機能。 |
| • #, % ユーザーが異なるプラットフォーム機能 (R28) でアプリを使用しています。 • #, % [操作中] タブ。 • #, % Interacting with Messaging extension. • #,% ボットとの対話。 • #, % 会議のサイド パネルとの対話. • #, % Interacting with Stageview. |
•アプリ機能のエンゲージメントと価値のプロップ。 • プラットフォーム機能の使用率が低い場合は、使いやすさと付加価値の詳細にドリルダウンすることを検討してください。 |
| タスクの成功 | |
| • コア アクションを完了しているユーザーの割合。 | •コアタスクを実行する簡単さ。 •週レベルでレポート。 |
| • Teams アプリでのユーザー体験 - ユーザーのドロップオフを含むファネル ビュー。 | •ユーザー体験の摩擦ポイント。 • テナント レベルでドリルダウンします。 |
• コア アクションの失われたスコア:
ここで、 L = Lostness N = コア アクションの実行中に実行される異なる一意のステップの数。 S = 繰り返しステップを含むコア アクションの実行中に実行されたステップの合計数。 R = コア アクションを完了するために必要な最小ステップ数。 |
• 地域訓練での使いやすさは、ロケールの必要性に関する分析情報を提供します。 • リージョンとテナント レベルでドリルダウンします。 • 紛失が 0.4 を超える場合、アプリはユーザーエクスペリエンスを向上させ、ユーザーのコア アクションの完了を容易にする必要があります。 |
| • コア アクションを実行するために要した平均時間。 | •使いやすさ。 • Teams アプリの外部でコア アクションを実行するその間に実行された時間と共にレポートします。 |
| • コア アクションが 1 か月に実行された平均回数。 • 主要なビジネス イベントが 1 か月に実行された平均回数。 |
•エンゲージメントのレベルと強度。 • 月ごとの傾向を表示します。 • テナント別にドリルダウンします。 |
保持
目標: ユーザーがアプリに関心を持つほどメリットを得ることで、製品の粘着性を向上させます。
ユーザーリテンション期間は、ユーザーが製品を使用するために戻ってくる頻度を測定します。 基本的にエンゲージメントの頻度を測定します。 ユーザーがより多くの利点を得る場合、ユーザーは製品を繰り返し使用します。 製品を使うほど、アプリの切り替えコストが高くなります。 たとえば、ユーザーがアプリの一部として追跡するタスクまたはアクション 項目の追加を開始すると、プロジェクト間の調整が向上し、タスク管理システムを破棄するコストが徐々に高くなる可能性があります。
ヒント
- 複数の Teams プラットフォーム機能を使用しているユーザーは、1 人の機能ユーザーよりも 20 ~ 35pp の方が保持されます。
- 最初の 1 週間に新しいユーザーを魅力的なプラットフォーム ユーザーに変換すると、リテンション期間が向上します。
- アプリで作成イベントを実行するユーザーのリテンション期間は、通知によって受動的に情報を使用するユーザーに比べて高くなります。 作成イベントは、ビジネスによって異なります。 たとえば、チケットの作成、新しい投稿の作成、プロジェクト ボードなどです。
- 1 か月に複数回 (>5 回) 使用されたアプリのリテンション期間は、1 か月にわたってより優れています。 使用頻度の高い定期的なユース ケースにより、リテンション期間が向上します。
| メジャー | インサイト |
|---|---|
| • 新しいユーザーリテンション期間のコホート分析 (週単位、月単位)。 | • クライアント別のリテンション期間の内訳 - Teams デスクトップ、Web、モバイル アプリ、Teams 以外の Web アプリ。 • テナント レベルにドリルダウンします。 |
| •14日、28日、56日、72日でユーザーチャーン。 | • ユーザーチャーン。 • テナント レベルにドリルダウンします。 • プラットフォーム機能と機能のドリルダウン。 • クライアント別のチャーンの内訳: Teams デスクトップ、Web、モバイル アプリ、Teams 以外の Web アプリ。 |
| • #, % ユーザーが複数のスコープでアプリを使用しています。 | • エンゲージメントの深さ。 目標は、さまざまなスコープにわたるアプリの使用を奨励することです。 |
| • #, % アプリの 1 つ以上の機能を使用しているユーザー。 | • エンゲージメントの深さ。 •目標は、ユーザーがアプリでサポートされているさまざまなプラットフォーム機能を使用することを奨励することです。 |
| • [コア アクション 1,2.] 間の平均時間 ユーザーごとに。 | • エンゲージメントの強度。 • テナント レベルでレポートします。 • 目標は、定期的な使用を促進するために、この時間を短縮することです。 |
| • 作成イベントを実行しているユーザーの割合。 • 消費イベントを実行しているユーザーの割合。 トラック： - ボット メッセージのレシートを読み取ります。 - 通知のクリック。 |
• エンゲージメントの強度。 純粋な消費と比較して作成イベントを実行するユーザーが多い場合、アプリのリテンション期間が高くなります。 |
| • 定期的な使用量が多いアプリの機能またはスコープ。 | •アプリの非常にリテクティブな機能や機能。 |
幸福
目標: エンド ユーザーに十分で差別化された価値を提供し、支払う意欲を高めます。
幸福は、製品に対するユーザーの態度を測定することを意図しており、支払いを行う意欲に変換し、他のユーザーを製品に参照することができます。 幸せは主に自己報告です。 フィードバックの収集、満足度評価など、主要な指標があります。 遅延インジケーターには、新しいサブスクリプションや、他のモダリティよりも Teams アプリを使用することを好むユーザーが含まれます。
ヒント
- 幸せは、適切なタイミングでコンテキストで測定し、ユーザーにコンテキスト化する必要があります。 固定日に一般的なアンケートを送信すると、ユーザーが自分の経験を覚えていない可能性があるため、正確な幸福度測定が得られない可能性があります。
- コア アクションを完了した後、ユーザーがフローでフィードバックと評価を簡単に送信できるように、製品主導のフィードバック キャプチャと評価メカニズムを統合します。
- 適切な製品サポートを提供し、ユーザーがクエリを明確にし、バグを報告し、フィードバックを提供するためのヘルプデスクを提供します。
| メジャー | インサイト |
|---|---|
| • アプリ ソースからのアプリ ネット プロモーター スコア (NPS)。 | •ネットプロモータースコア。 • Microsoft Entra ID とテナント情報。 |
| • 幸せまたは満足しているユーザーの割合。 | • テナント レベルでドリルダウンします。 • 時間の経過に伴う傾向を報告します。 |
| • Teams アプリと Web、またはモバイル アプリを使用するユーザーの割合。 | • 月を超えて報告します。 |
| •コアアクションを完了した後の経験に関するユーザーフィードバック。 | •コアアクションを完了した後にフィードバックを収集するための製品主導の方法を導入します (たとえば、フィードバックを送信するアプリ内メッセージ)。 |
次の手順
Platform Docs