OKIYUKI99 Blog

データ分析や日常に関するブログ

2019年導入してよかったこと・振り返り

今年も終わります。毎年のまとめに続きに今年も振り返ってみます

2018年

gingi99.hatenablog.com

2017年

gingi99.hatenablog.com

習慣とか

ワーク管理

たぶん以下の感じで使っている

  • 一次受け

    • Google Keep:すべてのメモはまずここに。起動と同期の速さがやはり良い
    • Pocket : TwiterやWeb系の気になる記事をすぐに保存できるのが良い。読んだのはアーカイブに入れておけばあとから検索もできるし。無駄に記事をまとめることが減ったのも良い
    • ひとりLINEグループ:同期の速さはGoogle Keepよりも確実ということで、スマホからPCに送りたいものはこれを活用している
  • 仕事のタスク管理

    • 2019年はチームでGithub Projectsのカンバン形式を導入したこともあり、会社のTo Do系はそれに移行
    • 会社のメモのようなタスクのようなものは、色をわけてKanbanflowを使っている
  • 家のタスク管理とか

    • Trello : To Do管理。カンバンっぽく使っている。去年と同様に目標管理や勉強したいことなど、メタなこともメモのように書いている
    • TimeTree : 妻と予定を共有するのに便利。Keep機能で日付が未定な予定も入れておけるのも便利。ここで買ってきてほしいものも気軽に共有できるのが良い
  • まとめ先

    • ASANA:英語に関するメモやまとめ
    • ANKI:英語の表現で暗記したいものはANKIで覚えている。もっと前からやればよかった…
    • Dropbox Paper:リンクが見やすく表示してくれたりするので、今有力候補として使っている。ただし、ディレクトリの階層を複雑にしたくないので使い方は考え中
    • Scrapbox:書き心地が良いので使っているが、タグをつける習慣が自分にあまりないので、使いこなせてない感じもする
    • Evernote:メモを含むすべてのまとめとして使ってたが、重くなってきたのと、整理できなくなってきたので、上記に一部移行中。2020年にはすべて移行できれば…
  • 辞めたツール

    • Github と Gitlab のIssueやWikiに一部まとめていたが、あまり効率的ではないこともあり、限定して使用するように移行

マンション・住宅購入検討

マンション買おうと思って本をかなり一気読みしていた時期があったので、少しだけ詳しくなった気がする。結局買うのは見送ったけど  

アウトプット

  • はてぶ : 9件
  • Qiita : 8件
  • note : 2件
  • 外部発表:3件(Tokyo.R / KDD読み会 / DevDay)

であった。なんとなく論文とか勉強した系ははてぶ、技術TipsはQiita、その他はnoteみたいな感じ。ゆくゆくはこの振り返りもnoteに移行するかも

Qiitaが多いのは、今年はShiny系の記事のネタが多かったため

もとの文章はプラットフォーム依存せずに、MarkdownでGitlabとかで保存しておきたいなーとも思う

キャッシュレス

お財布いらずで買い物できるし、貯まるポイントでお買い物できるのは良い。使える場所もものすごいスピードで増えているのでほんとに便利。妻に導入してもらって、お金送るのも楽になった

自動化

ブックマークレットやちょいちょい付け足した。Alfreadを拡張していく方向でも良いことに気づいたので、なんか使い分けたい

KPT

チームでKPTをやり始めて半年経ち、振り返りの習慣が着実についたのがよかった

モノ

電動自転車

ビッケのポーラーを購入。電動自転車初めて乗ったけど、移動範囲が広くなるし、スピードも出るしで快適

www.bscycle.co.jp

NAS

I-O DATA NAS 2TBモデルを購入。主に妻が簡単に写真を保管できるようにするため。昔から使っていたUSB型のHDDが壊れたこともあり、家のデータはNAS + Google Drive の体制になった。今のところたまに同期をしないとだめくらいで特に問題はない

レイコップ

ふとん掃除を効率化するために購入。毎回吸うたびにかなり吸ってくれるので、きっと効果があったと信じてる

大吉ブレンドドリップバッグ30枚

近くの猿田彦珈琲のドリップバックが美味しいので、基本まとめ買い。この手のドリップパックのなかで圧倒的に美味しい。親族の土産にも重宝する

猿田彦監修コーヒーベース

夏は箱買いしてこれ飲んでた

一本満足 プロテインバー

小腹が空いたときに食べるようにしている。この手のもので味が圧倒的に美味しいので続けられている

エネループ

子供のおもちゃが増えてるので、エネループ導入した。長期的に見るときっと安くなると思う

キャップ

近くのショッピングモールで買ったキャップ。子供と遊ぶときにちょうどよい。自転車乗ってるときに眩しくないのも良い

お風呂掃除

防カビくんとバスタブクレンジングで基本的に労力をかけないようにしている。といっても、足りない部分はスポンジで擦るのだが。伸び縮みするものを買ってだいぶ楽になった

ルックプラス バスタブクレンジング クリアシトラスの香り 本体 500ml

ルックプラス バスタブクレンジング クリアシトラスの香り 本体 500ml

  • 発売日: 2018/01/28
  • メディア: ヘルスケア&ケア用品

スターアライアンスゴールドメンバー解約

2015年から使用していたが、海外にいく機会が減ったのですっぽり解約

メディアやアプリ

freeeで確定申告

freeeの確定申告のサービスが便利だったので、その月だけ会員になった。煩わしい時間が簡単になるので、とても良い。確定申告だけのサービスもほしい。

