Giter Club home page Giter Club logo

papers's People

Contributors

shyaginuma avatar

Stargazers

avatar

Watchers

avatar

papers's Issues

Democratizing online controlled experiments at Booking.com

Meta

どんなもの？（著者は何をやりたかったの？）

Booking.comでどのようにA/Bテストが活用されているかを紹介する

Contents

Central repository of successes and failures

PMだけでなく誰もがA/Bテストのアイデアを思いつくためには過去のA/Bテストの知見がまとまっている必要がある。
必要な要素は以下

  • チーム
  • テストによる変更箇所
  • ターゲットセグメント
  • テスト初期の仮説
  • メトリクスの動き
  • 最終的な意思決定

検索可能にするというのが難しい。例えば、「what were the findings related to improving the clarity of the cancellation policies in the past year」のような問いに答えること。タグでの運用はうまくいかなかったとのこと。

Genericity and extensibility

クロスプラットフォームでのユーザー追跡を可能にするロジックがある。（tracking methodと呼ばれている）

Adding a new tracking method can be done by any developer and we now have more than a dozen ways to identify visitors across all our products.

Booking.comのようなアプリもWebも使われる可能性のあるプロダクトでは重要になってくるそう。

Data which can be trusted

A/Bテストでは意図しない結果となることが多くあるため、数字が信頼できるものであるということがとても重要。

データが正しいということのチェックに、二つの全く別のログから計算された数値があっているかをチェックしている。

We monitor the validity of the data used for decision making by computing a set of common metrics in two entirely separate data pipelines maintained by different engineers who do not review each other’s code, one doing near real-time aggregations (less than a five minutes’ delay) and one doing daily batch updates.

計算方法が正しいことの保証に、A/Aテストを行ったいくつかのケースを使ってテストを行っている。

Finally, we also monitor the statistical framework used for decision making by maintaining a pool of AAs (experiments whose treatment does not introduce any sort of change) which allow to validate its theoretical properties (e.g. false positive rates or the statistical distribution of metrics).

Building safeguards

selective attrition: 解放後にその変更を目にする機会があるユーザーが集計に入っていない状態を指す。

議論はある？

  • A/Bテスト結果を一元管理することの価値はとても高いと感じる。こうして見てみると、そのA/Bの評価に使われたメトリクスとそれがどのくらい動いたのか、そしてテストの開始時期さえきちんと取れていれば検索可能というのは担保される気がする。
  • selective attritionについて、コンセプトは理解できたが実際にA/Bで起こる気がしなかった。

次に読むべき論文はなに？

特になし

Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners

Meta

どんなもの？（著者は何をやりたかったの？）

Sample Ratio Mismatch(SRM)というABテストの結果の信頼性を著しく侵害する現象の定義をし、そのパターン化や検出方法、事前に回避する方法をまとめること

先行研究と比べてどこがすごい？

  • SRMという用語を定義したのがおそらく初めて
  • ABテストの実行プロセスに応じて遭遇するであろうSRMの型を定義している。おそらく遭遇するSRMのほとんどを網羅できている。

技術、手法のキモはどこ？

image

この図にこの論文の全てが凝縮されている。

Sample Ratio Mismatch(SRM)とは？

一言で言うと、各variantに割り当てられるunitの割合が想定とずれることを指す。

例：以下のようなシンプルなABテストを想定する。

  • variants: treatment, control
  • weight: 0.5:0.5
  • unit: user_id

ここで、各variantに割り当てられるunit数の比（ # in treatment / # in control ）が1であることが期待されている。実際に計測を行った際、0.9など離れた値が確認され、適合度のカイ二乗検定などの統計的手法によって有意性が確認された時、SRMが起こっていると確認できる。

SRMはABテストのvariant割当以外でも発生する。例えば、分析の段階で特定のアクションをとったuser_idを分母にした指標で評価を行うとする。（Triggered Analysis）この時、分母となるuser_id数に不均衡が発生していればSRMが起こっていると見做され、分析結果の信頼性は低下する。

例：検索エンジンの検索結果の広告効果測定

  • 背景：自社がGoogleのような検索エンジンの検索結果に広告を出稿しているとする
  • 変更箇所：検索結果に出稿している広告ページのタイトルを注意を引くようなものに変更するとする。（広告ページの内容は変更なし）
  • 評価指標：広告ページからのCVR（例：購入数/ページ訪問数）

この場合、検索結果の文言を変更したことによってtreatment群において広告ページへの流入増加が期待される。一方でtreatment群においてページの内容に変更はないので、購入数においては変化がないと仮定すると、分母となる訪問数が増えたことによってCVRは低下する。ここでは訪問数と言う評価指標の分母にSRMが生じており、これによって分析結果が全く当てにならなくなってしまうことが確認できる。

SRMのパターン

  • Experimentation Assignment
    • variantのアサインの段階で発生するSRM
    • 実は他のテストのアサインと相関しているなど
  • Experiment Execution
    • Experimentの実行中に発生するSRM
    • バグで途中でvariantが変わってしまうなど
  • Experiment Log Processing
    • ログ収集段階で発生するSRM
    • 特定variantのログの欠損など
  • Experiment Analysis
    • 分析の段階で発生するSRM
    • フィルタリングが適切でないなど
  • Experiment Interference
    • 外側からの影響によるSRM
    • ユーザーが意図的にvariantをスイッチさせるなど

SRMを防ぐにはどうする？

それぞれのSRMに対して有効な対処法、検知方法があるがまとめると以下のようになると感じた。

  • SRMの存在を設計者が理解すること、理解した上での実験設計を行うこと
  • SRM metricsやdata quality metricsを定義しモニタリングすること

どうやって有効だと検証した？

  • Microsoft, Booking.com, Outreach.ioの過去のABテスト結果やData Analystへのインタビューを行っている

議論はある？

null

感想

今まで自分がABテストを設計、分析していく中で遭遇したあの現象はSRMと呼び、またそれがSRMのほんの一部であることを知った。システマティックにできる部分はシステムに実装してExperimentationの信頼性を高めて行きたい。

次に読むべき論文はなに？

  • Referenceに書いてある論文ほぼ全て

Engineering for a Science-Centric Experimentation Platform

Meta

どんなもの？（著者は何をやりたかったの？）

  • NetflixのExperimentation PlatformのSoftware Architectureについての論文
  • 次の要件を満たすように設計されている
    • Scalable：グローバルスケールのデータ規模にも耐えうること
    • Performant：実験結果が数秒や数分以内に計算できること
    • Cost efficient：ストレージや計算コストをできるだけ抑えること
    • Trustworthy：再現可能な結果を計算すること、計算が正しいこと
    • Usable：初見でも簡単に使うことができること
    • Extensible：Data Scientistが拡張可能なこと

