次の方法で共有


Application Insights による利用状況分析

最も人気のある Web アプリまたはモバイル アプリの機能は何か。 そのアプリによりユーザーは目標を達成したか。 特定の時点でアプリを離れたか。その後、利用を再開したか。

Application Insights は、アプリケーションのパフォーマンスと使用状況を監視するための強力なツールです。 ユーザーによるアプリの操作方法に関する分析情報を提供し、改善を要する領域を特定します。変更による影響を理解するのにも役立つツールです。 この情報により、次の開発サイクルに関してデータに基づく意思決定を行うことができます。

この記事では、次の領域について説明します。

  • ユーザー、セッション、イベント - アプリケーション、セッションの傾向、および特定のイベントに対するユーザーの操作を追跡および分析して、ユーザーの動作とアプリのパフォーマンスに関する分析情報を取得します。
  • ファネル - ユーザーがアプリケーションの一連の手順をどのように進め、どこに着地するかを把握します。
  • ユーザー フロー - ユーザー パスを視覚化して最も多く見られるルートを識別し、ユーザーが最も関心を寄せているユーザーや、問題が発生する可能性がある領域を特定します。
  • コーホート - 一般的な特性でユーザーまたはイベントをグループ化し、動作パターン、機能の使用状況、および時間の経過に伴う変化の影響を分析します。
  • 影響分析 - アプリケーションのパフォーマンス メトリック (読み込み時間など) がユーザー エクスペリエンスと動作に与える影響を分析して、改善項目に優先順位を付けることができます。
  • HEART - HEART フレームワークを利用することで、ユーザーの幸福度、エンゲージメント、導入、保持、タスクの成功を測定して理解します。

アプリケーションからテレメトリを送信する

エクスペリエンスを最適化するには、Application Insights をアプリ サーバー コードと Web ページの両方に統合することを検討してください。 このデュアル実装により、アプリケーションのクライアント コンポーネントとサーバー コンポーネントの両方からテレメトリを収集できます。

  1. サーバー コード:ASP.NETAzureJavaNode.js、またはその他のアプリ向けの適切なモジュールをインストールします。

    サーバー コードをインストールしない場合は、Application Insights リソースを作成します。

  2. Web ページ コード: JavaScript SDK を使用して、Web ページからデータを収集します。「JavaScript SDK の開始」を参照してください。

    Note

    インストルメンテーション キーのインジェストのサポートは、2025 年 3 月 31 日に終了します。 インストルメンテーション キーのインジェストは引き続き機能しますが、この機能の更新プログラムやサポートは提供されなくなります。 接続文字列に移行することで、新機能をご利用いただけます。

    Web サイトを監視するためのより高度な構成については、JavaScript SDK の参照記事を参照してください。

  3. モバイル アプリ コード: App Center SDK を使用して、アプリからイベントを収集します。 次に、このガイドに従い、これらのイベントのコピーを分析のために Application Insights に送信します。

  4. テレメトリの取得: プロジェクトをデバッグ モードで数分間実行します。 次に、Application Insights の [概要] ウィンドウで結果を確認します。

    アプリを発行し、アプリのパフォーマンスを監視してユーザーがアプリを使って何をしているか確認します。

ユーザー、セッション、イベント - 3 つの観点からテレメトリを分析する

3 つの [使用状況] ペインは同じツールを使用して、これら 3 つの視点から、Web アプリのテレメトリを詳細に分析します。 データをフィルター処理および分割することによって、さまざまなページや機能に関連する使用について分析情報を得ることができます。

  • ユーザー ツール: アプリとその機能を使用したユーザーの数。 ブラウザーの Cookie に格納されている匿名 ID を使用してユーザーがカウントされます。 複数のブラウザーまたはコンピューターを使用する 1 人のユーザーは、複数のユーザーとしてカウントされます。

  • セッション ツール: アプリの特定のページおよび機能を含むユーザー アクティビティのセッション数。 セッションは、ユーザーの非アクティブ状態が 30 分続いた後、または継続した 24 時間の使用の後、リセットされます。

  • イベント ツール: アプリの特定のページと機能が使用された回数。 ページ ビューは、(インストルメント化した場合) ブラウザーがアプリからページを読み込むときにカウントされます。

    カスタム イベントは、アプリでの何らかのイベントの 1 回の発生を表します。 多くの場合、ボタンの選択やタスクの完了などのユーザー操作です。 アプリにコードを挿入してカスタム イベントを生成するか、クリック分析拡張機能を使用します。

Note

匿名 ID を使用して正確なカウントを得る方法に代わる手段については、認証済みの ID に関するドキュメントを参照してください。

[他の分析情報を表示] をクリックすると、次の情報が表示されます。

  • アプリケーションのパフォーマンス: ユーザーの応答性の認識に関連するセッション、イベント、パフォーマンス評価。
  • プロパティ: ブラウザーのバージョン、国または地域、オペレーティング システムなど、最大 6 つのユーザー プロパティを含むグラフ。
  • ユーザーを確認する: ユーザー アクティビティのタイムラインを表示します。

使用状況の人口統計データや統計を調査する

ユーザーが Web アプリをいつ使い、どのページに最も興味があり、ユーザーがどこにいて、どのようなブラウザーやオペレーティング システムを使っているかを確認しましょう。 Application Insights サービスを使用してビジネスおよび使用状況テレメトリを分析します。

棒グラフが表示されている [ユーザー] タブのスクリーンショット。

  • [ユーザー] レポートは、選択した期間内にページにアクセスした一意のユーザー数をカウントします。 Web アプリの場合、ユーザーは Cookie を使用してカウントされます。 ユーザーが異なるブラウザーまたはクライアント マシンを使用してサイトにアクセスした場合、または Cookie を消去した場合は、複数回カウントされます。

  • [セッション] レポートには、サイトにアクセスしたユーザー セッションの数が一覧表示されます。 セッションは、ユーザーによって開始されたアクティビティの期間を表し、非アクティブな期間が 30 分を超えると終了します。

特定のユーザーのクエリ実行

[ユーザー] ペインの上部にあるクエリ オプションを調整して、さまざまなユーザー グループを調査します。

オプション 説明
期間 時間範囲を選択します。
表示 分析するユーザーのコーホートを選択します。
次を使用した カスタム イベント、要求、ページ ビューを選択します。
Events 複数のイベント、要求、ページ ビューを選択します。これにより、必ずしも選択したものすべてではなく、少なくとも 1 つを実行したユーザーが表示されます。
値による x 軸 時間の範囲によって、または、ブラウザーや都市など別のプロパティによってデータをカテゴリ化する方法を選択します。
分割基準 データの分割またはセグメント化に使用するプロパティを選択します。
フィルターの追加 ブラウザー、市などのプロパティに基づいて特定のユーザー、セッション、またはイベントに対するクエリ実行を制限します。

ユーザーを確認する

[Meet your users](ユーザーを確認する) セクションには、現在のクエリに一致する 5 人のサンプル ユーザーについての情報が表示されます。 個人の行動と全体の行動を調査することで、ユーザーがアプリをどのように使用しているかについての分析情報が得られます。

ユーザーの保有期間の分析

Application Insights の保有期間機能は、アプリに戻るユーザーの頻度とパターン、および特定の機能の使用状況を追跡することで、ユーザー エンゲージメントに関する貴重な分析情報を提供します。 これにより、ゲームに勝ったユーザーと負けたユーザーとの間のリターン率の差といったユーザーの行動を比較し、操作可能なデータを提供することで、ユーザー エクスペリエンスを強化したりビジネス戦略を通知したりできます。

特定の期間内のアクションに基づいてユーザーのコーホートを分析することで、繰り返し使用を促進する機能を特定できます。 この知識は、次の場合に役立ちます。

  • どのような特定の機能により、どのような特定のユーザーが使用を再開したかを把握します。
  • 製品でリテンション期間が問題になるかどうかを確認します。
  • 実際のユーザー データに基づいて仮説を立てる。この仮説は、ユーザー エクスペリエンスとビジネス戦略の改善に役立てることができます。

ユーザーがアプリの使用を再開する頻度に関する情報が表示されているリテンション期間ブックのスクリーンショット。

上部のリテンション期間コントロールでは、特定のイベントと時間範囲を定義して、リテンション期間を計算できます。 中央のグラフは、指定した時間範囲別のリテンション期間全体のパーセンテージを視覚的に表しています。 下部のグラフは、特定の期間における個々のリテンション期間を表しています。 この詳細レベルでは、ユーザーが何を実行し、どのような理由でユーザーが使用を再開するかをさらに詳しく把握できます。

リテンション期間ブックの詳細については、以下のセクションを参照してください。

リテンション期間ブック

Application Insights でリテンション期間ブックを使用するには、[ブック] ペインに移動し、上部にある [パブリック テンプレート] を選択して、[使用法] カテゴリの下に一覧表示されている [ユーザー保有期間の分析] ブックを特定します。

[Public Templates] (パブリック テンプレート) タブの [ブック ギャラリー] を示すスクリーンショット。

ブックの機能:

  • 既定では、定義した期間に何かを実行して再び戻ってきた後、さらに何か他のことを実行したすべてのユーザーが表示されます。 各種のイベントを組み合わせることで、特定のユーザーのアクティビティを絞り込むことができます。

  • 1 つ以上のフィルターをプロパティに追加するには、[フィルターの追加] を選びます。 たとえば、特定の国またはリージョンのユーザーに注目することができます。

  • [Overall Retention] (リテンション期間全体) グラフには、選んだ期間のユーザー リテンション期間の概要が表示されます。

  • グリッドには、保有されたユーザー数が表示されます。 各行は、表示された期間に選択したいずれかのイベントを実行したユーザーのコーホートを表します。 行の各セルは、そのコーホートの中で、その後の期間に 1 回以上戻ったユーザーの数を示しています。 ユーザーは複数の期間に戻ってくることがあります。

  • 分析情報カードには、開始イベントの上位 5 つと、復帰イベントの上位 5 つが表示されます。 この情報から、リテンション期間レポートの理解を深めることができます。

    ユーザーが何週間後に戻ってきたかをグラフで示すリテンション期間ブックのスクリーンショット。

ビジネス イベントを使用してリテンション期間を追跡する

最も役立つリテンション期間分析を行うには、重要なビジネス アクティビティを表すイベントを測定する必要があります。

詳細とコード例については、以下のセクションを参照してください。

カスタム イベントを使用してユーザー操作を追跡する

アプリでのユーザー操作を理解するには、カスタム イベントをログに記録するコード行を挿入します。 これらのイベントは、ボタンの選択などのさまざまなユーザー アクションや、購入やゲームの勝利などの重要なビジネス イベントを追跡します。

Click Analytics Autocollection プラグインを使用してカスタム イベントを収集することもできます。

ヒント

アプリの各機能を設計するときに、ユーザーの満足度をどのように測定するかを検討します。 記録する必要のあるビジネス イベントを決定し、これらのイベントの追跡呼び出しを一からアプリにコーディングします。

ページ ビューでは、役立つイベントを表すことができる場合もありますが、通常そうではないことがほとんどです。 ユーザーは、製品を購入しなくても製品ページを開くことができます。

特定のビジネス イベントを使用して、サイトからユーザーの進行状況をグラフ化できます。 さまざまなオプションについて、ユーザーの嗜好や、どの段階で使用を止め、どのような問題が発生しているかを確認できます。 この知識があれば、開発バックログでの優先順位について情報に基づいた意思決定を行うことができます。

イベントは、アプリのクライアント側からログに記録することができます。

appInsights.trackEvent({name: "incrementCount"});

または、イベントはサーバー側から記録できます:

var tc = new Microsoft.ApplicationInsights.TelemetryClient();
tc.TrackEvent("CreatedAccount", new Dictionary<string,string> {"AccountType":account.Type}, null);
...
tc.TrackEvent("AddedItemToCart", new Dictionary<string,string> {"Item":item.Name}, null);
...
tc.TrackEvent("CompletedPurchase");

これらのイベントにプロパティ値をアタッチできます。これにより、ポータルでイベントを確認するときに、イベントをフィルター処理または分割できます。 匿名ユーザー ID などのプロパティの標準セットも各イベントにアタッチされます。これにより、個人ユーザーのアクティビティのシーケンスを追跡できます。

