Top Challenges from the first Practical Online Controlled Experiments Summit
TL;DR
OCE (A/Bテスト) についてテックカンパニー12社が集まって、挑戦や難しい部分を話すサミットのまとめ A/Bテストで陥る困難とその解決策を分類してまとめた論文
13-14, 2018, USAで行われた
概要
Airbnb、Amazon、Booking.com、Facebook、Google、LinkedIn、Lyft、Microsoft、Netflix、Twitter、Uber、Yandex がこのサミットに参加
これらの会社は合わせて、100,000回以上の A/Bテスト を去年行った A/Bテスト は理想的には、同じ時期ですればAとBの間の機能の差しか出ない (が当然そんなことはない) グループごとの違いを計測するのに t-検定 などを用いることもある Top Challengesを分類すると以下
Analysis
通常は2週間やそこらの数値しか見ないが本当は、長いスパンでの効果を知りたい
解析の正しさや予想・結果分析の正しさを担保するのが難しい
Engineering and Culture
プロダクトに関わる人全員の理解が必要
またツールを使ってエンジニアリング目線での効率化が必要
Deviations from Traditional A/B Test
ユーザーセグメントや機能以外の差をしっかりと分析しないとバイアスが含まれた分析結果になってしまう
Data quality
データ自体のクオリティをどうやって担保するか
以下、紹介されてるChallengeをそれぞれ紹介する (以下CHはChallengの略)
CH1. Estimating the long term effect
課題
追加した機能のKPIへの影響が長い時間かかることがある
例えば、
宿泊サービスでは、ユーザーの満足度は泊まるまで測定するのは難しい
広告を入れて検索のクオリティを下げると数週間の間は revenue があがるかもだけど、数ヶ月後には下がるかもしれない クリックしたくなるようなバナーを出すと、クリック数はあがるかもしれないけど、ユーザーがコンテンツのクオリティが低いことを理解して満足度を下げるかもしれない
解決策
Long-term Experiments or Holdouts
長い期間の結果が欲しいからといって、長い時間 A/Bテスト を走らせるのは会社のagilityを下げるのでよくない アップデートがしばらくないユーザーグループを作るのも方法の1つだが、これも当然あんまりよくない
ちなみにブラウザのcookieなどに保存されてるGUIDを用いるのもよくない、複数のデバイスからAとBどちらにも含まれることにもなるので注意しないといけない
MicrosoftやTwitterでは、長い期間計測するときには結果を測定するときの2週間前と比較したりする
例えば4週間計測が必要だった場合には、0週目と1週目、1週目と2週目...と相対的に比較して長い期間の結果を推定したりする
Proxies
長い期間の結果を表現できる Proxies (代わり) を見つけることで長い期間の結果を推定することが一般的
Netflixでは、ロジスティック回帰などを用いて長い期間のユーザーの retention を推定している LinkedInでは、LTV に基づいたモデルを作成している Uberでは、市場の影響を考慮した macro-economicsモデルを作成している
この方法には、デメリットもあって相関が結果に紐づかない場合もあるので誤用を招きやすい
Modeling User Learning
Googleは、User Learning effects を長い期間の実験によってモデリングした
User Learning effects = 多分、機能に気づいたり、機能を使うためにユーザーが学習するフェーズのことだと思う
長い実験の中でいくつかのグループに対して時間差で機能を提供して、それぞれを比べてどれくらいで効果が出るのかというのをモデリングした
これによって短い結果だけで長い期間の結果を予測できるようになった
いくつかのサンプリングデータを生成して近い波形 (サロゲート) を見つけることで擬似的に長い結果を得る手法
Facebookは7日のデータを2,3日のデータによって推測したりしている
CH2. OCE: Overall evaluation criterion metircs
課題
OCE のメリットの1つにはデータによって意思決定が可能というものがある 個人に依存した意思決定をすることを HiPPO と呼び、否定している データドリブンな意思決定をするためにはいくつかのmetricsを考えないといけない
またmetricsを含めてOCEを構成する要素である データの結果が信用できるかどうか
実験の結果が信用できるかどうか
実験の成功には関係ないが、毀損したくない数字もある
よい OCE (metrics) を見つけるのは大変である 長い期間のKPIの指標を測定するものでないといけない
達成が難しくないといけず、正しいことをするインセンティブになる設計でないといけない
要するに誤ったことをして達成できる指標ではだめ
敏感に結果が影響する指標でないといけない
KGIによい結果をもたらすための様々なシナリオを網羅していないといけない
いろんなシナリオを収容できていないといけない
時間などを取得せずに、クリック数だけしか取得していなければ、シナリオがわからなくなってしまう
解決策
Search vs Discovery
検索体験の指標の分析は、長い間研究対象になってる
以下が一般的によいとされてる
Happiness、Engagement、Adoption、Retention、Task Success
PULSE に基づく metricsを毀損してはいけない数値 Page views、Uptime、Latency、Seven-days active users、Earnings
HEART を計測するために様々な方法が提唱されてる しかし単純な問題ではなく、以下のユーザーは同じ行動で対立する結果を出す
目的が決まっていて探しに来ているユーザー
だらだらと検索して探求しているユーザー
Product Goals and Tradeoffs
複数のKPIがトレードオフになる場合
Aが上がってBが探す場合には何を成功と呼ぶかが個人に依存してしまう
Bingではこれらの明確に比率を決めていて意思決定の統一をしている
Evaluating Methods
OCE で測定している項目が本当に正しいかということを考える必要がある MicrosoftやYandexは今までの結果を分析するコーパスを使って、項目の更新や評価をしている
有名な例は、MicrosoftやGoogleがわざと検索結果の速度を遅くする実験などを行ってる
Using Machine Learning in Metrics
指標分析にMLを使うのが流行ってる
新しい指標が入らないような成熟してしまったプロダクトではさらに改善するにはMLなどを使った分析が必要になる
一方でがんがん新しい機能を入れることができているプロダクトは普通にやればよい
MLにも問題点があり、アルゴリズムがブラックボックス化してしまうことが多々ありそれ自体を評価することが難しくなるという問題がある
CH3. Heterogeniety in treatment effects
課題
セグメントに応じた OCE の効果の差をどうやって分析するか 誰にとって良い結果だった、誰かにとって悪い結果ではなかったか
解決策
Common Segment
ユーザーセグメントを以下の指標でわけるのは一般的
複数の市場に向けたプロダクトを作ってる場合には市場
国によってわける
ユーザーの行動のレベル
ヘビーユーザーやライトユーザーや新しいユーザー
デバイスやプラットフォーム
多くの研究でiPhoneとAndroidのユーザーは異なると言われている
週末や平日などの時間
プロダクト独自のセグメント
LinkedInはリクルーターと普通のユーザー
Twitterはメインアカウントとサブアカウント
Netflixはネットワーク速度とデバイス
Airbnbは前の予約の時の天気や、Airbnbのどのページに最初にたどり着いたか
Methodology and Computation
測定方法は、昔からよく研究されていて線形回帰が一般的である
しかし問題は当然まだまだあり特に以下が難しい問題とされている
Computation Scale
1人1人のデータを見ても仕方がなく、シンプルなアルゴリズムで全体を解析したい
Low Signal Noise Ratio
セグメントなどにわけてしまうと母集合が小さくなってしまう
Multiple Testing Problem
metricsもいくつかあったり、セグメントがいくつもあると分析が複雑になってしまう
Interpretable and memorable
多くの実験者は、統計や機械学習の専門家ではないので、説明のために解釈しやすくわかりやすいサマリーを書くことが必要
Absoulute and Relative
異なったセグメント間で正規化するために、相対的な結果を使うべき
具体値では、セグメント間で結果がわからなくなってしまう
これらの問題の解決策として
on-demand analysis と scheduled analysis を明確にわける
:thinking_face: omuomugin.icon
Low Signal Noise Ratio の問題に対しては、スパースになってるモデルが必要
理解しやすいレポートを作るためには、何が伝えたいかをしっかりと書く
Correlation is not Causation
Xという変量によって結果はわかるが、それが必ずしも原因というわけではない
例えば、iOSとAndroidでセグメントを切っているときに結果が異なることは理解できるがiOSとAndroidが原因かどうかはわからない
CH4. Developing experimentation culture
課題
OCE が活発じゃない組織で OCE を導入するのは難しいかもしれない アイディアをデータによって否定されると精神的によくない
しかし失敗はカスタマーに悪い機能を提供することを避けることができたし、ビジネスを毀損しないで済むので喜ばしい結果である
プロダクトバックログにずっと眠ってる価値があるかどうかわからないタスクを試してみて実験して価値があるかどうかを実際に見ることができるというメリットもある
解決策
Experimentation Platform and Tools
仮説検証をするコストが低く、結果が信頼できないといけない
そのためにはツールの開発、導入が必要である
Practices, Policies and Capabilities
正しく実験や分析するための方法がいくつかある
High Touch
LinkedInやMicrosoftでは、分析のサポートチームと一緒に働いてサポートする
デメリットは、コストが高いのでスケーリングのボトルネックになりかねない
Top down buy in
支配力の高い人がいれば、「あれやれ」「これやれ」をリードできる
Netflixでは Product Strategy という場で実験をする人たちの間で結果をディスカッションして実際に本番にするかどうかを ピアレビュー する Negative and positive case studies
期待していた以上の結果があると導入しやすい
その結果を見せることで、データの必要性を説得できる
Safe Rollout
MicrosoftやGoogleでは、全てのユーザーに安全に機能をリリースするように全てのデプロイで自動的にちょっとずつユーザーに提供している
Report cards and Gamification
成績表のようなものを出したり、ゲームっぽくしてモチベーションアップを促してる
Education and support
全ての実験を少人数で観測するのは不可能なので、分散する必要がる
そのためには次の章で細かく議論するが、サポート体制や教育体制を作る必要がある
CH5. Training Others in the organization to scale experimentation
課題
だけど、分析や実験を実際にするのは難しかったり、知識が必要だったりする
中央集権的なサポートチームは、スケールしないので知識を広げていく必要がある
解決策
Yandexの例 (Experts on Experiment)
社内資格を用意する
全ての A/Bテスト は、社内の有資格者の承認を通らなければならない 自分のプロダクトの承認プロセスを早くするためみんな資格を取るインセンティブがある
Amazonの例 (Weblab Bar Raisers)
A/Bテスト について相談する会を 2-4時間 / 週 設けてて、有資格者が答えてくれる 資格を取得するインセンティブは、自己の成長とミッションにサポートを組み込みこと
Twitterの例 (Experiment Shepherds)
こちらも資格を付与してる
責任と成果に取り入れることができるのがインセンティブ
Booking.comの例 (Experimentation Ambassador)
Twitterと同じような形でアンバサダーを用意している
Microsoftの例 (Center of Excellence Model)
分析専門チーム (データサイエンス系のチームかな) がいて、プロダクトチームの近くでサポートする
そこでプロダクトチームに知識を広げて、成熟しきったら他のプロダクトチームに移る
毎週、実験についてフィードバックをそのチームから得られる会も開催している
Googleの例 (Just in time Education Model)
実験をするときに埋めるべきチェックリストがある
そのレビューやサポートをMicrosoftと同じようにする
違いは、
実験の結果の分析をサポートする機会がある (Just in timeに起こる)
分析チームによるパターンの発見 (meta-analysis)
CH6. Computation of experiment analysis and metrics
課題
数百のテストが同時に走るようになると、データのパイプラインやワークフローの多くを自動化して生産性をあげるようなツールが必要になる
ツールは以下の要件を満たすべきで
ツールの全ての要素は、数万ユーザーに対して、数百のテストを同時実行できるほど、効率的で早くないといけない
非中央集権にして、全てのユーザーが使えるようにしないといけない
結果が正しいようにある程度のクオリティコントロールの機構が必要
featureチームが新しい計測項目などを追加できるように柔軟でなくてはならない
解決策
Data Management and Schema
データパイプラインをどうやって作るかという話
依存と柔軟は、トレードオフになる
データを整形するところまでやって、計測やクエリなどはチームでやる
LinkedIn
Facebook
Airbnb
Timely adn Trustworthy Experiment Analysis
分析チームによって結果を出す
Microsoft
Google
Booking.com
Lyft
LinkedInはmetricsを更新する場合には、クオリティ確保のために承認が必要
いくつかの会社では、意味のある変化が生じるかどうかを事前にテストしないといけない
Metric ownership
metricsには一般的に明示的なオーナーや暗黙的なオーナーがいる
metricsによって誰と会話すべきかを明確にしておく必要がある
Mictosoftでは、大きな変化がmetricsに現れたら実験者とオーナー両方に自動で通知がいく仕組みになっている
Supporting Exploratory and Advanced
新しい計測手法を導入するときには注意深く考える
明確な手法はまだないが以下の質問に答えるとよい
新しい手法は、信頼できるか?他にも応用できるくらい一般的か?
新しい手法は、混乱や導入コストに対してROIが高いか
過去の手法と別の結果が出た場合にはどちらを信頼すべきか
分析結果を正しく解釈するためには、どのようなガイドラインが必要か
CH7. Dealing with client bloat
課題
多くの A/Bテスト はフィーチャーフラグなどに隠れており、これをオンにするようなconfigをダウンロードしたりする 多くのテストが同時に走れば走るほど、多くのconfigをダウンロードすることになりこれはパフォーマンスの問題を引き起こす
解決策
あるバージョンでその機能が確定した場合には、configを必要としないようにしなければならない。
したがって全てのconfigは 実験中には min version コードが綺麗になったあとには min max version が必要になる
max version 以降はconfigを送信しないでローカルの値もしくはフィーチャーフラグを片付ける
CH8. Network interactions
課題
あるユーザーが他のユーザーに影響を及ぼす場合には、これを考慮するのが非常に重要である
これを考慮しないとバイアスにさらされた結果が出る
解決策
Producer and Consumer Model
何かをpostする機能と読み取る機能は別々に実験する必要がある
例えばハッシュタグを投稿、閲覧できるような場合には投稿者がProducerで閲覧者がConsumerとして、Producerを最初割合を低くして出す
同時に A/Bテスト してしまうと投稿者の効果が低くなってしまう。なぜなら閲覧者が少ないので。 Producerを 50 : 50にして、Consumerを 95 : 5 とかにすると結果を測定できるようになる
Known Influence Network Model
ユーザー間にネットワークがある場合には、ネットワークに基づいたクラスタリングとランダム化が行われる
egoClusterという (論文が文献としてあがってるのでそちらを見るのが良さそう) omuomugin.icon
One-to-One Communication
1 : 1のコミュニケーションモデルの場合には、4つのカテゴリでメッセージ数を測定して実験する
新しい機能が見える
オリジナルのまま
1 : 1 で新しい機能とオリジナルが混ざってる
Skypeでは会話それぞれをランダムに振って音声通話のクオリティを測定した
Market Effects
例えば、ライドシェアサービスでは、マッチした場合にはその近くの運転手はマッチする確率が減る
Lyftはこれに対して、場所や時間でクラスタリングをしてランダムに振っている
広告系でも、A/Bで広告の効果が異なり、A/Bで広告の効果をそれぞれで食いつぶして全てを世に出すと実は効果を出さないということがある。
Multiple Indetities for the Same Person
1ユーザーが複数のアカウントを保持できるとき、それをシンプルにA/Bテスト してしまうと効果を低く見積もってしまう。 Facebookの調査では、cookieレベルのランダム化は2、3割効果が変わってくることがわかってる
factor of 2 or 3 は割合なのか倍数なのかわからなかった omuomugin.icon
CH9. Interactions between multiple experiments
課題
複数の非独立な実験があると効果が計算できなくなる
数百のテストを行うとなれば、これは大きな問題になってくる
解決策
一般的なソフトウェア企業では小さなチームで独立して開発しているため、ほとんどの A/Bテスト は独立するはずである GoogleやMicrosoftでは、 同じ numberlines や layer で複数のテストが走るときには、集合のXORを取ることになる。
例えば Aというテストが50:50で走ってるときには、オリジナルになっている 50 に対して 50 : 50 でテストすることになる (100人の場合には、50人、25人、25人というグループになる)