先行研究と比べてどこがすごい？

  • Engineering for a Science-Centric Experimentation Platform というタイトルの通り、Science部分はData Scientistが拡張できるようにmetrics, causal modelsに統一的、直感的なインターフェースを提供し、EngineeringとData Scienceの共存を達成できていること
  • Science部分をData Scientistに任せることでエンジニアはパフォーマンスの部分に集中することができている

技術、手法のキモはどこ？

大きくPerformant, Extensibleがコアだと感じた

Performant

  • Pre-compute vs Live-compute.
    • よく使われる切り口でのブレークダウンは事前に計算しておく
      • userの国、OSなど
    • それ以外の切り口でのブレークダウンはadhocに計算する
  • Data compression
    • 正規分布を仮定する場合、ローデータを全て保持するのではなく、平均と分散のみ保持するなど
  • その他、自分の知識では字面を追うことしかできなかったが様々なEngineering的な工夫が施されていると感じた

Extensible

  • Metrics Repo
    • 下のようなクラスを書くとクエリを自動で生成してくれる
    • メトリクス定義の一元的管理が可能になる

  • Causal Models
    • In-houseなPythonのライブラリ
    • Metrics Repoからデータを受け取り、サマリ的統計量やATEを返す
    • 入力と持つべきメソッドを抽象化してある（scikit-learnのような感じ）
      • 入力：
        • y: The metric that needs to be measured
        • X: A binary variable indicating whether a user received treatment
        • W: Other features that are useful for modeling the variation in y
        • t: A variable for indexing time
        • θ: Hyperparameters for a model
      • 持つべきメソッド
        • train: モデルのトレーニング
        • predict: 介入がされた時とされなかった時のアウトプットの予測

どうやって有効だと検証した？

  • どのくらいのメトリクスが新規に作成されたか
  • 何人のDSがCausal Modelsにコントリビュートしたか

議論はある？

Next frontiersとして三点挙げられている

  • Feature-based analyses
  • Automation
  • Adaptive experiments

中でも Adaptive experiments がとても興味深い

  • テストを走らせている中で自動で意思決定してくれる仕組み
    • 悪い効果があった時に自動でテストを停止してくれる
    • 多腕バンディッドを用いて良いvariantのweightを調整することでビジネス的な機会損失を最小化する

次に読むべき論文はなに？

  • 参考文献の文献には一旦一通り目を通す

Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications

Meta

どんなもの？（著者は何をやりたかったの？）

Webサービスで測定するべきメトリクスを作成するフレームワークの提供（HEART）

先行研究と比べてどこがすごい？

従来からよく見られていた指標としてPALSE metricsがあった。これらはシステムやビジネス面のみカバーしたものだったが、新たにHEART metricsというユーザー行動に焦点を当てたフレームワークを提供しているところ。

技術、手法のキモはどこ？

HEART metricsの分解そのもの。その前に従来からあるPULSE metricsについての説明から

PULSE Metrics

  • Page views
  • Uptime: 稼働時間
  • Latency
  • Seven-day active users (WAU)
  • Earnings

プロダクトの全体的な健康状態のチェックに使用される。とても重要なメトリクス群だが、解釈が難しい場面もある。例えば下記引用。

A change that brings in more revenue in the short term may result in a poorer user experience that drives away users in the longer term.

HEART Metrics

  • Happiness
  • Engagement
  • Adoption
  • Retention
  • Task success

It is not always appropriate to employ metrics from every category, but referring to the framework helps to make an explicit decision about including or excluding a particular category

常に全種類網羅しなければならないわけではない。以下で一つ一つについてメモ

Happiness

  • satisfaction
  • visual appeal
  • likelihood to recommend
  • perceived ease of use

に相当するもの。定期的なsurveyでとるケースが多いみたい。（NPSとか）

Engagement

  • frequency of interaction
  • intensity of interaction
  • depth of interaction

に相当するもの。

例としてGmailでは元々WAUをengagementのメトリクスとしておいていたが、一週間で5日以上Gmailを使った人の割合をEngagement metricsにおいた。long-termなリテンションへの説明性も証明されたとのこと。

With the reasoning that engaged users should check their email account regularly, as part of their daily routine, our chosen metric was the percentage of active users who visited the product on five or more days during the last week. We also found that this was strongly predictive of longer-term retention, and therefore could be used as a bellwether for that metric.

Adoption and Retention

新規 / 既存 のこと。Adoptionはプロダクトや機能の新規利用者数、Retentionは既存の継続率。何を持って継続と見なすのかはプロダクトや機能による。

Task success

  • efficiency: time to complete a task
  • effectiveness: percent of tasks completed
  • error rate

taskが成功したかどうかはログベースで定義しても良いし、UERでも良いとのこと。

Goals - Signals - Metrics

No matter how user-centered a metric is, it is unlikely to be useful in practice unless it explicitly relates to a goal, and can be used to track progress towards that goal.

ただメトリクスを決めるだけでなく、きちんとゴールに沿ったものにするためにはどうすれば良いのか？

  • Goals: まずゴールを定義する。
  • Signals: どのような状態になったら成功/失敗か考える。
    • user behavior
    • attitudes
    • actions
    • feeling, perception
    • 失敗の方が簡単に定義できることもある
  • Metrics: どのように上記のsignalを定量化できるのか考える

感想

  • Google社内での例にも豊富に触れられていてとても参考になった。
  • ちゃんと仕事に活かすぞ

次に読むべき論文はなに？

  • Query Logs Alone are not Enough.
  • Implicit Measures of Lostness and Success in Web Navigation.

Controlling the False Discovery Rate: A Practical and Powerful Approach to Multiple Testing

Meta

どんなもの？（著者は何をやりたかったの？）

先行研究と比べてどこがすごい？

技術、手法のキモはどこ？

どうやって有効だと検証した？

議論はある？

次に読むべき論文はなに？

Statistical inference in two-stage online controlled experiments with treatment selection and validation

Meta

どんなもの？（著者は何をやりたかったの？）

  • 複数のvariantがある時に二段階のA/Bテストを行うことを提案し、その具体的な方法を示したもの
    • screening stage: Bestなvariantを決める
    • validation stage: Bestなvariantとcontrolを比較する

先行研究と比べてどこがすごい？

  • 複数のvariantを設定するA/B testを行う際、controlとbest treatmentの比較だとupwardなバイアスがかかることを示した。
  • それに対応する手法として二段階のA/Bテストを提案し、二つのA/Bテストの組み合わせ方や点推定値の計算方法、またその計算方法をとるための仮定の証明などを行っている点

技術、手法のキモはどこ？

  • 前述の通り

