Skip to main content
Auth0 Experiment Center は、Auth0 にネイティブで組み込まれた実験エンジンです。認証エクスペリエンスの変更を A/B テストし、認証イベントのログへの影響を確認できます。 Experiment Center を使うと、Auth0 で A/B テストを定義でき、トラフィックは決定論的に分割されます。さらに、既存の認証イベントには実験メタデータが付加されて返されるため、お使いのツールで結果を分析できます。

仕組み

Experiment Center を使うと、Auth0 の認証パイプラインで、制御された A/B テストを実行できます。変更を一度にすべてのユーザーへデプロイする代わりに、新しい動作をトラフィックの一定割合にのみ公開し、拡張された認証イベントを通じて結果を測定したうえで、準備が整ったら勝ったバリエーションを採用できます。 Experiment Center は、次の 3 つのエンティティを中心に構成されています。
  • 実験: トラフィックをどのように分割するか、またテストをいつ実行するかを定義します。
  • 機能フラグ: 何をテストするか、および利用可能なバリエーションを定義します。
  • セグメント: 実験を特定のバリエーションに振り分けるためのルールセットを定義します。
Beta 期間中、Experiment Center は開発用テナントでのみ利用できます。本番テナントはサポートされていません。

実験

実験とは、機能フラグの効果を測定するための仕組みです。次の内容を定義します。
  • どの機能フラグをテストするか
  • 各バリエーションにトラフィックをどのように割り当てるか
  • テストをいつ実施するか
各実験は、必ず1つの機能フラグを参照します。

実験のライフサイクル

実験には5つの状態があります。

割り当て戦略

実験では、次の 2 つの割り当て戦略のいずれかを使用します。 割合ベース: トラフィックは重みに応じて各バリエーションに分配されます。すべての重みの合計は 100 である必要があります。重み 0 も有効です (そのバリエーションは実験の定義には含まれますが、トラフィックは割り当てられません) 。 セグメントベース (ターゲティング) : トラフィックはセグメントへの所属に基づいて各バリエーションに振り分けられます。セグメントは優先順位の高い順に評価されます。最初に一致したセグメントが適用されます。どのセグメントにも一致しない場合は、is_fallback の割り当てがそのリクエストを受け取ります。 実験エンティティの詳細については、Entities Details を参照してください。

実験コンテキスト

実験が有効でバリエーションが割り当てられると、Experiment Center は実行環境の各サーフェスに ExperimentContext オブジェクトを注入します。 ACUL の画面でこれを受け取れるのは、context_configuration でその画面をオプトインした場合のみです。 詳しくは、ACUL integration guide をご覧ください。 Actionspage templates では、実験が有効な場合、このオブジェクトが自動的に渡されます。オブジェクトの構造は次のとおりです。
config フィールドには、割り当てられたバリエーションに対応する、マージ済みの完全な設定が含まれます。機能フラグで定義されたすべてのパラメータには常に値が設定されるため、フォールバックロジックを記述する必要はありません。

割り当て

割り当てとは、認証トランザクション中にユーザーが特定のバリエーションに振り分けられる仕組みです。割り当ては決定的で固定されるため、同じユーザーは同じデバイス上では、同じ実験に対して常に同じバリエーションを見ることになり、ログインをまたいでも一貫した体験が保たれます。
  • Percentage 割り当て は、重みに基づいてトラフィックを各バリエーションに振り分けます。特定の対象は常に同じバリエーションに割り当てられます。
  • Segment 割り当て は、優先順位に従ってリクエストのプロパティをセグメントルールに照らして評価します。最初に一致したセグメントがバリエーションを決定し、同じセグメントに一致するリクエストは常に同じバリエーションになります。
割り当て結果は、details.experiment 配下のテナントログに記録され、個別のAPIとしては公開されません。 割り当てエンティティの詳細については、Entities Detailsを参照してください。

機能フラグ

機能フラグは、テスト対象を制御する単位です。これには次のものが含まれます。
  • ベースライン設定: 型付きパラメーターとそのデフォルト値
  • 1 つ以上の バリエーション: ベースラインとは異なる代替設定
機能フラグはテナント単位で管理され、再利用できます。同じフラグを、複数の実験で継続的に参照できます (たとえば、同じ機能に対する第1四半期のテストや第2四半期の調整など) 。

機能フラグのライフサイクル

機能フラグにはライフサイクルがあり、次の 3 つの状態で管理されます。 機能フラグエンティティの詳細については、Entities Details をご覧ください。

バリエーション

バリエーションとは、機能フラグ内で定義された体験の1つのバージョンです。ベースラインと比べて、どの設定パラメータがどの程度異なるかを指定します。
  • コントロールバリエーションはベースラインです。オーバーライドは空で、フラグのデフォルト設定から変更されたパラメータはありません。
  • トリートメントバリエーションは、それぞれ1つ以上のパラメータのオーバーライドを指定します。
バリエーション自体には is_control マーカーはありません。特定の実験でどのバリエーションを統計上のコントロールとするかは、バリエーションではなく割り当てで設定されます。同じバリエーションが、ある実験ではコントロールになり、別の実験ではトリートメントになることもあります。 バリエーションエンティティの詳細については、Entities Details を参照してください。

セグメント

セグメントは、一連のルールに一致する認証リクエストをまとめた名前付きのグループです。ターゲットを絞った割り当て実験では、セグメントを使用して特定のトラフィック群を特定のバリエーションに振り分けます。 セグメントはテナント単位で管理され、複数の実験で再利用できます。 セグメントエンティティの詳細については、Entities Detailsを参照してください。

制限事項

Beta期間中は、以下の制限があります。
  • テナントごとに有効な実験は1つのみ。 draftpausedcompleted 状態の実験は複数作成できますが、同時に active にできるのは1つだけです。
  • 構造化パラメータのみ。 機能フラグのパラメータは、key/type/value の構造を使用します。
  • Actions トリガーは3つのみ。 実験コンテキストは、post_loginpre_user_registrationpost_user_registration で利用できます。
  • テストトラフィックのみ。 Beta は、お客様が生成したトラフィックを使用する開発用テナントでのみ実行されます。本番環境のエンドユーザーデータが Beta を通過することはありません。
  • 手動プロモーション。 実験が完了したら、勝ったバリエーションの設定をテナントに手動で適用します。

詳しく見る

Experiment Center のエンティティとプロパティについては、**Entities Details**をご覧ください。 フラグの作成、実験の有効化、強化されたログイベントをエンドツーエンドで確認する方法については、**Experiment Center Quickstart**をご覧ください。