OKIYUKI99 Blog

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

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

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

今年はコロナによりリモートワーク化と次男生誕と育児休業が大きな出来事だったなーと感じる

2019年はこちら

gingi99.hatenablog.com

習慣とか

ワーク管理

2019年と大きく変わったなと思うのは、notionを導入できたこと

  • 一次受け

    • Google Keep
    • Pocket
    • ひとりLINEグループ
  • 仕事のタスク管理

    • Github Projectsのカンバン形式でほぼ足りている。Google keepにメモ残してたり、KanbanFlowにも一部残ってはいるがそこまで違和感はない
  • 家のタスク管理とか

    • Trello : もともと仕事やそれ以外のことも使ってたが、家のこと以外はnotionに移行。家のことはアクセスが頻繁にあるのでTrelloくらいがちょうど良いと思いそのままにしている。
    • TimeTree : 去年から変わらず使用中。体験も良い
  • まとめ先

    • notion:EvernoteScrapboxDropbox Paper(一部)とTrello(家のこと以外)にあったものをnotionに移行した。自由にページの階層をコントロールできたり、表現の幅が広いので使いやすい。あとは、Alfredからの検索が無料でできれば嬉しい
    • ASANA:英語に関するメモやまとめ
    • ANKI:英語の表現で暗記したいものをANKIで覚える
    • Dropbox Paper:notionに移行しきれてないので、少しずつやりたい
  • 辞めたツール

    • EvernoteScrapboxはnotionに移行したことで使わなくなった。ツールの数を

アウトプット

  • はてぶ : 2件
  • Qiita : 1件 (アクセスの多い記事のアップデートは行った)
  • note : 1件
  • 外部発表:2件(DEIM2020 / DevDay2020)

今年は件数が減ったのは、次男の生誕もあり、準備や育児の時間が増加したことで、アウトプットの優先度が下がっていた。また、技術面でのインプットは今年少なかったと感じている。逆にインプットとしては書籍が多く読めたり、技術面以外のインプットは多かった。シニアポジションになったことでソフトスキルのキャッチアップを意識していた。そのへんのアウトプットも来年気軽にしていきたいなと思う

英語

リモートワークになるまでは会社の英会話講座を継続していたが、リモートワークになったことで難しくなり、ラジオ英会話とかしたりしたが、今は英語日記に落ち着いている。100日以上続けれているのでまずまずあってそう。あとはANKIで記憶に定着させたい

モノ

Pixel 4a

前のスマホが2年たちそうだったタイミングで、ちょうどPixel 4aが発売されたので乗り換えた。動作も軽いし、なにより以前のスマホの容量32GBから128GBになったのが一番快適な気がする。スマホはある程度良いのを使ったほうがやっぱり良い

store.google.com

Nature スマートリモコン

前々から欲しかったスマートリモコンをやっと購入した。Alexa経由で電気やTVを操作できるのは、育児で手が使えないときにやはり便利だった

掛け時計

子供が時計に興味を持ったので、見やすい掛け時計を買った

プレNEO図鑑

安く買える機会があったので、まとめておもしろそうな図鑑を購入した。図鑑がたくさんある家に憧れてたのでちょうど良かった

Brita

水道に浄水器をセットできるタイプでなくなったので、ブリタを導入した

Kids Park

コロナになって子供が運動不足にならないようにと、両親から頂いた。楽しそうに遊んでたので良かった

おりたたみキッズパークEX

おりたたみキッズパークEX

  • メディア: おもちゃ&ホビー

ストライダースポーツモデル

息子の誕生日プレゼントで母から頂いた。公園で練習がんばってる

横向き用まくら

息子に枕を取られるようになったので、新しいのを購入した

メディアやアプリ

MoneyForwardに戻って家計簿つけはじめた

MoneyForwardのほうがUXが良いのと、家計簿管理を今更真面目につけれることに気づいたので1月分からちゃんと管理するようにした。結果、だいたい毎月の支出と収入がわかるようになってよかった。続けれてるのも良い。

2021年の導入予定

ルンバは来年導入したいが、ハイモデルじゃないとしたいことができなそうなので大きな買い物になるな...。任天堂スイッチで運動も来年くらいにしてみたい。息子の幼稚園も始まるので、なにか関連グッズも増えそう。

Trustworthy Online Controlled Experiments: 1 Introduction and Motivation を読んだ

gingi99.hatenablog.com

Prefaceに続いて1章を読んだメモ

COBOL開発者のGrace Hopper氏の言葉

Grace Hopper氏の引用から本章は始まる

One accurate measurement is worth more than a thousand expert opinions.

正しいデータの価値の強さを表現した良い言葉

イデアの価値を評価するのは難しい

It is hard to assess the value of an idea.

施策リストの中で優先度が低く6ヶ月以上バックログに入ってた施策を開発者から簡単にコーディングできるよと言われてA/Bテストを実施したら、数時間後には今まで見たことのない上昇率を叩き出した話。これはMicrosoftのA/Bテストの中で最も成功した事例となっている。これからわかるように、アイデアの価値は評価するのが難しいという代表的な事例