レアジョブ

会社の制度で条件を満たせば無料で利用できるということで利用中。条件も難しいものではないので、無料で利用できている。現在100回以上受講したこともあり、少しずつ言える表現が増えているとは感じているが、滑らかさはまだまだだなーと思っている。こういうのは継続することがまず大事なので、ブレずに来年もやっていく。ANKIで覚える速度も効率よくしていきたい

Youtube Premium

オフライン保存と子供に電車を見させるときに無駄なCMを省かせるのはとても良いので利用している。なので、Youtubeはヘビーに利用している

Netflixに体験だけした

英語学習に良いと聞いていたので、30日間の無料体験だけした。Chrome拡張などでスクリプトや同時翻訳はやはり便利そう。しかし結果としては、今やってるレアジョブの復習時間くらいしか今は時間が取れてないのもあり、活かしきれないと思い途中解約。またいつかやるかもしれない

MoneyForwardからMoneyTreeに移行

MoneyForwardで資産推移グラフが見えなくなったこともあり、有料利用するほど真面目に使うつもりもなかったので、MoneyTreeに移動。資産推移を見るのはおもしろいが、それよりも今の資産が漏れなく知れることのほうが重要だと思うので、登録制限数が無いサービスが良い

Udemyで動画学習

フロントエンド周りの勉強に使った。知識が少ないものを使えるところまで習得するには動画が効率が良いケースも多いと感じるので、Youtubeと合わせて勉強するのが良さそう

AtCoderをやり始めた

新鮮なので楽しい。せめて今年中に緑に到達したかったが、達成ならず。緑を達成したらブログにまとめたいと思っている

2020年の導入予定

子供用のおもちゃ

息子が2歳になって、来年くらいから知育っぽいゲームもできそうになってきたので、ちょいちょい欲しい物リストには入れている。自分がやるのが楽しみなものを多い

スマートリモコン

やっとAlexa使える様になってきた感があるので、次はスマートリモコンを導入したい

KDD2019論文読み会で発表しました

2019-10-16(水)のKDD2019論文読み会でA/Bテスト周りについて発表しました。 どの辺の研究が流行ってるのか聞けていろいろ刺激を受けました。

connpass.com

togetter.com

speakerdeck.com

もともとの内容は以下の記事から作ってます。A/Bテスト周りの論文は興味深いのが多くて読んでいて楽しいですね。

gingi99.hatenablog.com

第81回 TokyoR Shiny特集会に参加&発表してきました

前回参加したのが覚えてないくらい(5年ぶり?くらいか)、TokyoRに参加&発表してきました

tokyor.connpass.com

togetter.com

今回のTokyoRはShiny特集会でした。Shinyユーザとしては発表したいと思い、運営サイドに連絡したところ、応用枠を頂きました。貴重な機会を頂きありがとうございました

ということで、以下は聴講したメモです

初心者セッション1 – R基礎 –

speakerdeck.com

発表者は @kilometer0101 さん。はじめての人にR説明する機会がたまにあるんですが、この資料を使えば良いのかと思い出されました

初心者セッション2 - はじめてのShiny -

speakerdeck.com

発表者は @kyyonko さん。Shiny入門するのに公式チュートリアルが今でも良さげのようです。

Shiny ユーザのための非同期プログラミング入門

www.slideshare.net

発表者は @hoxo_m さん。日本語でわかりやすく説明してくれて大変参考になりました。

RStudio社のJoeの講演資料や公式ページも参考になります

speakerdeck.com

rstudio.github.io

30分でそこそこ使えるShinyアプリを作ってみる

github.com

発表者は @Np_Ur さん。Shinyでスライドを作ってすごかったです(しかし、後悔したと言ってましたが笑)

Shiny入門したあとは、このコードに進むのが今なら良さそうですね

Shiny ユーザーのためのアプリケーション設計入門

github.com

発表者は @kos59125 さん。アンケートをリアルタイムにShinyで集計するアプリ作ってました。

発表内容は自分と似てて、ShinyProxyの話などがありました。また、Shinyを実運用で使うために考えるべきことなどとても参考になりました

{shiny}と{leaflet}による地図アプリ開発Tips

www.slideshare.net

発表者は @kashitan さん。leafletパッケージを使ったShinyアプリ構築のために知らない便利パッケージがあったので地図アプリ作るときはぜひ参考にしたいと思います

Shiny Appを支えるエンジニアリング

自分のスライドです。Shinyアプリを複数人が使用してもなるべく高速に動くように色々便利なパッケージがあるよっていう話です

speakerdeck.com

LT : Shinyで作る写真編集アプリ

imager というパッケージがあることを知りました。発表がとてもおもしろかったです

LT : 推しの情報が知りたい

趣味のバンドの情報をShinyアプリで見れるようにしてる話。趣味から始めるのが、一番モチベーション高く作れるので良いですね

LT : Shinyで社内向け汎用統計アプリを作ってみた

ShinyServerを運用するのではなく、R自体も詰め込んだShinyアプリをzipファイルを配布して、VBAのマクロで起動するやり方が参考になりました

LT : Shinyと再現可能性のすゝめ

docs.google.com

useR!2019で講演があったshinymetaの話です。スクリプトのダウンロード機能や現在のshinymetaの状況についてとても参考になります

LT : オープンソースで薬物動態シミュレーション(Shinyもあるかも)

微分方程式を直接解けるパッケージがあることを知りました。あまりこれまで関わりがうすい分野でしたが面白かったです

