機能フラグのテレメトリを有効にする

テレメトリは、アプリケーションとその機能の使用方法に関するデータを収集、送信、分析する自動化されたプロセスです。 機能フラグのテレメトリを有効にすると、機能のロールアウトの動作と影響に関する貴重な分析情報が得られ、チームがより迅速に反復し、ユーザー エクスペリエンスを向上させ、問題を早期に検出し、新機能の有効性を検証するのに役立ちます。 テレメトリを使用すると、チームは次のような重要な質問に答えることができます。

• 機能は期待どおりに有効または無効になっていますか?
• 特定のユーザーまたはグループが新しい機能にアクセスしていますか?
• 機能によってパフォーマンスの低下やエラーが発生していますか?
• エンゲージメントやコンバージョンなどの主要メトリックに対する機能の影響は何ですか?

組織はテレメトリ データを活用することで、情報に基づいたデータドリブンの意思決定を行い、問題をすばやく特定して解決し、機能の配信を最適化してビジネスとユーザーの成果を向上させることができます。

テレメトリは、アプリケーションの使用状況とパフォーマンスに関するデータを収集、送信、分析するプロセスです。 機能フラグの動作を監視し、データドリブンの意思決定を行うのに役立ちます。 機能フラグの変更がデプロイされると、多くの場合、アプリケーションへの影響の分析が重要です。 たとえば、可能性のある質問は次のとおりです。

• 私のフラグは期待どおりに有効または無効になっていますか?
• 対象ユーザーは、期待どおりに特定の機能にアクセスできていますか?
• バリアントは顧客エンゲージメントにどのように影響しますか?

この種の質問には、機能フラグ評価イベントの生成と分析を通じて回答できます。

[前提条件]

• [バリアント機能フラグの使用] で作成された機能フラグ。

Application Insights に接続する

1. Azure portal で App Configuration ストアを開きます。

2. [ テレメトリ ] セクションで、 Application Insights (プレビュー) ブレードを選択します。

3. サブスクリプション、リソース グループを選択します。 次に、App Configuration ストアに接続する既存の Application Insights リソースを選択するか、[ 新規作成 ] を選択して新しい Application Insights リソースを作成します。

4. [接続] を選択します。

   

機能フラグのテレメトリを有効にする

1. Azure portal で App Configuration ストアを開き、[操作] セクションの [機能マネージャー] ブレードを選択します。

2. Greeting という名前の機能フラグを選択します。 お持ちでない場合は、 指示に従って作成します。 次に、機能フラグを右クリックし、[ 編集] を選択します。

   

3. 新しいビューで、[ テレメトリ ] タブを選択します。

4. [ テレメトリを有効にする ] ボックスをオンにし、ページの下部にある [確認と更新 ] ボタンを選択します。

   

5. 使用している言語またはプラットフォームのアプリケーションでテレメトリを使用するには、次の手順に進みます。

   • ASP.NET Core
   • パイソン
   • JavaScript

Azure App Configuration でテレメトリの結果を確認する

1. App Configuration ポータルの Application Insights ブレードに移動します。 アプリケーションからのすべてのイベントを表示するグラフが表示されます。 このグラフでは、アクティビティ パターンの初期概要を示します。

   

2. 時間範囲セレクターを使用して、特定の期間に焦点を当てて傾向を特定したり、関心のある特定の期間を調査したりします。

3. 機能フラグを使ってフィルタリングする

   1. イベント グラフの上にあるドロップダウン メニューをクリックします
   2. イベント付き機能フラグ で機能フラグを選択します
   3. グラフには、機能フラグの評価に関連するイベントのみが表示されるようになりました

   

4. 詳細なテレメトリにアクセスするには、[ 詳細の表示 ] をクリックして [テレメトリ] タブを開きます。

   

注

このタブには、 フィーチャー マネージャー に移動し、目的の機能フラグのテレメトリ列で [イベントの表示 ] をクリックしてアクセスすることもできます。

バリアントの割り当てを確認する

[テレメトリ] タブでは、次の情報を表示できます。

• イベントの合計数: アプリケーションによって生成された評価イベントの合計数
• 一意のユーザー: 対象とイベントが生成された個別のユーザーの数。

Simple、Long、None の各バリアントに対するユーザーの分布と評価の数を表示するには、バリアントでメトリックをグループ化します。 このグループ化を使用すると、構成された割り当てが期待どおりに動作しているかどうか、および期待されるすべてのバリアントがユーザーに提供されているかどうかを確認できます。

