はじめに
はじめまして。2021年4月にエブリーに入社した山西と申します。
データサイエンティストとしてデータ関連部門に所属後、DELISH KITCHENアプリ改善施策のA/Bテストに約3ヶ月間従事してまいりました。
今回はその実業務の中での体験も踏まえ、A/Bテストにおける評価指標の選定プロセスや苦労したポイントなどを紹介していきます。
A/Bテストについて
DELISH KITCHENのアプリでは機能の改善に向けたUIやアプリ内動線等の変更を定期的に実施しております。
このようなアプリ機能の変更はユーザーの体験を多かれ少なかれ変化させるものであるため、ユーザー視点、および事業視点で良い効果が見込めるものを見極めたうえでユーザー全体へ展開するのが望ましいといえます。
そこでエブリーでは、プロダクトマネージャーがアプリ機能変更施策を企画し、データサイエンティストがA/Bテストによりそれらの効果を事前検証することで、変更を施すべきか否かの意思決定への還元を行っています。
A/Bテストは、文字通りAパターン（変更前）とBパターン（変更後）の結果を比較する手法です。
「とあるアプリ機能の変更施策」の文脈においては、一部ユーザー（テスト群）のみに介入した結果の効果を、変更を施さなかったユーザー（コントロール群）と比べて検証する手法とも言い換えられます。
あらかじめ検証期間を定めて行うのが一般的であり、その期間内でテスト群がコントロール群よりもどの程度良くなったか（または悪くなったか）を評価指標を用いて統計的な見地から判断する、という流れをとります。
以下、その流れを簡潔にですが整理します。
A/Bテストの流れ
プロダクトマネージャー、データサイエンティストが連携しつつ実施することとなります。
データサイエンティストが主体となるのは2~6のフェーズとなります。
1. 施策の企画
プロダクトマネージャーが施策の案を企画し、データサイエンティストへ共有、内容の精緻化を行う。
2. 評価指標の選定
施策の効果を測るために事前設定しておく指標を選定する。
※ とある機能の継続率や訪問回数などのユーザーのエンゲージメントを測る指標や、CTRやCVRなどのビジネス上注視すべき指標が例として挙げられる。
3. 対象ユーザーの抽出
アプリ利用ユーザーをランダムに抽出した後、コントロール群（施策を実施しないグループ）とテスト群（施策を実施するグループ）に分ける。
4. 施策の実施
テスト群のユーザーに対してアプリ機能の変更を適用する。
5. 結果の集計
アプリのログを各評価指標へと集計するSQLクエリを作成。
コントロール群とテスト群それぞれに対して算出した評価指標値の有意差検定や信頼区間の推定を行う。
各集計値の比較結果を表や時系列グラフで表現し、ダッシュボードにまとめる。
6. 結果の報告
プロダクトマネージャーにダッシュボードを共有すると共に結果を報告する。
有意差の有無や効果量の結果レポート、及びそこから得られる考察を述べつつ議論する。
7. 意思決定
A/Bテストの結果を省みて、施策を全ユーザーに適用するか否かの判断、または追加施策の実施の有無について判断を下す。
本記事では以後、2.の評価指標を選定するプロセスについて掘り下げていきます。
評価指標の選定
前述の通り、施策の効果による「良し悪し」をA/Bテストによって見極めるためには、その目的にあった評価指標を設定する必要があります。
エブリーでは現在、以下の指標分類フレームワークをその選定基準として採用しております。
指標の分類
これらの分類は書籍『A/Bテスト実践ガイド』にて提唱されているものです。
要点を整理し紹介いたします。
ゴール指標
- ビジネスにおける最終的な目標を直接反映した指標。
- 施策に携わるステークホルダー間で広く受け入れられるようなシンプルなものであるのが望ましい。
ドライバー指標
- ユーザー体験等を元にした、ビジネス目標を間接的に表現する指標。
- 短期的に観察することが出来、その変動が捉えやすいという特徴を持つ。
- ゴール指標の代理指標としての役割も担う。
ガードレール指標
- 施策が問題なく進行しているか確認するための指標
- 予期せぬバグ等でユーザー体験が悪化してないかを確認する指標
また、優れたオンライン実験を設計するためには各指標が『短期的（実験期間内で）に測定可能であり、計算可能であり、十分に敏感（分析感度）で即時的（即時性）に反応するものでなければならない。』ことが書籍『A/Bテスト実践ガイド』で指摘されています。
つまり、計算するためのログが存在し集計可能であること、それらが有限である検証期間内に測定可能であり、さらにその変化が観察できることを確かめたうえで、ゴール、ドライバー、ガードレールの枠組みに照らし合わせながら評価指標を選んでいくことになります。
このようなA/Bテストに向けた評価指標に求められる観点は、ビジネスでの報告目的で用いられる指標の観点とは一致しないケースが多々あることにも留意する必要があります。
指標の実装
施策の目的と指標分類のフレームワークを照らし合わせながら評価指標を洗い出し、それらが集計可能であること（元となるログが存在していること）を確認した後は、各々の評価指標を集計するためのSQLクエリを作成します。
その後、ダッシュボード上にこれらのクエリを登録し、表やグラフとして可視化します。
このようにして、A/Bテストの結果をダッシュボードを軸に報告、考察および意思決定へ還元する準備が整います。
大変だったこと
次に、施策の目指す向きをうまく表現する指標を選定したり、それを実装へ落とし込むために元となるログ周りを理解したり、さらにプロダクトマネージャーと連携したりする過程で大変だったことについて紹介します。
指標の選定作業
ゴール指標の代理指標の設定
本来は上記の指標の分類にて挙げたゴール指標で施策の良し悪しの意思決定が出来れば理想ですが、実際には代理指標（指標の分類でいうところのドライバー指標）を設定し、これを主要な指標として観察していく場合も多々あります。
主な理由として以下2点が挙げられます。
ゴール指標が遅行指標（数値として現れるには一定の期間が必要な指標）であり、施策実施期間終了まで、すなわちビジネスにおける意思決定のタイムリミット時点までに十分な観察が行えない。
ゴール指標には関連する因子が多くあることが想定されることから、施策によってその一部に介入を行っただけではほとんど変化しない恐れがある。
この際には代理指標としての妥当性（擬似相関になっていないか、因果関係まで整理できているか）の模索に、多くのリソースを割かなければなりません。
施策の影響範囲を見極めた集計
ひとえに施策の効果を測るといっても、集計対象とするユーザーをどう選ぶかでその意味合いは大きく変わります。
例えば「アプリトップ画面→機能A→機能B→機能C」と遷移するアプリ内動線の中で機能Cに介入するA/Bテストを実施する場合、機能Cを利用したユーザーのみ集計するのか、それより前の動線のユーザーも集計対象に含めるか、を注意深く設定しないと求めたいものと乖離する場面が多々ありました。
求めたいものに応じてどう集計するか、以下2パターンに整理します。
「使った人がどう反応するか」を知りたいとき
機能の使い心地に介入するような施策を打った場合は、その機能が利用されない限り効果を測ることが出来ないため、機能利用実績があるユーザーのみを集計対象とするのがふさわしいといえます。
ユースケースとしては「ユーザーが必ず1回は利用または訪問するであろう機能のデザインに対して介入する施策を打ったとき、2回目以降の利用が伸びるか否か」を判断したいとき等が挙げられます。
「使わなかった人がどれだけ使ってくれるようになったか」も含めて知りたいとき
アプリ内動線の追加や、デザイン変更等で機能の利用を促す施策を打った場合はその機能の獲得傾向に興味があるため、注目する機能を利用していないユーザーも集計対象となります。
このケースではまず施策検証期間内に、アプリトップ画面にアクセスしたA/Bテスト対象ユーザー全体を対象に集計することが多くなります。
しかし、「注目する機能があまり使われていないときに指標を平均値として集計したい」場合は、単なる全アプリアクセスユーザーの平均値を出すと0に非常に近い値が出てしまい意味のある解釈が難しくなってしまいます。
その際には集計対象を「該当機能により近いアプリ内動線を利用したユーザー」に絞ったうえで平均値を算出する場面もありました。
このようにして「どのユーザー集団に対して平均を取り、そこから何を知りたいのか」をイメージしながら意味のある指標に落とし込むにはアプリのUI/UX側の深い理解が必要だと感じました。
アプリ内の機能、動線にどのようなものがあるか把握しておくことはもちろん、各機能のアプリ利用傾向を普段からモニタリングしておくことで、求める分析軸に対して適切な指標を設計する目を養っていきたいと思いました。
ログ周りの理解
ログの仕様および状態の確認
評価指標を実装するためには当然その元となるログの存在が前提となるため、選定時点でそれらの仕様を頭に入れておく必要があります。
また、アプリ内OSの特定のバージョンでのバグ発生等により、ログが汚染され評価指標として正しく集計できなくなっている場合は、事前にその影響を排除する措置を取ったうえで指標をデザインする必要があります。
しかし、複雑なクライアント・サーバーサイドの実装背景を咀嚼したり、大量に存在するアプリ内動線から必要なログを洗い出したり、さらにそれらが正しく記録されているかをモニタリングしたりするのは中々に骨が折れる作業でもあり、入社後しばらくは評価指標一つの集計クエリを書くだけでも多くの時間を費やす日々が続いてしまいました。
こうした経験から、アプリ内のユーザーの動きがログとしてどのように反映されているか、そのログが何処に格納されているか、さらに仕様変更や更新、バグ等にも目を張り巡らせておくこともデータサイエンティストの重要な役割であることを実感いたしました。
実装したい評価指標に対応するログが存在しない場合の対処
もし評価指標の実装に必要なログが存在しない場合は、以下のいずれかの選択肢を取ることになります。
クライアント・サーバーサイドで新たに実装してもらう
代替、近似できるような既存ログを探す
これらのうちどの方向に舵を切るかは、当該指標のビジネス的な重要性、意思決定までのタイムリミットから逆算した施策の実施期間、他部署のリソース等の間のトレードオフ関係の熟慮ののちに各ステークホルダーと相談することによって決定されることとなります。
データ側の視点から、こうした調整を円滑に進めることの難しさも実感しました。
プロダクトマネージャーとの連携
わかりやすく説明する能力
流れの説明にて解説した通り、A/Bテストの狙いはその分析結果をプロダクトマネージャーへ報告し、そこから意思決定につなげる洞察を得ることです。
それを円滑に行うため、「データサイエンスの見地をわかりやすく、かつ誤解無く説明する」能力がデータサイエンティスト側に求められることとなります。
評価指標を解釈する観点、有意性の解釈の仕方、懸念事項などの多くの情報をどのようにしてまとめれば簡潔にアウトプットできるか、試行錯誤の毎日です。
評価指標についてのすり合わせ
指標の分類の項でも述べたように、プロダクトマネージャーが追跡するKGIなどのビジネス指標とA/Bテストとして設定する評価指標は必ずしも一致しない場合が多くあります。
例えば、一般的にKGIとして利用されるビジネス指標の多くは短期的に変化を観察するのが困難であり、そのままA/Bテストで追っていくとすると多くの場合ゴール指標の代理指標の設定にて説明した懸念に直面するため、この場合はより効果検証にふさわしい代理指標を主に見ていくことになります。
そのため「なぜA/Bテストとしてその評価指標を選定したのか」「どう解釈すれば良いか」等の認識をプロダクトマネージャーとデータサイエンティスト側でしっかりと認識を合わせておく必要があります。
最後に
「コントロール群とテスト群を比較する」というコンセプトだけ聞くと単純明快な印象を受けがちなA/Bテストですが、それを良質な意思決定へつなげるためには一筋縄にはいかない工夫が必要であることをこの数ヶ月間の業務で改めて認識しました。
分析要件とアプリ側のドメイン知識を相互に照らし合わせつつ、試行錯誤も繰り返しながら最適な指標を見定める力を付けていきたいと思います。
最後までお読みいただきありがとうございました。
参考文献
Ron Kohavi,Diane Tang,Ya Xu,大杉 直也.(2021)「A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは (Japanese Edition) 」
Alex Deng, Xiaolin Shi. Data-Driven Metric Development for Online Controlled Experiments: Seven Lessons Learned. In Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, KDD, 2016
