Auth0 Experiment Center は、Auth0 にネイティブに組み込まれた実験エンジンです。これにより、認証エクスペリエンスの変更を A/B テストし、その影響を認証イベントのログで確認できます。
Experiment Center では、Auth0 上で A/B テストを定義すると、トラフィックが決定論的に振り分けられ、既存の認証イベントには実験のメタデータが付加されて返されるため、独自のツールで結果を分析できます。
Experiment Center では、Auth0 認証パイプラインで管理された A/B テストを実行できます。変更を一度にすべてのユーザーにデプロイするのではなく、新しい動作をトラフィックの一定割合にのみ適用し、拡張情報を含む認証イベントで結果を測定したうえで、準備ができたら勝ちパターンを採用できます。
Experiment Center は、次の 3 つのエンティティを中心に構成されています。
- Experiment: トラフィックをどのように分割し、テストをいつ実施するかを定義します。
- Feature flag: 何をテストするかと、利用可能なバリエーションを定義します。
- Segment: 実験を特定のバリエーションに振り分けるための一連のルールを定義します。
ベータ期間中、Experiment Center は開発テナントでのみ利用できます。本番テナントはサポート対象ではありません。
- テスト対象の機能フラグ
- バリエーション間でトラフィックをどのように割り当てるか
- テストの実行期間
各実験は、必ず 1 つの機能フラグを参照します。
実験には 5 つの状態があります。
| Status | Meaning |
|---|
draft | 作成済みですが、まだ実行されていません。クエリパラメーターのオーバーライドを使用して安全にテストできます。 |
active | 実行中です。すべての認証トランザクションで、バリアントの割り当てとコンテキストの挿入が有効になります。 |
paused | 一時停止中です。新しい割り当ては行われません。進行中のセッションでは、割り当て済みのバリアントが維持されます。 |
completed | 完了しています。新しい割り当ては行われません。手動で昇格する際の参照用に、設定は保持されます。 |
archived | 論理削除されています。デフォルトの一覧表示には表示されません。分析データは保持されます。 |
is_fallback の割り当てがリクエストを受け取ります。
実験エンティティの詳細については、エンティティの詳細を参照してください。
実験がアクティブでバリエーションが割り当てられている場合、Experiment Center は ExperimentContext オブジェクトをランタイムの各サーフェスに挿入します。
ACUL 画面では、context_configuration を使用してその画面をオプトインした場合にのみ、これを受け取ります。
詳しくは、ACUL 統合ガイド を参照してください。
Actions と ページテンプレート では、実験がアクティブな場合、このオブジェクトが常に自動的に渡されます。オブジェクトの構造は次のとおりです。
{
experiment_id: string; // アクティブな実験ID
variation_id: string; // 割り当てられたバリエーションID
config: { // マージ済み設定（ベースライン + オーバーライド）
[paramName]: { value: unknown }
};
is_control: boolean; // コントロールバリエーションの場合はtrue
}
config フィールドには、割り当てられたバリエーションに対するマージ済みの完全な設定が含まれます。機能フラグで定義されたすべてのパラメーターには、常に値が設定されます。フォールバック ロジックを記述する必要はありません。
割り当てとは、認証トランザクション中にユーザーが特定のバリエーションへどのように振り分けられるかを指します。割り当ては決定論的で固定的です。つまり、同じユーザーは同じデバイス上で同じ実験に対して常に同じバリエーションを見るため、ログインをまたいでも体験の一貫性が保たれます。
- 割合による割り当てでは、重みに基づいてトラフィックを各バリエーションに振り分けます。特定の対象は常に同じバリエーションに割り当てられます。
- セグメントによる割り当てでは、リクエストのプロパティをセグメントルールに対して優先度順に評価します。最初に一致したセグメントによってバリエーションが決まり、同じセグメントに一致するリクエストは常に同じバリエーションに割り当てられます。
割り当て結果はテナントログの details.experiment に記録され、個別のAPIとして公開されることはありません。
割り当てエンティティの詳細については、エンティティの詳細を参照してください。
機能フラグは、何をテストするかを管理する単位です。これには次が含まれます。
- ベースライン構成: 型付きパラメーターとそのデフォルト値
- 1 つ以上の バリエーション: ベースラインとは異なる代替構成
機能フラグはテナント単位で適用され、再利用できます。同じフラグを、複数の実験で繰り返し参照できます (たとえば、同じ機能に対する第 1 四半期のテストと第 2 四半期の改善) 。
機能フラグには、次の 3 つのライフサイクル状態があります。
| 状態 | 意味 |
|---|
draft | 作成済みですが、まだ有効ではありません。アクティブな実験から参照することはできません。 |
active | 使用可能な状態です。このフラグを参照する実験を有効化するには、この状態である必要があります。 |
archived | 終了状態です。新しい実験からはこのフラグを参照できません。必要に応じて新しいフラグを作成してください。 |
- control variation はベースラインです。overrides は空であり (flag のデフォルトから変更されたパラメーターはありません) 。
- Treatment variations はそれぞれ、1つ以上のパラメーター override を指定します。
バリエーション自体には is_control マーカーはありません。特定の実験でどのバリエーションを統計上のコントロールにするかは、バリエーションではなく 割り当て で設定されます。同じバリエーションが、ある実験ではコントロールになり、別の実験ではトリートメントになることがあります。
バリエーションエンティティの詳細については、エンティティの詳細 を参照してください。
セグメントは、一連のルールに一致する認証リクエストをまとめた名前付きのグループです。ターゲットを絞った割り当て実験では、特定のトラフィックグループを特定のバリエーションに振り分けるためにセグメントを使用します。
セグメントはテナント単位で管理され、複数の実験で再利用できます。
セグメントエンティティの詳細については、エンティティの詳細を参照してください。
ベータ期間中は、次の制限が適用されます。
- テナントごとにアクティブな実験は 1 つのみ。
draft、paused、completed 状態の実験は複数保持できますが、同時に active にできるのは 1 つだけです。
- 構造化パラメーターのみ。 機能フラグのパラメーターでは、キー / 型 / 値の構造を使用します。
- 3 つの Actions トリガー。 実験コンテキストは、
post_login、pre_user_registration、post_user_registration で利用できます。
- テストトラフィックのみ。 ベータは、開発テナントで生成したトラフィックのみを対象に実行されます。本番環境のエンドユーザーデータがベータを通過することはありません。
- 手動での反映。 実験が完了したら、勝利したバリエーションの設定をテナントに手動で反映します。
Experiment Center のエンティティとプロパティについては、エンティティの詳細 を参照してください。
フラグの作成、実験の有効化、拡張情報が付加されたログイベントをエンドツーエンドで確認する方法については、Experiment Center クイックスタート を参照してください。 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム