Exclusion Groups 排他的グループ機能 の使い方

この場合、サイトに訪問して2つの実験の対象になったビジターは、ひとつだけの実験に出くわした場合と違う行動をとる可能性があります。これを回避できるのが相互排他的な実験です。

Exclusion Groups(排他的グループ機能)を活用すれば、実験Aの対象となったビジターが実験Bの対象になることはありません。そのためノイズを避けることができ、ビジター行動分析の精度が高まります。

目次

1.こんな方におススメ
2.排他的グループの作り方
3.さらに詳しく
3.1.トラフィックの割り当てが100%で行われる重複した実験
3.2.異なるトラフィック割り当てでの重複した実験
3.3.100%トラフィックの割り当てだが、相互排他的な2つの実験とひとつの重複した実験
3.4.割り当てられていないトラフィックも存在する、ひとつの重複した実験と2つの相互実験
3.5.2つの相互排他的グループの実験
3.6.途中停止された実験
3.7.パーソナリゼーションキャンペーンと排他的グループ
3.8.違うページをターゲットにした2つの実験
3.9.相互排他的でないビジターと相互排他的な閲覧者をターゲットにした2つの実験
3.10.異なるトラフィックの割り当て率をもつ2つの実験
3.11.実験とキャンペーンを排他的グループから取り除く
3.12.実験やキャンペーンを排他的グループ内で複製する
3.13.排他的グループ内での実験やキャンペーンのトラフィック配分を変更する
3.14.おすすめの活用法
3.15.Debugging techniques バグの検出
 

こんな方におススメ

  • 同じページで2つの実験を実装している
  • 同じフローで2つの実験を実装している(段階的な決済やフォームなど)
  • 実は同時に行った方が効率がよい2つ実験を実装している(多変量の実験など)

下の図は、2つの実験の関連性を表しています。

ひとつはホームページ上、もう一つは検索結果のページ上での実験です。

  • パターンA、Bを見たビジターが、等しい確率でパターンCかDを見る
  • パターンC、Dを見たビジターが、等しい確率でパターンAかBを見る

イメージ図

すなわち、以下の条件のもとでの実験は重複しづらいということです。

  • 同じサイトでも異なるエリアでの実験
  • 異なるゴールのトラッキング

しかし下記のようなケースでは、相互排他的実験を活用するか、ひとつの実験が完了するまで他の実験の実装を待つことをお勧めします。

  • 同じページで同じゴールを目指して、要素をテストしている場合
  • 同じゴールで同ファネル内の複数ページをテストしている場合

すでに幾つかの企業では、データの統合性を保つべく同時に相互排他的な実験が実装されています。下記のOptimizelyコードを利用すればこの実験を走らせることができます。

*相互排他的な実験は実装に手間がかかり、テストサイクルが長引く可能性があるという点にご留意下さい。

排他的グループの作り方

Optimizelyの XWebによって、複数の実験やキャンペーンの相互排他的の作成が可能です。

イメージ図

1. 実験のダッシュボード Experiments dashboard から排他的グループ Exclusion Groups のタブを開く       

2. 排他グループの作成 Create an Exclusion Groupをクリック                                               

3. 名前をつけ説明を加える 上のデモではアルゴリズムを探すグループ(Search Algorithm Group)と名付けられています。

4. 排他グループの作成を再度クリック

これで完了です。

さらに詳しく

実装に向けて実験のタイプを再確認してみましょう。

まずはレギュラーバージョン重複した実験から。

トラフィックの割り当てが100%で行われる重複した実験

トラフィックの割り当てがそれぞれ100%の2つの実験を実装するとします。ターゲティングの条件を満たしている限り、すべてのビジターにAとB両方の実験が表示されます。

イメージ図

異なるトラフィック割り当てでの重複した実験

重複しているもののトラフィックの割り当てが異なる2つ実験を実装するとします。

  • 実験A: トラフィックの割り当て100%
  • 実験B: トラフィックの割り当て 50%

この例でも、すべてのビジターは実験の対象となります。半数のビジターには実験Aのみが表示され、残りの半数には実験AとBの両方が表示されます。つまりBの実験が全く表示されないビジターもいるということです。

イメージ図

続いて、排他的実験バージョン

100%トラフィックの割り当てだが、相互排他的な2つの実験とひとつの重複した実験

