なぜ、A/Aテストは時間の無駄なのでしょう？

この記事のタイトルは、議論を呼ぶものかもしれません。しかし、「行った実験がうまくいっているかどうか確認するため、A/Aテストをすべきでしょうか？」という質問は、大企業からも、中小企業からもよく受ける質問です。

その答えは、あなたを驚かせるかもしれません。

私Craig Sullivanは、2004年からスプリットテストと多変量テストを行っており、その1つ1つを注意深く見守ってきました。私は、有効なテストを行う能力を磨き上げるために、書籍に記載されているあらゆるテストを行い、そして、多くの時間を無駄にしてきました。

この記事では、そんな私の経験からお伝えできることを記載したいと思います。

私は、なにも「A/Aテストは間違っている」と言いたいわけではないのです。私の経験から、「テストを行う際、もっと有効に時間を使うための方法がある」ということなのです。ダイエットに多くの方法があるように、テストを行うための最適な方法が複数あります。

テストを開始する際にはテストの豊富さも重要です。しかし、毎月どのくらいのテストを完了できるのか、そこからどのくらいの有益な情報を得ることができるのか、といったことが最重要なのです。

A/Aテストの実行は、「本当のテスト」に費やすための時間を少なくしてしまいます。

大規模な最適化プログラムにおいて必要なことは、リソースの機会費用（opportunity cost）の比率を下げ、テストの速度とそこから学ぶ機会を確保し、各プロセスから無駄と愚かさと非効率を徹底的に排除することです。

自身のWebサイトで実験を行うことは、主要な空港を利用する多忙な航空会社を運営するようなものです。発着便の枠には上限があり、あなたはそれを効果的に使わなければなりません。

この記事では、下記の項目を取り扱います。

• ・どのような種類のA/Aがあるのか？
• ・A/Aテストを行う理由は？
• ・なぜ、A/Aテストが問題となるのか？
• ・スプリットテストの知られたくない秘密
• ・データを三角測量する
• ・シェフのようにテストを観測する
• ・セグメンテーション
• ・機械学習とまとめ

最もよくある設定は、全く同じテストを50/50の割合で行うことです。そう、元のページと元のページのテストを行うのです。なぜでしょうか？

ここでの考えは、それぞれのバージョンで同じパフォーマンスが得られるかを確認すること、となります。テストの設定自体を検証するのです。テストの対象をそれ自身とテストすることで、データ内に、「シグナルがあるか」ではなく、「ノイズがあるか」を確認するのです。

コイントスを例に挙げると、コインを何回も投げ、表と裏が同じような回数で出るかどうかを確認する、ということです。（手品のタネのように）コインの片方に重みがあれば、コイントスの結果に何らかの偏りが見られることでしょう。

A/Aテストは、テストの設定を検証するためのものです。Webサイトの場合、それぞれの数字が一致するかどうかを確認するために、このテストが行われます。

問題は、通常のスプリットテストを行う時間と同程度の時間が必要になるということです。トラフィックの多いWebサイトにとっては、優れた方法であると思うかもしれません。しかし、私の考えでは、貴重なテストの時間を使い果たしてしまっている、ということになります。

私の経験上、本番のテストに移る前に適切な事前テストを行う方が、はるかに迅速です。こうすることで、A/Aテストの曖昧さが疑われるようなテストにも、自信をもって臨むことができます。

そのためには、なにをすれば良いでしょう？

• ・クロスブラウザのテスト
• ・デバイスのテスト
• ・フレンド＆ファミリー
• ・分析の統合
• ・テストの詳細な観測

これらの方法を採ることで、A/Aテストを行うよりも、はるかに早くテストを行うことができ、私にとっての最適な方法と言えます。A/Aテストを行う代わりに、三角測量されたデータの使用、しっかりとした観測、堅牢なテストの実行、結果に偏見をもたらすフローや互換性の問題の抽出、などを行っています。

フロー、プレゼンテーション、デバイスやブラウザの問題は、A/Bテストにおける、よくあるバイアスの問題として挙げられますが、多くの人が認識していない問題でもあります。