カスタム イベントプロパティの詳細については、こちらを参照してください。

イベントの詳細な分析

[ユーザー]、[セッション]、および [イベント] ツールでは、ユーザー、イベント名、プロパティごとにカスタム イベントを詳細に分析することができます。

AnalyticsItemsOperation によってフィルター処理され、AppID で分割された [イベント] タブのスクリーンショット。

状況に応じて、[Open the last run query](最後の実行クエリを開く) アイコンを選択すると、基になったクエリに戻ります。

Azure portal の [Application Insights セッション] 画面のスクリーンショット。[最後の実行クエリを開く] アイコンの強調表示。

その後、基になるクエリを変更して、求めている情報を取得できます。

ページ ビューの基になるクエリの例を次に示します。 そのままクエリ エディターに直接貼り付けてテストします。

// average pageView duration by name
let timeGrain=5m;
let dataset=pageViews
// additional filters can be applied here
| where timestamp > ago(1d)
| where client_Type == "Browser" ;
// calculate average pageView duration for all pageViews
dataset
| summarize avg(duration) by bin(timestamp, timeGrain)
| extend pageView='Overall'
// render result in a chart
| render timechart

A/B テストを使用して機能の成功を判断する

どちらの機能バリエーションが成功するかわからない場合は、その両方をリリースして、異なるユーザーが各バリエーションにアクセスできるようにします。 各バージョンの成功の度合いを測定してから、統合したバージョンに切り替えます。

この手法では、アプリの各バージョンから送信されるすべてのテレメトリに一意のプロパティ値をアタッチします。 これは、アクティブな TelemetryContext のプロパティを定義することで実行できます。 これらの既定のプロパティは、アプリケーションによって送信されるすべてのテレメトリ メッセージに含まれます。 これには、カスタム メッセージと標準テレメトリの両方が含まれます。

Application Insights ポータルでは、プロパティ値に基づいてデータをフィルター選択および分割して、異なるバージョンを比較します。

このステップを行うには、テレメトリ初期化子を設定します:

// Telemetry initializer class
public class MyTelemetryInitializer : ITelemetryInitializer
{
    // In this example, to differentiate versions, we use the value specified in the AssemblyInfo.cs
    // for ASP.NET apps, or in your project file (.csproj) for the ASP.NET Core apps. Make sure that
    // you set a different assembly version when you deploy your application for A/B testing.
    static readonly string _version = 
        System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.ToString();
        
    public void Initialize(ITelemetry item)
    {
        item.Context.Component.Version = _version;
    }
}

ASP.NET Core アプリケーションの場合は、Program.cs クラスの依存関係の挿入サービス コレクションに新しいテレメトリ初期化子を追加します。

using Microsoft.ApplicationInsights.Extensibility;

builder.Services.AddSingleton<ITelemetryInitializer, MyTelemetryInitializer>();

ファネル - 顧客によるアプリケーションの使用方法を確認する

カスタマー エクスペリエンスの理解は、ビジネスにとって非常に重要です。 アプリケーションが複数のステージに渡る場合は、顧客がプロセス全体を進めているか、またはどこかの時点でプロセスを終了しているかを把握する必要があります。 Web アプリケーション内の一連の手順の進行は、ファネルと呼ばれています。 Application Insights のファネルを使用すると、ユーザーの分析情報を取得し、ステップ バイ ステップでコンバージョン率を監視することができます。

ファネルの機能:

  • アプリがサンプリングされる場合は、 バナーが表示されます。 バナーを選択すると、サンプリングをオフにする方法を説明するコンテキスト ペインが開きます。
  • 手順を選択すると、右側に詳細が表示されます。
  • コンバージョン履歴のグラフによって、過去 90 日間のコンバージョン レートが表示されます。
  • ユーザー ツールにアクセスすることで、ユーザーの理解を深めます。 各ステップでフィルターを使用できます。

ファネルを作成する

前提条件

ファネルを作成する前に、答えを知りたいテーマを決めておきます。 たとえば、何人のユーザーがホーム ページを閲覧するか、顧客プロファイルを閲覧するか、チケットを作成するか知りたい場合があります。

作業の開始

ファネルを作成するには、以下を実行します。

  1. [ファネル] タブで [編集] を選択します。

  2. [最上位のステップ] を選択します。

    [ファネル] タブのスクリーンショット。[編集] タブでステップを選択しています。

  3. ステップにフィルターを適用するには、[フィルターの追加] を選択します。 このオプションは、最上位のステップの項目を選択した後に表示されます。

  4. 次に、[2 番目のステップ] を選択します。以降、同様に続けます。

    注意

    ファネルは最大 6 ステップに制限されます。

  5. [表示] タブを選択して、ファネルの結果を表示します。

    最上位と 2 番目のステップの結果を示す [ファネル ビュー] タブのスクリーンショット。

  6. ファネルを保存して後で表示するには、上部の [保存] を選択します。 保存したファネルを開くには、[開く] を使用します。

ユーザー フロー - ユーザー ナビゲーションのパターンの分析

Application Insights の User Flows ツールを示すスクリーンショット。

User Flows ツールを使用すると、ユーザーがサイトのページや機能の間をどのように移動するかを視覚化することができます。 次のような疑問の答えを得るのに役立ちます。

  • ユーザーが対象サイトのページから他のサイトにどのように移動しているのか
  • ユーザーは対象サイトのページで何を選択したのか
  • 対象サイト内でユーザーが他のサイトに移動するのが最も多い場所はどこか
  • ユーザーが同じ操作を何回も繰り返している場所があるか

ユーザー フロー ツールは、指定した最初のカスタム イベント、例外、依存関係、ページ ビュー、または要求から開始します。 この最初のイベントを前提に、User Flows には、ユーザー セッションの前後に発生したイベントが表示されます。 太さが異なる線は、ユーザーが各パスを通過した回数を示します。 特別な [セッションを開始しました] ノードには、後続のノードがセッションを開始した場所が表示されます。 [セッションが終了しました] ノードには、前のノードの後でページ ビューまたはカスタム イベントを送信しなかったユーザーの数を示し、ユーザーが対象サイトを離れたと思われる場所が表示されます。

