はじめに
こんにちは。オークファン新卒2年目の @aucfan-kumasaka です。
今年は業務でバックエンドのロジックをABテストを通じて決定しようとしたときの話を書きたいと思います。
プロジェクトにアサインされて色々調査しながら取り組みましたが、後から振り返ったり学習を進めると反省点が多かったので、同じ轍を踏まないようここに記録します。
ABテストとは
分析のモチベーション
そもそもなぜ実装だけして済ませずにABテストという分析をするのか、というモチベーションについてです。
改修はユーザビリティやSEO効果などなどの改善をするために行いますが、実際にデプロイしてみたら実は効果がなかった、ということは往々にしてあると思います。
成熟した環境においては、アイデアが実際に改善をもたらす割合は1~2割程度しかないという報告もあるそうです。
したがって、新旧や、候補となるアイデアたちの効果を実際に測定して比較し、効果がない場合は取り下げるという判断が必要になります。
この観点では、効果検証はサービス改修時のガードレールであるといえます。
ABテスト
ABテストは効果検証のためのフレームワークです。
この名前はWebマーケティングなどの世界での呼び方のようで、統計学ではランダム化比較試験という呼び方をします。
例えばクーポンを配る施策の効果を検証するために、実際のユーザーをクーポンを配るグループと配らないグループに分けるとします。
両者の売り上げを比較すればクーポンの効果を測れそうですが、このとき購買額の高いユーザーに優先的にクーポンを配ってしまったとします。
すると、クーポンを配られた人たちは元々クーポンがなくてもある程度商品を買ってくれるので、クーポンの効果を過剰に（時には過少に）見積もってしまうことになります。
このように、測定したい効果はユーザーの属性や時期などいろいろな要素に依存しており、知らず知らずのうちに測定結果の中に上記のようなバイアスが含まれてしまうことがあります。
しかし現実には、同じユーザーにクーポンを配った世界線と配らなかった世界線に行ってもらって購入額を比較するということもできないので、理想的な実験を組むこともできません。
これを解決するために、ユーザーをクーポンを配るグループと配らないグループにランダムに割り振ることにします。
こうすれば購買量が多いユーザーも少ないユーザーも両グループに均等に割り振られるため、思考の外にある要素も含めてバイアスを最小限にできます。
結局のところABテストというのは、難しいことを考えなくてもいいように「施策を反映するグループとしないグループにランダムにユーザーを割り振って比較する」手法です。
やったこと
画面に表示する内容をバックエンドのロジックによって制御している部分について、従来のロジックから新規ロジックへ変更してCTRを上昇させよう、という改修を担当しました。
このときのロジックには6通りのパラメータの候補があったため、ランダムに割り振ってフロントへレスポンスを返しました。これによりユーザーは6パターンの画面のいずれかを目にすることになります。
各画面が表示された際にユーザーがリンクをクリックしたかどうかを測定し、最もクリックをもらいやすいロジックを採用しよう、という内容でした。
反省点
ランダム化のパラメータと計測パラメータが違った
問題点
当初の設計では、ユーザーが見たページを表すフラグがロジックを分岐したときのものと異なっていました。
処理を行った結果が表示したページのコンテンツにも依存していたため、異なるロジックを適用しているのに同じ画面が表示される可能性があるような状態でした。
このため閲覧記録を適用したロジックではなく表示された画面で行ってしまったのです。
その結果、上図のような処理が発生したとき、画面3が表示されたとしてもロジック1,2,3のどれを通したのか区別がつかなくなります。
例えば下の図のようにユーザーを各ロジックに割り振ったとします。割り振りはランダムなので件数はほぼ同じです。
しかし各ロジックからどの画面に遷移するかには偏りがあるため、画面で記録した場合の件数とそのロジックは次の図のようになるかもしれません。
これでは画面3でたくさんクリックがもらえたという実験結果を見ても
- ロジック3が優秀なのでクリックが多くもらえた
- 画面3へ遷移するようなコンテンツがもともとクリックをもらいやすい
という二つの効果が区別できません。本来のABテストのメリットを享受できなくなっています。
これだけでなく、各画面を見たユーザー数が偏ることも問題になります。
各ロジックにはランダムに割り振っているので、ロジック1もロジック2も通る人数は同じです。
しかしその結果どの画面が表示されるかには偏りがあったので、画面1を見た人数と画面2を見た人数は違いました。
この問題は分析フェーズでも面倒を増やすことになりました。
各画面を見た人数が同じなのであれば、その中で一番成績の良いものを選ぶのは簡単で、一番クリックをもらったページを選ぶのが合理的です。
さらに旧画面と比較するときも、一番成績の良かった画面と比較すればよく、2番目以下のものは検討する必要がありません。これは単に手間が省けるというだけでなく、比較の回数を減らせることにメリットがあります。
データはランダムな不確実性を含むため、統計的に優位な差があるという結論を得られたとしても、一定の頻度でそれは間違っているのです。比較の回数が多くなるということはそれだけ間違いを含みやすくなり、これは検定の多重性問題などといいます。
今回各画面を見た人数が異なった結果、「サンプル数は多いが微妙な結果」と「サンプル数は少ないがいい結果」を比較する手間が増えたほか、それを判断することで間違うリスクも余分に負ってしまいました。
どうすればよかったのか
この点については適用ロジックを記録するに尽きます。
フロントで画面を見ている人からすると、見ている画面が同じなのに違うラベルを付けるのは違和感があるかもしれませんが、ロジックを評価するという観点からはそのようにするのがよいと考えます。
あるいは時間があるのであれば、各画面に遷移する条件とはどのようなものかを考察し、その条件ごとに検証を行ってもよいでしょう。ただ、その簡便さを魅力に感じてABテストを行うわけですので、少し難しい選択肢になりそうです。
必要なデータ数などの議論ができなかった
問題点
ABテストは先に述べたようにガードレールの役割を果たす手法です。このためどの程度の結果であれば本格的なリリースを取りやめるかの基準を決めておかなくてはいけませんが、このあたりの相談を十分に行うことができませんでした。
繰り返しになりますが、データにはランダムな不確実性があるので、ロジック1がロジック2より0.01%多くクリックをもらえたからと言って、必ずしもロジック1の方が優れているとは結論付けられません。これだけの差を検出するためには十分な量のデータをためる必要があります。
逆に十分な量のデータがない状態でこのような差を検出しても、統計的には「証拠不十分」となってしまいこれ以上何も言えません。
そのため、期待するクリック数の増加量と、確保できる実験期間などと総合的に相談してデータ量を決める必要がありますが、当時はそのような知識が不足しており、十分な根拠をもとに実験条件を決定することができませんでした。
どうすればよかったのか
このようなことは企画段階で相談を行っておくべきだったと思います。そのため、分析の必要性や目的を関係者に伝達しなければいけなかったと思います。
また、私としてはこういった内容を事前に勉強しておく必要がありました。データ量の決定には検出力関数を用いますが、分析対象によって、まとどれだけの精度を求めるかによって結果が変わってくるので、注意して検討する必要があります。
最後に
今回は初めて分析を担当しましたが、分析はデータさえとればどうとでもなるようなものではなく、計画段階でよく検討を行っておく必要があるということを学びました。
また、分析者としてただ分析結果を提供すればよいわけでもなく、関係者とよくコミュニケーションをとりながら進めていく必要性も感じられました。
次回以降の分析プロジェクトが少しでも建設的なものになるようにしたいです。