A/Bテストのやり方
Webサービスを変更するアイデアを評価するA/Bテストは、以下の要素からなります。
- 「実際はこうである」をちゃんと確かめる
- 実際に変更をかけたいWebサービスに変更を加える
- 変更前と変更後を直接比較する
- 実際に知りたいユーザー行動を見る
- 変更前後が同じ時期での比較になるようにする
- 変更ありサービスを使うユーザーとそうでないユーザーが同じような集団になるようにランダムに割り当てる
- 実験した結果、望ましい変化が起こることと望ましくない変化が起きていないことを確かめる
このうち、1〜6の部分は「なぜ」それが必要なのかについて書いてきました。7がなぜ必要かは自明だと思うので割愛します。
手順
まず、複数種類の実験条件、つまり新アイデアを適用したWebサービスと、適用していないWebサービスを用意します[2]。ここで同時に試すアイデアは1つだけである必要はありません。複数のパターンを同時に試すことも可能です。実際のWebサービスを使って比較することで、要素1、2、3が満たされます。
次にユーザーに対してランダムにどの実験条件を割り当てるかを決めます[3]。そして、その実験条件に応じたWebサービスをユーザーが利用します[4]。実際のユーザーをランダムに割って同時期に複数のパターンを試すことで、要素4、5、6が満たされます。
最後に、実験条件ごとのユーザー行動の違いを分析し、実際に望ましい変化が起きていることを確かめます。これにより、要素7が満たされます。
このようにすることで、アイデアの価値を評価し、正しくWebサービスの改善が実施できているかを確かめることができます。
この「実際に望ましい変化が起きていることを確かめる」はボタンの色変更でクリックが増えるかどうか、であればクリック数が増えることです。ただし、実際の観測データにはばらつきがあり統計処理が必要だったり、クリック数以外にも気をつけるべき指標があったりと、実はかなり考えることが多いです。
第1回では「なぜA/Bテストが必要か」と「A/Bテストはどうやるか」の概要を紹介しました。第2回ではA/Bテストを実施する上で注意すべき点について具体例をもとに紹介します。
[2]どの単位で用意するかは、実施したい実験によって異なります。例えば、ボタンの色を変更したいだけであれば、HTMLあるいはJavaScriptのコードを変えたものだけ用意すれば良いでしょうし、レコメンデーションロジックのようなものならばバックエンドのコードを変えたものが必要かもしれません。実験の目的がサーバのCPU利用率変化を測る目的だったらマシンがもう一台必要になります。
[3]ログイン後のユーザー、あるいはネイティブアプリであれば内部でもっているユーザーIDとA/Bテストごとにユニークの名前を組み合わせたものをハッシュ化して、それの余りを使えばユーザーに固有なランダムな割り当てを実現できます。どのようなハッシュ関数を使うと良いかなどの詳細は、私が翻訳を担当した『A/Bテスト実践ガイド』のp.50が参考になります。非ログインユーザーの場合はセッション単位やブラウザCookieでの追跡単位を用いることになりますが、セッション単位の場合はセッションをまたいだ効果（再訪率など）が測定できない、ブラウザCookieの場合は正確性が犠牲になります。
[4]この実際のWebサービスへの割り当て方法にリダイレクトを使う場合は注意が必要です。新しい条件のみリダイレクトをかけるなどすると、ページ描画時間が新しい条件で遅くなりユーザー行動に悪影響が出る危険性があります。この悪影響の程度は第2回で紹介するA/Aテストで推定できます。