Note

ユーザー フロー ツールを使うには、Application Insights のリソースにページ ビューやカスタム イベントが含まれる必要があります。 アプリをセットアップし、Application Insights JavaScript SDK を使用してページ ビューを自動的に収集する方法について説明します

最初のイベントを選ぶ

User Flows の最初のイベントを選択していることを示すスクリーンショット。

ユーザー フロー ツールを使用して前に示したような疑問への回答を始めるには、まず、表示の起点となる最初のカスタム イベント、例外、依存関係、ページ ビュー、要求を選択します。

  1. What do users do after?」(その後のユーザーの行動) タイトルのリンクを選択するか、[編集] を選択します。
  2. [最初のイベント] ボックスの一覧から、カスタム イベント、例外、依存関係、ページ ビュー、要求を選択します。
  3. [グラフの作成] を選びます。

視覚化の "Step 1" 列には、ユーザーが最初のイベントの直後に最も頻繁に行ったことが表示されます。 項目は、上から頻度の高い順に表示されます。 "手順 2" 以降の列には、ユーザーが次に行ったことが表示されます。 この情報により、ユーザーがサイト内を移動したすべての方法が示されます。

既定では、User Flows ツールはサイトのページ ビューとカスタム イベントの過去 24 時間分のみをランダムにサンプリングします。 [編集] メニューから、時間範囲の拡大や、ランダム サンプリングのパフォーマンスと精度のバランス変更を行うことができます。

ページ ビュー、カスタム イベント、または例外に関係のないものが含まれる場合は、ノードの [X] を選択して非表示にできます。 非表示にするノードを選択したら、[グラフの作成] を選択します。 非表示にしたすべのノードを確認するには、[編集] を選択し、[除外されたイベント] セクションを見ます。

表示されているはずのページ ビューやカスタム イベントが表示されていない場合は、以下を確認します。

  • [編集] メニューの [除外されたイベント] セクションを確認します。
  • 頻繁の低いイベントを視覚化に含めるには、 [その他] ノードのプラス ボタンを使用します。
  • 表示されているはずのページ ビューまたはカスタム イベントが、ユーザーによって頻繁には送信されていないものである場合は、[編集] メニューで視覚化の時間範囲を広げてみます。
  • 予想されるカスタム イベント、例外、依存関係、ページ ビュー、要求が、サイトのソース コードで Application Insights SDK によって収集されるように設定されていることを確認します。

より多くのステップを視覚化したい場合は、視覚化の上の [前のステップ][次のステップ] の各ドロップダウン リストを使用します。

ユーザーがページまたは機能にアクセスした後の移動先と選択内容

User FLows を使用してユーザーが選択した場所を理解する方法を示すスクリーンショット。

最初のイベントがページ ビューである場合、視覚化の最初の列 ("Step 1") を見ると、ユーザーがページにアクセスした直後に行ったことが簡単にわかります。

User Flows の視覚化の横にあるウィンドウでサイトを開きます。 ユーザーによるページの操作方法の予想と、"Step 1" 列のイベントの一覧を比較してみてください。 多くの場合、あなたのチームにとって重要でないと思われるページ上の UI 要素が、そのページで最も使用されている要素の 1 つである可能性があります。 これは、サイトのデザイン改善のよい出発点になる場合があります。

最初のイベントがカスタム イベントの場合、最初の列にはユーザーがそのアクションを実行した直後に行ったことが示されます。 ページ ビューと同様に、観察されたユーザーの行動が、チームの目標や予想と一致するかどうかを検討します。

選んだ最初のイベントが [Added Item to Shopping Cart](買い物かごに商品を追加した) である場合、そのすぐ後に [Go to Checkout](会計に進む) および [Completed Purchase](購入を完了した) が表示されているかどうかを確認します。 ユーザーの行動が予想と異なる場合は、視覚化を使って、サイトの現在のデザインのどこにユーザーの行動が "阻害される" 原因があるかを理解します。

対象サイト内でユーザーが他のサイトに移動するのが最も多い場所はどこか

視覚化の上位に表示される [セッションが終了しました] ノード (特にフローの早い段階) を調べます。 この位置は、多くのユーザーがそこに至るまでのページ移動と UI 操作を行った後、サイトから離脱した可能性があることを意味します。

予期される離脱もあります。 たとえば、ユーザーが電子商取引サイトで購入を完了した後などに想定されます。 通常、サイトからの離脱は、設計上の問題、パフォーマンスの悪さ、またはサイトに関するその他の改善可能な問題を示しています。

[セッションが終了しました] ノードはその Application Insights リソースによって収集されたテレメトリのみに基づくことに注意してください。 Application Insights が特定のユーザー操作に対するテレメトリを受け取らない場合、ユーザーはユーザー フロー ツールがセッション終了を示した後もまだサイトを操作している可能性があります。

ユーザーが同じ操作を何回も繰り返している場所があるか

視覚化の後続ステップで多くのユーザーによって繰り返されているページ ビューやカスタム イベントを探します。 このアクティビティは通常、ユーザーがサイトで反復的なアクションを実行していることを意味します。 繰り返しが見つかった場合は、サイトのデザインの変更または繰り返しを減らす新しい機能の追加を検討します。 たとえば、ユーザーがテーブル要素の行ごとに反復的アクションを実行していることがわかった場合は、一括編集機能を追加します。

コーホート - 特定のユーザー、セッション、イベント、または操作のセットを分析する

コーホートとは、共通点を持つユーザー セット、セッション セット、イベント セット、または操作セットのことです。 Application Insights では、コーホートは分析クエリによって定義されます。 特定のユーザー セットまたはイベント セットを繰り返し分析する必要がある場合、コーホートを使用することで、より柔軟性の高い方法で目的のセットを正確に表現することができます。

コーホート対基本的なフィルター

コーホートは、フィルターと同様の方法で使用できます。 ただし、コーホートの定義はカスタム分析クエリから作成されるため、それらははるかに適応性があり、複雑です。 フィルターとは異なり、コーホートの場合はチームの他のメンバーも再利用できるように保存することができます。

