Skip to main content
Auth0 Experiment Centerは、Auth0に標準搭載された実験エンジンです。認証体験の変更をA/Bテストし、その影響を認証イベントのログで確認できます。 Experiment Centerでは、A/BテストをAuth0上で定義すると、トラフィックが決定論的に振り分けられ、既存の認証イベントに実験のメタデータが付加されて返されるため、お使いのツールで結果を分析できます。 Experiment CenterはAuth0 Identity Conversion Suiteの一部です。

仕組み

Experiment Centerを使用すると、Auth0の認証パイプラインで制御されたA/Bテストを実行できます。変更をすべてのユーザーに一度に適用するのではなく、一定の割合のトラフィックにのみ新しい動作を公開し、拡張された認証イベントを通じて結果を測定して、準備が整った時点で優れた方を本番へ展開します。 Experiment Centerは、次の3つのエンティティで構成されています。
  • Experiment:トラフィックの分割方法とテストの実行タイミングを定義します。
  • 機能フラグ:テストの対象と、選択し得るバリエーションを定義します。
  • セグメント:experimentを特定のバリエーションに振り分けるためのルールのセットを定義します。
お客様は、クッキーおよび類似技術に関連する機能を、エンドユーザーにサービスを提供するうえで厳密に必要な目的にのみ使用する責任を負います。詳しくは、Auth0の一般データ保護規則 (GDPR) への準拠をお読みください。

Experiment

experimentは、機能フラグを包み込む計測の仕組みです。定義する内容は次のとおりです。
  • どの機能フラグをテストするか
  • バリエーションごとにトラフィックをどう配分するか
  • テストをいつ実行するか
各experimentが参照する機能フラグは、必ず1つだけです。

experiment のライフサイクル

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

割り当て戦略

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

Experiment コンテキスト

experiment がアクティブでバリエーションが割り当てられると、Experiment Center はランタイムサーフェスに ExperimentContext オブジェクトを注入します。 ACUL の画面では、context_configuration で対象の画面をオプトインした場合にのみ受け取ります。 詳細については、ACUL 統合ガイドを参照してください。 アクションとページテンプレートは、experiment がアクティブな場合は常に自動的に受け取ります。オブジェクトの構造は次のとおりです。
config フィールドには、割り当てられたバリエーションのマージ済みの設定がすべて含まれます。機能フラグで定義されたパラメーターには常に値が設定されているため、フォールバック処理を記述する必要はありません。

Assignment

Assignment (割り当て) とは、認証の取引中にユーザーを特定のバリエーションへ振り分ける仕組みです。割り当ては決定論的かつスティッキーであり、同じユーザーは同じデバイスで同じ experiment に対して常に同じバリエーションが表示されるため、ログインをまたいでも体験が安定します。
  • 割合による割り当ては、重みに応じてトラフィックを各バリエーションに振り分けます。特定の対象は常に同じバリエーションに割り当てられます。
  • セグメントによる割り当ては、リクエストのプロパティをセグメントルールと優先順位順に照合します。最初に一致したセグメントによってバリエーションが決まり、同じセグメントに一致するリクエストは常に同じバリエーションになります。
割り当ての結果はテナントのログの details.experiment に記録されます。個別の API では公開されません。 assignment エンティティについて詳しくは、Entities Detailsをお読みください。

機能フラグ

機能フラグは、テスト対象を制御する単位です。次の要素を含みます。
  • ベースライン設定: 型付きのパラメーターとそのデフォルト値
  • 1つ以上のバリエーション: ベースラインとは異なる代替設定
機能フラグはテナント単位のスコープを持ち、再利用できます。同じフラグを、期間をまたいで複数のexperimentから参照することも可能です (たとえば、同じ機能に対する第1四半期のテストと第2四半期の改善テストなど) 。

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

機能フラグには、3つの状態からなるライフサイクルが保存されています。 機能フラグエンティティの詳細については、Entities Detailsをご覧ください。

Variation

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

セグメント

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