具体的な失敗例──分析での失敗
A/Bテストの失敗は分析時にも起こり得ます。分析時の失敗は実装時のそれとは違い、機械的な検知が困難です。またサービスや検証したいアイデアの種類によっても注意すべき点が変わることがあり、一律に対策をすることも難しいです。ここでは、架空の例をもとに失敗やその対策を具体的に紹介します。
不正確な指標
検索エンジンの例
とある検索サービスで、内部のアルゴリズムの変更をA/Bテストしました。その結果、そのサービスのビジネス上での主要指標である収益（広告クリックによって発生）とクエリシェア率（多様な検索が行われて欲しい）が改善しました。これだけ見ると新しい変更は良いものに見えます。しかし、その実態はアルゴリズムが劣化したことで、広告の方がクリックされやすくなったため売り上げが上がり、ユーザーは知りたい情報にたどりつくために何度も検索し直す羽目になったため、クエリシェア率が上がりました。明らかに、この変更はサービスにとって良い変更だとは考えられません。
メールの例
とあるECサイトでは、ユーザーに新商品を紹介するメールを機械的に作成し送信するアイデアを検討しようとしました。そこでランダムに選んだ一部のユーザーにだけこの新しいメールを送信することで売り上げが上昇するかを検証しました。当然、新しくメールを送った方が何もしなかった場合よりも比較した場合、短期的には売り上げが上がります。つまり、どんなメールでも送ればOKという結論になります。その結果、A/Bテストを繰り返すことでそのECサイトはユーザーにとってはスパムメールも同然のメールを大量に送りつけるサービスとなりました。明らかに、この結果はそのサービスにとって良い結果だとは言えません。
対策
上記の例は、A/Bテストの意思決定に用いた指標が正しくなかったために起こる失敗です。これらの例は直感的に明らかにおかしな結論になったため失敗に気がつきましたが、もっと微妙な例だとなかなか失敗に気がつけません。
この失敗発生を抑制するために、指標をゴール・ドライバー・ガードレールの３つに分類する考え方を紹介します。指標を分類することで、A/Bテストと指標の間の論理関係が整理されやすくなります。
（1）ゴール
組織の成功を直接表現する指標です。検索サービスの例だと広告による収益やクエリシェア率が、ECサイトでは売り上げが指標になります。この指標を監視することは非常に重要ですが、A/Bテストの種類によってはこの指標だけで判断すると上記のような誤った結論になる危険性があります。
（2）ドライバー
別名、代理指標とも呼ばれます。これは決めることが特に難しい指標です。以下の条件を満たす指標を見つけてきます。
- ゴールの原因になると考えられる
- 短期的に計測できる
- A/Bテストで評価したいアイデアから影響を受ける
検索エンジンの例では、ユーザーの再訪率や、クリックされたアイテムの検索一覧結果画面での表示位置などが考えられます。ユーザーの再訪が増えれば、ゴールである広告収入やクエリシェア率が増えます。なのでゴールの原因だと考えられます。毎日使ってほしいサービスなので、再訪率も比較的短期に計測できます（日次アクティブユーザー数を見るなど）。
また、サービスのアルゴリズム改善によってユーザー体験が向上すれば、再訪が増えると考えられます。クリックされたアイテムの検索一覧結果画面での表示位置は、ユーザーの再訪よりもすぐ計測でき、アルゴリズム変更の影響をより直接的に受けます。
さらに、ユーザー再訪の原因となるユーザー体験に密接に関連すると考えられます。かなり下まで検索結果をスクロールしないと目当ての情報が見つからない検索サービスは使い勝手が悪いからです[1]。
（3）ガードレール
これはあってはならない事態を定義し、それが起きてないことを確認するための指標です。メールの例では、メールの配信停止設定率がガードレールとして考えられます。メールの配信停止により、将来的にメール経由で得られる売り上げが損なわれます。これを観測することで、短期的に売り上げが上がっても、長期的に売り上げが下がるといった事態を抑制しやすくなります[2]。
[1]検索機能の場合、アイテムクリック率がドライバーに設定されやすいです。ECサイトなどではアイテムの購入に至るためには検索結果画面からのアイテムクリックが主要な原因になるからです。ただしアイテムクリックが常にゴールの原因になるとは限りません。例えば、男性ユーザーが女性モデルの水着画像（当然、購入する予定は全くない）をついクリックしてしまうことが知られています。これを指標にA/Bテストを繰り返すと、検索結果画面が女性の肌露出が高い画像をもつ商品だらけになるかもしれません。このように、ドライバーと考えられているものが本当にゴールの原因になっているかについては注意が必要です。実際にA/Bテストをしてみてドライバー指標が改善してもゴール指標が改善しない場合は、何かがおかしいのでしっかりとした分析を行うべきです。
[2]メールの配信停止設定による将来の売り上げ減少金額が推定できるのならば、これはガードレールとしてではなく、ゴール指標の変更に用いた方が良いです。つまりメールによる短期的な売り上げ増加分から配信停止による減少分を引いた金額をゴールにします。なぜなら、配信停止率が高くても、それを補ってあまりあるほどの売り上げをもたらすメールであれば、そのメールを採用する可能性があるからです。再訪率などが測定できない、ブラウザCookieの場合は正確性が犠牲になります。
外れ値の扱い
妥当な指標を選択できたとしても、今度はその指標の内部の問題とその取り扱いが原因で、A/Bテストが失敗してしまうことがあります。ここでは、指標内部の問題としてしばしば起こりうる外れ値について考えます。
外れ値にひっぱられる
とあるECサイトでクーポンの内容変更により、1人あたりの購入点数が増えるかどうかのA/Bテストを実施しました。1人あたり平均購入点数が約3.5から約4.1に増加したらこのアイデアは大成功でした。ところが1人で10,000点を購入するユーザーがいて、そのユーザーがどの実験条件に割り当てられるか（ランダムに決まる）で結果が大きく変わってしまうことになりました。これではアイデアの価値を評価できません。これは架空の例ですが、買い占めや抽選券狙いなどで本当におこる可能性はあります。
不当に外れ値扱いしてしまう
とあるポータルサイトで一度に表示されるアイテムを増やすアイデアをA/Bテストで検証しました。このアイデアは大変すばらしく、アイテムを大量に閲覧するユーザーを増やしました。しかし、アイテムを大量に閲覧するユーザーをシステムがBotだとみなし、A/Bテストの分析時に除外してしまった結果、新しいアイデアの方が平均アイテム閲覧数が少ないといった逆の結論を導き出してしまいました。
対策
外れ値問題への対策は万能な解決策がありません。実際にどんなサービスでどんな指標に対しての外れ値なのかによって対策方法が変わってくるからです。対策を考える前に、実際に指標のヒストグラムなので可視化をし、外れ値への理解を深めることも非常に重要です。
ここでは外れ値へのよくある対処方法や問題の検知方法について紹介します。
（1）外れ値に強い指標を採用
ECサイトでは１人あたりの購入点数の平均ではなく、購入するか否かの2値で評価したり、中央値で評価したりするなどして、より外れ値に頑健な手法を採用することで対策ができます[3]。また、極端な値を外れ値として排除する方法も可能です。しかし、この排除する方法だと外れ値の基準を慎重に決めないと、ポータルサイトの例のようにアイデアが大当たりした場合に、失敗してしまう危険性があります。
（2）A/Aテストでシミュレーションを行う
これは外れ値があることの悪影響を評価する方法です。対策そのものではなく検知方法になります。
事前に過去のログデータから、当時A/Aテストしたとみなし、ユーザーをランダムに2つの群にわけて、指標に統計的に有意な変化があるかをみます。もし外れ値があり悪影響を及ぼすのなら、統計的に有意な変化が起きやすくなっているはずです。このA/Aテストを大量に繰り返します。ログデータからのシミュレーションなので100回でも1000回でもできます。その結果、本来は変化が起きないはずの指標で有意な変化が起きやすくなっていたら、それは外れ値が悪さをしている可能性が高いです[4]）。
（3）割り当て割合を監視する
これは実装での失敗で述べたのと同じ方法です。ポータルサイトの例では片方の条件だけ外れ値としてユーザーが除外されたため、ユーザーの実験の割り当て割合が崩れています。なので、割り当て割合を監視していれば問題は検知できます。
まとめ
第1回ではA/Bテストの理解に不可欠な「なぜ」と「どうやるか」（WhyとHow）について、第2回ではA/Bテストの実用上重要な起きがちな失敗と対策について紹介しました。本連載を通して皆さまがA/Bテストをやってみようと思えたり、実際のA/Bテストの失敗に気がつけたりできるようになると嬉しいです。
ここでは紹介しきれなかったA/Bテストの発展的な応用例やその歴史、失敗例やその対策、さらには組織的にA/Bテストを推進するために必要な考え方など、A/Bテストを中心とした改善活動をするために知っておいたほうがよい知識はまだまだあります。それらの詳細については、『A/Bテスト実践ガイド』を参照していただけるとうれしいです。
[3]仮説検定の方法を変えることで、平均の比較ではなく中央値の比較ができます。
[4]この方法の詳細な実施方法は『A/Bテスト実践ガイド』p.215に書かれているのでそちらも参考にしてください。