アプリの新機能を試してみたすべてのユーザーのコーホートを定義するとします。 Application Insights リソースにこのコホートを保存できます。 後で、この保存された特定のユーザーのグループを簡単に分析できます。

Note

コーホートが作成されたら、ユーザー、セッション、イベント、ユーザー フローの各ツールからコーホートを利用できます。

例: 関心度の高いユーザー

チームでは、特定の月間に対象のアプリを 5 回以上使用したユーザーを関心度の高いユーザーとして定義しています。 このセクションでは、このような関心度の高いユーザーのコーホートを定義します。

  1. [コーホートの作成] を選択します。

  2. [Template Gallery](テンプレート ギャラリー) タブを選択して、さまざまなコーホート用テンプレートのコレクションを確認します。

  3. [関心度の高いユーザー] (利用日数による) を選択します。

    このコーホートに対しては 3 つのパラメーターがあります。

    • [Activities](アクティビティ): 使用としてカウントするイベントおよびページ ビューを選択します。
    • [Period](期間): 月の定義。
    • [UsedAtLeastCustom]: 関心度が高いとしてカウントするために、ユーザーが期間内に何かを使用する必要がある回数。
  4. [UsedAtLeastCustom][5+ days](5 日以上) に変更します。 [Period](期間) は既定値の 28 日のままにします。

    これで、このコーホートは過去 28 日間の個別の 5 日間において、任意のカスタム イベントまたはページ ビューと共に送信されたすべてのユーザー ID を表すようになりました。

  5. [保存] を選択します。

    ヒント

    "関心度の高いユーザー (5 日以上)" のような名前をコーホートに付けます。 "個人用レポート" または "共有レポート" に保存します。どちらにするかは、この Application Insights リソースへのアクセス権を有する他のユーザーにもこのコーホートを表示させるかどうかによって決まります。

  6. [ギャラリーに戻る] を選択します。

このコーホートを使用して行えること

ユーザー ツールを開きます。 [表示] ドロップダウン ボックスから、[次のものに属しているユーザー] で作成したコーホートを選択します。

コーホートを示している [表示] ドロップダウンを示すスクリーンショット。

注意すべき重要な点は、次のとおりです。

  • このセットは、通常のフィルターによって作成できません。 日付のロジックがより具体的になっています。
  • ユーザー ツールでは通常のフィルターを使用してこのコーホートをさらにフィルター処理することができます。 コーホートは 28 日の期間に定義されていますが、ユーザー ツール内で時間の範囲を 30 日、60 日、または 90 日に調整することができます。

これらのフィルターは、クエリ ビルダーによって表現できないより高度な質問をサポートします。 たとえば、過去 28 日間で関心が高かったユーザーがいるとします。それらの同じユーザーが過去 60 日間でどのような行動をしていたでしょうか。

例: イベントのコーホート

イベントのコーホートを作成することもできます。 このセクションでは、イベントとページ ビューのコホートを定義します。 次に、他のツールからそれらを使用する方法を確認します。 このコホートは、チームによって アクティブな使用 と見なされるイベント セットや特定の新機能に関連するイベント セットを定義できます。

  1. [コーホートの作成] を選択します。
  2. [Template Gallery](テンプレート ギャラリー) タブを選択して、さまざまなコーホート用テンプレートのコレクションを確認します。
  3. [Events Picker]\(イベントの選択) を選択します。
  4. [Activities](アクティビティ) ドロップダウン ボックスで、コーホート内に含めるイベントを選択します。
  5. コーホートを保存し、名前を付けます。

例: クエリを修正するアクティブ ユーザー

前の 2 つのコーホートは、ドロップダウン ボックスを使用して定義されました。 全体的な柔軟性を高めるために分析クエリを使用してコーホートを定義することもできます。 方法を確認するために、英国のユーザーのコーホートを作成します。

  1. コーホート ツールを開き、[テンプレート ギャラリー] タブを選択して、[Blank Users cohort]\(空のユーザーのコーホート) を選択します。

    コーホートのテンプレート ギャラリーを示すスクリーンショット。

    次の 3 つのセクションがあります。

    • Markdown テキスト: チームの他のメンバーのためにコーホートの詳細を記述します。
    • パラメーター: 前述の 2 つの例の [Activities](アクティビティ) やその他のドロップダウン ボックスのような独自のパラメーターを作成します。
    • クエリ: 分析クエリを使用してコーホートを定義します。

    クエリ セクションには、分析クエリを記述します。 クエリは、定義するコーホートが記述された特定の行セットを選択します。 コーホート ツールによって、| summarize by user_Id 句が暗黙的にクエリに追加されます。 このデータはテーブル内のクエリの下にプレビューとして表示されるので、クエリが結果を返していることを確認できます

    Note

    クエリが表示されない場合は、セクションの高さを高くしてクエリが表示されるようにサイズ調整を行います。

  2. 以下のテキストをコピーして、クエリ エディターに貼り付けます。

    union customEvents, pageViews
    | where client_CountryOrRegion == "United Kingdom"
    
  3. [クエリの実行] を選択します。 ユーザー ID がテーブルに表示されない場合は、アプリケーションのユーザーがいる国や地域に変更します。

  4. コーホートを保存して名前を付けます。

影響分析 - さまざまなプロパティがコンバージョン率に与える影響について理解する

ページ ビュー、カスタム イベント、または要求のディメンションが、異なるページ ビューまたはカスタム イベントの使用にどの程度影響するのかについて、明らかにします。

影響については、サイトの一部における遅さがユーザーの定着にどの程度影響しているのかについて、チームのメンバーとの議論を収める究極のツールとして考えるのが、1 つの方法です。 ユーザーがいくらかの遅さを許容する場合がありますが、影響によって、最適化とパフォーマンスのバランスを最善にしてユーザーのコンバージョン率を最大化する方法についての洞察が得られます。

パフォーマンスの分析は、影響の機能の一部にすぎません。 影響ではカスタム イベントとディメンションがサポートされているため、ユーザーのブラウザーの選択と異なるコンバージョン率がどのように相関しているかなどの質問に簡単に答えることができます。

Note