二段階のA/Bテストによって測定されるeffect sizeが独立（従属性が極めて弱い）であることの証明

  • 正確なeffect sizeを求めるために必要な情報である。
  • トラフィックが段階で完全に分離されていれば自明なものとして扱えるが、実際は検出力の保証やInfra側の実装を要するため現実的ではない（となっている）。

Meta-Analysis: Combine Data from Two Stages

  • 二段階のA/Bテストから得られた結果を組み合わせてどのように有意な効果があることを述べるか？
  • 一つの帰無仮説を独立な複数の統計的仮説検定の結果を用いて検定する方法にFisher's methodがある。（Fisher's combined probability testとも言うみたい。日本語名がわからなかった。）

image

複数の統計的仮説検定におけるp値を統合した値がカイ二乗分布に従うことを使って元々の帰無仮説を検定する方法。

最終的に以下の方法をベンチマークとして使用する。

  • screening stageでは、多重比較の問題があるためBonferroniの補正を用いる。（p値をtreatment群の数で割る）
  • validation stageでは、Fisher's methodを用いて検定を行う。

Sharp Multiple Comparison Adjustment

  • Step down法を用いてBonferroniの補正がコンサバすぎることへ対処する。
  • Generalized weighted average testを用いて、screening stageのtreatment effectを推定する。（ここ理解が甘い）

image

Point estimate

  • A/Bテストでは、何が最良か？の他にどのくらい効果があるのか？という問いに精度良く答える必要がある。
  • 普通に考えるとvaliadtion stageで得られた推定値を使えば良いが、screening stageの情報を使わないのは勿体ない。
  • screening stageにおいてどれだけ正確に効果を推定できるかが最終的な効果の推定値の正確さに影響するが、それにはupwardな方向へのバイアスを考慮する必要がある。

Naive-correction estimator

  • 単純にscreening stageでの効果の推定値から、upward biasの推定値を減算する方法
  • biasは軽減するが、varianceが増大する。そしてこれはbiasが元々小さい時に逆に改悪となってしまう。

image

Hは下の形で定義される誤差。Hによってlambdaが決定できることが示唆されている。

image

他の手法

  • Simple linear-correction estimator
  • Bayesian posterior driven linear-correction estimator
  • Beyond simple linear-correction

どうやって有効だと検証した？

シミュレーションによって検証した。

Type-1 Errorの検証

本来の効果が0であり、複数のvariantを持つテストをシミュレーションした。

  • BFでは3.2%ほどとなり、要求よりも厳しい基準となることが示された。
  • WAvgでは5.1%ほどとなり、事前の想定と等しくなることが示された。

検出力の検証

image

疑問点

  • screening stageで効果最大のtreatment群のみに対して検定を行うのであれば、多重比較補正について考える必要はないのでは？
  • どのくらいのvariant数を持っていると、screening stageでのupward biasが無視できないんだろうか？

感想

  • 用途は限定的であると感じた。今のところ現実的に使うイメージは沸いていない。
    • かなり小さな改善しか見込めないA/Bテストであること：この場合、そもそもそこを改善するべきなのか？と言う問いがある。
    • 多くのパターンを試すテスト

次に読むべき論文はなに？

一旦なし

Pitfalls of Long-Term Online Controlled Experiments

Meta

どんなもの？（著者は何をやりたかったの？）

長期間A/Bテストを走らせるときのプラクティス共有

先行研究と比べてどこがすごい？

Long-termなA/Bの評価を行いたいケースはあるが、実際に気をつけるべきポイントなどがまとまっているものがあまりなかった。

内容

3章から実際にPitfallについての説明となっている。
それと、この論文の中でFLT Paperと略されているGoogleの論文(#5) がこの論文の中で多分に引用されており、そちらを読んだ上でこちらを読まないとかなり理解が難しい部分が多い。

COOKIE DELETION AND CLOBBERING

ログインを必須としないWebアプリケーションにおいては、A/Bテストのrandomizationにcookieを用いることがほとんどだが、そこまでstableじゃないので注意が必要。（1ヶ月の間に31%のcookieが破棄されるというリサーチがある）

SURVIVORSHIP BIAS

例えばuserのchurnを促すような施策だった場合、long-termになればなるほどtreatment群に残るユーザーはヘビーに偏る。そこでchurnの様子を噛みできないような指標を用いていた場合、上振れした指標で間違った判断を下してしまうことにつながるので注意が必要。

SELECTION BIAS

TBD

PERCEIVED TRENDS

線が引いてあるのを見ると、何かトレンドを見出したくなるけど実際はそこまで単純ではない。

SIDE EFFECTS

例えばtreaement群において広告のクオリティを高くする実験を行ったとする。このとき、treatment郡ではより広告がクリックされるようになり、さらにアルゴリズムの学習が進む。なので実際の効果以上に効果が現れてしまうことがある。

SEASONALITY EFFECTS

期間中に、片方のvariantだけに影響を与える何かしらのイベントがあった時、効果が歪んでしまう可能性がある。
そしてこれはLong-termになればなるほど起こる確率が高くなる。

次に読むべき論文はなに？

N/A

Data-Driven Metric Development for Online Controlled Experiments: Seven Lessons Learned

Meta

どんなもの？（著者は何をやりたかったの？）

  • A/Bテストにおける評価指標の作成におけるBest Practice的なものをまとめた
  • 評価指標を評価する方法についてもまとめた

先行研究と比べてどこがすごい？

  • 実験結果の信頼性やExperimentation Platform系の論文は過去にあったが、何を持って評価するかというところに焦点を当てた論文は過去にとても少なく、この論文ではその分野に焦点を当てたこと

技術、手法のキモはどこ？

  • Goal metrics(Overall Evaluation Criterion)について、sensitivityとdirectionalityを定義し、それを信頼できる過去の実験リスト（Validation Corpus)で評価することで定量化をしている点
  • Goal metrics, Guardrail metrics, Debugging metricsというA/Bテストにおいて測定するべき3種類のメトリクスを定義している点
    • Goal metrics：directionalityとsensitivityを兼ね備えたA/Bテストの成功判断指標
    • Guardrail metrics：Goal metricsが意図しない方向に動いた時に、Goal metricsの代わりに使えるものや、サービスにとっての重要事項（利益など）が損なわれていないことを確認できる指標
    • Debugging metrics：Goal metricsの解釈を助ける指標

他にもSensitivityには2種類（検出力と動く確率）があり、動く確率がそもそも低い（例えばサービスに費やせる時間的制約を受けるなど）の場合はそのメトリクスで成功を判断するのは難しく、検出力が問題であれば打ち手があるといった切り分けは勉強になった。

議論はある？

  • それでも長期的なゴールと相関があり、sensitivityとdirectionalityを兼ね備えたOECを発見するのはとても難しいとのこと

