この場合、サイトに訪問して２つの実験の対象になったビジターは、ひとつだけの実験に出くわした場合と違う行動をとる可能性があります。これを回避できるのが相互排他的な実験です。
Exclusion Groups（排他的グループ機能）を活用すれば、実験Aの対象となったビジターが実験Bの対象になることはありません。そのためノイズを避けることができ、ビジター行動分析の精度が高まります。
目次
1.こんな方におススメ下の図は、２つの実験の関連性を表しています。
ひとつはホームページ上、もう一つは検索結果のページ上での実験です。
すなわち、以下の条件のもとでの実験は重複しづらいということです。
しかし下記のようなケースでは、相互排他的実験を活用するか、ひとつの実験が完了するまで他の実験の実装を待つことをお勧めします。
すでに幾つかの企業では、データの統合性を保つべく同時に相互排他的な実験が実装されています。下記のOptimizelyコードを利用すればこの実験を走らせることができます。
＊相互排他的な実験は実装に手間がかかり、テストサイクルが長引く可能性があるという点にご留意下さい。
Optimizelyの XWebによって、複数の実験やキャンペーンの相互排他的の作成が可能です。
１. 実験のダッシュボード Experiments dashboard から排他的グループ Exclusion Groups のタブを開く
２. 排他グループの作成 Create an Exclusion Groupをクリック
３. 名前をつけ説明を加える 上のデモではアルゴリズムを探すグループ（Search Algorithm Group）と名付けられています。
４. 排他グループの作成を再度クリック
これで完了です。
実装に向けて実験のタイプを再確認してみましょう。
まずはレギュラーバージョン重複した実験から。
トラフィックの割り当てがそれぞれ100%の２つの実験を実装するとします。ターゲティングの条件を満たしている限り、すべてのビジターにAとB両方の実験が表示されます。
重複しているもののトラフィックの割り当てが異なる２つ実験を実装するとします。
この例でも、すべてのビジターは実験の対象となります。半数のビジターには実験Aのみが表示され、残りの半数には実験AとBの両方が表示されます。つまりBの実験が全く表示されないビジターもいるということです。
続いて、排他的実験バージョン
仮に３つの実験を実装し、うち２つが排他的グループに属するとします。
この場合、すべのビジターには共通して実験Aが表示されます。たしかに一部のビジターには実験Bあるいは実験Cも表示されるものの、BとCが重複して表示されることはありません。なぜなら実験Bと実験Cは共通の排他的グループ属しているため、相互に排他的となっているからです。
この例でも３つの実験が実装されますが、２つは相互排他的なものの、相互排他的実験に割り当てられていないトラフィックも存在します。
またこの場合も全てのビジターには実験Aが表示されるでしょう。実験Bと実験Cは引き続き相互排他的なので、実験Bを見るビジターもいれば実験Cを見るビジターもいます。ただBとCの両方を見る人はいません。しかし、３０％のビジターは排他的な実験のどちらにも割り当てられていないので、彼らには実験Aのみが表示されます。
さらに、２つの異なる排他的実験を実装するとしますう。
この例では、すべてのビジターに実験Aが表示され、いくらかのビジターには実験Bや実験Cが表示されるもののBとCの両方をみるビジターはいません。30%のビジターにはBもCも表示されません。
しかし排他的グループ2が存在することによって、さらに他の可能性が生まれます。全てのビジターに実験Dあるいは実験Eが表示されます。しかし、実験Dと実験Cを同時に見るビジターはいません。そのため、３つすべてのレイヤーから実験が表示されるビジターも存在します。（実験A＋排他的グループ1と排他的グループ2のいずれかに属する実験）
さらに、排他的グループ1のどちらにも属さないトラフィックも割り当てているので、ビジターが、２つのレイヤーから実験を見る可能性もあります。
実験を停止すると、新しいビジターはそれ以上実験に出くわすことはありません。停止されている間は、実験を既に見たユーザーに再びそれが表示されることはありませんが、引き続きその実験の対象となります。もし実験が再開されれば、実験を既に見ていたユーザーは再びそれを見ることとなり、新しいビジターはまたその実験が割り当てられます。
例えば、あるビジターが実験Cに割り振られたとします。もしここで、実験Cを停止すれば、彼はそれを再び見ることはありません。もし実験が再開され、そのビジターがサイトに返ってきたとしたら、彼らは実験Cをもう一度見ることとなります。
さらに、実験とキャンペーンを相互排他的にするために、排他的グループにパーソナリゼーションキャンペーンを加える事もできます。以下の例が示すように全てのビジターは、実験Aを見ます。実験BあるいはキャンペーンBが表示されるビジターも居れば、実験Aのみ表示されるビジターも居ます。
排他的グループをパーソナリゼーションキャンペーンに加えれば、キャンペーンのホールドバックは影響を受けることはありません。
2つの相互に排他的な実験が、違うページをターゲットにすると、どの実験をビジターに振り分けるかに関する排他的グループの決断が確固たるものとなります。言い換えれば、もしビジターがサイト上で実験Aに割り振られれば、実験Aはサイト上の"order" page “注文”ページでは実験Bと同じ排他的グループに属され、実験Bを目にすることはありません。
2つの相互に排他的な実験が、違う閲覧者をターゲットにすると、どの実験をビジターに振り分けるかに関する排他的グループの決断が確固たるものとなります。例えば、“カリフォルニア州にいるビジター”と“全てのビジター”の２つの相互排他的閲覧者がいたとします。仮に“カリフォルニア州にいるビジター”が実験Aに属し、実験Aは実験Bと同じ相互排他的グループ属しているとすると、彼らは“すべてのビジター”であるにも関わらずビジターは実験Bを見ることはありません。
これは以下の２つケースと同じです。
２つの相互排他的な実験が異なるページと相互排他的な閲覧者をターゲットにする際
３つの相互排他的な実験が同じページをターゲットとする際
また、"Android ユーザー" と "iPhoneユーザー"のような、相互排他的な閲覧者をターゲットにした２つの相互排他的実験は、どの実験をビジターに振り分けるかに関する決断が確固たるものとなります。しかしながら、もし閲覧者が相互排他的であれば、実験自体に排他的グループを設ける必要がありません。
もし実験が排他的グループ内で行われるならば、排他的グループに割り当てられたトラフィックの割合が100%になります。例えば、排他的グループ１がこれらのトラフィック配分をもった2つの実験を含めるとします。
この設定だと実験Aに割り当てられたトラフィックのうち100％は（トラフィック70%は排他的グループ１に属す）実験Aを見ます。
もし排他的グループから実験やキャンペーンを取り除くのであれば、以前にそれらが割り当てられたビジターは排他的グループから除外されます。これはすなわちビジターが他の実験やキャンペーンを見ないという事を意味しています。しかし、もしその実験やキャンペーンが実装中で、ビジターが条件を見たしているならば、彼らは引き続きそれらを目にすることになります。
もし排他グループに属している実験やキャンペーンを複製するのであれば、新規の実験やキャンペーンはどの排他的グループとも関係性を持つことはありません。
Optimizelyは排他的グループ内での実験やキャンペーンに決定的なトラフィックを割り当てます。これは、もしトラフィックの配分を変更すると、再帰したビジターは変更前に見た実験やキャンペーンと同様のものを目にするという事を意味します。また、新しいビジターには新しいトラフィック配分によって実験やキャンペーンが表示されます。
例えば、２つの排他的グループがあるとすると
ビジターのうち半数には実験A、残りの半数には実験Bが表示されます。
ここで新しく２つの実験を排他的グループに付加し、トラフィックを以下のように配分し直すとします。
トラフィック配分を更新することで、再帰するビジターには最初に見た実験と同じ実験、すなわち実験Aと実験Bが表示されます。彼らは実験Cや実験Dを目にすることはありません。新しいビジターには、ABCDの4つの実験のうちいずれも表示される可能性があります。すなわち25%のビジターは、実験ABCDを見るでしょう。
より精度を高めるために、排他的グループに、すべての実験やキャンペーンを加えたあと、それらを同時に始動させることをおススメします。私たちは実装中の実験やキャンペーンを排他的グループに追加してしまうと、予期せぬ結果を導いてしまいかねません。
JavaScript APと Console logを利用します。
ログの“Group” を確認してください。
グループ実験やキャンペーンのあるページにおけるwindow.optimizely.get('data').groupsからチェックすることも可能です。また、weightDistributionsはシステム対象（あるいはキャンペーンIDｓ）含みます。