影響分析ブックを使うには、Application Insights のリソースにページ ビューまたはカスタム イベントが含まれる必要があります。 アプリをセットアップし、Application Insights JavaScript SDK を使用してページ ビューを自動的に収集する方法について説明します。 また、相関関係を分析しているため、サンプル サイズが重要です。

影響分析ブック

影響分析ブックを使用するには、Application Insights リソースで [使用量]>[詳細] に移動し、[User Impact Analysis Workbook] (ユーザーへの影響分析ブック) を選びます。 または [ブック] タブで、[Public Templates] (パブリック テンプレート) を選びます。 次に、[使用状況][ユーザーへの影響分析] を選択します。

[パブリック テンプレート] タブの [ブック ギャラリー] を示すスクリーンショット。

ブックを使う

最初のページ ビュー、カスタム イベント、または要求を選択する場所を示すスクリーンショット。

  1. [選択されたイベント] ドロップダウン リストからイベントを選択します。
  2. [分析方法] ドロップダウン リストからメトリックを選択します。
  3. [影響するイベント] ドロップダウン リストからイベントを選択します。
  4. フィルターを追加するには、[選択したイベント フィルターの追加] タブまたは [影響するイベント フィルターの追加] タブを使用します。

ページの読み込み時間がページでのコンバージョン数に影響しているか

影響ブックを使って質問への回答を始めるには、初期ページ ビュー、カスタム イベント、または要求を選択します。

  1. [選択されたイベント] ドロップダウン リストからイベントを選択します。

  2. [期間] の既定の選択では、[分析方法] ドロップダウン リストのままにします。 (このコンテキストで、[期間][ページ ロード時間] の別名です)。

  3. [影響するイベント] ドロップダウン リストで、カスタム イベントを選択します。 このイベントは、手順 1. で選択したページ ビューの UI 要素に対応する必要があります。

    選択したイベントを期間で分析されたホームページとした例を示しているスクリーンショット。

カスタムの方法でページ ビューまたは読み込み時間を追跡する場合

影響では、標準とカスタムの両方のプロパティと測定値がサポートされています。 お好きな方をお使いください。 期間の代わりに 1 つ目と 2 つ目のイベントでフィルターを使用すると、より具体的な情報が得られます。

ユーザーの国またはリージョンの違いがコンバージョン率の違いに影響するか

  1. [選択されたイベント] ドロップダウン リストからイベントを選択します。

  2. [分析方法] ドロップダウン リストから国またはリージョンを選択します。

  3. [影響するイベント] ドロップダウン リストでは、手順 1 で選択したページ ビューの UI 要素に対応するカスタム イベントを選択します。

    選択したイベントが国とリージョンによって分析された例を示しているスクリーンショット。

影響分析ブックによってこれらのコンバージョン率が計算される方法

内部的には、影響分析ブックはピアソン相関関係の係数に依存しています。 結果は -1 から 1 の間で計算されます。 係数 -1 は負の線形相関を表し、1 は正の線形相関を表します。

影響分析のしくみを単純に分解すると、こちらのようになります。

  • [選択したイベント] ドロップダウン リストで選択したメイン ページ ビュー、カスタム イベント、または要求を A とします。
  • [使用量に影響] ドロップダウン リストで選択するセカンダリ ページ ビューまたはカスタム イベントを B とします。

選択された時間の範囲で、ユーザーからの全セッションのサンプルが影響によって確認されます。 各セッションについて、A のそれぞれの発生が検索されます。

セッションは、2 つの条件のいずれかに基づいて、2 つの異なる種類の "サブセッション" に分けられます。

  • コンバージョンが行われたサブセッションは、B イベントで終わったセッションで構成され、B の前に発生したすべての A イベントを含みます。
  • コンバージョンが行われなかったサブセッションは、B で終わらず、すべての A が発生した場合に発生します。

最終的に影響がどのように計算されるかは、メトリックにより分析しているのか、それともディメンションにより分析しているのかに基づいて異なります。 メトリックでは、サブセッション内のすべての A は平均化されます。 ディメンションでは、各 A の値は、B に割り当てられた値への 1/N に貢献します。ここで、N はサブセッション内の A の数です。

HEART - カスタマー エクスペリエンスの 5 つのディメンション

この記事では、Azure Monitor で Heart ブックを有効にして使用する方法について説明します。 HEART ブックは、HEART 測定フレームワークに基づいており、Google によって最初に導入されました。 複数の Microsoft 社内チームが、より優れたソフトウェアを提供するために HEART を使用しています。

概要

HEART は、Happiness (幸福度)、Engagement (エンゲージメント)、Adoption (導入)、Retention (リテンション)、Task success (タスク成功) を表す頭字語です。 製品チームがカスタマー エクスペリエンスの 5 つのディメンションに焦点を当てて、より優れたソフトウェアを提供できるようにサポートします。

  • 幸福度: ユーザーの受け止め方の測定
  • エンゲージメント: アクティブ ユーザーの関与のレベル
  • 導入: 対象ユーザーへの普及
  • リテンション: ユーザーが再び使用する割合
  • タスク成功: 生産性の強化

これらのディメンションは個別に測定されますが、相互に作用しています。

HEART ディメンション間のファネル リレーションシップを示す図。ファネル パスとは、導入、エンゲージメント、リテンション、幸福度です。タスク成功は、このファネルを推進する要素です。

  • 導入、エンゲージメント、リテンションは、ユーザー アクティビティ ファネルを形成します。 ツールを導入したユーザーの一部だけが再びツールを使用します。

  • タスク成功は、ユーザーをファネルの下に進め、導入からリテンションまで推進します。

  • 幸福度は、独立したディメンションではなく、他のディメンションの結果です。 ファネルを下に進み、より高いレベルのアクティビティを表示しているユーザーは、理想的には幸福度が高くなります。

作業の開始

