アプリケーションにコードを追加する
重要
サポート終了通知: 2025 年 10 月 16 日、AWS は CloudWatch Evidently のサポートを終了します。2025 年 10 月 16 日以降、Evidently コンソールまたは Evidently リソースにアクセスできなくなります。
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 テスト」を参照してください。