ついに1週間空いてしまいましたが、第6弾です。

前回はエンジニアチームとどのようにプロダクトを作っていくかについて書いたので、今回はできたプロダクトが実際にどのくらいのインパクトを生んでいるのか、逆にマイナスに働いていることはないかを計測する方法について書いてみます！

Measurement 101

前回までのプロセスを踏んで作ってきたプロダクトですが、実際にインパクトはどうやって計測したらいいんでしょう？

一番単純に思いつきそうな方法は、プロダクトをリリースした前後で計りたいメトリックが変わったかを計測する、ですかね？
実は結構これがトリッキーで、この方法だと必ずしもそのプロダクトのインパクトを正確に計測できるとも限らないんですね。

ちょっと前になってしまいますが、前々回で使用した航空会社の例を使ってみてみましょう。

前々回で、航空会社の「飛行機遅延によって顧客が離れてしまう(churn)」という問題に対して、仮に「アプリの通知機能を使って遅延時のゲート、荷物到着情報を搭乗者に伝える」という機能を作って解決されるかみてみるというのを例に挙げてみました。

この例の場合ですと、仮説が正しい場合、「通知機能をリリースすることで飛行機遅延によって離れてしまう顧客の数が減る」はずです。

なので、実際にプロダクトをリリースして、飛行機遅延後に離れてしまう顧客の数(カスタマーチャーン)が減ったかを測ったとします。測った結果先月と比べてカスタマーチャーンが5%減っていました。

これを見ると「おぉ、この機能はカスタマーチャーンに効果があったんだ」と思ってしまいそうですが、本当にそうでしょうか？

もしかしたら先月は年末で、そもそも普段利用しない顧客がたくさん利用していて、結果そういった顧客は戻って来ず、今月は普通の月なのでビジネスユーザーの比率が高く、そういった顧客はそもそも利用頻度が高く、同じ航空会社を使いがちなのかもしれません。その結果今月のカスタマーチャーンがたまたま先月に比べて低かっただけかもしれません。

また、もしかしたらマーケティングチームが今月割引キャンペーンを行なっていて、たまたま今月多くの顧客が戻ってきただけかもしれませんし、たまたま、今月はライバル会社が先月の年末商戦との調整で価格を大幅に上げたので、相対的に両方の会社を利用しているユーザーが自分の会社に来ただけかもしれません。

こんな風に、世の中に起きていることを全て完璧に把握して、「そういったことが全く起きていないので、この5%は確実にプロダクトをリリースしたことによる効果です」と言えればいいのですが、多くの場合世の中に起きていることの全てを把握することなんてできません。

仮に実は何もしなければ先月に比べてカスタマーチャーンが30%減っていたのにプロダクトを出したせいで5%しか減らなかったとなっていた場合、「このプロダクトをリリースしたおかげで5%チャーンが改善したんだー！よし、もっとアグレッシブにこのプロダクトをロールアウトしていこう」なんてしてしまうと、気づかないうちにどんどん状況を悪くしていってしまいます。

こんなことにならないように、プロダクトのインパクトを正確に測る手法の一つが実験です。
そして、その実験の中で一番一般的なのはA/Bテストです。

広義のA/Bテストはインターネットマーケティングにおける施策の良否を判断するために、二つの施策同士を比較検討する行為全般を指す。

Wikipedia (Japanese) – A/Bテスト

なんかWikipediaの解説は結構広義な意味の解説をしているっぽくて、そのまま鵜呑みにしてやると上記のリリースの前後測定同様間違った結果が出てしまうことがあるので、(プロダクト、マーケティング含めた)ソフトウェア業界での文脈でちょっと書いてみます。

Experimentation 101 – A/B Testing

Overview – Treatment & Control

ソフトウェア業界では、基本的にA/B Testingというと、ユーザーを2つのグループに分け、1つを現状維持のグループ(コントロール)、もう1つを新たな施策を試すグループ(トリートメント)として一定期間片側にだけ新たな施策を試し、コントロールとのメトリックの違いをその施策のインパクトとする、という実験のことを指します。

