#paper
[https://exp-platform.com/top-challenges-from-first-practical-online-controlled-experiments-summit/](https://exp-platform.com/top-challenges-from-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]] があがるかもだけど、数ヶ月後には下がるかもしれない
- クリックしたくなるようなバナーを出すと、クリック数はあがるかもしれないけど、ユーザーがコンテンツのクオリティが低いことを理解して満足度を下げるかもしれない
- [[2 sided markets]] では、マーケットの状況によっては結果が変わってしまうかもしれない
- 解決策
- 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 = 多分、機能に気づいたり、機能を使うためにユーザーが学習するフェーズのことだと思う
- 長い実験の中でいくつかのグループに対して時間差で機能を提供して、それぞれを比べてどれくらいで効果が出るのかというのをモデリングした
- これによって短い結果だけで長い期間の結果を予測できるようになった
- Surogates ([[サロゲート]])
- [[サロゲート法]] によって長い期間の結果を推測する
- いくつかのサンプリングデータを生成して近い波形 (サロゲート) を見つけることで擬似的に長い結果を得る手法
- Facebookは7日のデータを2,3日のデータによって推測したりしている
# CH2. OCE: Overall evaluation criterion metircs
- 課題
- [[OCE]] のメリットの1つにはデータによって意思決定が可能というものがある
- 個人に依存した意思決定をすることを [[The Dangerous Animals of Product Management]] と呼び、否定している
- データドリブンな意思決定をするためにはいくつかのmetricsを考えないといけない
- またmetricsを含めて[[OCE]]を構成する要素である
- データの結果が信用できるかどうか
- 実験の結果が信用できるかどうか
- 実験の成功には関係ないが、毀損したくない数字もある
- よい [[OCE]] (metrics) を見つけるのは大変である
- 長い期間のKPIの指標を測定するものでないといけない
- 達成が難しくないといけず、正しいことをするインセンティブになる設計でないといけない
- 要するに誤ったことをして達成できる指標ではだめ
- 敏感に結果が影響する指標でないといけない
- [[OCE]] を実行するコストが高すぎてはいけない
- KGIによい結果をもたらすための様々なシナリオを網羅していないといけない
- いろんなシナリオを収容できていないといけない
- 時間などを取得せずに、クリック数だけしか取得していなければ、シナリオがわからなくなってしまう
- 解決策
- Search vs Discovery
- 検索体験の指標の分析は、長い間研究対象になってる
- 以下が一般的によいとされてる
- [[HEART]] に基づくmetricsを [[OCE]] の分析として
- Happiness、Engagement、Adoption、Retention、Task Success
- see also [https://ai.google/research/pubs/pub36299](https://ai.google/research/pubs/pub36299)
- [[PULSE]] に基づく metricsを毀損してはいけない数値
- Page views、Uptime、Latency、Seven-days active users、Earnings
- see also [https://ai.google/research/pubs/pub36299](https://ai.google/research/pubs/pub36299)
- [[HEART]] を計測するために様々な方法が提唱されてる
- しかし単純な問題ではなく、以下のユーザーは同じ行動で対立する結果を出す
- 目的が決まっていて探しに来ているユーザー
- だらだらと検索して探求しているユーザー
- Product Goals and Tradeoffs
- 複数のKPIがトレードオフになる場合
- Aが上がってBが探す場合には何を成功と呼ぶかが個人に依存してしまう
- Bingではこれらの明確に比率を決めていて意思決定の統一をしている
- Evaluating Methods
- [[OCE]] で測定している項目が本当に正しいかということを考える必要がある
- MicrosoftやYandexは今までの結果を分析するコーパスを使って、項目の更新や評価をしている
- 意図的に毀損するようなものをリリースして [[OCE]] がこれを検知できるかという [[degradation experiment]] を行っているところもある
- 有名な例は、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: <img src='https://scrapbox.io/api/pages/omuomugin/omuomugin/icon' alt='omuomugin.icon' height="19.5"/>
- 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
- 課題
- [[A/Bテスト]] のアイディアはシンプル
- だけど、分析や実験を実際にするのは難しかったり、知識が必要だったりする
- 中央集権的なサポートチームは、スケールしないので知識を広げていく必要がある
- 解決策
- 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という (論文が文献としてあがってるのでそちらを見るのが良さそう) <img src='https://scrapbox.io/api/pages/omuomugin/omuomugin/icon' alt='omuomugin.icon' height="19.5"/>
- One-to-One Communication
- 1 : 1のコミュニケーションモデルの場合には、4つのカテゴリでメッセージ数を測定して実験する
- 新しい機能が見える
- オリジナルのまま
- 1 : 1 で新しい機能とオリジナルが混ざってる
- Skypeでは会話それぞれをランダムに振って音声通話のクオリティを測定した
- Market Effects
- [[2 sided markets]] では、需要供給の曲線が影響を及ぼす
- 例えば、ライドシェアサービスでは、マッチした場合にはその近くの運転手はマッチする確率が減る
- Lyftはこれに対して、場所や時間でクラスタリングをしてランダムに振っている
- 広告系でも、A/Bで広告の効果が異なり、A/Bで広告の効果をそれぞれで食いつぶして全てを世に出すと実は効果を出さないということがある。
- Multiple Indetities for the Same Person
- 1ユーザーが複数のアカウントを保持できるとき、それをシンプルに[[A/Bテスト]] してしまうと効果を低く見積もってしまう。
- Facebookの調査では、cookieレベルのランダム化は2、3割効果が変わってくることがわかってる
- factor of 2 or 3 は割合なのか倍数なのかわからなかった <img src='https://scrapbox.io/api/pages/omuomugin/omuomugin/icon' alt='omuomugin.icon' height="19.5"/>
# CH9. Interactions between multiple experiments
- 課題
- 複数の非独立な実験があると効果が計算できなくなる
- 数百のテストを行うとなれば、これは大きな問題になってくる
- 解決策
- 一般的なソフトウェア企業では小さなチームで独立して開発しているため、ほとんどの [[A/Bテスト]] は独立するはずである
- GoogleやMicrosoftでは、 同じ `numberlines` や `layer` で複数のテストが走るときには、集合のXORを取ることになる。
- 例えば Aというテストが50:50で走ってるときには、オリジナルになっている 50 に対して 50 : 50 でテストすることになる (100人の場合には、50人、25人、25人というグループになる)