おわりに

これまでShinyユーザと話す機会は多くなかったので、とても楽しかったです。そいえば、自分の発表でShiny Server Proを使っている人はいるか質問したところ、だれも手があがりませんでした。やはりProユーザはいったいどこに…

ちなみに、海外でShinyを使っている企業はいくつかあります。最近の記事だと、

Netflixでは、A/Bテストなんかの実験のモニタリングや統計処理にShinyを使っているみたいです

medium.com

今年のStrata Data ConferenceではLinkedinでもShiny使っている話があったみたいです

conferences.oreilly.com

今回の特集回をきっかけにShiny Appを開発し、Shiny Contestに投稿するShinyユーザもどんどん増えてほしいと思います。Enjoy Shiny!

参考

gingi99.hatenablog.com

WSDM 2019 : How A/B Tests Could Go Wrong : Automatic Diagnosis of Invalid Online Experiments を読んだ

dl.acm.org

LinkedinでInvalidなA/B テスト検知するための方法論を紹介している論文を読みました

A/Bテストにおけるメトリック解析の話から、丁寧にメトリックを分解し、検知ロジックを提案しています。LinkedinのA/B テストプラットフォームで実際に動いてるみたいです

Introduction

まずはじめに、invalidなA/BテストにはInternally または Externally なテストがあることを紹介しています

Internally invalid とは?

Treatment と Control間の差がTreatmentによる効果と結論づけれるのが本来のA/B テストの魅力の1つですが、その差がTreatmentによる効果ではない ことを言います

特にこの論文では、incomparable samples(つまり、比較不可なサンプル群)における Internally invalidを紹介しています。LinkedinでのA/Bテストのうち10%ほどが発生していたと報告されています

比較不可なサンプル群って何?と初見では思うかもですが、今年のKDD2019でも話があったSample Size Ratio Mismatchの話はこれの1つに該当します

gingi99.hatenablog.com

Externally invalid な A/B Test とは?

実験自体は正しく行えていても、実験の設定を超えて結果を一般化したときに妥当性が維持できない ことを言います

これも初見では何?となりましたが、具体的な例を述べますと、実験の結果が例えば時間依存 または サンプルの集団依存 していただけであって、100%リリースしたら思ったより有効な効果がでないような話がこれに該当します

これら2つのInvalidなA/Bテストを自動で検知するアルゴリズムを考えたのがこの論文の貢献です

このブログでは、Externally invalid が興味深かったので、それについて紹介します*1

Triggered Analysis

Triggered Analysisとは聞き慣れない言葉ですが、これを理解することがExternally invalidの実例を理解する上でとても重要になります

これは要するに、評価したいモノを実際に体験したユーザのみ を含んだ分析のことを言います。つまり、Treatment郡の集団に属した人でも、A/Bテストで評価したいモノ(例えば画面)を見てない人を含めて良いんだっけ?ということが動機です。例えば、Daily Active User(DAU) が2億人のウェブサイトがあったときに、A/Bテストで評価したあるページのDAUが200万人であるなら、本来Treatmentすべてのユーザを含めると、せっかくインパクトがある変更でもNoise(体験していないユーザが99%にいるため)になってしまいます

このTriggered analysisには session-triggeringuser-triggering の2種類があります*2

f:id:gingi99:20190317215938p:plain

みたとおり、session-triggeringとは、評価したいモノを体験したセッションのみ を解析する。user-triggeringとは、ユーザが一度体験してからのユーザのすべてのデータ を解析することを言います

この論文では、user-triggeringに絞ります*3

Cross-day vs Single-day Impact

どのユーザを使ってImpact(効果)を評価するかの考え方として、cross-day impactsingle-day impact の2つを述べています

実験期間k日あるとします

cross-day impact とは、1日目からt日目( 1 \le t \le k)までの どこかの日にトリガーしたすべてのユーザ を使って効果を求めるやり方です

single-day impact とは、t日にトリガーしたユーザ を使って効果を求めるやり方です

cross-day impactを評価するために、 n^{[1,t]}を1日目からt日目までのサンプルサイズ、  X^{[1,t]} をユーザiのメトリック、 \Delta^{[1,t]}\%をパーセンテージインパクト(リフト)とみなすと、 single-day impactはそのまま、 n^{[t,t]} X_{i}^{[t,t]} \Delta^{[t,t]}\%として評価すればOKです

cross-day impactはあくまで、一度でもtriggerすればそのユーザは評価対象に含まれます。つまり、ある日はtriggerしてなくてもそのときのそのユーザのメトリクス値もImpactを評価する際に使われるということです

Fully-covered vs Partially-covered Metrics

実験を評価するメトリックとして、Fully-coveredPartially-covered メトリクスの2つを述べています

fully-covered metrics とは ユーザがトリガーしないとメトリクスの計算ができない指標 のことです。サイトに訪れることがトリガーであるA/Bテストの場合、ページビューの合計はFully-covered metricsに該当します。つまり、ページビューの合計は、トリガーの影響を100%受けているからです。

partially-covered metrics とは ユーザがトリガーしなくても計算できる指標 のことです。あるページを見ることがトリガーであるA/Bテストの場合、ページビューの合計はpartially-covered metricsになります。つまり、ページビューの合計は、トリガーがなくても計算することができるからです。

In-trigger vs Off-trigger Impact

in-trigger impact は、ユーザがトリガーした日におけるtreatment impact のことです

off-trigger impact は逆で ユーザがトリガーしていない日におけるtreatment impact のことです