この例では、"None" バリアントと "Long" バリアントのほぼ 2 倍のユーザー数が、それぞれ "None"、"Simple"、"Long" の間で構成された 50-25-25 パーセンタイル分割を受け取っていることがわかります。

フラグの状態に基づいてオーバーライドと動作を確認する

ユーザーは、さまざまな理由でバリアントを受け取る場合があります。 バリアント割り当てが適切な比率だけでなく、正しい理由で確実に行われるようにする必要があります。 割り当て理由でメトリックをグループ化できます。 この例では、割り当ての理由はパーセンタイルの割り当てのみであることがわかります。

1. 機能マネージャーに移動し、機能フラグの [有効] スイッチを切り替えて、機能フラグを無効にします。

2. テレメトリ列で、[ イベントの表示 ] をクリックして、読み取り専用モードで [テレメトリ] タブに移動します。

3. バリアントごとにユニークなユーザー数を表示します。 Long と Simple のすべての割り当てが 0 に設定されていることがわかります。 この場合の既定値である None バリアントのみがユーザーに割り当てられます。

   

4. 割り当て理由別に一意のユーザー数を表示するように切り替えます。 グラフから、パーセンタイルの割り当てが 0 になり、DefaultWhenDisabled がユーザーにバリアントが割り当てられている唯一の理由であることを確認します。

   その他の考えられる理由としては、"DefaultWhenEnabled"、"Group"、または "User" (構成されている場合) があります。

   

Application Insights でテレメトリを分析する

機能フラグの割り当てが期待どおりに動作していることを確認したら、テレメトリ イベントを詳しく調べて、ユーザーに対して出力された同類に基づいてさまざまなバリアントがどのように実行されているかを確認できます。

Azure portal で Application Insights リソースを開き、[監視] の下の [ログ] を選択します。 クエリ ウィンドウで、次のクエリを実行してテレメトリ イベントを表示します。

// Step 1: Get distinct users and their Variant from FeatureEvaluation (Replace <store-endpoint> with your store's endpoint)
let evaluated_users =
    customEvents
    | where name == "FeatureEvaluation"
    | where tostring(customDimensions.FeatureFlagReference) == "https://<store-endpoint>/kv/.appconfig.featureflag/Greeting"
    | extend TargetingId = tostring(customDimensions.TargetingId),
            Variant = tostring(customDimensions.Variant)
    | summarize Variant = any(Variant) by TargetingId;

// Step 2: Get distinct users who emitted a "Like"
let liked_users =
    customEvents
    | where name == "Liked"
    | extend TargetingId = tostring(customDimensions.TargetingId)
    | summarize by TargetingId;

// Step 3: Join them to get only the evaluated users who also liked
let hearted_users =
    evaluated_users
    | join kind=inner (liked_users) on TargetingId
    | summarize HeartedUsers = dcount(TargetingId) by Variant;

// Step 4: Total evaluated users per variant
let total_users =
    evaluated_users
    | summarize TotalUsers = dcount(TargetingId) by Variant;

// Step 5: Combine results
let combined_data =
    total_users
    | join kind=leftouter (hearted_users) on Variant
    | extend HeartedUsers = coalesce(HeartedUsers, 0)
    | extend PercentageHearted = strcat(round(HeartedUsers * 100.0 / TotalUsers, 1), "%")
    | project Variant, TotalUsers, HeartedUsers, PercentageHearted;

// Step 6: Add total row
let total_sum =
    combined_data
    | summarize Variant="All", TotalUsers = sum(TotalUsers), HeartedUsers = sum(HeartedUsers);

// Step 7: Output
combined_data
| union (total_sum)

見積もりページが読み込まれるたびに "FeatureEvaluation" イベントが 1 つ表示され、いいねボタンがクリックされるたびに "Liked" イベントが 1 つ表示されます。 "FeatureEvaluation" イベントには、評価された機能フラグの名前を持つ FeatureName というカスタム プロパティがあります。 どちらのイベントにも、引用を気に入ったユーザーの名前を持つ TargetingId というカスタム プロパティがあります。

この例では、Long バリアントと Simple バリアントのユーザー数はほぼ同じですが、Simple バリアントは22%の差でより良いパフォーマンスを示していることがわかります。