次に読むべき論文はなに？

  • Measuring the user experience on a large scale: User-centered metrics for web applications.
  • Modeling action- level satisfaction for search task satisfaction prediction
  • Beyond clicks: Query reformulation as a predictor of search satisfaction
  • User behavior as a predictor of a successful search.

Measuring Success with Experimentation

Meta

どんなもの？（著者は何をやりたかったの？）

A/Bテストにおけるメトリクスの設定について、そのプロセスや役割など

技術、手法のキモはどこ？

成功を定義する

  • どのような状態になったら成功とするかを定義し、そこから必要なメトリクスを導く
  • 考えられうるビジネスインパクトとユーザー行動変化の両方を包含したものであるべき
  • まずユーザーストーリーを一番先に考える。良いユーザーストーリーが設定できれば、メトリクスは自然と定まる

成功を測定する

3種類のメトリクスを設定する

  • Primary success metric:
    • 最もダイレクトに実験の成功を決める指標
    • Product metricsであるべき（プロダクトの変更に十分近い位置の指標）
  • Guardrail metrics
    • 毀損したくない指標
  • Secondary/monitoring metrics
    • インサイトを提供するメトリクス

Streaming Video Experimentation at Netflix: Visualizing Practical and Statistical Significance

Meta

どんなもの？（著者は何をやりたかったの？）

先行研究と比べてどこがすごい？

技術、手法のキモはどこ？

どうやって有効だと検証した？

議論はある？

次に読むべき論文はなに？

Focusing on the Long-term: It’s Good for Users and Business

Meta

どんなもの？（著者は何をやりたかったの？）

プロダクトの変更による長期的なインパクトを短期的に測定できる指標から予測すること

先行研究と比べてどこがすごい？

  • 変更の短期的な影響と長期的な影響を分離する測定方法を考案した点（Cookie-Cookie-Day）
  • 長期的な影響を短期的に測定可能な指標で予測し、予測精度が十分に高い点

技術、手法のキモはどこ？

Cookie-Cookie-Day Method

  • Ads blindness, sightednessと言った長期的に見て影響が出るものを定量的に測定するための方法
  • 通常通り、継続的に介入を受ける群と、毎日介入を受ける群を入れ替える群を作成し、効果を比較する

Ads blindnessのモデリング

  • 単純な指数関数でモデリングすることで、長期的影響が収束するのにどのくらいの期間を要するのかを明らかにした

長期的な影響の予測

  • AdRelevanceはCTRなどで測定することができる
  • それだけでなく、LandingPageQualityの変化も組み合わせることによって、より予測精度が上がった

  • 最終的に長期的な収益の増加を短期的な増加と長期的な増加の和で表現することができた。

どうやって有効だと検証した？

  • 過去のGoogleの実験結果から教師データを得た
  • 実際に上記の指標をA/Bテストの評価に用い、実際に長期で見るとその通りの効果が出た

議論はある？

  • 今回の論文はアルゴリズムの変更に関してのものだったため、UI面での変更にも適用できるようにしていきたい
  • nano-model（広告一つ一つに対してもそれによって起こる長期的影響をモデリングすること）

次に読むべき論文はなに？

  • Google. AdWords Help: Understanding Landing Page Experience.
  • G. Hotchkiss. More Ads = Better Ads = Better User Experience: Microsoft’s Success Formula?
  • R. Kohavi, M. Round. Front Line Internet Analytics at Amazon.com.

Reach for the Top: How Spotify Built Shortcuts in Just Six Months

Meta

どんなもの？（著者は何をやりたかったの？）

SpotifyのHome最上部にあるShortcutについて、どのように開発を行ったか

技術、手法のキモはどこ？

Understanding the user experience

まず最初にユーザー行動の把握をしてどのようなものをショートカットに表示すれば便利に使ってもらえるのかを理解した。

Our analysis showed that, over the course of a week, for a given user, a meaningful amount of listening on Spotify comes from a relatively small number of entities.

とても少ないentity（プレイリストやアルバムのこと）から意味のある再生は生成されていることがわかった。

However eclectic our musical taste, once we have discovered a new song or a new album that we really like, most of us have a tendency to play it over and over again.

一度気に入ったものに出会うと、それを何度も聞く行動があることもわかった。

Validating our Hypothesis

our initial hypothesis was: by creating a dedicated space on the top of Home and populating it with a user’s favorite content, we can reduce the effort needed to find and play the content they want to listen to, right now.

最初の時点で持っていた仮説をA/B testで検証し、モジュールの改善に集中できた。

Refining Recommendations with Heuristics

最初からMLありきで開発するのではなく、まずヒューリスティクスを元にモジュールの改善を行った。
以下のような理由がある。

  • Provide an improvement to the existing experience.
  • Enable us to iterate quickly.
  • Allow us to determine whether a model improves the recommendations to the extent that it is worth supporting in production.

特に三つ目の理由が大事で、MLモデルのプロダクション実装には多大なコストがかかる。なのでヒューリスティクスでも良いのであればヒューリスティクスでやるに越したことはない。

Models are significantly harder to maintain, monitor, and debug in comparison to heuristics. What’s more, if we found that the model didn’t perform better than the baseline heuristic, there would be a good reason to keep a heuristic in production.

また、クイックにA/B testを回すことによってオンラインメトリクスとオフラインメトリクスの相関を取れ、集中するべきオフラインメトリクスを明らかにできた。

どうやって有効だと検証した？

メトリクスに使用したのはショートカット経由での意味のある再生（時間か本数なのかは詳しく述べられていない）
ヒューリスティクスのものよりもMLを用いたものの方が 26.7% メトリクスを改善することができた。

感想

  • spotifyでは取り組むべき課題をどのように決めているのか？今回のShortcutの機能について、ユーザーの手間の削減がどのくらいプロダクトにインパクトがあるのか、どうやって開発に至ったのか？

次に読むべき文献はなに？

From Data to Action With Airbnb Plus

Meta

どんなもの？（著者は何をやりたかったの？）

AirbnbでのSummar intern報告

AirbnbでのData Scientistの大まかな分類

image

  • Analytics
    • Story telling
    • Answer business questions through metrics, dashboards, and creative analyses
  • Algorithms
    • Machine Learning
  • Inference
    • versed in Statistics
    • help Airbnb measure and interpret the impact of changes
    • improving decision making

Airbnbでの仕事

Operational Efficiency Analysis

  • on-boardingの分析
  • 行動の傾向を定量化したり、ディメンションで切った分析

Metric Definition

  • guestの満足度を測定するメトリクスの開発
  • 年レベルで測定するもの

次に読むべき記事はなに？

Current State of Research on Continuous Experimentation: A Systematic Mapping Study

Meta

