A/Bテストを実行する際にやってしまいがちな典型的ミスまとめ
![](https://image.news.livedoor.com/newsimage/stf/2/f/2f77c_88_1efaf344000dd6d8d89bafbce0fea933.png)
A/Bテストを始め、多数の分析・調査ツールを提供するサービス「PostHog」の公式ブログにおいて、エンジニアのリオル・ノイナー氏がA/Bテストを実行する際にやってしまいがちな典型的ミスをまとめています。
A/B testing mistakes I learned the hard way
https://newsletter.posthog.com/p/ab-testing-mistakes-i-learned-the
![](https://image.news.livedoor.com/newsimage/stf/0/3/03d4f_88_a32c9a5ba80346ac9412bc804159df21.png)
ノイナー氏はMetaで働いていた時や、個人的なプロジェクトなどにおいて数百回のA/Bテストを実行してきたとのこと。「数百回の経験を元に苦労して学んだ典型的な間違い」をノイナー氏は6つ述べました。
◆1:検証する仮説が不明確
テストを行うときの仮説は「何をテストするのか」「なぜテストするのか」が明確であるべきです。仮説が不明確だと、時間を無駄にするだけでなく、知らないうちに製品に損害を与えるような変更をしてしまう場合があります。
ノイナー氏は悪い仮説の例として、「『レジに進む』ボタンの色を変更すると購入が増える」という仮説を紹介しました。この仮説では、なぜこの変更によって購入が増加すると期待しているのかが不明瞭であり、ボタンのクリック数だけを測定すれば良いのか、その他のどんな指標を確認すれば良いのかが分かりません。
一方、良い仮説とは「ユーザー調査により、ユーザーは購入ページに進む方法がわからないことがわかりました。ボタンの色を変更すると、より多くのユーザーが気付いて購入ページに進むようになります。これにより、購入が増えることになります」というようなものとのこと。この仮説に従えば、ボタンのクリック数と購入数を確認すれば良いことがわかります。
このミスを防止するためには仮説が「なぜテストを実行するのか」「どのような変更をテストするのか」「何が起きると予想されるのか」という3つの質問に答えているかを確かめるべきとのこと。
◆2:全体の結果のみを表示する
例えば、全ユーザーを対象にしたA/Bテストで次のような結果が出たとします。結果だけを見ると、変更後の「Test」バージョンの方がコンバージョン率が倍増しているように見えます。
![](https://image.news.livedoor.com/newsimage/stf/e/1/e1ab3_88_1ae53c1ec6e557d24fe14c3e345a7b4b.png)
しかし、端末の種類ごとに結果を確認するとこの通り。デスクトップ端末では変更しない方がコンバージョン率が高いという結果になりました。
![](https://image.news.livedoor.com/newsimage/stf/6/4/64be9_88_dd0ac43eeeb025e0cb40b040fb6c6d4c.jpg)
グループ単位の結果と全体の結果が必ずしも一致しない「シンプソンのパラドックス」が発生する可能性があるため、デバイスの種類のほか、「価格帯」「新規ユーザーかリピーターか」「獲得チャネル」などユーザーの属性に分けて実験結果を確認するべきです。
◆3:影響を受けないユーザーを実験に含める
テストしている機能にアクセスできないユーザーや、すでに目的を達成しているユーザーをテストに含めると結果がゆがみ、結論が変わってしまったり、実験期間が延びてしまったりする可能性があります。
例えば下記のように、A/Bテストツールのフラグ取得をユーザーを実験に参加させるかどうかのチェックよりも前に行ってしまうと、ツールが割り当てたフラグと実際のユーザーの表示が食い違うことに。
![](https://image.news.livedoor.com/newsimage/stf/7/d/7d5c4_88_f277b166a68a7d05f141f959b2df90ea.png)
正しい結果を出すためには、A/Bテストツールのフラグ取得はその他のチェックの後に行うべきです。
![](https://image.news.livedoor.com/newsimage/stf/0/8/08fae_88_5719cea4b0c6cc7cabec6e1a22db016d.png)
◆4:テストを早く終わらせる
ノイナー氏はこのミスを別名「のぞき見問題」と呼んでいるとのこと。このミスはテストが完了する前にテストの結果を確認し、不完全なデータで決定を下してしまうというミスです。初期の結果が統計的に有意と表示されても、最終結果でも統計的に有意となるかどうかは分かりません。
A/Bテストを行う際は、あらかじめ必要な期間を計算し、その期間に従うべきとのこと。ツールによっては自動で必要な期間を計算してくれる場合も存在しています。
◆5:いきなり全体を対象に実験を実行する
結果を早く得たいがために、最初から全ユーザーを対象に実験を行ってしまうと、バグがあった場合に実験を行えなくなる可能性があります。例えば全ユーザーを対象にしたA/Bテストの開始後に変更した点がアプリをクラッシュさせて正しい結果が取得できなくなっている事に気付いた場合、修正してもすでに多くのユーザーが変更を見てしまっているためA/Bテストを再度行うことができません。
最初は少数のユーザーを対象に実験を開始し、各種のデータでアプリが問題なく動作していることを確認しつつ段階的に実験に参加するユーザーを増やしていくのが適切です。
![](https://image.news.livedoor.com/newsimage/stf/8/b/8b89e_88_21263ed19e71b4a5de5dfb1323126594.jpg)
◆6:カウンターメトリックを無視する
カウンターメトリックとは、実験によって間接的に影響を受ける可能性のあるメトリックのことです。例えばアカウント登録ページの変更をテストしている時、カウンターメトリックとしてはアクティブユーザー数などが考えられます。登録率が増加しても、アクティブユーザー数が変化していないのであれば「変更後のページがアプリの機能についてユーザーを誤解させているせいで離脱率も向上している」という可能性があります。
「ユーザー維持率」「セッション継続時間」「アクティブユーザー数」など、製品の健全性を確かめる指標を設定して追跡することで変更点について悪影響を与える予期しない副作用が無いことを確かめられます。また、少数のユーザーに実験終了後も変更前のバージョンを見せ続ける「ホールドアウトテスト」も長期的な影響を調べるのに有効とのこと。
ノイナー氏は「A/Bテストを実行することは変更が製品をより良い方向に変えることを検証できるという点で強力な一方、テストを台無しにする方法がたくさんあるので恐ろしい」と正しくA/Bテストを行うことの大切さを訴えました。