前提条件
- Auth0 の開発テナント
-
Machine-to-Machine アプリケーション (以下の Management API スコープが必要) :
1. 機能フラグを作成して有効化する
/api/v2/experimentation/feature-flags エンドポイントに POST リクエストを送信します。
- レスポンスには
feature_flag_idの値が含まれます。後続の手順でこの値が必要になります。 - 機能フラグは
draftステータスで作成されます。
2つのバリエーションを追加する
コントロールバリエーションを作成する
overrides パラメータを指定してコントロールバリエーションを作成できます。
コントロールバリエーションを追加するには、/api/v2/experimentation/feature-flags/{feature_flag_id}/variations エンドポイントに POST リクエストを送信します。
レスポンスには、コントロール用の
variation_id 値が含まれます。割り当てを設定する際にこの値が必要になります。トリートメントバリエーションを作成する
/api/v2/experimentation/feature-flags/{feature_flag_id}/variations エンドポイントに POST リクエストを送信し、overrides オブジェクトを設定します。
Example
機能フラグを有効化する
active ステータスでない限り、実験を有効化することはできません。
機能フラグのステータスを active に変更するには、/api/v2/experimentation/feature-flags/{feature_flag_id}/status エンドポイントに POST リクエストを送信します。
2. セグメントを作成する (任意)
/api/v2/experimentation/segments エンドポイントに POST リクエストを送信します。
この例では、米国内のモバイルユーザーに一致するセグメントを作成します。
Example
レスポンスには
segment_id の値が含まれます。セグメントは、実験で segment の割り当て戦略を使用する場合にのみ適用されます。3. 実験を作成して有効化する
/api/v2/experimentation/experiments エンドポイントに POST リクエストを送信します。
この例では、allocations オブジェクトを使用して 90 対 10 の割合で振り分けます。ユーザーの 90% にコントロールを、10% にトリートメントを割り当てます。これは、慎重に段階的ロールアウトを始める際の一般的な出発点です。
Example
draft ステータス、is_valid: false の状態で開始されます。これは想定内です。完全な準備状況の確認は次のステップで行われます。
実験を検証する
/validate エンドポイントでは、有効化時に実行されるものと同じチェック結果が返されます。
実験を確認するには、/api/v2/experimentation/experiments/{experiment_id}/validate エンドポイントに POST リクエストを送信します。
レスポンスには is_valid の値が含まれており、有効化する準備ができているかどうかを確認できます。
実験を有効化する
activeに変更するには、/api/v2/experimentation/experiments/{experiment_id}/statusエンドポイントにPOSTリクエストを送信します。
実験のstarted_at値は最初に有効化した時点で設定され、一時停止して再度有効化しても変わりません。
アクティブな実験はテナントごとに1つだけです。 すでに別の実験がアクティブになっている場合、有効化すると
400 experiment_active_limit_exceededが返されます。先にその実験を一時停止するか、完了してください。4. 認証イベントを発生させ、結果を確認する
/authorize URL にアクセスします。
ログインフローを完了します。Experiment Center は有効な実験を判定し、決定論的ハッシュを使用してバリエーションを割り当て、実験コンテキストを挿入し、生成される認証イベントを拡張します。
拡張ログを確認する
- Auth0のDashboard > Monitoring > Logsに移動します。
- Log streamingを使用します。すでにテナントのログを分析ツール (Datadog、Splunk、Segmentなど) にストリーミングしている場合、拡張された実験メタデータも同じストリームを通じて自動的に送信されます。
このイベントには、
details.experimentオブジェクト内に実験メタデータが含まれます。variation_idフィールドを見ると、ユーザーにどのバリエーションが割り当てられたかがわかります。次の条件を満たしていれば、最初の実験は正常に実行できています。
- テナントのログ内の認証イベントに、
experiment_idとvariation_idを含むdetails.experimentが含まれている - クエリパラメーターのオーバーライドでテストしたときに、両方のバリエーションが期待どおりに動作する
- 同じデバイスまたはユーザーで、複数の認証イベントにわたって常に同じ
variation_idが割り当てられる (決定論的な割り当て)
詳細はこちら
- 実験コンテキストに応じて ACUL コンポーネントのコードを分岐する方法については、ACUL integration guideを参照してください。
- post-login と registration のトリガーで
event.experimentを使用する方法については、Actions integration guideを参照してください。