仮に3つの実験を実装し、うち2つが排他的グループに属するとします。

  • 実験A: トラフィック割り当て100%
  • 実験B: トラフィック割り当て50%  排他的グループ1 
  • 実験C: トラフィック割り当て50%  排他的グループ1 

この場合、すべのビジターには共通して実験Aが表示されます。たしかに一部のビジターには実験Bあるいは実験Cも表示されるものの、BとCが重複して表示されることはありません。なぜなら実験Bと実験Cは共通の排他的グループ属しているため、相互に排他的となっているからです。

イメージ図

割り当てられていないトラフィックも存在する、ひとつの重複した実験と2つの相互実験

この例でも3つの実験が実装されますが、2つは相互排他的なものの、相互排他的実験に割り当てられていないトラフィックも存在します。

  • 実験A: トラフィック割り当て100%
  • 実験B: トラフィック割り当て 20% 排他的グループ1
  • 実験 C: トラフィック割り当て50% 排他的グループ1
  • トラフィック割り当て(30%とか) 排他的グループ1は実験Bや実験Cに割り当て無し

またこの場合も全てのビジターには実験Aが表示されるでしょう。実験Bと実験Cは引き続き相互排他的なので、実験Bを見るビジターもいれば実験Cを見るビジターもいます。ただBとCの両方を見る人はいません。しかし、30%のビジターは排他的な実験のどちらにも割り当てられていないので、彼らには実験Aのみが表示されます。

イメージ図

2つの相互排他的グループの実験

さらに、2つの異なる排他的実験を実装するとしますう。

  • 実験A: トラフィック割り当て100%
  • 実験B: トラフィック割り当て20% 排他的グループ1
  • 実験C: トラフィック割り当て 50% 排他的グループ1
  • トラフィック(30%とか): 排他的グループ1実験BにもCにも割り当てられない
  • 実験D: トラフィック割り当て 50% 排他的グループ2
  • 実験E: トラフィック割り当て 50% 排他的グループ2

この例では、すべてのビジターに実験Aが表示され、いくらかのビジターには実験Bや実験Cが表示されるもののBとCの両方をみるビジターはいません。30%のビジターにはBもCも表示されません。

しかし排他的グループ2が存在することによって、さらに他の可能性が生まれます。全てのビジターに実験Dあるいは実験Eが表示されます。しかし、実験Dと実験Cを同時に見るビジターはいません。そのため、3つすべてのレイヤーから実験が表示されるビジターも存在します。(実験A+排他的グループ1と排他的グループ2のいずれかに属する実験)

さらに、排他的グループ1のどちらにも属さないトラフィックも割り当てているので、ビジターが、2つのレイヤーから実験を見る可能性もあります。 

イメージ図

途中停止された実験

実験を停止すると、新しいビジターはそれ以上実験に出くわすことはありません。停止されている間は、実験を既に見たユーザーに再びそれが表示されることはありませんが、引き続きその実験の対象となります。もし実験が再開されれば、実験を既に見ていたユーザーは再びそれを見ることとなり、新しいビジターはまたその実験が割り当てられます。

イメージ図

例えば、あるビジターが実験Cに割り振られたとします。もしここで、実験Cを停止すれば、彼はそれを再び見ることはありません。もし実験が再開され、そのビジターがサイトに返ってきたとしたら、彼らは実験Cをもう一度見ることとなります。

パーソナリゼーションキャンペーンと排他的グループ

さらに、実験とキャンペーンを相互排他的にするために、排他的グループにパーソナリゼーションキャンペーンを加える事もできます。以下の例が示すように全てのビジターは、実験Aを見ます。実験BあるいはキャンペーンBが表示されるビジターも居れば、実験Aのみ表示されるビジターも居ます。

イメージ図

排他的グループをパーソナリゼーションキャンペーンに加えれば、キャンペーンのホールドバックは影響を受けることはありません。

違うページをターゲットにした2つの実験

2つの相互に排他的な実験が、違うページをターゲットにすると、どの実験をビジターに振り分けるかに関する排他的グループの決断が確固たるものとなります。言い換えれば、もしビジターがサイト上で実験Aに割り振られれば、実験Aはサイト上の"order" page “注文”ページでは実験Bと同じ排他的グループに属され、実験Bを目にすることはありません。

相互排他的でないビジターと相互排他的な閲覧者をターゲットにした2つの実験

