背景
現在、私が携わっている pjt では、ある機能の利用率を向上させるため、アジャイルに改善の開発を進めています。
その中で挙がった課題の1つとして、画面流入後の離脱率がありました。本機能を利用するためには、ある画面に遷移していくつかの項目を選択した後、ボタンを押下することが必要なのですが、押下する前に離脱してしまうユーザが一定存在する、というものです（あるあるな課題の1つではあると思います）。
課題へのアプローチを考える中で、初期の入力項目を選択することが手間なのではないか？（ので、めんどくさくて次に進まない）という仮説が挙がり（こちらもあるある）、それを検証するために A/B テストをすることになりました。
A/B テストについて
A/B テストは、対照実験（ある要因の効果を明らかにするために、その要因以外の条件をできるだけ同じにした2つ以上のグループを比較する実験手法）の一つです。
今回はユーザを次のように2つのグループに分けました:
- （実験群） 画面表示時に、選択項目の一部の入力の手間を減らす
- （対照群） 今まで通りに全て選ばせる
その上で遷移率（機能の利用率）に変化があるか？を比較することにしました。
モニタリング方法
モニタリングの方法は、いくつも考えられますが、できるだけ労力をかけない構成を選択しました。具体的には
- Google スプレッドシートで結果を見れるようにする
- データソースとして BigQuery を設定し、SQL で結果を直接出力する
- 統計的判断のための指標は、Google スプレッドシート上の関数で計算する
です。これは、今回の A/B テストはごく一時的なものである（そのため、BI ツール等を用いて、継続的にモニタリング体制を整えるほどでもなかった）という理由と、そもそも、ある程度のデータ分析のための体制が整えられていた、という前提があります。
（１）機能の流入時や利用時に、ログ出力が行われていた
機能の流入タイミング、また画面遷移のいくつかのタイミングにおけるバックエンド処理内で（本機能の利用がわかる識別子とともに）ログ出力が行われていました。
このログは（いくつかの経路を辿った後） BigQuery に書き込まれており、利用できる状態でした。
（２）上記のログが、ユーザごとのレコードとして格納されていた
これらのログは、パイプラインを経由して、最終的にデータマートとして利用率を追っており、その途中のテーブルを利用することで、ユーザの行動ログを確認することができました。
あとは、クエリをいい感じにき、スプレッドシートに適切な設定をすれば、サクッと結果が見られるようになりました（実際に手を動かした時間としては、2-3時間程度だった気がします）。
統計的判断
モニタリングを行う上で、統計的有意性の観点から検証することは重要です。確率的な信頼度を検証することで、A/Bテストで得られた差が、偶然ではなく、本当に施策の効果であるかとを判断できるようになります。実際には、p 値を計算し、統計的に有意な差が出たかどうかを判断しました。
こちらの計算についても、Python を用いるとか、クラウド上で自動化するなどの方法も考えられますが、できるだけ労力をかけずにスプレッドシート上の関数を用いることにしました。
まとめ
勘と経験を排除して意思決定することの大切さを学びつつ
- （ログや基盤が）整っているから、すぐモニタリングできた
- データ分析基盤の内容について、プロダクトサイドのメンバで多少理解している人（私）がいたので、作業ハードルが低かった
といった観点も重要だなぁと思うに至りました。