Randomization

A/B Testingで一番大事なことは、このコントロール、トリートメントのグループ分けです。

上記の航空会社の例でもあったように、世の中に起きていたかもしれないいろんな事象を全て把握するのは不可能ですし、仮に把握できたとしてもそれら全てを計算要素に入れてプロダクトのメトリックへのインパクトを計算するのも大変です。

A/B Testingは、コントロール、トリートメントのグルーピングをランダムに行うことでこの問題を解決しようとしています。世の中で自分の関知しない事象があったとしても、ユーザーをランダムにコントロールグループ、トリートメントグループに分けていくことで、その事象に関与しているユーザーの割合がコントロールとトリートメントで一緒になります。なので、コントロールグループとトリートメントグループ全体でみると、その事象による影響はキャンセルされて、コントロールグループとトリートメントグループでの違いが、この実験で試したかった施策(航空会社の例でいうと通知機能の有無)だけになり、コントロールグループとトリートメントグループで計測されたメトリックの違いは全てその施策が原因であると言えるようになる。という感じです。

Statistical Significance & Sample Size

上記で解説したようにコントロールグループとトリートメントグループをランダムにアサインすることで、インパクトを計測したいもの以外の効果を無効化できるのですが、本当に無効化するためにはもう一つ条件があります。それが、コントロールグループとトリートメントグループにそれぞれたくさんのユーザーがいることです。

コインを投げて表が出る確率が1/2でも実際投げてみると3回連続で表が出ることがあるように、ランダムにアサインしても偶然特定の要素を持つユーザーが一方のグループにいっぱい入ってしまうことがあります。

数が少なければ少ないほど1回の偶然が起こすインパクトは大きく、逆に数が多くなれば1回の偶然が起こすインパクトは小さくなります。(表が出る確率が1/2のコインは3回投げて全部面になることはたまにありますが、100万回投げたら大体表と裏の出た回数が一緒になるというのと同じ感覚です)

ここで行うのがサンプルサイズの計算です。簡単に言うとコントロール/トリートメント間の違いが偶然によるものでないというために必要なユーザーの最低人数が何人なのかを計算し、実験に必要なサイズを決定します。

そしてこの「コントロール/トリートメント間の違いが偶然によるものでない」ということを統計的有意性(Statistical Significance)と言います。現実的には100%の確率で絶対に「コントロール/トリートメント間の違いが偶然によるものでない」ということを言い切るのはとっても難しいので、実務的にはこの「コントロール/トリートメント間の違いが偶然によるものでない」確率が何%だったら安心/満足できるかを決めます。多くの場合90%〜95%以上の確率で「コントロール/トリートメント間の違いが偶然によるものでない」と出るのであれば、きっとそうなんでしょうというのがソフトウェア業界での一般的な統計的有意性のスレッショルドです。(もちろんテストしたいものや実験の文脈によってこの値をいくつに設定するのかは変わります)

そしてこの%をいくつにするかで必要になってくるサンプルサイズも大きく変わります。プロダクトマネージャーはできるだけインパクトを正確に計測したいのですが、それに必要なサンプルサイズが大きすぎると計測が終わるまでに時間がかかりすぎ、機敏にプロダクト開発ができなくなってしまうので、この二つのバランスを取って実験のスペックを決めます。

実際のサンプルサイズの計算方法は、「A/B Test Sample Size Calculator」等でググると大体便利なウェブ計算機が出てくるので、割愛します 笑

Wrap Up

実験やメトリックの計測は、UX(ユーザーエクスペリエンス)とならんでザ・シリコンバレーなプロダクト開発の核となる部分です。特に(あくまで個人的な主観ですが)ウーバーはMetrics Obsessionと言われるくらいデータ、メトリックス、実験に、会社として強みを持っていて、いかに速く正確にインパクトを計測してそれを元にプロダクトを改善していくかについて、結構他では得られないような学びを得られた気がします。その点についても今回でカバーしたかったのですが、長くなってしまったので一旦切って、次回その辺の僕なりの学びについて紹介してみようかなーと思います！