2つの相互に排他的な実験が、違う閲覧者をターゲットにすると、どの実験をビジターに振り分けるかに関する排他的グループの決断が確固たるものとなります。例えば、“カリフォルニア州にいるビジター”と“全てのビジター”の2つの相互排他的閲覧者がいたとします。仮に“カリフォルニア州にいるビジター”が実験Aに属し、実験Aは実験Bと同じ相互排他的グループ属しているとすると、彼らは“すべてのビジター”であるにも関わらずビジターは実験Bを見ることはありません。

これは以下の2つケースと同じです。

2つの相互排他的な実験が異なるページと相互排他的な閲覧者をターゲットにする際

3つの相互排他的な実験が同じページをターゲットとする際

また、"Android ユーザー" と "iPhoneユーザー"のような、相互排他的な閲覧者をターゲットにした2つの相互排他的実験は、どの実験をビジターに振り分けるかに関する決断が確固たるものとなります。しかしながら、もし閲覧者が相互排他的であれば、実験自体に排他的グループを設ける必要がありません。

異なるトラフィックの割り当て率をもつ2つの実験

もし実験が排他的グループ内で行われるならば、排他的グループに割り当てられたトラフィックの割合が100%になります。例えば、排他的グループ1がこれらのトラフィック配分をもった2つの実験を含めるとします。

  • 実験A: トラフィック配分70%
  • 実験B: トラフィック配分30%

この設定だと実験Aに割り当てられたトラフィックのうち100%は(トラフィック70%は排他的グループ1に属す)実験Aを見ます。

実験とキャンペーンを排他的グループから取り除く

もし排他的グループから実験やキャンペーンを取り除くのであれば、以前にそれらが割り当てられたビジターは排他的グループから除外されます。これはすなわちビジターが他の実験やキャンペーンを見ないという事を意味しています。しかし、もしその実験やキャンペーンが実装中で、ビジターが条件を見たしているならば、彼らは引き続きそれらを目にすることになります。

実験やキャンペーンを排他的グループ内で複製する

もし排他グループに属している実験やキャンペーンを複製するのであれば、新規の実験やキャンペーンはどの排他的グループとも関係性を持つことはありません。

排他的グループ内での実験やキャンペーンのトラフィック配分を変更する

Optimizelyは排他的グループ内での実験やキャンペーンに決定的なトラフィックを割り当てます。これは、もしトラフィックの配分を変更すると、再帰したビジターは変更前に見た実験やキャンペーンと同様のものを目にするという事を意味します。また、新しいビジターには新しいトラフィック配分によって実験やキャンペーンが表示されます。

例えば、2つの排他的グループがあるとすると

  • 実験A: トラフィック配分50% 排他的グループ1
  • 実験B: トラフィック配分 50% 排他的グループ1

ビジターのうち半数には実験A、残りの半数には実験Bが表示されます。

ここで新しく2つの実験を排他的グループに付加し、トラフィックを以下のように配分し直すとします。

  • 実験A: トラフィック配分25%  排他的グループ1
  • 実験B: トラフィック配分25%  排他的グループ1
  • 実験C: トラフィック配分25% 排他的グループ1
  • 実験D:トラフィック配分25%  排他的グループ1

イメージ図

トラフィック配分を更新することで、再帰するビジターには最初に見た実験と同じ実験、すなわち実験Aと実験Bが表示されます。彼らは実験Cや実験Dを目にすることはありません。新しいビジターには、ABCDの4つの実験のうちいずれも表示される可能性があります。すなわち25%のビジターは、実験ABCDを見るでしょう。

イメージ図

おすすめの活用法

より精度を高めるために、排他的グループに、すべての実験やキャンペーンを加えたあと、それらを同時に始動させることをおススメします。私たちは実装中の実験やキャンペーンを排他的グループに追加してしまうと、予期せぬ結果を導いてしまいかねません。

Debugging techniques バグの検出

JavaScript APと Console logを利用します。

?optimizely_log=debug

ログの“Group” を確認してください。

グループ実験やキャンペーンのあるページにおけるwindow.optimizely.get('data').groupsからチェックすることも可能です。また、weightDistributionsはシステム対象(あるいはキャンペーンIDs)含みます。

お問い合わせ

すべてのデバイス、チャンネル、すべてのユーザーとのタッチポイントで
最適な顧客体験を提供できます。