同時実験を実行する必要がありますか? 矛盾する結果を避けるためのガイド

最適化の世界では、同時実験を実行するかどうかについていくつかの議論があります。 A/B テストを同時に実行すると、結果が曖昧になり、不正確なデータが生成されると考える人もいます。 Web サイトのさまざまなページで A/B エクスペリエンスを同時に実行すると、より多くのことをテストし、成功する戦略をより迅速に特定するのに役立つと主張する人もいます。

それで、どれが正しいですか？

このブログ投稿では、同時実験の利点と欠点を探り、最適化プログラムに最適なアプローチを決定するのに役立ちます。

このブログ記事を読むと、次の質問に答えることができます。

• 分割 URL エクスペリエンスを同時に実行できますか?
• A/B エクスペリエンスを同時に実行できますか?
• A/A エクスペリエンスと A/B エクスペリエンスを同時に実行できますか?

簡単な答えはイエスです。単一のページまたは一連のページで複数のエクスペリエンスを同時に実行できます。 ただし、あるエクスペリエンスのバケット化は、同時に発生する別のエクスペリエンスのデータに影響を与える可能性があることに注意してください。

経験の重複はどのように発生し、心配する必要がありますか?

同時実験を実行する際に留意すべき点が 1 つあります。 場合によっては、2 つの変更が相互に作用し、組み合わせた場合と単独の場合で動作に異なる影響が生じることがあります。 これは、実験が同じページ、同じユーザー フローなどで実行される場合に発生する可能性があります。

経験の重複が発生する可能性がある場所と、それが問題と見なされるべきかどうかの例をいくつか見てみましょう。

同じ要素のテスト

商品ページのデザインを変更して、無料返品ポリシーや無料配送などの特典機能を強調することは、実行できる A/B テストの一例です。

お客様の 1 人が、まさにこのシナリオをテストしました。 顧客サービス部門からのデータに基づいて、彼らは、この機能が製品ページで十分に表示されていなかったため、顧客がブランドの無料返品ポリシーを認識していなかったという仮説を立てました. 次に、A/B テストを実行して機能をより際立たせ、顧客の反応を測定しました。

元のバージョンとバリエーションは次のようになります。

ただし、すべての製品ページに変更が適用されるわけではないため、テストの実装はもう少し複雑でした。 一部の製品は無料返品の対象外で、特定のセール品は変更できませんでした。これらの理由から、彼らは別の A/B エクスペリエンスを並行して実行し、同じ要素を変更して免責事項のコピーを多くの製品に追加することにしました。これらのページには「アイテムは返品不可です」と書かれています。

ご覧のとおり、2 つの A/B エクスペリエンスは同じ Web サイト要素に影響を与えているため、結果にある種の重複が生じており、明確な結論を導き出すことが困難になっています。

同じページでのテスト

A/B エクスペリエンスのもう 1 つの例は、当社の顧客が製品ページを最適化して、訪問者数を増やしたときです。

製品ページの各要素を分析し、目標コンバージョンを追跡したところ、メイン ナビゲーション バーのリンク、特に「今すぐ購入」が最も多くクリックされていることがわかりました。 当社のお客様は、ホームページ上で放浪するのではなく、より質の高いトラフィックをカテゴリ ページに送ることの重要性を認識していました。

その結果、顧客は「今すぐ購入」セクションを「スーパーセーバー」や「バザー」などの他のカテゴリに置き換えることにしました。 さらに、「Shop Now」セクションをサイトの左側に移動して、ページをより視覚的に魅力的にし、資格のある訪問者を引き付けました。

これは、製品ページが最初にどのように見えたかです。

その間、製品ページで別の A/B 実験が行われ、「今すぐ購入」ボタンの色を変えるとコンバージョンが向上するかどうかが判断されました。

これら 2 つの A/B エクスペリエンスは同じページの同じ要素に影響を与えるため、結果に重複が生じることは避けられません。

同じファネル/フローに参加しているユーザーのテスト

同じ目標到達プロセスに参加しているユーザーをテストするときにも、エクスペリエンスの重複が発生する可能性があります。 ほとんどの Web サイトは、複数のファネルを通じてコン​​バージョンを促進します。 主な焦点は購入にあるかもしれませんが、アカウントの作成または獲得もビジネスの重要な原動力になる可能性があります。

製品ページでエクスペリエンスを実行すると、購入コンバージョンに影響を与える可能性があります。 ただし、アカウント作成ページでフォーム レイアウトをテストすると、目標到達プロセスの改善に役立ちます。 獲得テストには、トラフィックをサイトに誘導することから、マーケティング目的で電子メール アドレスを収集することまで、すべてが含まれます。