もちろん、fully-covered metricsのoff-trigger impactは常に0になります*4

External Invalidity

普通我々はA/Bテストの結果から、最も良いTreatmentを見つけて、100%のユーザに向けてテストした機能をリリースしていくかと思います。例えば、「この機能で○%良くなる結果を得たので、すべてのユーザに適用して、四半期経てば、△%の収益アップが狙えます」という感じですね

これは暗黙的に 別のサンプル集団時間 というものに対しても一般化して考えてる自然な思考だと思いますが、実はこれが External Invalidity を引き起こし得ることを論文では述べています

1つ目を Generalizing beyond the experiment population と言っており、A/Bテストの実験集団のみでの結果はあくまである機能に対する Local Impact であると言っています。 これをユーザ全体の Global Impact にするには、別の集団でもA/Bテストを複数行い、Site wide Impact を求め、Global Impactに転換していくことを述べています。Site wide impactとは、いわゆるサイト全体への影響を評価することを言います。詳しい内容は、以下の論文で紹介されているようです

dl.acm.org

2つ目の Generalizing over time が本論文で扱うExternal Invalidityになります。文字通り、メトリクスとは時間に依存してしまうがゆえにTreatment Effectを見過うことです

ここでさらに、この時間依存型のtreatment effectを novelty effecttrigger-day effect に分類しています

Novelty Effect

これは、ユーザの振る舞いの変化 に起因するEffectのことを言います。具体的には、最初にトリガーを体験したときと、何度もトリガーを体験したときでは、ユーザの反応は異なってきます。例えば、最初は通知に対してとても反応していたのが、だんたんと無視するようになるような行動の変化のことを言います

結果、ユーザがトリガーすればするほど、treatment effectは増加/減少します。これは以下の左図のとおり、single-day と cross-day impactの両方で強い一定の傾向をします

f:id:gingi99:20190824125424p:plain

まず左図を理解するために、まず右図を理解します。x軸が表しているのは、A/Bテストが開始してからの経過日数で、y軸は ユーザのトリガーした平均的な日数 です。これが増加するのは、A/Bテスト後に新たにトリガーするユーザが増えるためです。x = 1のときに、y = 1になるのは、トリガーした人のみを対象に数えるためですね。x = 2のときに、y = 1.7くらいでしょうか。2日経過して、2日ともにトリガーしたユーザと1日しかトリガーしていない人(1日目 or 2日目)がいるためですね。x = 3のときに、y = 2くらいなので、このA/Bテストでは、3日間のうちに1度以上トリガーした人は平均的に2日くらいはトリガーすると解釈すれば良いと思います

ここで左図を振り返ると、single-day impactのほうがA/Bテストが経過するほど、減少スピードが速いです。single-day impactは 各日でトリガーした人(初めてトリガーしたユーザ、もしくは何度かトリガーしているユーザも含まれる)のみインパクトを測ります。経過日数が立つほど、何度もトリガーしてる人が増えてくるため、後半の日ほどsingle-day impactは小さくなります。一方、cross-day impactはA/Bテスト開始日から、現時点までの どこかの日でトリガーしたユーザインパクトを測ります。Novelty Effectがある場合は、最初の体験時がImpactを大きくするため、そのImpact分が後半の日でも影響してくるため、このようにcross-day impactのほうがsingle-day impactより大きくなります

こういったNovelty Effectの特徴を使って、検知するアルゴリズム(以下のSTEP1とSTEP2)を提案しています

STEP 1

single-day impactを評価する回帰モデル  \Delta \%^{[t,t]} = \beta_0 + \beta_1 \frac{1}{t^{\alpha}} + \beta_2 \frac{1}{t^{\gamma}} を学習します。   \frac{1}{t^{\alpha}} がslow-decay 項、 \frac{1}{t^{\gamma}} が fast-decay項を表します。パラメータ \alpha \gammaはLinkedinのこれまでの何千ものA/B test結果チューニングした値(例として、 \alpha=0.35 \beta=2)を使っています。 slow-decayとfast-decayは以下のgradualとelbowタイプになると述べています

f:id:gingi99:20190824132245p:plain

STEP 2

Novelty effectが検知されたとフラグをつけるために、(a) STEP1で学習したモデルの決定係数が0.8より大きい(つまり十分single-day effectを捉えている)(b) 回帰直線が経過日数に対して単調増加/減少する (c) single-day impactが最も大きい日と最も小さい日で比較し、統計的に有意な差があるか。これらの3つの条件で判定します

最後に注意点として、あくまでSTEP1とSTEP2の評価により、single-day impactに強い傾向が見られることがわかるが、Novelty effectのせいでその傾向が起こってるかは保証できないことを述べていいます。当然ですが、曜日効果や季節効果 *5 により、このような強い傾向を観測することはあります。また、Novelty effectがどれくらいの程度であったかを評価するのも困難であることを述べています

ちなみに、LinkedinでよくNovelty effectが検知されるテストには、新しい機能に最初に触ったユーザは強い傾向を示すこと / 通知系のテスト / 推薦アルゴリズムなどでよく見られると述べています

Trigger-day effect

Trigger-day effectとNovelty effectの違いとして、cross-day impactに強い傾向があるのに対し、single-day impactがフラットになるといった特徴があります

f:id:gingi99:20190824134402p:plain

trigger-day effectがいつ起こるかというと、off-trigger impactとin-trigger impactに大きな違いがあるとき に発生します

