仕組み
- 実験: トラフィックをどのように分割するか、またテストをいつ実行するかを定義します。
- 機能フラグ: 何をテストするか、および利用可能なバリエーションを定義します。
- セグメント: 実験を特定のバリエーションに振り分けるためのルールセットを定義します。
実験
- どの機能フラグをテストするか
- 各バリエーションにトラフィックをどのように割り当てるか
- テストをいつ実施するか
実験のライフサイクル
割り当て戦略
is_fallback の割り当てがそのリクエストを受け取ります。
実験エンティティの詳細については、Entities Details を参照してください。
実験コンテキスト
ExperimentContext オブジェクトを注入します。
ACUL の画面でこれを受け取れるのは、context_configuration でその画面をオプトインした場合のみです。
詳しくは、ACUL integration guide をご覧ください。
Actions と page templates では、実験が有効な場合、このオブジェクトが自動的に渡されます。オブジェクトの構造は次のとおりです。
config フィールドには、割り当てられたバリエーションに対応する、マージ済みの完全な設定が含まれます。機能フラグで定義されたすべてのパラメータには常に値が設定されるため、フォールバックロジックを記述する必要はありません。
割り当て
- Percentage 割り当て は、重みに基づいてトラフィックを各バリエーションに振り分けます。特定の対象は常に同じバリエーションに割り当てられます。
- Segment 割り当て は、優先順位に従ってリクエストのプロパティをセグメントルールに照らして評価します。最初に一致したセグメントがバリエーションを決定し、同じセグメントに一致するリクエストは常に同じバリエーションになります。
details.experiment 配下のテナントログに記録され、個別のAPIとしては公開されません。
割り当てエンティティの詳細については、Entities Detailsを参照してください。
機能フラグ
- ベースライン設定: 型付きパラメーターとそのデフォルト値
- 1 つ以上の バリエーション: ベースラインとは異なる代替設定
機能フラグのライフサイクル
機能フラグエンティティの詳細については、Entities Details をご覧ください。
バリエーション
- コントロールバリエーションはベースラインです。オーバーライドは空で、フラグのデフォルト設定から変更されたパラメータはありません。
- トリートメントバリエーションは、それぞれ1つ以上のパラメータのオーバーライドを指定します。
is_control マーカーはありません。特定の実験でどのバリエーションを統計上のコントロールとするかは、バリエーションではなく割り当てで設定されます。同じバリエーションが、ある実験ではコントロールになり、別の実験ではトリートメントになることもあります。
バリエーションエンティティの詳細については、Entities Details を参照してください。
セグメント
制限事項
- テナントごとに有効な実験は1つのみ。
draft、paused、completed状態の実験は複数作成できますが、同時にactiveにできるのは1つだけです。 - 構造化パラメータのみ。 機能フラグのパラメータは、key/type/value の構造を使用します。
- Actions トリガーは3つのみ。 実験コンテキストは、
post_login、pre_user_registration、post_user_registrationで利用できます。 - テストトラフィックのみ。 Beta は、お客様が生成したトラフィックを使用する開発用テナントでのみ実行されます。本番環境のエンドユーザーデータが Beta を通過することはありません。
- 手動プロモーション。 実験が完了したら、勝ったバリエーションの設定をテナントに手動で適用します。