Web サイトの同じページでエクスペリエンスが重複すると、バグが発生する可能性があります。 エクスペリエンスの目標が同じ目標到達プロセスと一致している場合、結果は影響を受ける可能性があります。

より多くの完了したサインアップを取得しようとしているとしましょう。 サイトにアクセスすると、ユーザーは登録を求められます。

サインアップのコンバージョン ファネルを設定するには、次のイベントを追跡できます。

• サインアップ時のユーザー数
• 完了したサインアップの数
• ホームページ画面読み込み数

次に、次の変更をテストすることで、目標到達プロセスを改善する方法についていくつかの仮説を立てることができます。

1. サインアップ プロセスにオンボーディングを追加する
2. 登録フォームを短くして、より使いやすくする
3. サインアップを完全に削除する

ただし、この場合、A/B エクスペリエンスは同じ目標到達プロセスに影響を与えるため、A/B テストから変更の正確な影響を判断することはできません。したがって、それらの結果には重複があります。

サイト全体のエクスペリエンスの実行

すべてのページに表示される要素を試す必要がある場合があります。 たとえば、フッターの行動を促すフレーズの色やフォント サイズを変更して、コンバージョン数を確認したいとします。

このプロセスは、Convert で簡単に実装できます。すべてのページをターゲティングに追加するだけです。

それで全部です！

ただし、サイト全体のターゲティングは、それらのページで実行されている他の A​​/B テストに影響を与えるため、エクスペリエンスが重複します。

同じオーディエンス/訪問者のテスト

次のケース スタディを検討してください。e コマース システムの 2 つの側面を評価する必要があるため、モバイル ユーザーとデスクトップ ユーザー用に 2 つの A/B テストを作成します。

1. 「カートに入れる」ボタンを青ではなく赤にすると、クリック数が増えるかどうかを確認しようとしています。
2. あなたは、ステップ数を 5 から 2 に削減する新しいチェックアウト プロセスを試して、より多くのサインアップが得られるかどうかを確認しています。

両方のアクションが同じ成功イベント (トランザクションの完了) につながる場合、デスクトップとモバイル デバイスで赤いボタンがコンバージョンを押し上げたのか、それともより良いチェックアウト エクスペリエンスがコンバージョンを押し上げたのかを判断するのは難しい場合があります。

結果の重複やその他のエクスペリエンス配信の問題を回避するには、上記のテストをさまざまな対象ユーザー (モバイルのみまたはデスクトップのみなど) で実行する必要があります。

セグメンテーション テストの唯一の欠点は、トラフィック数が少なくなることです。これは、テストの実行に必要な時間に影響を与える可能性があります。 ただし、これはパーソナライゼーション手法に基づいているため、A/B テストの際にエクスペリエンスの重複を回避するための推奨される方法です。 セグメントを慎重に選択すると、エクスペリエンス全体への影響が最小限に抑えられます。

他のエクスペリエンスと共有される目標に重大な影響を与える可能性のあるエクスペリエンスを実行する

言うまでもなく、テスト全体で目標が類似している場合、結果はこの個々の目標に集中します。 それぞれの経験がその目的を達成するためには、それぞれの目標が互いに矛盾してはなりません。

テストを成功させるための戦略

オーバーラップしないテストの実行に関しては、万能のソリューションはありません。 実験の旅の各段階を進むにつれて、ニーズによって進行方法が決まります。

十分な情報に基づいた決定を下すために、重複に対処するために使用できる最も一般的な戦略について見ていきましょう。

1. 重なりのない同時体験 (孤立)

通常、最も単純な戦略は、これまで使用してきた戦略であり、同時に実行される分離されたエクスペリエンスです。

上で説明したように、孤立した経験には重複がなく、ある経験の結果が別の経験の結果に影響することはありません。

次のケースでは、この戦略が必要です。

• オーバーラップが技術的に不可能な場合: 上記の可能なオーバーラップの組み合わせをすべて除外する方法でテストしている場合。
• ユーザー エクスペリエンスが損なわれる可能性がある場合: エクスペリエンスの組み合わせによってはユーザー エクスペリエンスが損なわれる可能性があるため、これらのエクスペリエンスは個別に実行する必要があります。
• 主な目標が正確な指標であり、孤立した実験のみが意味をなす場合。

このような場合、2 つの異なる目標を持つ 2 つの異なるページで 2 つのエクスペリエンスを同時に実行しても、1 つのエクスペリエンスが他のエクスペリエンスに影響を与えることはありません。 体験 1 に参加する訪問者は、体験 2 には参加しません。その逆も同様です。

上記のケースを超えて、効率の観点から、同時に分離されたレーンでエクスペリエンスを実行することは意味がありません。 別々のレーンで 2 つのエクスペリエンスを実行すると、任意の数のユーザーまたはセッションに対して、それらを次々に実行するのと同じ時間がかかります。 毎月 10,000 人のユーザーがいて、2 つのエクスペリエンスを実行する必要があり、それぞれに 5,000 人が必要な場合でも、エクスペリエンスを完了するのに 1 か月かかります。

さらに、この戦略には明らかな欠点があります。孤立したレーンでエクスペリエンスを実行すると、バリエーション間の潜在的な相互作用を調査することが間違いなく妨げられます。

別のテスト レーンがあれば、デスクトップ ユーザーとモバイル ユーザーの両方が勝者のバリエーションを利用できるようにする前に、デスクトップ ユーザーで実験を行うのと同じです。 モバイル ユーザーへの影響はデスクトップ ユーザーへの影響と同じかもしれませんが、かなりの違いが生じる可能性もあります。

2. 非同時（連続）体験

エクスペリエンスの重複を避ける方法がない場合は、シーケンシャル エクスペリエンスの使用を検討する必要があります。 これは、別のエクスペリエンスと重複する可能性がある各エクスペリエンスを順番に実行する必要があることを意味します。

「開始済み/計画済み」および「停止済み」列の変換を使用して、一連のテストを可視化できます。

この戦略は、優先順位付けのロードマップを使用してさらに効果的にすることができます。

PIE と ICE フレームワークは、チームのエクスペリエンスに優先順位を付けるための 2 つの効果的なオプションです。

PIE フレームワーク (Widerfunnel によって開発された) は、可能性、重要性、および容易さの 3 つの基準に基づいてテストをランク付けする一般的な優先順位付け方法です。 PIE スコアを使用すると、これらの各基準の平均スコアに基づいて各テストをランク付けし、優先順位を付けることができます。

Impact, Confidence, and Ease (ICE) モデル (Growthhackers の Sean Ellis によって開発された) は、PIE と非常によく似ていますが、「可能性」の代わりに信頼係数を使用します。

ロードマップがないと、トラフィックとリソースを最大限に活用する能力が制限されます。

たとえば、次々と実装しなければならないホームページのアイデアが、意図せずに溜まってしまう可能性があります。 このボトルネックが続くと、Web サイトの他の部分を同時にテストすることができず、待機ゲームを余儀なくされる可能性があります。 または、オーバーラップの可能性を考慮せずに複数のテストを同時に実行すると、疑わしい結果が生じる可能性があります。

3. オーバーラップによる同時体験

あなたの経験を分析した後、あなたはそれらが重複していると結論付けました。 したがって、それらを分離する必要があります。 どうやってそれをしますか？ それは簡単です！ 最初のテストを実行してから、2 番目のテストを実行しますよね? 順次セクションでは、これがどのように機能するかを説明します。

ただし、何らかの理由で、より多くの訪問者が訪れ、エクスペリエンスがより大きな影響を与える可能性があるため、クリスマス期間またはホリデー シーズン中にいくつかのテストを実行したいとします。 じゃあ何？ すべての経験を次々と実行できますか? 明らかに、いいえ。

以下の戦略を使用して、オーバーラップを心配することなく、エクスペリエンスを同時に実行できます。

を。 A/B/N エクスペリエンス

このカテゴリの最初の戦略は A/B/N テストです。これには、一度に 2 つ以上のバリエーションをテストすることが含まれます。 A/B/N は 3 番目のバリエーションを指すのではなく、A/B/C、A/B/C/D、およびその他の拡張 A/B テストなど、任意の数の追加バリエーションを指します。

A/B/N テストの原則は、追加のバリエーションの数に関係なく同じままです。ユーザーをグループに分割し、バリエーション (通常はランディング ページまたは他の Web ページ) をグループに割り当て、主要な指標 (通常はコンバージョン率) の変化を監視します。 ）、経験結果の統計的有意性を調べ、勝者のバリエーションを展開します。

ただし、あまりにも多くのバリエーションを試すと (1 つしか選択できない場合)、Web サイトへのトラフィックがさらに分割される可能性があります。 したがって、統計的に有意な結果を得るために必要な時間とトラフィックの量が増加し、「統計的ノイズ」が発生する可能性があります。

複数の A/B/N 実験を実行するときは、全体像を見失わないようにすることも重要です。 異なる変数が実験で最高の結果を示したからといって、それらが一緒にうまく機能するという保証はありません。

このような場合は、多変量テストを実行してすべてのバリエーションをテストし、改善が最上位のメトリックまで確実に実行されるようにすることを検討してください。

b. 多変量エクスペリエンス (MVT): 1 つのテストで多くのエクスペリエンスを組み合わせる

多変量エクスペリエンス (MVT) は、さまざまな変更の多数の組み合わせを一度に実行します。

考えられるすべての組み合わせの中で、どの要素が目標に最も大きな影響を与えるかを判断するには、同じページで多くの要素を同時に変更する必要があります。

A/B/N テストとは異なり、多変量テストでは、変更のどの組み合わせが訪問者の要求に最も適しているかを判断できます。 多変量テストを使用すると、複数の変数が変更されたときにどの変数の組み合わせが最も効果的かを判断できます。

たとえば、ページで 2 つの異なる見出し、2 つの画像、および 2 つのボタンの色をテストする場合、MVT テストは次のようになります。

上記の MVT テストでは、さまざまな要素 (見出し、色、画像) をさまざまな組み合わせで同時にテストします。

Convert Experiences で MVT を設定する方法

まず、Convert アカウントの [エクスペリエンス] タブから、[新しいエクスペリエンス] を選択します。

これで、体験に名前を付けることができます。 「My first MVT」を使用して、多変量オプションを選択し、[続行] をクリックします。

MVT にはセクションとバリエーションがあります。 セクションは、1 つまたは複数のバリエーションをテストするページ上の場所です。

セクションの例を次に示します。

• ロゴ
• 見出し
• 第一段落
• オプトインフォーム

次のように構成された (これらのセクションの) バリエーションもあります。

• セクション: ロゴ
  
  
  • オリジナルロゴ
  • バリエーション 1) ロゴ左
  • バリエーション 2) ロゴ右

• セクション: 見出し
  
  
  • 元の見出し
  • バリエーション 1) 見出し「Search Now My Friend」
  • バリエーション 2) 見出し「Give Search A Go」
• セクション: 最初の段落
  
  
  • 元の最初の段落
  • バリエーション 1) 最初の段落「赤」
  • バリエーション 2) 最初の段落「青」
• セクション: オプトインフォーム
  
  
  • 元のオプトイン フォーム
  • バリエーション 1) ラストネーム フィールドを追加したオプトイン フォーム
  • バリエーション 2) チェックボックス「ホワイトペーパー」のあるオプトイン フォーム
  • バリエーション 3) オプトイン フォーム フローティング 左
  • バリエーション 4) オプトインフォーム「女性の顔」

Convert Visual Editor で上記の構造がどのように表示されるかを次に示します。

テストするページの URL がビジュアル エディターに読み込まれます。 その後、最初のバリエーションを編集できます。 コンテンツの変更は、オレンジ色の強調表示された領域をクリックするだけです。 バリエーション名の横にある緑色のプラス記号をクリックすると、新しいバリエーションを追加できます。

たとえば、次のことができます。

• 変更する要素をクリックします (要素はオレンジ色の境界線で強調表示されます)
• 画像ソースの変更など、メニューでアクションを選択します

MVT エクスペリエンスの概要は次のようになります。

ただし、MVT にはいくつかの制限があります。

最初の制限は、多変量エクスペリエンスの調査結果を統計的に有意にするために必要な訪問者数に関連しています。

多変量テストで変数の数を増やすと、多くのバリエーションが生じる可能性があります。 トラフィックの 50% が元のバージョンに割り当てられ、50% がバリエーションに割り当てられる標準的な A/B テストとは対照的に、多変量テストではトラフィックの 5、10、または 15% のみが各組み合わせに割り当てられます。 実際には、これによりテスト期間が長くなり、意思決定に必要な統計的有意性を達成できなくなります。

もう 1 つの制限は、MVT の複雑さです。 多くの場合、A/B テストは、多変量テストよりも設定と分析が簡単です。 基本的な多変量テストを作成するだけでも時間がかかり、簡単に問題が発生します。 エクスペリエンスの設計に小さな欠陥が現れるまで、数週間または数か月かかる場合があります。

さまざまな Web サイトでさまざまな種類のテストを実行した経験があまりない場合は、多変量テストを考慮する必要さえありません。 私がカバーしている次の戦略、相互に排他的なエクスペリエンスを使用したほうがよいかもしれません。

c. 相互に排他的な体験

相互に排他的であることを確認することで、オーバーラップのあるエクスペリエンスを同時に実行することもできます。 A/B テスト プラットフォームによっては、相互に排他的なエクスペリエンスを作成できる場合があることに注意してください。 基本的に、エクスペリエンスが実行されているのと同じ数のグループにトラフィックを分割し、各グループが 1 つのエクスペリエンスだけに参加するようにする必要があります。