収益単体をA/BテストのOECにすることは不適切

収益をOECにすると、ユーザ体験が良くなくても上がることがある。たとえば、一時的に広告の量を増やせば収益はあがるが、長期的にみてユーザの離脱を引き起こす可能性がある。Bingでは、ユーザ体験としてユーザあたりのセッション数に対する収益を見ている。つまり、ユーザ体験を下げず収益を上昇させることが重要

OECの例

代表的なOECとして、Active days per userもよく使われる。OECはA/Bテスト期間中で測定できかつ、長期的にもプラスに働くと考えられるものが良い

ParameterとVariant

Parameterは実験変数のこと。一方、Variantはテストされるユーザ体験を指す。ある値をParameterに割り当てることでVariantが発生する

A/Bテストでは、2つのVariantがあるのが一般的。ControlとTreatment。個人的には、Variantが直訳だとよくわからなかったけど、ユーザ体験と言われてスッと理解できた

Data-drivenとData-informed(Data-aware)

Data-informed(Data-aware)はときどきシングルソースデータによって意思決定がdriveされるという意味を避けるために使われる言葉だけど、この本では同一の言葉とみなしている。究極的に、意思決定は複数のデータソース(A/Bテストの結果や定性調査やコードのメンテンスコスト)で決定されるべきだし、Data-driven組織もData-informed組織も意思決定するために、直感に頼るのではなく関連のあるデータを集め、HiPPoに知らせるということは変わらないから

成功するアイデアは3分の1

Microsoftでは、3分の1くらいしかアイデアは成功していない。さらに、BingやGoogleのように十分最適化されているドメインでの成功はさらに難しくなる。メジャーな成功というのは、OECが10%-20%くらいの上昇を指したりするが、Bingだと毎年OECを2%上昇させることを目標にあげられているえらしい(この2%はすべてのA/Bテストの上昇率、つまりTreatment effectの総和で計算しているらしい)

Guardrail メトリックの定義

組織が変更を許容できないと判断するときに使うのがGuardrail メトリック。飛行機の例でいうと、飛行機がクラッシュする確率は絶対にあげてはならない。Guardrail メトリックを保ちつつ、OECを上げるのが必要

実験期間の設定

部屋の温度を少し上げると氷が溶けるかどうかの実験を考える。部屋の温度を少し上げただけではすぐには変わらない(つまり、Short-termでは変わらない)が、長期的にみると溶けてるかどうかは一目瞭然でわかる(long-termでみると変わる)という例えはなるほどと思った

多腕バンディットのはなし

多腕バンディットは大方優れているが、単一のOECで評価関数を最適化していくのが一般的。A/Bテストだと複数のメトリックを評価して決断できるのがメリット

次回2章を読む

Trustworthy Online Controlled Experiments: Contents & Preface を読んだ

Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing を買って興味ある章を読んでいる。読んだ章のメモを残していく。今回はまず目次とPreface

ちなみに、この本の著者はBigカンパニーのフェロー級のメンバーで構成されている

Prefaceではまずこの引用から始まっている。

If we have data, let’s look at the data. If all we have are opinions, let’s go with mine.

これは、NetscapeのCEOであったJim Barksdale氏による言葉

自分なりに日本語に訳すと、"データがあるならデータをみよう。意見しか持ってないないなら、私(つまりCEOのJim)の意思に基づいて次にいこう。” と言ったイメージ

データドリブンと言った言葉がどこでも聞くようになっているので説明不要だと思うが、一方データがないならその会社で最大の発言力があるCEOの意見についていくことになるという意味である。この本は別名HiPPo本と呼ばれているらしいが、HiPPo = Highest Paid Person's Opinion のこと。普通の会社では、CEOのことを指していると思う。CEOの意見に勝るのはデータしかない。データ強し

以下も個人的に好きなフレーズがあった

Getting numbers is easy; getting numbers you can trust is hard !

つまり数値を得るのはかんたんだが、信頼できるかどうかはまた別問題(というか難しい)というのがかなり自分的に刺さる言葉である

このあと、この本の構成が書かれている。Prefaceを除いて全体でPartが5部構成になっている

Part 1: Introductory Topics for Everyone

1から4章で構成されている。このPartはすべての読者が読むべきPartといったところかなと想像

Part 2: Selected Topics for Everyone

5から9章で構成されている。メトリック関連や倫理の話がありそう

Part 3: Complementary and Alternative Techniques to Controlled Experiments

10と11章で構成されている。普遍的な分析技術やA/B testingの限界と因果推論あたりがありそう

Part 4: Advanced Topics for Building an Experimentation Platform

12から16章で構成されている。実験プラットフォームの話で、データエンジニアが主に注力して読むことが期待されている

Part 5: Advanced Topics for Analyzing Experiments

17から23章で構成されている。A/B testingで集めたデータの分析に関わるさまざまな発展的なTopicが議論されている。データサイエンティスト向けだろう

次回1章を読んでみる

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:いつかブログで使い方を書くかも