さて、これは何を意味するでしょうか？A/Bテストと同じように見えますが、そうではありません。テストを25%ずつ、4つのサンプルに分割します。そして、そのサンプルにはAとBの重複したセグメントが含まれています。

では、このテストを行うことで、何が解決されるのでしょう？（A/Aテストと同様に）テスト設定の確認と併せて、テスト結果におかしなところがないかを確認します。A/Aテストが検証する内容は前述の通りですが、2つのAと2つのBのサンプルで異なる結果となった場合は、どうなるでしょうか？

それらが完全に一致しない場合、何を意味するでしょうか？気にすることはないでしょう。おそらく、あなたは間違ったもの、つまり、平均値を見ているはずです。

例えば、とあるWebサイトに20人のユーザーが訪問したとします。そして、その内の5人づつが各サンプルに割り当てられたとしましょう。このうち、5人がリピーターであり、彼らが全員同じサンプルに割り当てられたとします。結果はゆがんだものになるでしょうか？その通りです。これこそが、少ないサンプルサイズからインサイトを得るべきではない理由となります。

では、この方法を用いることで得られる知見は何でしょうか？テストの初期の段階やコンバージョン数が少ない場合などでは、サンプルのパフォーマンスは安定しないということです。私は、サンプルの結果が350件、最低でも2つのビジネスサイクル（例：週次）、その他の要因などの条件が満たされない限り、何も信じないようにしています。

この方法を使う際の問題点は、AとBを4つのサンプルに分けたため、ゆがみの影響が顕著になり、有効なサンプルサイズが小さくなる結果、個々のサンプルのエラー率（曖昧さ）が高くなることです。

簡単に言うと、AとBのサンプルを単純に計測するよりも、ゆがみが発生する確率が高くなります。また、サンプルのサイズが小さいため、各回の測定におけるエラー率（+/-）が高くなります。

もし、A/A/A/B/B/Bテストを行った場合、さらにその影響は大きくなるでしょう。問題は、サンプルがいつ安定するかを知ることです。これは数字的な問題ではありますが、テストサンプルの安定性を感じ取ることで、多くのことが可能になります。重要なことは、特定のサンプル（A/A/B/B）でテスト結果が変動するかではなく、訪問者のセグメントがどのように変動するかなのです（この後、説明します）。

Danbarker氏によって提唱されたこの方法は、非常に優れています。（A/Aテストと同様に）テスト設定に関わる問題を特定することができますが、テスト時間はそれほどかかりません。

A/A/B/Bと同様、この方法はサンプルAが2つあり、それぞれのサイズが小さいため、エラー率は高くなります。また、3行の数値を計算することになるため（A/A/B/Bでは4行）、レポートのためのインターフェースが複雑になる傾向があります。

さらに、サンプル数が少ないことが理由で、2つの変数Aが安定するまで、A/Bテストよりも時間がかかります。ここでも、時間と検証のトレードオフが課題となります。私は、どちらも取りたくありません。

こうした検証を本当に行いたいのであれば、Danbarker氏が提唱する方法が最適だと思いますが、私はさらに良い方法があると考えています。それは、セグメンテーションです。

「統計的な良い慣習である」や「テストを適切に行う証」であると見なされることがあり、それが理由と言えるでしょう。

また、本番前の予行練習を行うことは、テストの実行において、クリーンな方法であると見なされることもあります。私は、運転中に車を修理することのほうが（ライブテスト）、ガレージに停車しているときに修理するよりも（QA：品質保証)、コストは高くなると感じています。

私にとっては、あらゆるテストから問題を取り除くことが最優先事項であり、A/AテストはQAのように、テストの不備を特定することはできません。もし、開発者が後に行われるテストで再度利用できるような、複雑なコードを組み込んでいるのであれば、A/Aテストを行う価値はあるかもしれません。ただし、あらゆる機会にA/Aテストを行うことは、推奨しません。

問題は、A/Aテストの際、テストの実行時間を事前にロードする必要があるため、トラフィックとテスト時間を常に費やしてしまうことです。月間で40個のテストを行っているとすれば、ものごとを進めるための能力が損なわれてしまうでしょう。2〜4週間をかけてA/Aテストを実行するのであれば、半日かけてQAテストを行うほうが良いと考えています。

もう1つの問題として、80％近くのA/Aテストが、ある時点で、有意に達するということです。言い換えると、このテストシステムは、信頼性の高いオリジナルよりも、オリジナルのほうが優れている、と結論づけることになるのです。

なぜでしょう？数とサンプリングの問題でもありますが、テストを読み違えていることが理由です。サンプルサイズが小さい場合、実際は問題が無いにもかかわらず、問題があると判断してしまうことはよくあります。

さらに別の問題として、A/Aテストを行う場合、同一のもののパフォーマンスを比較することになる、とうことが挙げられます。A/Bテストと比較し、有意な偏りがないと証明するために、より多くのサンプルとデータが必要になります。

コカ・コーラのブラインドテスト（テスト対象はコカ・コーラ）で、同じくらい好まれていると結論づけるまでに、どのくらいの人数が必要になるでしょうか？500人？それとも、5,000人？

これが、スプリットテストにおいて、非常に似ているもの同士をテストしない理由となります。差益を得るのは非常に困難であり、同一のもの同士をテストする場合、これはさらに顕著になります。A/AテストをA/Bテストよりも長く行う、といったことも起こりえます。そして、テストが成功したのか、失敗したのかを判断することはできず、また、サンプリングを正しく理解するための価値のあるインサイトを得ることもできません。

A/Aテストを実行する人は、テストの実行における別のバイアスを忘れてしまうことがあります。良い例として、「遅いコンバーター」と「新奇性効果（Novelty Effect）」が挙げられます。

テスト期間が2週間で、平均購入サイクルが4週間である場合、テストを終了する際、実験のための訪問者を何人かカットすることになります。このように、「早いコンバーター」のみを対象としたA/Bテストを実行してしまう可能性があるため、コンバージョンに至るまでの購入サイクルを知ることは重要なのです。

（私も同意見ですが）Ton Wesseling氏は、新しい訪問者に対する実験を「閉じる」際、実験を続行中のままにしておくべきと推奨しています。このようにすると、コンバージョンの途中の訪問者も実験を見続けることになり、テストの完了後に、コンバージョンすることができます。これは、テストの参加者にシステムを体験させ、新しい訪問者に見せることなく、サンプルを追加することができる方法なのです。

購入サイクルを理解することによって、テストサイクルの終盤を最適化することができるのであれば、テストの開始時にも何らかのバイアスがあるのでしょうか？

1つは、「平均への回帰」と呼ばれ、あらゆる種類のテストで見られるものです。もう1つは、新奇性効果と呼ばれるものです。

例えば、ジェームスという客は、4週間前からとあるWebサイトを訪問しており、ほぼ、商品を購入する気でいます。その間、彼は古い商品のページを見ていることになります。コンバージョン前の最後の訪問で、彼は非常に魅力的な新商品のページを見ました。このページは、彼の購入の判断に影響を与えました。一方、あなたの友人のボブは、4週間、同じページを見続けました。ジェームスとは異なり、ボブには古い商品のページ（コントロール）を表示しました。

これは、実験に参加する新しいメンバーは、「古い」訪問者も含まれていることを意味し、彼らはライフサイクルの後半にいるということになります。この、新奇性による影響は、少なくともサイクルのいくつかが実験中に消化されるまで、テストの序盤におけるバイアスとなりえます。理論上、テストは数週間早く開始されるべきであり、全ての訪問客にクッキーを付与します。そうすることで、新規の訪問客のみを実験に参加させることができ、購入サイクルの後半で新奇性効果による影響を受けた訪問者を排除することができます。

この2つの例を挙げた理由は、スプリットテストにはバイアスとなりうる要素が多く存在する、ということを示すためです。A/Aテストを行うことで、大きなバイアスを発見できるかもしれません。しかし、非効率であり、QA、分析の統合、セグメンテーションなどができることの全てに答えを出してくれるわけではないのです。

私がテストしたあらゆるビジネスには、固有のパターン、ランダム性、サイクルがあり、それが楽しみの1つでもあります。実行中のWebサイトやテストデータを観測し、そこから得られることは、私にとっての大きな楽しみです。しかし、テストには知られざる秘密があります。それは、1月に見られた上昇は、今後、2度と発生しないかもしれない、ということです。

なぜでしょうか？PPCの予算をカットした影響で、リード数が緩やかに減少しているかもしれません。もしくは、以前はあなたが作成したクリエイティブに良い反応を示してくれた人をないがしろにするような、テレビ広告を放映しているかもしれません。

あなたが思っている以上のパフォーマンスを出しているかもしれませんが、実際にそれを知ることはできないのです。

これは、スプリットテストにおける、「シュレーディンガーの猫」と言えます。つまり、同様の上昇を見せているかどうかは、テストを再度行わない限り、わかることはないのです。これは、ダイナミックテストというよりも、シーケンシャルテストの問題です。変化を起こし続けなければならず、かつて行った実験で見られた上昇が、現在も続いているのかどうかはわかりません。

私は、クリエイティブのパフォーマンスが安定しないという事実を避ける目的で、古いコントロール（敗者）と新しいバリエーション（勝者）を追跡するため、古いスタブ（5〜10%程度）をテストが終了してから数週間は稼働させたままにします。

CFOがこの数字に疑問を持った場合、スタブを稼働させたままにしておくと、古いクリエイティブが出していたであろうパフォーマンス以上の数字が出せていることを示すことができるからです。この方法は、少なくとも、新しいツールを導入することに反対の意見を持つ相手に対しては、非常に有効な方法でした。

しかし、継続的にテストと改善を繰り返していれば、クリエイティブの変化についてのあらゆる不安は、より学術的なものとなります。なぜなら、あなたは少しの改善や大きな飛躍を継続することになるからです。

問題は、何かをテストし、それで完了、としてしまうことにあります。これが理由で、私が関わったページの中には、4年間もテストを継続しているものがあります。時間が経過したとしても、継続的な改善は求められるのです。

Google Content Experiments（Google Analyticsの機能の1つ）やConductricsのような製品は、当時と現在のクリエイティブの明らかな差異を回避するための、多腕バンディットアルゴリズムを提供しています（訪問者の行動の反応に合わせ、表示内容を変化させます）。

2016年頃、私はこのようなツールが必要とされていると考えていました。ウェブデータ、訪問履歴、バックエンドのデータなどを動的にマイニングし、パーソナライズされた動的なスプリットテストを提供するシステムです。顧客属性、ターゲティング、広告、レコメンデーション、パーソナライゼーション、スプリットテストなどを全て管理し、誰に、いつ、何を見せればよいのかを知ることができます。このようなシステムが自身で調整できるようになれば、それは、私にとってのテストの未来となります。

[参考記事：Multi Armed bandits]

テストの設定状況や実行に係る問題を回避するためには、少なくとも2つの分析ソースを実行することが、非常に役に立ちます。スプリットテストのソフトウェアの能力を最大限活かし、最低でも2つ目の分析パッケージと統合するようにしましょう。

これを行うことで、2つのパフォーマンスデータのソースを持つことになり、それぞれを三角測量したり、クロスチェックを行うことができます。もし、これらが比例的に並んでいなかったり、アナリストの視点からはバイアスに見えたりした場合、テストを開始する前にレポーティングの問題を発見できたことになります。私は、A/Bテストのパッケージがサイトの分析結果と一致しないという問題に、何回も出会ってきました。そしてそれは、常に、開発者側とテスト設定側の問題でした。1つの実験指標を単純に信用することはできません。何かを破損させてしまうことに備え、比較のために用いるバックアップが必要なのです。

データを無くしてしまい後で泣きを見るべきではありません。そうしたことが起こらないよう、全力を尽くすのです。また、テストを開始する際には、ベルトとブレースのモニタリングシステムとしての効果も期待できます。つまり、データの測定と監視を続けることができるのです。

[参考記事： How to Analyze Your A/B Test Results with Google Analytics]

あなたは、シェフが腕を振るって料理を作るのと同じように、テストに臨まなければなりません。仕込みを行い、料理をし、完成に至るのと同様に、常に目を向け、味を確かめ、確認し、かき混ぜ、また確認するのです。これは、私が多くのテストを集中して見続けたことで得た、大きな気づきです。そこで何が起こっているのか、何が間違っているのか、それらをより良く感じられるようになります。

ときには、1週間のうち、何百回もテストを見ることもあります。変動、パターン、結果が出る状況などの様子を感じ取るためです。テストサイクルの初期の段階で描かれる、きれいなグラフによる誘惑に、あなたは耐える必要があります。

ビジネスサイクル（例：1週間）が1未満であった場合、その結果は無視しましょう。各サンプルが350未満の場合、その結果は無視しましょう。サンプルがまだ不安定な場合、その結果は無視しましょう。これらの状況は皆、まだ調理されていない状態なのです。

しっかりとしたテストの経験があれば、データとレスポンスは常に変化する、ということを理解しているはずです。ランダムな訪問者がWebサイトにアクセスし、クリエイティブを見ることで、あなたが見ているデータの精度や性質が常に変化してしまうのです。

テストのためのWebサイトの平均値における大きな問題は、平均値の内側、つまりセグメントを見ることはできない、ということです。パフォーマンスが低いと決定づけられた実験でも、再訪問者にとっては大きな効果があったかもしれません。セグメントを見ないということは、このような気づきを得る機会を逃していることを意味しています。

（Google Analyticsのカスタム変数のように）分析ツールとの連携を行うことで、クリエイティブレベルのパフォーマンスをセグメント化することができます。ここで注意すべきことは、サンプルを分割するとセグメントが小さくなってしまう、ということです。

AとBのクリエイティブがあった場合、それらをテニスコートに置かれた、2つの大きな黄色いスペースのあるホッパーと想像してください。あなたは観客席に座っており、それらがどのくらい離れているかを測ろうとします。その空間は確固たるものではなく、中心がどこにあるのかがわからないほど、不鮮明な空間です。

テストが進むにつれ、そのホッパーのスペースの位置とサイズが縮んでいきます。そして、それらの位置や高さの違いなどがわかるようになります。テニスボールくらいのサイズになると、正確な位置がわかり、その距離も正確に測ることができます。

AとBの結果をセグメントに分割する場合、そのデータの不鮮明さが増していきます。そのため、サンプルサイズが小さくなりすぎないように分割してください。もしくは、コンバージョン数や結果の数が小さい場合にデータが伝えるものについて、注意を払ってください。

それ以外では、セグメンテーションは、A/Bスプリットテストについて、あらゆるサンプル分割以上のことを伝えてくれるでしょう。なぜなら、数字の不鮮明さだけではなく、訪問者についての既知の属性のレベルにおいて、より良く機能するからです。テストが失敗したとしても、何らかの気づきを得ることはできるはずです。私は常にセグメントを確認し、平均値を動かしたものを特定します。こうすることで、私が立てた仮説だけでなく、異なるグループがどのように私の実験に反応したかについて、重要な気づきを得ることができるのです。

そして、これが最重要事項ですが、オリジナルと「ほとんど同じ」結果が出た場合、セグメントレベルでのドライバーがあることが示されます。これは、あなたにとって非常に興味深いものであるはずです。平均値は、「ほとんど同じ」という結果になるかもしれません。しかし、セグメントレベルの反応は、有益な気づきが含まれている可能性が高いのです。

スプリットテストは、将来的に、自動化されるのでしょうか？私は、そうなると考えています。テストツールは、「平均的な」訪問者のパフォーマンスを引き上げるのではなく、よりパーソナライズされ、セグメント基軸のテストに役立つようになるはずです。また、パーソナライゼーション、ターゲティング、スプリットテスト、多変量テストなど、「人に何かを試す」ような実験のためのツールは不要になるはずです。

ツールは、私が行える実験の領域の拡大を助けてくれるだけになるでしょう。ちょうど、耕運機からトラクターに乗り換えるように。 テストのための人手が不要になるとは思いません。ただ、手作業ではカバーしきれないほどの規模で、実験が行えるようになるのです。

問題を回避するための一番の方法はなんでしょうか？テストを注意深く観測し、セグメント化することが有効でしょう。また、QAに割く時間は、4週間後にデータを破棄するという結果になるような苦悩に比べれば、賢い投資であると言うことができるでしょう。