A/Bテストでいちばん大切なこと
「A/Bテスト」が、Webサービスの最適化技法として人口に膾炙して久しい昨今ですが、それでもなお、個々の施策実行時にはいろいろと迷うことがあります。たとえば:
- 有用なテスト結果を得るためにパターンをどのような基準で用意すればよいのか
- テスト結果の統計的有意性をどのように検定すればよいのか
- 個々の改善がそれぞれによかったとしても、それらが局所最適に陥らないためにはどうしたらよいのか
といったあたりが挙げられます。(2)については純粋に技術的な問題なので、ここでは議論しません。問題にしたいのは(1)および(3)についてです。ひとまず、いまのところ僕が思う一番大切なことをひとつだけ述べておきましょう。それは:
「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」
ということです。どういうことか。
視野狭窄的なA/Bテスト
A/Bテスト、あるいは同様の最適化技法については、かつて「グーグルのビジュアルデザイン責任者が退職--データ中心主義に嫌気 - CNET Japan」なんて記事がありました。「2種類の青色のいずれかで決めかねたら41の中間色をテストして最もパフォーマンスのよいものを選ぶ」という極端な実験は、マリッサ・メイヤー氏がYahoo!に移籍されたこともあっていまは行われてはいないようです。
昨今、A/Bテストを簡単に行えるツールが多数現れています。そうしたツールを利用すると、非常に簡単にA/Bテストを企画・実施し、結果の検定までやってくれます。便利な世の中になりました。自分でがんばってロジック実装から集計までしていた過去が、懐かしい感じです。しかしながら、そうした便利ツールの利用に際して、果たして上述のマリッサ氏的視野狭窄に我々は陥っていないといえるのでしょうか。
そのことをよく示す図が、fladdictさんによって提示されています:
「ABテストの悪循環」ってこんな感じ。 pic.twitter.com/BISRCwcpo7
— 深津 貴之 (@fladdict) January 8, 2014お手軽さの罠
A/Bテストの成功事例として「リンクの色をちょっと変えただけで〜」とか「ボタンの色を○○に変更したしただけで〜」とか「文言を○○に変更しただけで〜」といったお手軽な改善により、劇的な成果が得られたという話が喧伝されています。それはそれで大変けっこうなことですが、そのような部分的な改善によって一時的に数字がよくなったとして、それは本質的な改善につながるものなのでしょうか。局所最適に陥る結果に終わることがありはしまいか。A/Bテストツールがお手軽になった昨今だからこそ、あらためてその点が問われなくてはならないと思うのです。
昨今、飛躍的に簡単に行えるようになってきたA/Bテストを継続的に実施しつつ、Webサービスをよりよくするために、こうした問題に適切に対処する必要があると考えます。そのための第一の指針が、先に述べた「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」です。
目的は「ユーザ価値の増大」
そもそもA/Bテストはなんのためにするのか。それは、ユーザにとってより高い価値を提供し、その結果としてより高い利益を得るためです。その基本に立ち返ると、デザイナが「ボタンの色が青か赤かどっちがいいかわかんないけどとりあえず出してみるか」といってデザインを決めたり、ディレクタが「この文言や導線がいいかどうかわかんないけど(略)」といってディレクションを終えたりなんてことはあり得ないでしょう。デザイナやディレクタとしての能力・経験・信念といったものを総動員して、ユーザにとって最大限価値を提供し得ると信ずる決定をするはずです。
その意味において、たとえA/Bテストだからといって、どっちがよりよいかという意見のないパターンをテストすることは不適切であるといえます。もちろん、Webサービス提供者がよいと思ってもユーザはそうは思わないことはおおいにあり得ることです。なので、「青か赤かを決める」という事態をより正確にいうと、Webサービス提供者は、ユーザ価値を高めるための仮説を持つということです。A/Bテストは、不確実な状況下で、その仮説を検証するために行われるべきもの。それが、「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」ということの意味です。
全体最適への仮説
パターンを仮説に基いて用意するのであれば、それはWebサービス全体においての整合性の中で検討・作成されるものであることは自明です。そうであれば、全体のデザインにとっては微妙だけど、数字が上がるかもだからテストしようということにはならないでしょう。そしてそのことが、A/Bテストが局所最適なものに終わらないようにするための条件ではないかと思います。
