さて、半年以上空いてしまいました 笑
前回からの間にコロナの流行とかいろいろありまして、忙しく過ごしていました。最近になって、またBuilder’s Playbookシリーズを書いた後に書きたいものを思いついたので 笑 気を取り直して続きを書いていきたいと思います!
前回は世に出したプロダクトが実際にどのくらいのインパクトを生んでいるのか、逆にマイナスに働いていることはないかを計測する方法の基礎的な部分について書きました。今回はそれを踏まえて実際に現場で学んだMeasurementのノウハウを紹介してみたいと思います!
Measurement Acceleration
前回でカバーしたような実験/A/Bテストを行う場合、発生条件が極端に低い事象(例えば事故などの100万回に1回程度の頻度で起きる事象)を扱うプロダクトでは統計的有意性のある結果を得るまでに相当な時間がかかってしまいます。計測ー改善のサイクルを速くまわすためには、このデータ収集がボトルネックになりがちです。僕は今のチームの特性上そういう系のプロダクトを結構作ってきたので、そこで学んだいくつかのタクティクスを紹介します。
Cycle Time Measurement
Problem
例えば、Eコマースのサイトでユーザーがある商品を買ってから次にサイトに戻ってくるまでの時間を短縮するような機能を作ったとします。(例えばユーザーに送るレシートの下に「それを購入されたならこんなものも必要じゃないですか?」みたいなレコメンデーションを添付する機能とか)
この機能が実際に効果があるのかを確認するためには、A/Bテストで「ユーザーが戻ってくるのにかかる時間」に差があるか測定すると思うんですが、
例えば今のユーザーが戻ってくるのにかかる時間の平均が2週間だった場合、測定にものすごく時間がかかります。
平均2週間ということは1日で戻ってくる人もいれば、2ヶ月後に戻ってくる人もいるわけで、戻るべきユーザーが全て戻ってきてからでないと平均の計算ができないからです。
この場合ユーザーが戻る平均時間は2週間でも、99%のユーザーが戻るのにかかる時間は3ヶ月かもしれません。
ということは、この機能をリリースしてから、
- まず必要な数のユーザーにこのリコメンデーション付きのレシートが送付されるのを待つ
- 平均を計算するためには全部のユーザーが帰ってくるまで待たなければいけないので、実験期間の最後のレシートが送付されてからさらに3ヶ月待つ
というステップを踏まなくてはいけないので、めっちゃ時間がかかります。
Solution
こういう場合によく使われるメトリックが「ある一定期間の間に戻ってきたユーザーの割合」です。「平均」を使うと最後に戻ってくる数人のユーザーが数値に与える影響はとっても大きいので、最後の最後まで待たなければいけないのですが、「ある一定期間の間に戻ってきたユーザーの割合」をメトリックにすれば、その設定した期間だけ待つだけでメトリックが計測できます。
上記の例の場合、「2週間で何%のユーザーが戻ってきたか」という形で効果を測ることによって、待たなければいけない期間が「平均」を使った場合の3ヶ月から2週間に短縮できます!
とっても便利なメトリックなのですが、測定のスピード短縮の大きなメリットが得られる分、使用に注意しなければいけない点もあります。
「設定した期間までの効果しか測定しない」という点です。
上記のレコメンデーション付きレシートの例で言うと、「このレシートを見なくても2週間以内にサイトに戻ってきたであろうユーザーがレシートを見ることによってどれだけ速く戻ってくるか」は測定できるのですが「このレシートを見ないと戻ってくるの2週間以上かかっていたユーザーがこのレシートを見ることで不快に思って戻ってくるのにより時間がかかるようになった」という事象が起きていないことは測定できません。
こういうネガティブなインパクトが起きている可能性がある場合は「2週間で何%のユーザーが戻ってきたか」を実験のメインのメトリックにして、このメトリックに効果があった場合はこの機能を全ユーザーにリリースするという決断をしておいて、1ヶ月後、2ヶ月後に「このレシートを見ないと戻ってくるの2週間以上かかっていたユーザーがこのレシートを見ることでどうなっているか」を確認しながら、実験で確認された効果を上回るネガティブな効果が観察されたらリリースを巻き戻す、というような措置も必要になってきます。
Metric Decomposition
Problem
上記で使った例の続きで説明してみます。
上記のレコメンデーション付きレシートは、実験の結果「2週間で戻ってくるユーザーの割合」が6%増えるというポジティブな効果ありという結論になり、全ユーザーにリリースされたとしましょう。ただ、このメールで送っているレシートの開封率は60%で、チームとしては、もっと多くのユーザーにレシートを見てもらうことで「2週間で戻ってくるユーザーの割合」がさらに増えるだろうと考えているとします。
もっと多くのユーザーに見てもらうアイディアとして、メールだけじゃなく、アプリの通知でレシートの確認を促そうというのを思いつきました。
この場合もゴールは前回と同様「2週間で戻ってくるユーザーの割合」を増やすことなので、これを指標にしたいと考えています。
ただ、これまでの他の機能の実験結果からアプリの通知で期待できる開封率の増加はEメールの10%程度とアナリティクスのチームから報告がありました。ということは期待できる「2週間で戻ってくるユーザーの割合」に対する効果は「レシートにレコメンデーションをつける」という機能の10%程度ということになります。
前回よりも小さな効果を測定しなければいけないので同じメトリックを使うのであれば、統計的に有意な結果を測るのに必要なユーザー数が増えるので、結果として必要なユーザーにアプリの通知を送る期間が増えてしまいます。特に厄介なのが、「統計的に有意な結果を測るのに必要なユーザー数」は「測定したい効果」が小さくなるにつれ指数的に増えるので、今回のケースのように測定したい効果が10分の1の場合、必要なユーザーは数10倍から数100倍になってしまいます。
Solution
ここでよく使うのは、「メトリックの分解」です。
レシートレコメンデーションがどのように「2週間で戻ってくるユーザーの割合」に影響を与えているかを考えてみると
レシートを見るユーザーの数 ✖️レシートを見ることによって2週間以内に戻ってくる割合の増加率=2週間で戻ってくるユーザーの割合
という図式で表せます。
上記のアプリ通知は、この図式の中だとProblem Sectionでも書いた通り「レシートを見るユーザーの数 」を増やす役割を担っていると思います。同様にアプリ通知機能は単純にレシート機能へのトラフィックを増やすだけでレシートのデザインには一切関与していないので、「レシートを見ることによって2週間以内に戻ってくる割合の増加率」には理論上一切の影響を与えないはずです。
であれば、「2週間で戻ってくるユーザーの割合」を直接測るのと、「レシートを見るユーザーの数 」の増加率を測って「レシートを見ることによって2週間以内に戻ってくる割合の増加率」に影響がないことを測ることが同じことを証明できていると言えます。
このように最終的に測りたいメトリックを分解して、代わりに各要素を測ることで計測を早めることができるんです!
理論的な説明だけだとあまりピンと来ないかもしれないので、実際に数字を当てはめてみたいと思います。
上記のProblem Sectionで、レシートのレコメンデーション機能が60%のユーザーに利用されていて「2週間で戻ってくるユーザーの割合」を10%程度増やしたことが判明しました。
これを上記の図式に当てはめると
レシートを見るユーザーの数(60%) ✖️レシートを見ることによって2週間以内に戻ってくる割合の増加率=2週間で戻ってくるユーザーの割合の増加率(6%)
なので「レシートを見ることによって2週間以内に戻ってくる割合の増加率」は10%となります。
ここで、アナリティクスの予測通り、アプリ通知機能をリリースすることで「レシートを見るユーザーの数」が10%増え、「レシートを見ることによって2週間以内に戻ってくる割合の増加率」が変わらないとすると
レシートを見るユーザーの数の増加率(10%) ✖️レシートを見ることによって2週間以内に戻ってくる割合の増加率(10%) =2週間で戻ってくるユーザーの割合の増加率(1%)
となり、「2週間で戻ってくるユーザーの割合」にあたえる影響は1%となってしまい、その1%の違いを測るためのサンプルサイズが必要になります。
前述のようにMetrics Decompositionを使うと、「2週間で戻ってくるユーザーの割合(1%)」の代わりに「レシートを見るユーザーの数の増加率(10%)」を測ることになるので検出しなければいけない違いが10%になり、必要なサンプルサイズが大幅に減ります。
Summary
このように実験の基本を踏まえた上で小さなテクニックを使うことで、実験のサイクルを大幅に加速させることができます。今回紹介したのはどちらも簡単に使えるテクニックだと思うので、実際にA/Bテストを現場で使用している方は使ってみてもいいかもしれません。
Switchback
実験サイクルの加速に加えてもう一個、僕個人的にはあんまり学問的に勉強しなかったけども現場で学んで「おぉ」と思ったコンセプトにswitchbackがあります。
上記のMeasurement Accelerationで示したような、機能が直接単一のユーザーに影響するものであれば、単純なA/Bテストで十分有効なのですが、Facebookや、Amazon、Uberなどのマーケットプレイス的なプラットフォームプロダクト(需要サイドと供給サイドがあるプロダクト)でマーケットプレイス全体へのインパクトを与えるような機能は単純なA/Bテストで正確なインパクトを測ることが難しいです。
例えばUberでいうところのサージプライス。
サージプライスというのは、Uberを利用するときに、その利用する時間と場所における需要の多さに応じて追加料金をとるという機能です。ラッシュアワーのオフィス街などで、需要が多すぎて利用可能なドライバーが全て利用されてしまっていて本当に利用したいユーザーが利用できないという状況を改善できるように開発されました。
サージプライスが設定されると値段が上がるので、利用したいユーザーの数は減り、もらえるお金が増えるので利用したいドライバーが逆に増えます。この効果を利用して需要と供給のバランスをとるのですが、こういった機能(例えばサージプライスのアルゴリズムAとアルゴリズムBを比べる)の場合、同じ時間にユーザーをA/B、ドライバーをA/B に分けてAグループのユーザーとAグループのドライバーを、BグループのユーザーとBグループのドライバーをマッチするという方法をとってしまうと、そもそものマッチされるユーザー、ドライバーの全体数が実際のユーザー、ドライバーよりも小さくなってしまい、サージの効果を正確に計測することができません。(マーケットプレイスは、参加するユーザーの数によって市場の効率性に大きな差が出ます。)
これを解決するためにswtichbackを使います。
Switchbackは、同じ期間にユーザーをA/Bに振り分けるのではなく、一定期間を複数個のグループに分け、その各時間にAを使用するかBを使用するか切り替えるというコンセプトです。
ここで重要なのはこの期間のグループ分けで、一定期間の間になるべく多くのグループがあった方がいいのですが、各グループの長さもその機能の効果を測るのに十分な長さがなくてはいけません。
一番単純な例だと、1週間を基本期間として24時間単位のグループを7個作り、1週目の1、3、5、7日目はAのアルゴリズム、2、4、6日目はBのアルゴリズムを使い、2週目の1、3、5、7日目はBのアルゴリズム、2、4、6日目はAのアルゴリズムを使うという感じです。
一定期間を分けるグループ数を奇数個にし、偶数期間と奇数期間でアサインされる機能が交互になるようにすることで、シーズナリティを軽減することができます。
実際には分けるグループはもう少し細かくて、例えば、1週間を一個160分のグループ63個に分け、機能AとBを交互に160分ずつ使用する(そうすると1週間でそれぞれの機能が交互に21回、22回ずつ使用されることになります)
Switchbackをサポートするためにはマーケットプレイス自体にサポートするための機能をつけなくてはいけないので初めて行う時のハードルは結構高いのですが、プラットフォーム企業ではこういった機能が市場の効率性やその他のメトリックに大きな影響を及ぼすため、しっかり投資して正確に効果を測っている会社が多いです。
After-thoughts
ということで、僕個人的に現場で学んできたノウハウを書き留めてみましたが、いかがでしたでしょうか?笑
書いてて、内容がなんか当たり前すぎるような気もしつつ、でも逆にマニアックすぎるような気もしつつなので、正直どこまで需要があるのかはわかりませんが 笑
とりあえず、自分用の備忘録としては書きたかったことを書けたんじゃないかなと思います 笑