メインコンテンツへスキップ
このチュートリアルでは、Automation API を使用して実験結果をリクエストし、勝者のバリエーションを判断する方法を説明します。これは、実験の作成バリエーションの変更ゴールとセグメントの関連付け、および 実験の開始 に関する以前のチュートリアルに続くものです。

要件

  • access_token
Automation API には アクセストークン が必要です。アクセストークン取得セクション の手順に従って、プログラムでトークンを取得します。
  • experimentId
experimentId は、結果が必要な実験の数値識別子です。実験を表示している間に Kameleoon アプリの URL で見つけることができます(たとえば、https://app.kameleoon.com/.../experiments/188308/...)。フィーチャーフラグ実験の場合、ID は Rollout Planner に表示されます。

ゴール

このチュートリアルでは、以下の例の実験を使用します:
Experiment_188308
Product Page Redesign と呼ばれるこの実験には、オリジナルバージョンに加えて 2 つのバリエーション Redesign 1 (ID 828220)Redesign 2 (ID 828221) が含まれます。この実験にはいくつかの目的がありますが、本チュートリアルではメインゴール(クリックトラッキング を通じて 保険の登録 を追跡)のみに焦点を当てます。
このチュートリアルはフィーチャーフラグ実験にも適用されます。ただし、https://api.kameleoon.com/experiments/* の代わりに https://api.kameleoon.com/feature-flags/* エンドポイントを使用してください:experimentIdRollout Planner にあります:

結果取得の仕組み

結果の取得は 2 段階のプロセスです:
  1. 結果をリクエストする/experiments/{experimentId}/results に POST します。レスポンスは結果そのものではなく、dataCode ハッシュを返します。
  2. 結果をポーリングする/results?dataCode=<dataCode> に GET リクエストを送信して、実際のデータを取得します。
ステップ 1 の 2 つのケースは、認証方法のみが異なります。アクセストークンで直接認証する(ケース 1)か、または認証されていないユーザーが結果を閲覧できる共有トークンを使用する(ケース 2)かです。

1. データコードを取得する

以下の主要なボディパラメータは、レポートに含める内容を制御します。パラメータの完全なリファレンスについては、Request experiment’s results エンドポイント を参照してください。

ケース 1: 結果を直接取得する

アクセストークンを使用して Request experiment’s results エンドポイント に POST リクエストを送信します。 例:
レスポンス:
この dataCodeステップ 2 に渡して、実際の結果を取得します。

ケース 2: 認可なしで結果を共有する

このアプローチは、アクセストークンなしでユーザーが結果を閲覧できるようにするために使用します。たとえば、ステークホルダーとライブ結果ビューを共有する場合などです。

1. SharedToken を取得する

Share experiment results エンドポイント から SharedToken を取得します。このエンドポイントは結果エンドポイントと同じリクエストボディを受け付けます。
レスポンス:

2. SharedToken を使って dataCode を取得する

前のレスポンスの SharedToken をアクセストークンの代わりに使用して、Request experiment’s results エンドポイント に POST リクエストを送信します。
レスポンス:

2. 実験結果を取得する

上記のいずれかのケースから dataCode を受け取った後、result エンドポイント を呼び出します。
レスポンスが "status": "PENDING" を返す場合、レポートはまだ生成中です。ステータスが "READY" になるまで、少し待ってからリクエストを再試行してください。
レスポンス:

3. 結果を解釈して勝者バリエーションを判断する

勝者バリエーションは、高い信頼性(95% を超える)と参照バリエーションと比較した正の改善率を示す必要があります。 JSON レスポンスは、Redesign 1 と Redesign 2 の両方が 100% の信頼度を持つことを示しています。ただし、Redesign 1 は +211.48% の改善率を示すのに対し、Redesign 2 は -43.33% の率を示します。したがって、Redesign 1 が勝者です。 Redesign 1
Redesign 2

4. 実験結果をフィルタする

breakdown パラメータと filters パラメータを使用して、特定の結果を取得します。breakdown パラメータは、単一のディメンション(ブラウザ、オペレーティングシステム、曜日など)でデータを整理します。filters パラメータは、ブレークダウンが適用される前にデータを訪問者のサブセットに制限します。
breakdown パラメータは、リクエストごとに 1 つのオブジェクト のみを受け付けます(配列ではありません)。複数のディメンションを比較するには、ブレークダウンごとに 1 つのリクエストを送信してください。

ブレークダウンの形式

ほとんどのブレークダウンタイプは type フィールドのみを受け取ります。例:
3 つのブレークダウンタイプは追加のフィールドを必要とします: INTERVAL — 時間間隔で結果を分割します。"type": "INTERVAL"interval フィールドと組み合わせます:
interval フィールドは HOURDAYWEEKMONTHYEAR を受け付けます。 CUSTOM_DATUM — カスタムデータインデックスで結果を分割します。"type": "CUSTOM_DATUM"index フィールドと組み合わせます:
CROSS_CAMPAIGN — 別の実験またはパーソナライゼーションへの露出で結果を分割します。experiments または personalizations のうち少なくとも 1 つを指定します:

フィルタタイプ

各フィルタオブジェクトには type 文字列と include ブール値が必要です。一致する訪問者に結果を制限するには includetrue に設定し、除外するには false に設定します。追加のフィールドは type によって異なります:

例: 新規訪問者にフィルタされたブラウザブレークダウン

次のリクエストは、Request experiment’s results エンドポイント に POST を送信することで、新規訪問者に制限されたブラウザブレークダウンを適用します:
dataCode を受け取った後、結果を取得します:
成功レスポンスは、ブラウザ別に分割された結果を返します。レスポンスは上記のステップ 2 と同じ構造に従い、breakdownData 内の各ブラウザタイプ(CHROMEFIREFOXOTHERS など)がキーになります。次のレスポンスはわかりやすさのために省略されています: