世間でA/Bテストについて調べると、結構あっさり書かれていたり、逆にとんでもなく突っ込んで書かれた記事に出会ったりします。 自分のような初心者には、帯に短し襷に長しという感じだったので、こちらの書籍を読んでA/Bテストについて勉強してみました。
上記の本を読んで気になった部分や考えたことについて、思考の整理を兼ねてつらつら書いてみたいと思います。
想定する状況
まずは、フレーミングも兼ねて、どんな状況でA/Bテストが必要になるかについて確認してみたいと思います。
いま、何らかのサービスを運営していて、その改善に取り組んでいる状況を考えます。 そして、改善のために一つ良さそうな機能のアイデアが思い浮かんで、試してみようということになったとします。
さて、ここでちょっと立ち止まって一つ疑問が出てくるかもしれません。 いまサービスに新しく追加しようとしているその機能が本当にユーザーにとって良い機能でしょうか？
この疑問について、事前にユーザーに対して入念なヒアリングなどを通じて、確認したら良いのではないかいう意見もあるかもしれません。 しかし、多くの場合、ユーザーはまだ作られていない機能を正確に理解して良し悪しについて言及することはできませんし、場合によっては気を利かせてお世辞を言ったりもするでしょう。
実際に本番環境にリリースしてしまえば、ユーザーの反応を見ることができます。 本当に有効な施策であれば、求める評価指標を達成していきます。 一方で、予想に反してユーザーの体験を損ねてしまうこともあり、本番環境で完全な形でリリースするのはその機能が完全に良いものであると判断したときだけに限りたいのが本音です。
ここまでの状況は架空の話ですが、ここからわかることは、
- ユーザーに価値のある機能をヒアリング等で正確に把握することは難しい
- 新しく追加しようとしている機能が実際には改悪になるケースがある
ということです。
そこで、「小さく実験してユーザーの反応を見て価値があるかを判断したい」という考えになるかと思います。 試験的に新しい機能をリリースし、ユーザーの反応からそれが本当に価値があるか検証し、価値があると分かってから全面的にリリースするという考えに至るかと思います。 まさにこれがA/Bテストでやりたいことになります。
A/Bテスト一巡り
それではA/Bテストとはなんぞやということに話を移していきたいと思います。 A/Bテストについてちょっと調べてみると下記のような説明がされているかと思います。
A/Bテストとは、バナーや広告文、Webサイトなどを最適化するために実施するテストの一つです。
特定の要素を変更したAパターン、Bパターンを作成し、ランダムにユーザーに表示し、それぞれの成果を比較することで、より高い成果を得られるパターンを見つけることができます。「A/B」テストという名前ではありますが、もちろん3パターン以上でテストすることもあります。 今さら聞けない「A/Bテスト（ABテスト）」とは？成果を出すための進め方 | Urumo！
分かる人にとっては上記の説明で事足りるんですが、今回は私の理解のためにA/Bテストにまつわる実際の流れを簡単に追いかけて、A/Bテストというものをもう少し解像度を上げてみていきたいと思います。
流れは大体下記のようになるかと思います。
施策の検討やそのKPIの設定についてはA/Bテストとは若干話が離れるので今回は除外して、ここでは何らかのKPIを追いかけてそのための施策まで考えた状態から話を考えてみようと思います。
対照群と介入群
A/Bテストは何らかの施策の介入効果を測定するために行うテストと考えることができます。 介入効果をどうやって確認するかというと、下記のような比較を行います。
A/Bテストでは、対象となるアクティビティに関して対照群と介入群に分け、対照群と介入群の双方の評価指標を比較することで介入したことによる影響を判断します。
対照群がないと困ること
もしかすると、「対照群と介入群に分ける必要があるのか？テストを開始するまでのログとテストを開始した後のログを比較すれば対照群・介入群に分ける必要はないのではないか？」という疑問が出るかもしれません。
この点についてちょっと考えてみます。 例えば、比較のために実験を開始する前の評価指標をとっていたとします。 その後、新しい施策を開始して同様に評価指標をモニタリングしたとします。
一見すると、施策を開始する前後の評価指標を比較することで施策に効果があったかどうかを測定することができそうです。 ただし、これでは何らかの外部要因によって評価指標が影響を受けたことを考慮できなくなってしまいます。 運悪く施策を開始した後に発生した外部要因によって評価指標が変動した場合に、それを含めて施策の効果を判断することは非常に難しくなってしまいます。
そんなわけで、施策を評価するために、既存の方法のままの対照群と、新しい施策を適用した介入群の2つを比較するわけです。
どう分けるか
対照群と介入群に分けることは上で確認しました。 今度は、どのようにして対照群と介入群に分けるのが良いのでしょうか？
この問題を考えるのは大きく2つの観点があると思います。
- 何を元に振り分けるか
- どんなアルゴリズムで振り分けるか
1.に関しては例えば、
- ユーザー
- セッション
- ページ
などでの振り分けが考えられるかもしれません。
1.に関して考えるべきことは、対照群と介入群が互いに独立であるようにする点です。 介入群に対して行った施策が、対照群へ影響を与えてはいけません。 例えば、何らかの施策を適用する際に、セッションごとに対象群と介入群に振り分けたとします。 そうしてしまうと、1回目で介入群であったユーザーが2回目に利用したときに対象群になってしまう可能性があります。 この状況になったとき、介入群に対する施策は、二回目の対照群に対して影響を及ぼしてしまっている可能性があります。
実際にはセッションごとに振り分けたとしても対照群・介入群が干渉しないケース（検索結果の表示など）も考えられるのでそういう場合ではユーザーごとでなくても問題ないと考えられます。 いずれにせよ、2つのグループが相互作用してしまう状況を回避することは気をつける必要があります。
2.に関して考えるべきことは、振り分けの際にバイアスが入り込んでしまわないことです。 例えば、対照群・介入群の振り分けをアカウントの登録時期がある時点より前か後かで振り分けたとします。 このとき、登録時期によりユーザーのサービスに対する熱心度合いが異なっていた場合、介入群と対照群に含まれるユーザーにバイアスが入り込んでしまうかもしれません。 こうなってしまうと、本来対照群と介入群で施策の適用以外に行動傾向に差が出てしまい、正しい結果が得られないということがあるかもしれません。 そのため、こうしたバイアスを取り除くように振り分けを行う必要があります。 基本的には、完全に無作為に振り分けることがバイアスを排除するためには望ましいと考えられます。
評価
A/Bテストで対照群と介入群を比較することを確認しました。 今度は、実際に対照群と介入群で目的の評価指標のデータが出揃った後に結果を評価します。
ここではよくある例として取り扱われる、広告のクリックについて考えてみたいと思います。 今、広告の位置を変えたところクリック率が変動するのではないかという仮説が考えられたとします。 具体的にはこんな感じであったとします。
この新旧のレイアウトでどちらがクリック回数が多いかを調べてみたところ、下記のようになったとします。
| 対照群 | 介入群 | |
|---|---|---|
| ユーザー数 | 1000 | 1024 |
| クリック数 | 90 | 100 |
| 平均クリック数 | 0.09 | 0.097 |
このとき、介入群は対照群と比べてクリック数が多くなっていると言えるかを判断しなければなりません。 この集計の通り、本当に介入群のほうがクリック数が多いのかもしれません。 しかし、この集計をした時点でたまた介入群のクリック数が多くなってしまったのかもしれません。 そんなことを考えると単純にユーザーあたりの平均クリック数を比較して評価をしてはいけない気がしてきます。
こういうときに役立つのが検定です。 有意差検定に関しては、ここでちゃんと紹介すると長くなりそうなので、今回はざっくり概要だけ確認します。 対照群・介入群の評価指標の値について検定を行うことで、施策が本当に効いているかを判断していくことになります。
この辺に関しては本当に全く分かっていなかったので、こちらの記事を参考にさせていただきます。 実際には広告のクリック以外にもテストしたいことはあり、その時の条件で検定の種類は選択する必要がありそうです。 その中でもA/Bテストの文脈で使用される検定の方法には、大体下記のような検定が使用されあるようです。
この辺でやりたい検定にあったものを使用していくのが良いかと思います。
A/Bテストの設計
さて、仮想的にA/Bテストがどんな感じで進むかは確認しました。 ここまで分かったら、あとは自分が実際にA/Bテストを実施するときに、そのデザインでミスらないようにするだけです。
この辺りは個人的な意見満載なので、「ふーん、こんなもんか」くらいに思ってもらえれば。
基本原則
A/Bテストを含む、実験計画法には3つの基本原則があるとしています。
- 局所管理の原則
- 介入群・対照群に分け、どちらかだけに影響要因が介入してしまわないようにします
- 反復の原則
- ユーザーの行動には一定のランダム性があるため、十分な量のデータを収集することに努めます
- 無作為化の原則
- 介入群・対象群へは無作為に振り分け、各グループにバイアスが入り込まないように努めます
上記に沿わない（場合によっては沿えない）場合もあるかとは思いますが、基本的には上記に沿って進めることが望ましいと考えられます。
指標がどうなったらOKかを定義する
最優先でやったほうが良いことは、どんな指標がどう変化していたらA/Bテストで確認したかった事柄は正しかったと言えるかに関して明確に定義することだと考えます。 たとえば、
- 対照群より介入群のほうが広告のクリック率が高い
- 対照群より介入群のほうがユーザーの離脱率が低い
など、何のものさしで判断するかははっきりさせる必要があります。
期待通りに指標が推移してくれることもあれば、期待に反してあまり変わらないこともあります。 そして、意図せず、全然別の指標が良くなっていることを見つけることが稀によくあります。 そうなると、実験の担当者の思考として狙いとは違う部分が良くなっているのに、実験を成功にしたくなってしまうものです。
こういうことをしてしまうと、実際に起こっている事象をうまく把握できなくなってしまう恐れがあります。 A/Bテストの結果とその過程で得られた学びは切り分けて考えたほうが良いと、個人的には思っています。
何れにせよ、A/Bテストでユーザーの行動がどう変容するかの仮説を事前に明確にすることは必要なことなので、ウォッチする指標は明確にする必要があると考えています。
いつやめるかを定義する
A/Bテストでやりがちなこととして、「値としては良さそうなんだけど、統計的には優位とは言えない」といった状況が続いてしまい、テストを止めるに止められなくなってしまうことだと思います。
明確な優位な差が得られずにテストを続けてしまうことに関してメリットデメリットを考えてみます。
- メリット
- もしかしたらたまたま調子が悪かった場合、待っていれば実は優位な結果が得られる（かもしれない）
- デメリット
- 次のA/Bテストに取り掛かる期間が短くなってしまう
ある種のトレードオフの関係であるのは間違いなく、一概にA/Bテストを短期間で打ち切ったほうが良いということではありません。 ただ、見方を変えれば短期間で明確な効果が出ない機能に長時間を使ってテストを続けることは、投資対効果に見合っていないとも考えられます。 もちろんA/Bテストで試す内容にもよりますが、完了の条件とその継続の期限は決めておいたほうが無難かと考えています。
モニタリングする
最後に、モニタリングの用意はしたほうが良いと思います。 多くの場合、A/Bテストはすでに動いているサービス上で行われ、そのユーザーの体験を著しく損なうことは何より優先して避けなければなりません。 施策を適用してみて、気がついたら介入群のユーザーの体験が著しく悪くなってしまい、一気に大量のユーザーが離脱するということもあるかもしれません。
流石にここまで大げさなことはなかなかおこらないかもしれませんが、それでもモニタリングしておくに越したことはありません。 想定していない、異常な動きが見られる場合にすぐに対応できる状況は作っておくべきかと思います。
その他考慮するかもしれないことのなぐり書き
上記のストーリーに沿って考えて言ったら良いとは思っていますが、一部読んでいて気になった部分を雑にピックアップします。
- ランダム化の単位はなに？
- 基本はユーザーが単位、検索エンジン等のランキングに関する改善などではページやセッションレベルでのランダム化はありうる
- ターゲットにしたいランダム化単位の母集団はなに？
- 実験に必要な標本の大きさはどれくらいか？
- どのくらいの期間、実験を実践するのか？
- 明確な答えはないが、テストを継続することと打ち切って新しいテストに取り掛かることのPros/Consを見る必要はある
- その他、場合によっては下記のようなものも考慮する場合がある
- 曜日効果
- 季節性
- プライマシー効果
- いつも使っているものに慣れ過ぎて新しいものに対応するのに時間がかかる
- ノベルティ効果
- 新しい機能を導入するとユーザーはそれを試す方向に誘引されるが、うまく機能しない場合に徐々に介入効果が低下する
参考文献
下記の文献を参考にさせていただきました。
感想
A/Bテスト、何もわからん。
A/Bテストについて本当に何も分かっていなかったので、慌てて積読になってた本をひっくり返してきて頭の整理のために書いてみた記事でした。 見落としてることも結構あるかもしれないので、間違ってる部分を見つけたらTwitterのDMとかでこっそり教えてくれると嬉しいですm(__)m
おそらくこれを書いてる自分が一番分かってないので、まだまだ勉強しないとなーと思いました。