前提条件

  • Azure サブスクリプション: Azure サブスクリプションを無料で作成する

  • Application Insights リソース: Application Insights リソースを作成する

  • Click Analytics: Click Analytics Autocollection プラグインを設定します。

  • 特定の属性: HEART メトリックを計算するために、次の属性をインストルメント化します。

    source 属性 説明
    customEvents session_Id 一意のセッション識別子
    customEvents appName 一意の Application Insights アプリ識別子
    customEvents itemType customEvents レコードのカテゴリ
    customEvents timestamp イベントの日時
    customEvents operation_Id 関連するテレメトリ イベント
    customEvents user_Id 一意のユーザー ID
    customEvents ¹ parentId 機能の名前
    customEvents ¹ pageName ページの名前
    customEvents ¹ actionType クリック分析レコードのカテゴリ
    pageViews user_AuthenticatedId 一意の認証済みユーザー識別子
    pageViews session_Id 一意のセッション識別子
    pageViews appName 一意の Application Insights アプリ識別子
    pageViews timestamp イベントの日時
    pageViews operation_Id 関連するテレメトリ イベント
    pageViews user_Id 一意のユーザー ID
  • 認証されたユーザー コンテキストを設定する場合は、次の属性をインストルメント化します。

source 属性 説明
customEvents user_AuthenticatedId 一意の認証済みユーザー識別子

脚注

¹: これらの属性を出力するには、npm で Click Analytics Autocollection プラグインを使います。

ヒント

Click Analytics プラグインを効果的に使用する方法については、「Application Insights JavaScript SDK の機能拡張 (Click Analytics)」を参照してください。

ブックを開く

[Public Templates](パブリック テンプレート) のギャラリーでブックを確認できます。 ブックは、[クリック分析プラグインを使用した製品分析] セクションに表示されます。

Azure Application Insights 内の HEART ブックの場所を表示したスクリーンショット。

ブックは 7 つあります。

Azure Application Insights の [ブック] セクションで、[パブリック テンプレート] の下にある 7 つの HEART ブックの名前を表示したスクリーンショット。

メイン ブックである [HEART 分析 - すべてのセクション] を操作するだけで済みます。 このブックには、他の 6 つのブックがタブとして含まれています。 ギャラリーから各タブに関連する個々のブックにアクセスすることもできます。

データが流れていることを確認する

メトリックを正確に示すようにデータが想定どおりに流れていることを検証するには、[Development Requirements](開発要件) タブを選択します。

重要

認証されたユーザー コンテキストを設定しない限り、[ConversionScope] ドロップダウンから [匿名ユーザー] を選択してテレメトリ データを表示する必要があります。

[HEART 分析 - すべてのセクション] ブックの [Development Requirements](開発要件) タブを表示したスクリーンショット。

データが想定通りに流れていない場合は、特定の属性が問題点とともにこのタブに表示されます。

HEART ブックの [Development Requirements](開発要件) タブで、データの不一致を表示したスクリーンショット。

ブックの構造

ブックは、HEART ディメンションのメトリック傾向を 7 つのタブに分割して表示します。 各タブには、ディメンションの説明、各ディメンションに含まれるメトリック、およびそれらの使用方法が含まれています。

タブは次のとおりです。

  • [概要]: 使用状況ファネル メトリックを要約して、アクセス、操作、および繰り返し使用の概要を示します。
  • 導入: 対象ユーザーへの普及、獲得速度、および合計ユーザー ベースを把握するのに役立ちます。
  • エンゲージメント: 使用の頻度、深さ、幅を示します。
  • リテンション: 繰り返しの使用状況を示します。
  • タスク成功: ユーザー フローとその時間分布を把握できます。
  • 幸福度: アンケート ツールを使用して、5 段階で顧客満足度スコア (CSAT) を測定することをお勧めします。 このタブでは、使用状況とパフォーマンスのメトリックを使用して、幸福度の見込みが提供されています。
  • 機能メトリック: 機能の細分性で HEART メトリックを理解できます。

警告

現在、HEART ブックはログに基づいて構築され、実質的にはログベースのメトリックを提供しています。 サンプリングとフィルター処理によって、これらのメトリックの正確性が低下する可能性があります。

HEART ディメンションの定義と測定方法

喜び

幸福度は、提供された製品について、ユーザーがどのように感じているかを測定する、ユーザーによって報告されるディメンションです。

幸福度を測定する一般的なアプローチは、ユーザーに対して "この製品にどの程度満足していますか?" といった顧客満足度に関する質問をすることです。 3 段階または 5 段階のユーザー回答 (例: "いいえ"、"おそらく"、"はい") を集計して、1 から 5 の製品レベルのスコアを作成します。 ユーザーが開始したフィードバックは否定的な内容に偏る傾向があるため、HEART では、定義済みの間隔でユーザーに表示するアンケートから幸福度を追跡します。

一般的な幸福度メトリックには、"平均星評価" や "顧客満足度スコア" などがあります。 カスタム ソースで説明されているカスタム インジェスト方法のいずれかを使用して、これらの値を Azure Monitor に送信します。

エンゲージメント

エンゲージメントは、ユーザー アクティビティの尺度です。 具体的には、ユーザー アクションはクリックなどの意図的な行為を指します。 アクティブな使用状況は、次の 3 つのサブディメンションに分類できます。

  • アクティビティの頻度: ユーザーが製品を操作する頻度を測定します。 例: ユーザーは通常、毎日、毎週、または毎月操作します。

  • アクティビティの幅: 特定の期間にユーザーが操作する機能の数を測定します。 例: ユーザーは 2021 年 6 月に合計 5 つの機能を操作しました。

  • アクティビティの深さ: ユーザーが製品を起動するごとに操作する機能の数を測定します。 例: ユーザーは、起動するごとに 2 つの機能を操作しました。

エンゲージメントの測定は、使用されている製品の種類によって異なる場合があります。 たとえば、Microsoft Teams などの製品は毎日の使用量が多いと予想され、追跡することが重要なメトリックとなります。しかし、給与支払いポータルのような製品の場合は、月単位または週単位で測定する方が理にかなっている場合があります。

重要

ボタンのクリックや入力などの意図的な操作を行うユーザーは、アクティブ ユーザーとしてカウントされます。 このため、エンゲージメント メトリックでは、Application Insights 用の Click Analytics プラグインをアプリケーションに実装する必要があります。

導入

導入により、関連ユーザーへの普及、ユーザー ベースとして獲得されているユーザー、およびその獲得方法を把握できます。 導入メトリックは、次を測定する場合に役立ちます。

  • 新しくリリースされた製品。
  • 新しく更新された製品。
  • マーケティング キャンペーン。