どんなもの？（著者は何をやりたかったの？）

先行研究と比べてどこがすごい？

技術、手法のキモはどこ？

どうやって有効だと検証した？

議論はある？

次に読むべき論文はなに？

Experiments at Airbnb

Meta

どんなもの？（著者は何をやりたかったの？）

AirbnbがA/Bテストを行う中で踏んできた避けるべき落とし穴についての記事

  • A/Bテストで事前の想定よりも早い段階で判断すると間違った意思決定になるリスクがある
  • 全体の指標のみ見ると実際に何がうまくいっていて、何がうまくいかなかったのかというところまで理解できない
  • システムが想定通り動作することを確認するべき

技術、手法のキモはどこ？

A/Bテストで事前の想定よりも早い段階で判断すると間違った意思決定になるリスクがある

最もこの項目がコアだと感じた。

heuristic: p値を時系列でモニタリングして収束しているように見えるかを判断する

image

systematic: p値の閾値をテスト開始からの経過期間に応じてダイナミックに変化させる

image

  • Why: 実験の結果を早期判断したいタイミングは実際多い
    • ビジネス的に損失がある（ポジネガ両方）
    • バグなどでユーザーに被害を与える
  • How: シミュレーションを行って、各タイミングでの閾値を決めていく
    • 詳細については触れられていないが、以下のような感じだと推測
      • 早期のブレを完全に再現したい場合：過去のテスト結果を利用
      • そうでない場合：ブートストラップサンプリング

議論はある？

全体の指標のみ見ると実際に何がうまくいっていて、何がうまくいかなかったのかというところまで理解できない

ブレークダウンをすることによって、起こったことの解像度が上がる一方でブレークダウンをすることによって、偶然検出された差分を解釈してしまう可能性も高くなってしまうこと

次に読むべき論文（記事）はなに？

Experimentation growth: Evolving trustworthy A/B testing capabilities in online software companies

