Multi-variable testing のすすめ
大杉 直也
リクルートテクノロジーズの大杉です。
私はAPソリューショングループ(ASG)という組織で、検索基盤QASS1アルゴリズムの最適化に取り組んでいます。もっと具体的には、検索キーワードや条件が指定された時の、検索結果のソート順を決定するアルゴリズムを開発しています。
この検索順アルゴリズムの良し悪しは、ABテストでKPIが有意に向上するか否かによって決まります。現実のデータに勝る根拠は存在しないです(断言)。
検索アルゴリズムの改善のためには、パラメータ値を更新した場合の性能評価(最終的にはABテスト)が必要です。
一方で、検索順アルゴリズムに関わるパラメータ数は、1つや2つではとても済まず、かなり大量にあります。
そのため、ABテストを短期間にどれだけ大量にできるかが、改善のスピードに直結します。
しかし、ABテストは、検索アルゴリズム改善だけでなく、例えばUIデザイン改善にも必要です。
そこで、どのサイト訪問者にどのABテストを行うのかを両者が衝突しないように、仲良くわけたイメージ図がこちらです。
この方法では大きく2つの問題があります。
1. 検索とUIの施策に交互作用があった場合、それが測定できない(お互いの施策が効果を打ち消しあっていたらどうするのか?)
2. ABテスト枠の量をめぐって、検索チームとUIチームが対立するおそれがある(ABテスト枠を細分化していくと1枠内の訪問者数が減り、結果が不安定になります2。)
この"衝突しないように仲良くわけたはずなのに・・・"問題は、図2のような形で、ABテストの住み分けすることで解決できます。
Googleもこのような方法でABテストをしているようです3。
この方法では、検索が利用するABテスト枠とUIが利用するABテスト枠の間でAとB (あるいはC, D, E, ・・・)のわかれ方を統計的に独立にしています。要は別の乱数値を使って分け方を決定しています。
独立にしていることで、検索のA条件とB条件の中で、UIのA条件とB条件がほぼ同数混ざることになり、検索の立場から見た場合にUIのABテストを完全に無視しても、だいたいうまくいきます。交互作用が無視できないほど大きい場合も、この方法なら交互作用の影響を直接測定可能なので、その影響を定量化すれば良いだけです。
この方法のメリット・デメリットを列挙すると以下のようになります4。
- メリット
1. 短い時間でABテストを大量にできる
2. 交互作用の影響を測定できる - デメリット
1. 交互作用が大きくマイナスに働き、施策の良さを打ち消すことがある
2. 分析が比較的難しくなる
3. 複数のテストを一斉に始める場合、準備が大変
デメリットの内、1は計画段階で、交互作用が大きくマイナスに働きそうなものを排除する、2と3は交互作用の影響をあまり考えなくても良さそうな、検索とUIの間のような関係だったら交互作用の影響を無視する、といった方法で軽減できます。
そもそもの話、交互作用の影響を気にするのだったら、交互作用の影響を測定できる、こちらの方法の方が都合良いです。
この考え方をおしすすめていくと、ひとつの画面の中でもABテストを複数同時に行うことを認めるmulti-variable testing5といった、さらに一般的な方法に到達します。
すでにリーン開発のような高速開発体制が整っているところなら、じゃんじゃんABテストをしていき、改善をどんどんしていくメリットの方が大きいかと思います6。
こうして発想を変えることでABテストをたくさんでき、検索アルゴリズムの精度改善ができるようになりました。
やったね!
ということで、検索アルゴリズムの改善にはABテストのやり方を変えていくことも大切だ、という話でした。
当たり前のようにmulti-variable testingを運用している方にとっては自明の話だったかもしれませんが、ここまでおつきあいいただきありがとうございました。
検索アルゴリズム改善そのものについては、またの機会に書きます。
では、また。
- 検索基盤QASSについては、例えば、http://www.atmarkit.co.jp/ait/articles/1507/08/news009.htmlやhttp://atl.recruit-tech.co.jp/libraryfile/WebDBForum2013/をご参照ください。 ↩
- サイト訪問者が非常に多い場合は割合の小さいABテスト枠でも十分な数の訪問者が来ますが、たいていのサイトの場合、時間帯によってユーザー属性や行動が異なるため、有意差が出たからといって、ABテスト期間を超短期間で済ませるのは危険のようです。 ↩
-
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190.3883&rep=rep1&type=pdf
をご参照ください。実際の詳細な運用方法まではさすがに書いていないことに注意。 ↩ -
Ron Kohavi, et al., 2008を参考。
http://www.robotics.stanford.edu/~ronnyk/2009controlledExperimentsOnTheWebSurvey.pdf
これのp159~160に本文で書いたメリット・デメリットについて、より詳細に書かれています。 ↩ -
https://en.wikipedia.org/wiki/Multivariate_testing_in_marketing
ちなみに2015年7月30日現在、日本語の項目はないようです。 ↩ - コーディング中に改善案を思いついたら、即テストできるような開発・運用体制も視野に入ってきます。 ↩