例えば、トリガーが"通知を送る"、メトリックがTotal Page ViewであるA/Bテストを想像してみましょう。 トリガーを受けた日には2つのページを1度ずつ訪問し、それ以外の日はいつものページを1度訪問するだけである場合を考えると、ある週でのリフトは 8/7 - 1 ≒ 14.3%です。 つまり、 in-trigger impactは100%、off-trigger impactは0%、すべての日で見たcross-day impactは14.3% になります。 結果、single-day impactはin-trigger impactとほぼ同じとみなすことができるため一定のimpactが観測され、cross day impactはin-trigger と off-triggerの混合した結果になるので、テストが経過するにつれて増加/減少していきます

ここからtrigger-day effectを検知するアルゴリズムを提案しています

まずメトリックを分解していきます。 X_i がユーザ i のテスト期間中のあるメトリックの値の合計とします。それを、トリガーした日のメトリックの値の合計 I_iとトリガーしていない日のメトリックの値の合計 O_iに分解します(つまり、 X_i = I_i + O_i

k日間のそのメトリックのリフトを以下のように定式化します(はてなtex記法の挙動がよくわからなくなったので貼り付けます)

f:id:gingi99:20190824140515p:plain

f:id:gingi99:20190824142004p:plain

 w_k はin-trigger impactの重み係数として表現します

ここで、kを無限大に発散させたとき(つまり、経過日数をどんどん増やしていく)のことを考えると、ユーザがトリガーする確率が p ならk日後までにトリガーしたユーザ数は組み合わせの計算式で求めることができます

f:id:gingi99:20190824142744p:plain

f:id:gingi99:20190824142901p:plain

これで k \to \inf に発散させると、以下のように w_kを得ることができます

f:id:gingi99:20190824142830p:plain

実際のwを求めてシミュレーションしてみると一致することが確認できます

f:id:gingi99:20190824142948p:plain

この定式化を使って、以下の2つの条件を満たすかどうかでtrigger-day effectがあるかを判定します

  1. wが小さい(つまりテストがある程度経過している)、もしくはcross-day impactが圧倒的にsingle-day impactよりかつ一定の値を示している
  2. 2つのリフト  \Delta \%I \Delta \%O に有意な差がある

とくに、2つ目はDelta method*6を使って、 var(\Delta \%I) var(\Delta \%O)で求めれば検定のための情報が出揃うので、判定可能になります*7

さいごに

ヒューリスティック感はありますが、実際解釈しやすく意味のあるImpact指標になっており使い勝手がよさそうでした。しかし、完コピするというより、こういうオリジナル指標をデータやサービスの特性に合わせて自分たちも作る必要があるなーと感じました

参考

LinkedIn の A/Bテスト基盤と文化(KDD2015のFrom Infrastructure to Culture: A/B Testing Challenges in Large Scale Social Networks)の内容を紹介してくれています。Linkedinのように企業独自の1000を超えるメトリクスの管理は参考になりますね www.flywheel.jp

*1:というのも、Internally invalid の章も読んだのですが、Sample Size Ratio MismatchについてはKDD2019の論文が詳しく、他の事象については腑に落ちなかったので

*2:図はWSDM2015 Diluted Treatment Effect Estimation for Trigger Analysis in Online Controlled Experimentsより引用

*3:一度トリガーを経験すると、あとの行動にも影響はなんらかの影響が出る可能性はあるなーと想像は付くのですが、そのようにデータを引っこ抜くETLのほうが大変な印象です

*4:トリガーしないとfully-covered metricsは0になるので、Off-tiggerな日は0ですよね

*5:Linkedin では実用上見たことがないらしい

*6:A Note on the Delta Method - https://u.demog.berkeley.edu/~jrw/Biblio/Eprints/%20M-O/oehlert.1992_American.Statistician_delta.method.pdf

*7:いつかブログで使い方を書くかも

KDD 2019 : Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners を読んだ

KDD2019な時期がきましたので、A/Bテスト系の論文あるかなと探してたときに気になった論文を読みました。

Booking.comのDirector of Experimentation のLukas Vermeer氏のツイートより

dl.acm.org

自分的要約としては、 複数の企業(Microsoft、Booking.com、Outreach.io)のこれまでの知見を集結させて、A/BテストにおけるSample Ratio Mismatch(SRM)がなぜ発生してしまうのかの根本原因を分類し、原因調査の勘所とそれらの防止策をまとめた論文 です。

はじめに

MicrosoftのA/Bテストの例として、以下のようなカルーセル UI でカードの数を12から16個に増やした画面を用意し、どちらの画面が良いかを比較するA/Bテストが紹介されています。

f:id:gingi99:20190807223832p:plain

最初の期待では、16個に増やしたほうがユーザがカルーセルに魅力を感じ、クリックする回数が増えると予想し実験を進めました。しかし、全く反対の結果(つまり、多くのカードを見たユーザほど、カルーセルのクリック回数が有意に減少した)が検出されてしまいました。

なぜこれが起こったかを調べたところ、実験開始後に、A/Bテストに割り当てられたTreatmentユーザ数がControlユーザ数と比べて有意に少なかったことが原因でした。それが起こってしまった原因を特定し(後に理由はでてきます)、正しく検証した結果、期待どおりのPositiveな差を検出することができました。

まさにこの現象のこと、Sample Ratio Mismatch(SRM と言います。つまり、A/Bテストのために割当したControl / Treatmentの2つの集団で、サンプルサイズが 期待どおりの比率で集まらなかった ことで、誤った結果を導いてしまう現象です。

期待どおりというと、例えば多くのA/Bテストでは、テスト対象ユーザを事前に見積もったサンプルサイズのとおり集め、2つの集団が 50 / 50 の比率でスプリットして、テスト対象ユーザをControl / Treatmentのどちらかに割り当てるかと思います。

しかし、実際にA/Bテストを開始しデータを集めると、予定通り50/50になるかと思いきや、集計時にA/Bテストの対象ユーザの比率が 50.2/49.8 (たとえば、821,588人 vs 815,482人) になることがあります。

なぜTreatmentのほうが少なくなってしまったのでしょうか?ただの偶然?そして、これが問題になるのか?とも思いますが、MicrosoftのTechnical FellowのRon Kohavi氏のTweetでもSRMによって本来Flatな結果だった実験も誤って有意差が検出されてしまう例を紹介しています。

また、この論文でも、この現象によりA/Bテストの結果の信憑性が損なわれるため、SRMが発生しているかどうかは検知する必要があると述べています。

この期待どおりになっていないを検出する方法として、統計的仮説検定の枠組みで考えると、カイ二乗検定を行えば検出できそうであることは想像がつくかと思います。

この論文の貢献は、カイ二乗検定などの検出方法についての議論をするのではく、 なぜこのSRMが起こるかを複数の企業のA/Bテストの経験値と調査した実績から分類し、体系立てた ところにあります。

つまり、 SRMが起こってしまう根本原因はこれかこれかこれか....のどれかだと分類し、分析者がSRMの調査のための指針書として役立ててもらう ことが狙いのようです。

MicrosoftとBooking.comとOutreach.ioの連名であることからも、複数の企業の協力によりこの論文が完成しています。

本題の内容に入る前に、スムーズに論文を理解するために、一般的なA/Bテストの4ステップをおさらいしておきます。このステップそれぞれにSRMが起こってしまうポイントがありそうだなーという気持ちで理解しておけばOKです。

(1) 実験の割当。ユーザを、2つの実験グループ(Control or Treatment)に割り当てます。

(2) 実験の実行。ユーザに実験のためのコンテンツが実際に配信され、ユーザが実験に参加できる状態になり、実験が行われます。

(3) ログの処理。ユーザの行動ログなどのデータが収集・処理され、分析できる形式に集約します。

(4) 分析。集約したデータを分析します(当たり前ですが)

SRMの理解

SRMを分類するためにどうしたかというと、この論文の著者の過去のケースを再度分析したり(10,000個にもおよぶ)、実際A/Bテストを行っている分析者のインタビューも含めた定量&定性調査により分類しています。

インタビューに使ったスクリプトも公開されていました:SRM Interview Guide 2019

MicrosoftではそもそもSRMはどれくらい発生してるのかを調べたところ、調べたテストのうち約6%でSRMが検出されました。年間10,000以上のA/Bテストが走ってるプロダクトでは、1日に1度は発生していた試算だそうです。

f:id:gingi99:20190808213120p:plain

実際の分析者のインタビューの内容を紹介されています。そこでは、SRMの発生はA/Bテストにおいて深刻な問題である。またそれがなぜ起こったを特定するのに、何ヶ月もかかることがあったなどが紹介されています。 しかし、SRMを防ぐことも可能であることと、逆にSRMの発生がTreatmentユーザにPostiveな結果であると解釈することもできることが紹介されていました(たとえば、コンテンツのLoad のSpeedがTreatmentで改善した場合、そのLoad Eventに関するログが増加する可能性があるなど)。

5種のSRM

ここからSRMを実際に分類していきます。

1つ目が、実験に割当を行うステップで起こってしまったSRMを紹介しています。

この例では、あるA/Bテストの前に、A/Aテストの時点でSRMが発生したケースがあったそうです。

原因は、実験の割当システムで特殊なUser IDを持ったユーザでのテストの配信トラブル(あまり詳しいことは書いていませんでした)で、50/50でテスト対象者を割当るはずが、49.9/50になっていたことがわかりました。

また、複数の実験を継続的に行っていると、ある実験に参加した人が次の実験にも参加することによるキャリーオーバー効果(ユーザの実験慣れのようなもの)が発生する場合に、SRMが起こってしまったことを紹介しています。

テストを大量に同時に行っているMicrosoftだからこそのSRMな気もしました。

2つ目がA/Bテスト"実行中"(ここでは、1セッションが解析対象になっているため、実行中と言ったときには何かしらのスパンがあるイメージ)に起こるSRMです。

これは、Skypeの改善に関するA/Bテストで、TreatmentにはMLモデルを使ってバッファリングパラメータをオンライン更新し、通話品質を高めることができるかのテストでした。Controlは、予め固定されたパラメータを使っています。

この実験では、当然のようにTreatmentの品質が改善するとMicrosoftは予想していました。しかし、いざ評価すると、全く反対の結果(音声の歪みや遅延が増加)が示され、さらにTreatmentのセッション数(コール数)がControlと比べて30%も少ない結果が得られてしまったそうです。

この原因は、セッションの途中で実験のための非同期に設定がリフレッシュされてしまい、Treatmentユーザの割当が変更されてしまったことが原因であったとわかりました(つらすぎる...)

これにより、Treatmentユーザの30%が、結果としてTreatmentのログとして扱われていないことがわかり、リフレッシュにより品質劣化まで引き起こしてしまったようです。なんとかログを調べ尽くし、リフレッシュが起こっていないセッションのみを使って評価することになりました。

これは、SRMの問題というより、開発側のQAミスなのでは?と思いましたが、この問題からSRMの一般化を行っています。それは、(1) このセッションが実験対象になるときの振る舞い (2) 実験中(つまりセッション中)の振る舞い (3) そのセッションで生成されるログの振る舞いの3つで構成されることを述べています。(3)はログが発生する前にユーザがExitしてセッションが壊れるケースがあるので想像はつきますが、(1)と(2)はかなり丁寧にログを見ないと見つけることも一筋縄ではいかないだろうなと想像できます。また、品質のA/Bテストだからこそ起こる問題かとも思います。

これを検知する仕組みとしてBooking.comでは、データ収集時のログを丁寧に取得し、Treatmentで警告ログ(割当の変更など)が増えてないかなどをモニタリングする仕組みをいれているようです。クライアント側のデータといえば、一般的にはかなりノイズの多いデータになることが想像できます。そこから検知できる仕組みがすでに動いていることに感心しました。

3つ目がA/Bテストのログ処理中におこるSRMを紹介しています。

これは、最初に紹介した12枚のカードを16枚のカードに変更したA/Bテストで起こったSRMです。この実験では、Treatmentユーザ(16枚のカードを見る対象)の数が少なくなっていました。

この原因は、エンゲージメントが高いユーザがなんとログの処理中にBotに分類されて(!)、Treatmentユーザから除外されてしまっていたことがわかりました。 エンゲージメントが異常に高い(大量にカードを見ていた)ことにより、Bot検知アルゴリズム閾値を超えてしまったそうです。

Bot検知を開発してる側も、12枚のカードがきっとこれまでデフォルトでパラメータチューニングされてデプロイされている中、16枚のカードになるなんて思ってもいなかったのだろうと勝手に解釈してしまいました)

この問題をログ処理中のSRMであると一般化しています。実験時の生ログを分析ができるフォーマットにETLするときに不適当な処理が入ってしまう問題であると述べてます。このSRMは防ぐのが難しいとも述べており、個人的には納得できます。

4つ目が分析時に発生するSRMです。

これは一番想像しやすいSRMかと思います。分析時にさまざまFilterを入れることで、不適当にTreatmentユーザが少なくなってしまう、逆に多くなってしまうことはあるかと思います。とくにA/Bテストなので、Treatmentにしか無い機能がある場合だと、Controlと収集ログの特徴が変化してしまうことは想像できます。

5つ目が実験とは関係のない別の要因が干渉してくることにより発生するSRMです。

Microsoft Store のHomepageのリデザイン(画面イメージは下記)のA/Bテストをしたときに、Controlユーザのほうが多かったことがあったことを報告しています。

f:id:gingi99:20190808230245p:plain

この原因は、検索エンジンのキャンペーンにより、ユーザが割当とは異なる誤ったURLに強制的にリダイレクトされてしまったことが原因だったそうです。

これはインターネット上でのA/Bテストだからこそ、別の仕組みと干渉してしまうことはあると思うので、防ぐのが難しい気もします。ユーザ側で見えてる画面までをモニタリングするしかないのでは?とも思います。 実際、Microsoftでは、割当ユーザが正しい画面(URLのパラメータなども見て)を見ているかをチェックしているそうです。

ここまでの5つのSRMを最後の図でまとめています。赤い*マークが複数の実験でインパクトを起こしうる原因です。読者はこの図を用いてSRMの根本原因がどこにあるかを探っていけばよいでしょう。

f:id:gingi99:20190808231150p:plain

10のSRM調査の指針

最後の章に、SRM発生時に調べるべき10の指針を示してくれています。最後の図と合わせて見ながら、これらを調べていけばよいでしょう。

  1. Examine scorecards : 分析時のフィルタがミスってないか調べよう

  2. Examine user segments: あるユーザセグメントだけに起こってないか調べよう

  3. Examine time segments: ある時間セグメントだけに起こってないか調べよう

  4. Analyze performance metrics: A/Bテスト時のログのパフォーマンスメトリクス(ページのロード時間などに差がないか)を調べよう

  5. Analyze engagement metrics: EngagementがTreatmentで高いなら、Engagementが低いユーザが原因で起こっていると考えられる。そのユーザを調べよう

  6. Count frequency of SRMs: SRMが複数のA/Bテストで発生してるなら、原因はA/Bテストシステムである可能性が高い

  7. Examine A/A experiment: A/Aテストで発生してるなら、原因はA/Bテストシステムである可能性が高い

  8. Examine severity: TreatmentとControlのサンプル比率が大きく偏っていたなら、ログ収集およびログ処理時にユーザが除外されている可能性が高い

  9. Examine downstream: データの収集から集約までのパイプラインを確認してみよう

  10. Examine across pipelines: パイプラインが複数ある場合、互いに比べてみよう

おわりに

SRMは結果の信頼性を損なうだけでなく、分析者の調査時間もかなり必要であることを最後まで強調しています。

理想的には、今回の論文でのベストプラクティス集を使うことなく(つまり、SRMに出くわすことなく)A/Bテストを回していきたいと思いますが、SRMに出くわしたときはこの論文にそって調査していければと思います。

Udemyの【徹底的に解説!】Djangoの基礎をマスターして、3つのアプリを作ろう!をやりました

フロントエンドの基礎周辺をなんとなく知っておきたいと思って、udemyで以下をやってました。

https://www.udemy.com/django-3app/

個人的にはかなり良かったです。やった感想をつらつらと、

  • Data ScientistとしてPythonのコードは書けるくらいのレベルでしたが、いまいちWebアプリのPythonコードってどんなの?HTMLやCSSどれくらい知識としているの?とか不明瞭だったのが、かなりクリアになった感じです。
  • djangoの勉強はこれまで何度かトライしようとしては、習得に時間かかりそうだなと思ってやめていましたが、このビデオで用語やプロジェクトの始め方を1から丁寧に説明してくれました。著者はdjangoチュートリアルがわかりにくという感想を持ってるようで、チュートリアルとは違う観点で説明しており、それが自分的にもかなり良かった気がします。
  • pythonやHTMLの説明がなく、ちょうどdjango自体を0から知りたい人向けになっており、自分的にもちょうどよかったです。

次はReactかVue.jsあたりに入門してみようかなと思います。

逐次的に検定を行っていると第一種過誤が増幅してしまう例(KDD 2017 : Peeking at A/B Tests より)

最近KDD 2017のPeeking at A/B Testsの論文を読んでいました。

www.kdd.org

その論文の問題設定に関わるこの図が少し気になっていました。

f:id:gingi99:20190703211931p:plain

これは何かというと、

このシミュレーションでは、サンプルサイズ10,000のA/B Test(仮にAが5,000、Bが5,000の対象が集まるまで続ける)を行うという設定で、データはAとBともに平均0、標準偏差1の正規分布からサンプリングしたデータを使います。 これは全く同じ分布から生成されるデータですので、平均が同じである帰無仮説を棄却してしまうことは、False Positive = 第一種過誤が生じていることを意味します。 そのような設定のもと、対象が集まる度に逐次的に検定を行い、X個のサンプルサイズ(横軸)が集まるまでに設定した有意水準(0.05とか)で有意差が 一度でも 検出される(= P値が有意水準を下回った = 第一種過誤が生じてしまった)確率をこの図の縦軸Yが表現しています。

一例を述べると、有意水準0.05の場合(緑の線)、サンプルが集まる度に検定をしていると、10,000サンプルサイズ集まるころには、約60%の確率で一度はFalse Positiveが発生してしまうことを意味しています。

有意水準0.05なので、そもそも5%の確率でFalse Positiveが発生するのですが、逐次的に検定を行っていると、それが何倍にも増幅してしまうことを示すとても良い一例だと思いました。

論文ではこのシミュレーションの細かい設定までは書いていなかったのですが、自分の理解の確認のため、Rで再現してみました。

パッケージの読み込み等は省略し、以下のシミュレーションを回してみます(結構時間がかかります…)。

sim_func <- function(simulations, sample_size, times, alpha){
  obs <- sapply(1:simulations, function(j){
    data_a <- c()
    data_b <- c()
    n <- sample_size / times
    for(i in 1:(times+1)){
      a <- rnorm(n / 2, mean = 0, sd = 1)
      b <- rnorm(n / 2, mean = 0, sd = 1)
      data_a <- c(data_a, a)
      data_b <- c(data_b, b)
      pval <- t.test(data_a, data_b, alternative = "two.sided", paired = F, var.equal = F)$p.value
      if(pval < alpha){
        break
      }
    }
    return(length(data_a) * 2)
  })
  
  data.frame(alpha = as.character(alpha), obs = obs, stringsAsFactors = F) %>%
    dplyr::group_by(alpha, obs) %>%
    dplyr::count() %>%
    ungroup() %>%
    mutate(false_positive_prob = cumsum(n) / simulations) -> df
  df
}

simulations <- 10000
sample_size <- 10000
times <- 1000
df_010 <- sim_func(simulations, sample_size, times, alpha = 0.1)
df_005 <- sim_func(simulations, sample_size, times, alpha = 0.05)
df_001 <- sim_func(simulations, sample_size, times, alpha = 0.01)

df <- bind_rows(df_010, df_005, df_001) 

1回のシミュレーションの中で、10個のサンプルが集まる(すでに集まってるサンプルに新しいサンプルが追加されるイメージ)度にt検定を行い、設定した有意水準のもと有意差が検出されるかをチェックします。 検出されたときのサンプルサイズを返す(スクリプトの中の変数obs)ことで、10,000個のサンプルが集まるまでに初めて検出されてしまうのはどれくらいサンプルが集まったときなのか?についてのデータを集めます。 これを3つの有意水準でそれぞれ10,000回ずつシミュレーションします。論文と同じ図を描くために累積数を計算して、可視化します。可視化のコードは以下です。

df %>%
  filter(obs <= sample_size) %>%
  mutate(alpha = format(as.numeric(alpha), nsmall = 2)) %>%
  ggplot(aes(x = obs, y = false_positive_prob, group = alpha, color = alpha, linetype = alpha)) + 
    geom_line(size = 1) + 
    scale_y_continuous(breaks = seq(0.0, 0.8, by=0.2), limits = c(0,0.8)) +
    theme_bw() + 
    labs(x = "# of observations", y = "False positive probability")

結果は以下のようになり、だいたい同じような図が描けました。

f:id:gingi99:20190703215943p:plain

論文よりも、False positiveの確率が低くなっているのは、私のシミュレーションでは計算時間を減らす&簡略化するために10個のサンプルが集まる度に検定を行っているためだと思います。 これを1個ずつにすれば、検出される確率は大きくなるため、論文ではそのようにしているのかと思います。

手を動かすことで、論文の問題設定が少しクリアに理解できた気がします(先は長い)