Meta

  • Link: TBD(有料ソースしか見つからず）
  • Author: Aleksander Fabijan, Microsoft
  • Date: 2018
  • Journal: Journal of Software: Evolution and Process

どんなもの？（著者は何をやりたかったの？）

先行研究と比べてどこがすごい？

技術、手法のキモはどこ？

どうやって有効だと検証した？

議論はある？

次に読むべき論文はなに？

The Design of A/B Tests in an Online Marketplace

Meta

どんなもの？（著者は何をやりたかったの？）

ebayのようなA/B test実施時にSUTVAの侵害を避けられないプロダクトでどのように効果検証を行っていくのか、という一例を示したブログ

技術、手法のキモはどこ？

  • leaf-category（iphoneとか）単位でのCluster-Randomize
  • Selection biasを避けるために、実験期間前の指標の値を差し引くことでvariance reductionをしたこと
    • DID
    • post-stratification: 回帰分析モデル

image

image

どうやって有効だと検証した？

手法間で標準偏差を比較して、回帰分析が最良だとわかった

image

議論はある？

  • サンプルサイズを確保しつつ、できるだけspill overを抑えられるような適切な粒度を構築するのが難しそうだと感じた

次に読むべき論文はなに？

Computational Causal Inference

Meta

どんなもの？（著者は何をやりたかったの？）

先行研究と比べてどこがすごい？

技術、手法のキモはどこ？

どうやって有効だと検証した？

議論はある？

次に読むべき論文はなに？

Query logs alone are not enough

Meta

どんなもの？（著者は何をやりたかったの？）

先行研究と比べてどこがすごい？

技術、手法のキモはどこ？

どうやって有効だと検証した？

議論はある？

次に読むべき論文はなに？

Improving Experimentation Efficiency at Netflix with Meta Analysis and Optimal Stopping

Meta

概要

  • モチベーション：A/BテストをPower Analysisから導き出した期間よりも早い期間で終わらせたい。
    • Pros
      • 試行回数が増やせる
      • 機会損失を防げる
    • Cons
      • SeasonalityやNovelty effectなどを考慮しきれないケースがある
      • 単純なp-valueモニタリングではp-hackingになる

よって、上で挙げたConsを解消できれば、プロダクト改善を加速できる。

内容

Detecting Seasonal Effects with Meta Analysis

Meta analysisによって、該当するテストがSeasonalityを受けるのかどうかを判断する
個人的にmeta analysisを勉強できてないので時が来たらする。（fixed-effect modelとrandom-effect modelがある）

End Experiments Early with Optimal Stopping

p-hackingにならないように経時的なテストをする科学的方法はいくつかある。

  • Wald’s Sequential Probability Ratio Tests(SPRT)
  • Sequential Triangular Testing
  • Group Sequential Testing

中でも3番目のGSTが最も良かったと。
この辺も全然知らないので時が来たらインプットするぞ。

image

疑問点

  • 過去の実験に関してはseasonalityの影響を受けているのかどうか判断できそうだけど、新規で今から回すものに対しても適用できるんだろうか？

参考文献

Beyond Clicks: Query Reformulation as a Predictor of Search Satisfaction

Meta

モチベーション

  • レコメンド関連の評価指標を考えるに当たり、レコメンドは検索の一種であるので、検索での評価指標の論文が読みたかった。

どんなもの？（著者は何をやりたかったの？）

検索クエリの前後関係を使ってクエリに対する満足/不満足を単純なClick情報よりも精度よく判別しようとしたもの

先行研究と比べてどこがすごい？

  • Query reformulation（クエリの再構築）があったのかどうかを判別するためのリーズナブルな方法を提供しているところ
  • アノテータによってラベル付けされたデータを用いて、よくある検索行動へのインサイトを提供しているところ

技術、手法のキモはどこ？

Query reformulation prediction

Query reformulation: 前のクエリでは辿り着けなかった情報へ辿り着こうとしてクエリを再構築すること。

  • Query Normalization: 通常の形態素解析と同じように、スペースを削除したりlower casingしたり
  • Queries to Keywords: クエリの中から教師なし学習手法を使ってセグメンテーション（キーワード化）を行った。式は下に貼った通り。閾値は0.895

image

  • Matching Keywords: 完全一致、部分一致（タイポなどを考慮）、Semantic match（WordNetを用いた）を使って類似度を計算
  • 上記のステップを経て、判別モデルにいれる特徴を作った
    • Textual Features
    • Keyword Features
    • Other Features
      • Time between queries in seconds.など

→ 結果、全ての特徴セットを使うのが最も精度が良かった。

image

Query success prediction

Click情報とQuery reformulationの情報を用いて予測モデルを作る
Query level success: 投げたクエリの目的を達成できること（欲しかった情報にたどり着くようなこと）

  • Clicks only：クリックがあったら成功
  • SAT Clicks only：クリック+30secの滞在を成功と見なす
  • Reformulation Only：Reformulationがあった場合、成功しなかったと見なす
  • Reformulation + Click 2stages：Reformulationがあった場合、失敗と見なす。Reformulationがなかった場合、Clickの情報を用いて成否を判断する
  • Reformulation + Click classifier：分類機を作る

結果、Reformulation + Click classifierが最も精度が良かった。

image

どうやって有効だと検証した？

  • クエリログデータをアノテータによって、ラベル付けした正解データを使って評価をした。
  • 一つの一連のクエリが成功か失敗かを判断するのに三人アノテータを付けて、多数決をした。

所感

  • 検索系の評価を考えていく上で、Revenueはもちろん重要なんだけどUXをどう測定すれば良いのか基礎的な考え方を持つことができたかなと思う。
  • Clickがないけど満足しているパターン（Good abondonment）、Clickしたけど満足しなかったパターンなど、漠然と自分の中であった考えを示してくれたと思う。レコメンドにどう応用するのかは自分次第。
  • Additionalな分析で、成功する検索行動では、検索結果から新しい情報を得るのでクエリ間の類似度がさがると言う洞察がとても納得感があった。

次に読むべき論文はなに？

  • The query-flow graph: model and applications.
  • Evaluating implicit measures to improve the search experience.
  • Beyond the session timeout: automatic hierarchical segmentation of search topics in query logs.
  • Good abandonment in mobile and PC internet search.
  • Identifying Task-based Sessions in Search Engine Query Logs.
  • Automatic new topic identification using multiple linear regression.
  • Query chains: learning to rank from implicit feedback

Principles for the Design of Online A/B Metrics

Meta

どんなもの？（著者は何をやりたかったの？）

タイトルの通り。A/Bテストで評価指標を決めるときに知っておくべきこと

内容

よくConversionの予測モデルを作って、寄与度の大きな指標を評価指標に置こうとするアプローチがあるが、必ずしも効果的ではない。（First stepとしては良いとの言及もあるが）

  • そのメトリクスが、Sensitiveではないケース：その変数によって成功指標が予測できていたからと言って、A/Bで起こる差分を検出できるほどSensitive出ないケースもある
  • endogenousな情報を使っていた場合：システムとして何を提示したか？というユーザーの行動とは関係ない情報を使っていると、実際は役に立たない。使うのであればユーザーがどのように振る舞ったのか？という点にフォーカスするべき

メトリクスの良し悪しを客観的に判断するために、experiment corpusを作るのも効果的。experiment corpusとは、成否に確信が持てるA/Bテストのセットであり、教師あり学習の教師データのように使える。

Metrics system

様々な角度から起こったことがわかるようにmetrics setを作るべきである。一方で多すぎるメトリクスには次のような問題もあるので注意

  • 多重比較の問題（多くなればなるほど、偶然有意差が観測される確率が高まる）
  • 大きく動くものもあれば、その逆に悪化するものも考えられ、cherry pickingに繋がる

Metric definitions

  • 上限のない値の場合、分散が大きくなりすぎるので、truncationをおすすめする。
  • 分母が動くと信頼できなくなるので、分母の数値に何をおくか考慮が必要。限界までSensitivityを高めることのできる分母をおくべき

Debuggablity

例えば同じページの要素別など、簡単に分解できるようになっていると良い。MLモデルによって計算されたメトリクスなどは解釈が難しい。

次に読むべき論文はなに？

  • H. Feild et al. 2010. Predicting searcher frustration. In SIGIR’10: 34–41. 気になる。

A/B Testing and Beyond: Improving the Netflix Streaming Experience with Experimentation and Data Science

Meta

どんなもの？（著者は何をやりたかったの？）

NetflixでどのようにExperimentsが使われているのかについての記事

ざっくり内容

deduction-induction iterations

image

  • deduction: 仮説や理論、それに基づくモデルを構築し、データを得るプロセス
  • induction: 得られたデータから一般化可能な仮説を再構築するプロセス

Experimentはこのプロセスを繰り返すのに不可欠な手法である。
Experimentでは以下の質問に興味がある。

  • How does the change (“treatment”) affect QoE metrics?
  • What effect does the change have on member behavior: do our members prefer the new experience or the old one?

Streaming Quality of Experience

Netflixでは再生体験の質（QoE）を上げることを目的にプロダクト改善を行っている。

  • Adaptive Streaming: デバイスやネットワーク状況に応じて再生遅延が発生しないように画質を�最適化する
  • Content Delivery: できるだけ視聴者に近い場所にコンテンツを保管する
  • Encoding: 元ファイルからどのようにエンコーディングを行うか

Experiments to Improve QoE

image

  • System experiments: アルゴリズムの変更やパラメータの変更など。数時間から数日程度、ノンパラ検定をよく使う。多重比較もちゃんと考慮しているとのこと
  • Quasi-Experiments and Causal Inference: A/Bできない時に使う。SUTVAが成り立たない時とか
  • Consumer Science Experiments: 上記二つの実験を数回繰り返した後に行う。以下の二つの問いに興味がある。
    • Do members watch more Netflix if they have better video quality or lower rebuffers or faster playback start?
    • Do they retain better after the free trial month ends and in subsequent months?

議論はある？

  • Experiment Cultureはとても重要
  • Platform作るチームがいる
  • あるセグメントには良い変更でも、あるセグメントには悪い変更の場合がある

次に読むべき論文はなに？

Quasi Experimentation at Netflix

Meta

概要

  • NetflixでのQuasi-experiment（A/Bテストが行えない条件での擬似実験）を紹介するブログ。
  • オフライン広告の効果測定をしたいときに、地域レベルでのランダマイズを行って効果検証をする。
  • Quasimodoという簡単にQuasi-experimentが行えるプラットフォームも作成中

Seven Rules of Thumb for Web Site Experimenters

Meta

どんなもの？（著者は何をやりたかったの？）

OnlineサービスにおいてA/B testを行う時のRules of thumbの共有（タイトルの通りだけど）

内容

Small Changes can have a Big Impact to Key Metrics

小さな変更でも、Key metricsに大きなインパクトを産むこともあるという話。ただし、やはりこれが起こることは稀であって小さな変更だけを行ってしまうようなことには注意が必要。大胆な変更と上手くバランスを取っていく必要がある。

Changes Rarely have a Big Positive Impact to Key Metrics

Key metricsに大きなインパクトがもたらされるのは稀なので、Twyman's Lawに則ってそのような変化が起こった時は再現性を取るとか成功/失敗要因を特定するなど信頼性に注意するべきという話。大きな変化が起こった時だけではなく、期待に反する変化が起こった時もそうするべきとなっていた。

この式が良くて、元々動く確率が低いmetricsが統計的有意に動いた時、本当にそれが改善している確率は低いという直感をベイズの定理を用いて示している。

image

Your Mileage WILL Vary

mileage の意味を捉えられなかった。（有用性とかそういう意味なんだろうか？）
他で成功したA/Bテストは注意を持って見るべきという話。細かな前提条件が違ったり、有意水準が違ったりするとのこと。

Speed Matters a LOT

特にWebサービスにおいて、performanceはkey metricへのインパクトが大きいよという話。その上、単なるレイテンシなどではなくperceived performance（近くされるパフォーマンス）をどう測定するのかが課題となっている。例えば、サービスの全く使われていない要素の読み込み時の表示速度が激しく悪化してもおそらくユーザーへの影響は軽微なことが予想される。

BingではTTS(Time To Success)が使われているらしい。Successは、ページ上から何かしらのクリッカブルなものを踏んで30s以上滞在すること。Clickが発生しないものに対しては課題が残っているとのこと。

Reducing Abandonment is Hard, Shifting Clicks is Easy

タイトルにはAbandonmentとかClicksとかなっているけれど、実際はサイト全体の指標を改善するのは難しく、機能単体の指標を改善するのは簡単という話だった。

Avoid Complex Designs: Iterate

実験デザインを複雑にすると、デバッグが大変だし真の効果も測定しづらいのでなるべくシンプルにした方が良いという話。

Have Enough Users

中心極限定理を根拠に平均値が正規分布に従うとして仮説検定や信頼区間算出が行われるケースが多いけれど、実際に用いられる指標としては遥かにskewness（歪度）が大きくてサンプルをかなり大きく取らないと正規近似ができないものもあるよという話。確かに、サンプルサイズの計算等は正規性を仮定して行っているので上限が無い指標を用いる時は気をつけるべきかもしれない。

感想

ずっと積んであったけれどいろんな論文で良く参照されているのを見かけるのでGWの機会に読んでみた。当初の期待よりも良くて、特にRule of thumbだけではなく実例が豊富なのが良かった。

次に読むべき論文はなに？

N/A

Data Quality at Airbnb

Meta

どんなもの？（著者は何をやりたかったの？）

先行研究と比べてどこがすごい？

技術、手法のキモはどこ？

どうやって有効だと検証した？

議論はある？

次に読むべき論文はなに？

Automatic Detection and Diagnosis of Biased Online Experiments

Meta

どんなもの？（著者は何をやりたかったの？）

Experimentでバイアスをもたらすいくつかの現象についての解説とそれを検知するためのアルゴリズムを導入した

  • Novelty Effect
  • Trigger-day Effect

image

image

先行研究と比べてどこがすごい？

  • 以前から指摘されていた、Novelty Effectなどを自動的に検出できるようなアルゴリズムを提案したこと
  • SRMの検出方法についても自分が読んだ論文の中では初めて数式含めて触れられていた。

技術、手法のキモはどこ？

Linkedinにおける過去の実験から、SRMのroot causeを知るための筋の良い分析方針であったり、Novelty Effect, Trigger-day Effectの検知のためのアルゴリズムが考案されている。

SRMのroot causeを明らかにするための筋の良い分析手順

  • テスト対象の全てのuserを含めてSample Ratio Testを行う
  • 初訪問ユーザーと複数回訪問ユーザーに分けてSample Ratio Testを行う
  • 目的のトリガー条件を再現するコードとは独立したトラッキングイベントを特定する
  • その実験のユーザーが他の実験において、どのグループに割り当てられているのか確認する

Trigger-day Effect

Single day impactとcross day impactが全く違うものになること。Treatmentに触れる日と触れない日の評価指標の値が異なることによって起こる。

以下の式でモデル化される

image

Novelty Effect

最初のうちだけ大きな効果が出て時間がたつに連れて効果が収束すること。
以下のような変更で起こりやすい

  • 大きな変更をした時
  • 通知系の実験
  • レコメンデーションアルゴリズムの変更

線形回帰を行い、以下の条件を満たす場合、Novelty Effectと認める。

image

  • モデルが当てはまっていること（決定係数が0.8以上）
  • フィットした直線が時間に対して単調減少であること
  • 最大のSingle-day Effectが最小のSingle-day Effectと統計的有意に異なること

どうやって有効だと検証した？

  • Linkedinにおける過去のA/Bテストからパターンを見出した

議論はある？

  • Novelty Effectの検出アルゴリズムでは、Weekday Effect（曜日によって行動が変わること）との切り分けをできない
  • Novelty Effectの定量化はできない

次に読むべき論文はなに？

  • Data-driven metric development for
    online controlled experiments: Seven lessons learned.
  • Controlling the false discovery rate: a practical and powerful approach to multiple testing
  • Objective bayesian two sample hypothesis testing for online controlled experiments.
  • Online Controlled Experiments at Large Scale
  • Trustworthy online controlled experiments: Five puzzling outcomes explained
  • Seven rules of thumb for web site experimenters

Trustworthy Online Controlled Experiments: Five Puzzling Outcomes Explained

Meta

どんなもの？（著者は何をやりたかったの？）

MicrosoftのA/B testの中での直観に反した結果が出た実験の根本原因とそこからの学びで一般化可能な部分をまとめた

先行研究と比べてどこがすごい？

  • 理論だけでなくプラクティスをまとめてあるところ
  • metricsに生じがちなバイアスといった話だけでなくメトリクス選定やCarry over effectnなど割と広い範囲の実例、ベストプラクティスを提示している。

技術、手法のキモはどこ？

Best Practiceの共有といった内容なので技術的なポイントはほとんどなかった。

The OEC for a Search Engine

  • ユーザー体験の悪化を含む実験なのにもかかわらず、OECはポジティブだったケース
  • ビジネスメトリクスのみをOECに追いてしまうと、短期的なビジネスメトリクスのリフトにのみ目が行ってしまう。
  • 大きい指標を分解し、本当にその実験の目的に即した部分を使うべき

Click Tracking

  • 読み込み時間が遅くなるのに対して、クリック数は増加したケース
  • 実際は今まで欠損していたクリックログを計測できるようになっただけだった。
  • 差分が生じづらいセグメントで切った時に、差分が生じていないかをチェックすることでヒントが得られる場合がある

Initial Effects Appear to Trend

  • Novelty Effect, Primacy Effectと呼ばれるような現象
  • 実際はそう見えても、単に信頼区間幅が徐々に狭くなることによる場合も多い
  • 日付に対して何か傾向が見えても、符号を跨ぐのはほとんどない

Experiment Length and Statistical Power

  • 実験期間を伸ばすことで検出力を高めるという手段が取られることがあるが、実際は検出力が上がらない場合がある
  • 上限が決まっている値（Ratio metricsなど）ではあまり起こらないが、平均セッション数などの上限が決まっていない値の場合、sqrt(n_users)の増分よりも分散の増分の方が大きい場合があり、そうすると信頼区間幅は減少しない

Carryover Effects

  • 介入がなくなった状態においても介入の効果が持続することをCarryoverと呼ぶ
  • 実際に存在し、3ヶ月以上持続する場合もある

どうやって有効だと検証した？

Best Practiceの共有といった内容なので検証的なポイントもほとんどなかった。

議論はある？

Carry over effectについて、示されている例ではその持続期間がネガティブなものの方が長いなど興味深い。

次に読むべき論文はなに？

  • Online Experimentation at Microsoft
  • Overlapping Experiment Infrastructure: More, Better, Faster Experimentation

A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in Online Controlled Experiments

Meta

どんなもの？（著者は何をやりたかったの？）

A/Bテストを行う中で遭遇するmetricsの誤った解釈についての12のパターンとその検知、軽減策をまとめたもの

先行研究と比べてどこがすごい？

先行研究では長期的な効果の予測やexperimentation platform, 新しい統計手法によってメトリクスのSensitivityを向上させるなど理論、技術的なテーマが多かったのに対して、メトリクスの解釈という極めてプラクティカルな観点で過去の実験結果からの学びを構造化している

技術、手法のキモはどこ？

A/Bテストにおいて測定するべきメトリクスのTaxonomyの提供

  • Data Quality Metrics
    • バグや測定の不具合を検知するための指標
    • sample ratioなど
  • Overall Evaluation Criteria (OEC) Metrics
    • Experimentのインパクトを測定する指標
    • 要件
      • 短期的に変化を測定することができる（先行指標）
      • 長期的なビジネスの成功につながっている
      • 顧客の満足にもつながっている
    • 見つけるの難しい
  • Guardrail Metrics
    • 実験の直接的な成功とは関係ないが下げたくない指標
  • Local Feature and Diagnostic Metrics
    • プロダクトの個別機能の使用率など
    • サイドエフェクトの検知に使える

12種類のよくあるメトリクスの誤解釈

発生するタイミングが違うだけでSample Ratio Mismatchによって説明できるものが多かったように感じた。

  • Metric Sample Ratio Mismatch
    • 評価指標の分母の数値がvariant間で異なること
    • カイ二乗検定によって検出可能
    • 大抵なんらかのSelection Biasが働いてしまっていて、メトリクスが解釈不能になる
  • Misinterpretation of Ratio Metrics
  • Telemetry Loss Bias
    • ログの欠損が起こる（これもSRMの一種）
  • Assuming Underpowered Metrics had no Change
    • 差は出ているのに検出力が足りずに統計的有意とならない
    • 事前に検出力を担保できるようなサンプルサイズで実験を行うべき
    • OEC metrics, Guardrail metricsに関して行うべき
  • Claiming Success with a Borderline p-value
    • 有意水準に非常に近いp値をとっている時に成功と判断してしまうこと
    • トラフィックを増やした状態で再テストするのがおすすめ
  • Continuous Monitoring and Early Stopping
    • 基本的に実験の早期停止、期間継続はするべきではない
    • が、それをするためにはどうすれば良いのか？という研究も行われている
  • Assuming the Metric Movement is Homogeneous
    • あらゆるセグメントにおいて実験の結果が良い方向に動いたと考えてしまうこと
    • 多くの場合、セグメント間の指標の動きは異なることが多い
    • 自動化できるのが好ましい
  • Segment Interpretation
    • セグメンテーションの条件が介入の影響を受けないようにすることが重要
    • 都合の良いセグメントの切り方を模索してしまうのは、偽陽性率を高めてしまうので注意が必要
    • 多重比較の補正が必要になる
  • Impact of Outliers
    • 少数の外れ値によって評価指標の値が歪んでしまったり、外れ値を除外するロジックを組み込んでいたとして、介入の結果として外れ値とみなされるサンプルが多くなり、SRMを引き起こしてしまったりする
  • Novelty and Primacy Effects
    • 目を引く変更の場合は初回行動のみ数値が跳ねることがあ。これをNovelty Effectとよぶ
    • また、最初の方は効果が薄く、徐々にユーザーが慣れるなどして効果が現れることもある。これをPrimacy Effectと呼ぶ
  • Incomplete Funnel Metrics
    • ファネルの各ステップの指標はウォッチしておくべきということ
    • conditional rate: 直前のファネルステップに入ったサンプルのうち何割が次のステップに遷移したか
    • unconditional rate: 最初のステップに入ったサンプルのうち何割が当該ステップに到達したか
  • Failure to Apply Twyman’s Law
    • 考えられないような大きな改善が起こったときは懐疑的になれ

どうやって有効だと検証した？

  • Lesson Share系なので特になし

議論はある？

  • 特になし

次に読むべき論文はなに？

  • A. Deng and S. Xiaolin, "Data-driven metric development for online controlled experiments: Seven lessons learned," in KDD, 2016.
  • W. Machmouchi and G. Buscher, "Principles for the Design of Online A/B Metrics," in Proceedings of the 39th International ACM SIGIR, 2016.
  • P. Dmitriev and W. Xian, "Measuring Metrics," 2016, Proceedings of the 25th ACM International on Conference on Information and Knowledge
  • R. Kohavi, R. Longbotham, D. Sommerfield and R. M. Henne, "Controlled experiments on the web: survey and practical guide," Data Mining and Knowledge Discovery, vol. 18, no. 1, pp. 140-181, February 2009
  • A. Deng, Y. Xu, R. Kohavi and T. Walker, "Improving the Sensitivity of Online Controlled Experiments by Utilizing Pre-Experiment Data," in Sixth ACM WSDM, Rome, Italy, 2013.
  • P. Dmitriev, B. Frasca, S. Gupta, R. Kohavi and G. Vaz, "Pitfalls of Long-Term Online Controlled Experiments," in IEEE International Conference on Big Data , 2016.
  • H. Hohnhold, D. O'Brien and D. Tang, "Focusing on the Long-term: It’s Good for Users and Business," in KDD, 2015
  • A. Deng, J. Lu and S. Chen, "Continuous monitoring of A/B tests without pain: Optional stopping in Bayesian testing," in DSAA, 2016
  • A. Deng, "Objective Bayesian Two Sample Hypothesis Testing for Online Controlled Experiments," in Proceedings of the 24th International Conference on World Wide Web (WWW '15 Companion), 2015.
  • R. Johari, L. Pekelis and D. J. Walsh, "Always valid inference: Bringing sequential analysis to A/B testing.," In submission. Preprint available at arxiv.org/pdf/1512.04922, 2015.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.