リクルートテクノロジーズ メンバーズブログ  Multi-variable testing のすすめ

Multi-variable testing のすすめ

リクルートテクノロジーズの大杉です。

私はAPソリューショングループ(ASG)という組織で、検索基盤QASS1アルゴリズムの最適化に取り組んでいます。もっと具体的には、検索キーワードや条件が指定された時の、検索結果のソート順を決定するアルゴリズムを開発しています。

この検索順アルゴリズムの良し悪しは、ABテストでKPIが有意に向上するか否かによって決まります。現実のデータに勝る根拠は存在しないです(断言)。

検索アルゴリズムの改善のためには、パラメータ値を更新した場合の性能評価(最終的にはABテスト)が必要です。

一方で、検索順アルゴリズムに関わるパラメータ数は、1つや2つではとても済まず、かなり大量にあります。

そのため、ABテストを短期間にどれだけ大量にできるかが、改善のスピードに直結します。

しかし、ABテストは、検索アルゴリズム改善だけでなく、例えばUIデザイン改善にも必要です。

そこで、どのサイト訪問者にどのABテストを行うのかを両者が衝突しないように、仲良くわけたイメージ図がこちらです。

blog_mvtest_fig1
図1, 1変数型ABテストのイメージ
それぞれのABテスト枠内で施策を行い、基準無施策枠のKPIと比較し、有意差を出していく

この方法では大きく2つの問題があります。

1. 検索とUIの施策に交互作用があった場合、それが測定できない(お互いの施策が効果を打ち消しあっていたらどうするのか?)
2. ABテスト枠の量をめぐって、検索チームとUIチームが対立するおそれがある(ABテスト枠を細分化していくと1枠内の訪問者数が減り、結果が不安定になります2。)

この“衝突しないように仲良くわけたはずなのに・・・”問題は、図2のような形で、ABテストの住み分けすることで解決できます。

blog_mvtest_fig2
図2, 2変数型ABテストのイメージ
それぞれのABテスト枠内で施策を行い、自らのABテスト枠の中の無施策KPIとの比較し、有意差を出していく。他の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を運用している方にとっては自明の話だったかもしれませんが、ここまでおつきあいいただきありがとうございました。

検索アルゴリズム改善そのものについては、またの機会に書きます。

では、また。


  1. 検索基盤QASSについては、例えば、http://www.atmarkit.co.jp/ait/articles/1507/08/news009.htmlhttp://atl.recruit-tech.co.jp/libraryfile/WebDBForum2013/をご参照ください。 
  2. サイト訪問者が非常に多い場合は割合の小さいABテスト枠でも十分な数の訪問者が来ますが、たいていのサイトの場合、時間帯によってユーザー属性や行動が異なるため、有意差が出たからといって、ABテスト期間を超短期間で済ませるのは危険のようです。 
  3.  http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190.3883&rep=rep1&type=pdf
    をご参照ください。実際の詳細な運用方法まではさすがに書いていないことに注意。 
  4. Ron Kohavi, et al., 2008を参考。
    http://www.robotics.stanford.edu/~ronnyk/2009controlledExperimentsOnTheWebSurvey.pdf
    これのp159~160に本文で書いたメリット・デメリットについて、より詳細に書かれています。 
  5.  https://en.wikipedia.org/wiki/Multivariate_testing_in_marketing
    ちなみに2015年7月30日現在、日本語の項目はないようです。 
  6. コーディング中に改善案を思いついたら、即テストできるような開発・運用体制も視野に入ってきます。