シナリオ
3 つの相互排他的な実験 を実行したいとします。- 2 つの実験 は Kameleoon Web Experimentation（JavaScript ベース）を使用して クライアントサイド でトリガーされます。
- 1 つの実験 は Kameleoon Feature Experimentation（例: バックエンド SDK 経由）を使用して サーバーサイド でトリガーされます。
このユースケースの処理
クライアントサイドとサーバーサイドの両方の実験で相互排他性を確保するには、以下の手順に従います。1. 機能実験から開始する
機能実験は サーバーサイド でトリガーされ、早期のターゲティング（ページロード前）が必要なため、最初にこれにトラフィックを割り当てるのが最適です。- Feature Experiment を作成します。
- この実験に 総トラフィックの 33% を割り当てます（またはテスト計画に合わせて他のパーセンテージでも構いません）。
2. Web 実験用の相互排他グループを作成する
次に、2 つの Web 実験用に 相互排他グループ（Mutually Exclusive Group） を作成します。 👉 このドキュメントに従ってください: Mutually Exclusive Groups で重複するキャンペーンを防止する。重複を防ぐことで、訪問者は 2 つの Web 実験のうち どちらか 1 つ しか見ることができず、両方を見ることはありません。3. 機能実験参加者を除外するターゲティング条件を追加する
機能実験にバケットされたユーザーがどちらの Web 実験にも入らないようにするため、両方の Web 実験に次のターゲティング条件を適用します。- ターゲティング条件:
Campaigns → Feature Flag→ “feature_experiment_name” の任意のバリエーションに公開された訪問者を除外する。
4. 技術的な考慮事項
デフォルトでは、Kameleoon Web Experimentation は各ページロード時に リモート同期コール を実行し、ユーザーが Feature Experiment に公開されたかどうかをチェックします。このコールにより、Kameleoon はユーザーを Web 実験に含めるか除外するかを判断できます。 3 つの実験が 同じページ で走っている場合、このセットアップは 扱いが難しい ことがあります。なぜなら、Web エンジンはユーザーを Web 実験に含めるかどうかを決定する前に サーバーサイドの公開ステータスを待たなければならない ためで、これは フリッカリング や遅延コンテンツを引き起こす可能性があります。Feature Experiment と Web Experiments がカスタマージャーニーの異なるタイミング（例: 異なるページ）でトリガーされる場合、すでに Web Experiments の 1 つに公開された訪問者を除外するための除外ターゲティング条件を Feature Experiment にも追加する必要があります。
推奨される解決策
フリッカリングを排除し、リアルタイムの意思決定を確保するために、リモートコールを待たずに フロントエンドで直接 ユーザーの Feature Experiment ステータスを公開します。- SDK メソッドを使用します:
getEngineTrackingCode()。 - 出力をページの HTML、できれば
<head>セクションに挿入します。
まとめ
クライアントサイドとサーバーサイドの実験にまたがる相互排他テストは 複雑ですが、Kameleoon が適切に実装すれば完全にサポートされます。 要点を簡単にまとめると:- 機能実験から始め、そのトラフィックシェアを最初に割り当てる。
- 相互排他グループを使用 して Web 実験間の重複を管理する。
- キャンペーン条件を使用して、Web 実験のターゲティングから 機能実験参加者を除外する。
- 実験が同じページで重複する場合は、トラッキングコードメソッドを使用して 遅延とフリッカーを排除する。