こんにちは！ @hatuyuki4です。普段はiOSアプリ開発をしているエンジニアです。豆乳が好きです。
先週の前篇では、ABテストで検証を行うための仮説の立て方とサービスへの落とし込み方について書きました。
しかし高速で検証を行うためには、仮説を立てて機能を実装すればそれで終わりというわけではありません。
重要なのは、「適切に施策を振り返り、結果を分析し、どのように次に活かすのか」です。
今回は、「ABテストのリリース〜振り返り」のポイントについて書きたいと思います。
ABテストの実施
トクバイアプリでは、これまで本格的なABテストを実施したことがなかったので、まずは環境を整えることにしました。
サーバサイドの実装なしでABテストを実施できるとは、昨今は便利になりましたね。
Firebase Remote Config
Remote ConfigはFirebase上で設定したパラメータを、アプリの実装なしに受け取れる機能です。
これは全体のユーザの○○%にのみ公開するという表示の設定ができるので、ABテストのような機能の出し分けを簡単に実施できます。
ちなみに、Firebase A/B テストというABテスト用のFrameworkもあるのですが、今回は使うのを見送りました。
Remote Configに比べてコンバージョンイベントやバリアントなどを細かく設定でき、どちらがより効果があるのかもコンソール上で見られるため便利なのですが、
ABテストの数によっては設定に時間がかかり、結果が出るまでにも時間がかかってしまうため、今回のようなスピーディな検証には向かないと判断しました。
ABテストの問題点
Remote Configを使えば簡単にABテストを実現できますが、それだけで問題なくABテストができるわけではありません。
自分たちのチームもプロジェクトを進めていく上で、いくつかの問題点にぶち当たりました。
1.検証フローが整っていない
要因が重なって効果がわかりづらい
今回は新規ユーザの定着率向上を目的にしていました。
しかし、定着率という複合的な要因によって変動する指標では、複数のABテストを同時に実施した場合、それぞれの施策の効果がわからなくなるという問題が発生しました。
1バージョンに1つの検証だと、スピード感がでない
かと言って、1つのバージョンで1つの検証しかできないのでは、iOSとAndroidで別の施策を行ったとしても月4つまでしか検証できず、スピード感が出せません。*1。
画面構成を見直す大きな改善から文言変更などの小さな改善まで、多種多様なABテストを実施しようとしていたので、このままだと時間的余裕がなくなってしまいます。
2.効果があったのか測定できない
検証を行って実際に数値を見てみた場合、その差は様々なものになります。
3%以上差があるもの、1%以下しか差がないものなど、数字にはバラツキが多く、誤差（たまたま数字が良かっただけ）と本当に効果があったものの区別が付きません。
もしこの区別がつかない場合、本来は効果の低い機能を正式リリースとして組み込んでしまう恐れもあります。
1.ABテストの検証フロー
上記のような問題が発生したので、まずはリリースフローを再考しました。
アプリのリリースサイクルは変えることなく、以下のように複数のABテストを期間を分けて実施する方式に変えました。
| Day | Sprint Event | Test1 | Test2 | Test3 |
|---|---|---|---|---|
| Week1 月曜 | Sprint開始 | テスト1開始 | ||
| アプリ リリース | ||||
| 木曜 | テスト1 終了 | テスト2 開始 | ||
| 金曜 | テスト1 振り返り | |||
| Week2 月曜 | テスト2 終了 | テスト3 開始 | ||
| 火曜 | アイディア会 | テスト2 振り返り | ||
| 木曜 | テスト3 終了 | |||
| 金曜 | AppStore 申請 | テスト3 振り返り |
複数のテストを期間を分けて実施
アプリには、アップデート時にあらかじめ、3つの検証を含めてリリースします。それをRemote configを使ってそれぞれ別の期間に公開を分けます。
これにより、iOSとAndroidをあわせて6検証まで行えるようになりました！これで、だいぶスピード感をもって検証を繰り返せますね。
検証期間
今回のフローでは、スピードを重視したので、1つのABテストの検証期間は短めの3~4日程度にしました。
テスト内容や求める効果、アプリの規模、その機能を利用するユーザ数などによって、最適な検証期間は変わってくるかと思います*2。
細かな振り返り
はじめは、チームの振り返りを2週間に1度、sprintの最終日に行うようにしていました。
しかしこれだと、施策の結果を振り返って改善の仕様を検討し、次のsprintに間に合わせるための時間は取れませんし、次の次のsprintとなると、せっかく得たスピード感が活かせません。
そこで1つのABテストが終わるごとに、チームでの振り返り会を実施しました。
これにより、検証から発展させた施策を次のsprintに間に合うように用意でき、またチーム内の会話・議論も増え、コミュニケーションの場としても有用に働きました。
ちなみに、振り返りの日をテスト終了から1日ずらしているのは、今回の検証が新規ユーザの定着率を目的にしたものだからです。
(新規ユーザの定着の定義を「次の日に起動したかどうか」で判定していたので、翌日にならないと定着率がわかりません)
これが別の指標を測るためのABテストなら、振り返り日は別途調整したほうがよいかもしれないですね。
2.ABテストの効果測定
ABテストの実施と検証フローの整備により、施策による定着率の変動が定量的に分かるようになってきました。
次に、「2.効果があったのか測定できない」を解決するため、統計的検定方法の1つ、カイ二乗検定を用いました。
カイ二乗検定
カイ二乗検定（カイにじょうけんてい）とは、帰無仮説が正しければ検定統計量が漸近的にカイ二乗分布に従うような統計的検定法の総称である
Wikipedia
カイ二乗検定は、まずはAとBの効果には違いがないと仮設を立てます(帰無仮説)。
この帰無仮説を棄却できる＝効果があったと結論できることで、ABテストの有効性を証明しようというものです。
検定シート
チームでは、このカイ二乗検定を測定できる検定シートを作り、施策の効果に有意差があるのかどうかを確認しました。
これによって、定着率の差が偶然かそうでないかがはっきりとわかり、どの施策を残すべきかの意思決定がしやすくなりました。
自分はカイ二乗検定の計算方法を理解したくてシートを自作しましたが、カイ二乗検定を用いたABテストの有意差判定を公開しているサイトもあるので、シートを作る必要はないと思います。
終わりに
サービス開発にはスピードを求められるケースが多々あります。
ABテストを適切に行えば、効果があった施策は自信を持って全体にリリースできますし、効果がなかったら何故かを考え、次の施策に活かせます。それは意思決定のサイクルを早めることにつながります。
サービス開発は意思決定の連続です。その意思決定を高速にできるようになれば、開発やサービスの成長スピードをあげる助けになるのではないかと思います。
