アプリケーションにコードを追加する - Amazon CloudWatch
EvaluateFeature の使用PutProjectEvents の使用

アプリケーションにコードを追加する

CloudWatch Evidently を使用するには、アプリケーションにコードを追加して、各ユーザーセッションにバリエーションを割り当て、Evidently にメトリクスを送信します。CloudWatch Evidently EvaluateFeature オペレーションを使用してユーザーセッションにバリエーションを割り当てます。PutProjectEvents オペレーションを使用してイベントを送信し、起動または実験のメトリクスを計算するために使用します。

バリエーションまたはカスタムメトリクスを作成すると、CloudWatch Evidently コンソールに追加する必要があるコードのサンプルが表示されます。

エンドツーエンドの例については、「チュートリアル: Evidently のサンプルアプリケーションを使用した A/B テスト」を参照してください。

EvaluateFeature の使用

起動または実験で機能のバリエーションが使用される場合、アプリケーションは EvaluateFeature オペレーションを使用して、各ユーザーセッションにバリエーションを割り当てます。ユーザーへのバリエーションの割り当ては、評価イベントです。このオペレーションを呼び出すとき、以下を渡します。

  • 機能名 – 必須。Evidently では、起動または実験の機能評価ルールに従って評価が処理され、エンティティのバリエーションが選択されます。

  • entityId – 必須。一意のユーザーを表します。

  • evaluationContext – オプション。ユーザーに関する追加情報を表す JSON オブジェクト。セグメントを作成した場合、Evidently では機能評価中にこの値を使用して、ユーザーをオーディエンスのセグメントと照合します。詳細については、「セグメントを使用してオーディエンスを絞り込む」を参照してください。

    Evidently に送信できる evaluationContext の値の例を次に示します。

    {
    "Browser": "Chrome",
    "Location": {
        "Country": "United States",
        "Zipcode": 98007
    }
}

Sticky 評価

CloudWatch は明らかに「スティッキー」評価を使用します。entityId の単一の構成、機能、機能の構成および evaluationContext は、常に同じバリエーション割り当てを受け取ります。この変動の割り当てが変更されるのは、エンティティがオーバーライドに追加されるか、実験トラフィックがダイヤルアップされる場合のみです。

機能の構成には、以下が含まれます。

  • 機能のバリエーション

  • この機能で現在実行中の実験のバリエーションの構成 (各バリエーションに割り当てられたパーセンテージ) (ある場合)。

  • この機能で現在実行中のローンチのバリエーションの設定 (ある場合)。バリエーションの構成には、定義済みのセグメントオーバーライドが含まれます (ある場合)。

実験のトラフィック配分を増やしても、以前に実験処理グループに割り当てられていた entityId には、引き続き同じ処理が行われます。以前にコントロールグループに割り当てられていた entityId は、実験のために指定されたバリエーションの構成に従って、実験処理グループに割り当てられている場合があります。

実験のトラフィック配分を減少させると、entityId が処理グループからコントロールグループに移行する可能性はありますが、異なる処理グループに移行することはありません。

PutProjectEvents の使用

明らかにカスタムメトリクスをコーディングするには、 PutProjectEvents オペレーションを使用します。ペイロードの簡単な例を次に示します。

{
    "events": [
        {
            "timestamp": {{$timestamp}},
            "type": "aws.evidently.custom",
            "data": "{\"details\": {\"pageLoadTime\": 800.0}, \"userDetails\": {\"userId\": \"test-user\"}}"
        }
    ]
}

entityIdKey は entityId のままにすることも、名前を変更して userId など他のものに変更することもできます。実際のイベントでは、entityId は、ユーザー名、セッション ID などになります。

"metricDefinition":{
    "name": "noFilter",
    "entityIdKey": "userDetails.userId", //should be consistent with jsonValue in events "data" fields
    "valueKey": "details.pageLoadTime"
},

イベントが正しい起動または実験に関連付けられていることを確認するには、同じことを渡す必要があります。EvaluateFeature と PutProjectEvents の両方を呼び出すときは、同じ entityId を渡す必要があります。EvaluateFeature コールの後に必ず PutProjectEvents を呼び出してください。そうしないと、データが削除され、CloudWatch では明らかに使用されません。

PutProjectEvents オペレーションでは、入力パラメータとしてフィーチャ名は不要です。このように、単一のイベントを複数の実験で使用できます。例えば、 entityId を userDetails.userId に設定して EvaluateFeature を呼び出すとします。2 つ以上の実験を実行している場合、そのユーザーのセッションから 1 つのイベントでそれらの各実験に対してメトリクスを放出できます。これを行うには、同じ entityId を使用して、実験ごとに1回PutProjectEvents を呼び出します。

[Timing] (タイミング)

アプリケーションが EvaluateFeature をコールした後では、PutProjectEvents からのメトリクイベントがその評価に基づいて帰属される1時間の期間があります。1 時間後にさらにイベントが発生した場合、そのイベントは帰属しません。

ただし、その最初の呼び出しの 1 時間のウィンドウ中に同じ entityId が新しい EvaluateFeature 呼び出しに使用された場合、代わりに後の EvaluateFeature 結果が使用され、1 時間のタイマーが再開されます。これは、前の Sticky 評価セクションでの説明のように、実験トラフィックが 2 つの割り当て間でダイヤルアップされる場合など、特定の状況でのみ発生します。

エンドツーエンドの例については、「チュートリアル: Evidently のサンプルアプリケーションを使用した A/B テスト」を参照してください。