Convert は相互排他性を可能にします。以下では、エクスペリエンス A を表示する訪問者がエクスペリエンス B を表示しないように構成する方法を示します。

エクスペリエンスが実行される順序:

これを設定するための最初のステップは、Convert エクスペリエンスがどのように実行されるかを理解することです。 エクスペリエンス条件は、エクスペリエンス ID を考慮して、ページ上で順番に評価されます。

ID が最も小さいエクスペリエンスが最初に評価され、すべての条件が満たされると、新しいエクスペリエンスが開始されます。 したがって、以下のスクリーンショットでは、ID 100243925 のエクスペリエンスが最初に実行され、残りが続きます。

相互に排他的な 2 つのエクスペリエンス

2 つのエクスペリエンスを同時に実行していて、それらを相互に排他的にしたい場合は、次の手順に従う必要があります。

1. 最初のエクスペリエンスでトラフィック分布を 100% 未満に設定する

最小 ID のエクスペリエンスを設定して、トラフィックの 100% 未満を使用します。 これは、エクスペリエンスの概要の [トラフィック分布] セクションで行うことができます。

2. 2回目の体験で「体験にバケツなし」の視聴条件を設定

そして、2回目の体験では、「体験にバケツはNo」の視聴条件を設定。 これは、新しいオーディエンスを追加すると見つかります ([訪問者データ] の下)。 この条件は、訪問者が以前にテストされていない場合にのみテストされることを意味します。 これにより、同じ訪問者が 2 回テストされるのを防ぐことができます。

多くの相互に排他的な経験

相互に排他的である必要があるエクスペリエンスが 2 つ以上ある場合は、次の手順に従います。

1. すべてのエクスペリエンスのトラフィック分布を 100% 未満に設定します

100% 未満のトラフィックのみを使用するように、すべての並列エクスペリエンスを設定します。 これは、エクスペリエンスの概要の [トラフィック分布] セクションで行うことができます。

2. 訪問者の Cookie に基づいてアドバンス オーディエンスを設定する

次に、ID が最も小さいエクスペリエンスを除くすべてのエクスペリエンスで、訪問者の Cookie に基づく高度な対象ユーザーを使用して、他の並行エクスペリエンスに含まれていた訪問者を除外します。

たとえば、次の 4 つのエクスペリエンスがあるとします。

1. ID 123456 のエクスペリエンス A、トラフィック分散 80%
2. ID 123457 のエクスペリエンス B、トラフィック分散 50%
3. ID 123458 のエクスペリエンス C、トラフィック分散 30%
4. ID 123459 の経験 D、トラフィック分布 75%

エクスペリエンス B には、次の高度な対象者が必要です。

エクスペリエンス C には、次の高度な対象者が必要です。

そして最後に、エクスペリエンス D には次の高度な対象者が必要です。

上記のように、Cookie の値は次のようにフォーマットされます。

xxxxxx.{v.1-

これは、100% 未満のトラフィックで構成されたエクスペリエンスに含まれていた訪問者を除外しようとしている場合、訪問者がサイト エリアとオーディエンスの条件を満たしている場合でも Cookie が書き込まれますが、トラフィックの分布が原因で、訪問者はそうではなかったために発生します。その経験に含まれています。

Convert Cookie _conv_v は次のようになります。

exp:{12345678.{v.1-g.{}}}

上記の形式では、訪問者がエクスペリエンスに含まれていないため、バリエーション値はなく、v.1 のみであることに注意してください。 ただし、訪問者が次回ページにアクセスしたときに、同じエクスペリエンスから再び除外されるように、Cookie を使用してこれを追跡します。

結論

複数のエクスペリエンスを同時に実行すると、いくつかの複雑さが生じます。どのテストがコンバージョンを増加させるか、またはそれらの間に隠れた相互作用があるかどうかは常にわかりません。 ただし、これらの複雑さを軽減するための戦略があるため、これは大きな問題ではありません。

複数のテストを同時に実行することによって引き起こされる問題に対処するための 5 つの戦略について説明しました。

1. エクスペリエンスが互いに重複しない場合に同時に実行する
2. エクスペリエンスの重複が避けられない場合に、エクスペリエンスを順番に実行する
3. A/B/N エクスペリエンスの実行
4. MVT テストの実行
5. 相互に排他的なエクスペリエンスを実行する

また、Convert が上記のすべてのテスト戦略をサポートし、非常に用途の広いツールであることも示しました。

A/B テストを実行するときは、これらすべての複雑さを考慮に入れることが重要です。そうすれば、あらゆる場合に最適な戦略を選択できます。 ご不明な点がございましたら、お気軽にお問い合わせください。