保持

リテンション ユーザーとは、指定された報告期間とその前の報告期間にアクティブだったユーザーを指します。 リテンションは通常、次のメトリックを使用して測定されます。

メトリック 定義 質問への回答
リテンション ユーザー 前の期間にもアクティブだったアクティブ ユーザーの数 何人のユーザーが製品へのエンゲージメントを保持していますか?
保持 前の期間のアクティブ ユーザーのうち、この期間にもアクティブなユーザーの割合 何パーセントのユーザーが製品へのエンゲージメントを保持していますか?

重要

アクティブ ユーザーにはアクションの種類を持ったテレメトリ イベントが少なくとも 1 つ必要であるため、リテンション メトリックでは、Application Insights 用の Click Analytics プラグインをアプリケーションに実装する必要があります。

タスク成功

タスク成功は、製品の機能を使用してユーザーが効率的かつ効果的にタスクを実行できるかどうかを追跡します。 多くの製品には、タスクを完了することによってユーザーを絞り込むように設計された構造が含まれています。 次に例をいくつか示します。

  • カートに商品を追加してから、購入を完了する。
  • キーワード を検索してから、結果を選択する。
  • 新しいアカウントを開始してから、アカウントの登録を完了する。

成功したタスクは、次の 3 つの要件を満たしています。

  • 想定されるタスク フロー: 機能の意図しているタスク フローをユーザーが完了し、想定したタスク フローと一致している。
  • ハイ パフォーマンス: 機能の意図している機能範囲が、適切な時間内に完了した。
  • 高信頼性: 機能の意図している機能範囲がエラーなしで完了した。

上記のいずれかの要件が満たされていない場合、タスクは失敗と見なされます。

重要

このため、タスク成功メトリックでは、Application Insights 用の Click Analytics プラグインをアプリケーションに実装する必要があります。

次のパラメーターを使用してカスタム タスクを設定します。

パラメーター 説明
最初の手順 タスクを開始する機能。 カート/購入の例では、カートに商品を追加するが最初のステップです。
想定されるタスクの期間 完了したタスクを成功と見なす時間枠。 この制約外で完了したタスクはすべて失敗と見なされます。 すべてのタスクに必ずしも時間制約があるわけではありません。 このようなタスクの場合は、[No Time Expectation](時間の期待なし) を選択します。
最後の手順 タスクを完了する機能。 カート/購入の例では、カートから商品を購入するが最後のステップです。

よく寄せられる質問

最初のイベントは、そのイベントがセッション内で出現する最初の時を表しますか、それともセッション内の任意の時を表しますか

視覚化の最初のイベントは、ユーザーがセッションの間にそのページ ビューまたはカスタム イベントを初めて送信した時のみを表します。 ユーザーがセッション内で最初のイベントを何回も送信できる場合、"Step 1" 列は、最初のイベントのすべてのインスタンスではなく、最初のイベントの "最初の" インスタンスの後でユーザーが行ったことだけを示します。

視覚化の一部のノードの階層が高すぎます。 ノードをより詳しく見るにはどうしたらよいですか

[編集] メニューの [次で分割] オプションを使用します。

  1. [イベント] メニューで、分割するイベントを選択します。

  2. [ディメンション] メニューでディメンションを選択します。 たとえば、[Button Clicked](ボタンがクリックされました) というイベントがある場合は、[Button Name](ボタン名) というカスタム プロパティを試してください。

特定の国や地域からのユーザーのコーホートを定義しました。 ユーザー ツールでこのコーホートを、その国や地域に対してフィルターを設定しただけの場合と比較した場合、なぜ異なる結果が表示されるのですか?

コーホートとフィルターは異なります。 英国からのユーザーのコーホートが存在し (前の例のように定義された)、その結果を Country or region = United Kingdom というフィルターを設定した場合と比較するとします。

  • コーホートの結果には、現在の時間の範囲において英国から 1 つ以上のイベントを送信したユーザーのすべてのイベントが表示されます。 国または地域で分割した場合は、多くの国や地域が表示される可能性が高くなります。

  • フィルターの結果には、英国からのイベントのみが表示されます。 国または地域で分割した場合は、英国だけ表示されます。

データをさまざまな期間粒度 (日次、月次、週次) で表示する方法

[日付の粒度] フィルターを選択して、粒度を変更できます。 フィルターは、すべてのディメンション タブで使用できます。

ワークブックで [日付の粒度] を日次、月次、週次に変更するフィルターを示すスクリーンショット。

HEART ブックでは利用できないアプリケーションからの分析情報を使用するにはどうすればよいですか。

ビジュアルにすべての質問への回答が示されない場合は、HEART ブックに提供するデータを詳しく調査することができます。 このタスクを実行するには、[監視] セクションで [ログ] を選択し、customEvents テーブルのクエリを実行します。 Click Analytics 属性の一部は、customDimensions フィールドに含まれています。 サンプル クエリを次に示します。

Application Insights の [監視] の [ログ] セクションを表示するスクリーンショット。また、[ログ] セクションには、アプリケーション データを取得するためのサンプル クエリも表示されています。

Azure Monitor のログの詳細については、「Azure Monitor ログの概要」を参照してください。

ブック内のビジュアルを編集できますか。

はい。 ブックのパブリック テンプレートを選びます。

  1. [編集] を選び、変更を加えます。

    ブック テンプレートの左上隅にある [編集] ボタンを示すスクリーンショット。

  2. 変更を加えたら、[編集が完了しました] を選択し、[保存] アイコンを選択します。

    編集を加えた後で使用できるようになる、ブック テンプレート上部の [保存] アイコンが表示されたスクリーンショット。

  3. 保存したブックを表示するには、[監視][ブック] セクションに移動してから、[ブック] タブを選択します。カスタマイズしたブックのコピーがそこに表示されます。 このコピーに対して、さらに必要な変更を加えることができます。

    [パブリック テンプレート] タブの横にある [ブック] タブが表示されたスクリーンショット。ここには、編集されたブックのコピーが表示されます。

ブック テンプレートの編集の詳細については、「Azure Workbooks テンプレート」を参照してください。

次のステップ