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氏のツイートより
Diagnosing Sample Ratio Mismatch in Online Controlled Experiments: A Taxonomy and Rules of Thumb for Practitioners. The goal of this paper is to make diagnosing, fixing, and preventing SRMs easier. https://t.co/Qga8rPz31Z #KDD2019
— Lukas Vermeer (@lukasvermeer) August 6, 2019
自分的要約としては、 複数の企業（Microsoft、Booking.com、Outreach.io）のこれまでの知見を集結させて、A/BテストにおけるSample Ratio Mismatch（SRM）がなぜ発生してしまうのかの根本原因を分類し、原因調査の勘所とそれらの防止策をまとめた論文 です。
はじめに
MicrosoftのA/Bテストの例として、以下のようなカルーセル UI でカードの数を12から16個に増やした画面を用意し、どちらの画面が良いかを比較するA/Bテストが紹介されています。
最初の期待では、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な結果だった実験も誤って有意差が検出されてしまう例を紹介しています。
Here is an example of how serious an SRM can be: the "before" scorecard (left) and "after" cleanup (removal of two bots). Key OEC metrics, including sessions/user are indicating large positive movement on the left, but are flat on the right. pic.twitter.com/vsCUS0zSi2
— Ronny Kohavi (@ronnyk) November 21, 2017
また、この論文でも、この現象により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度は発生していた試算だそうです。
実際の分析者のインタビューの内容を紹介されています。そこでは、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ユーザのほうが多かったことがあったことを報告しています。
この原因は、検索エンジンのキャンペーンにより、ユーザが割当とは異なる誤ったURLに強制的にリダイレクトされてしまったことが原因だったそうです。
これはインターネット上でのA/Bテストだからこそ、別の仕組みと干渉してしまうことはあると思うので、防ぐのが難しい気もします。ユーザ側で見えてる画面までをモニタリングするしかないのでは？とも思います。 実際、Microsoftでは、割当ユーザが正しい画面（URLのパラメータなども見て）を見ているかをチェックしているそうです。
ここまでの5つのSRMを最後の図でまとめています。赤い＊マークが複数の実験でインパクトを起こしうる原因です。読者はこの図を用いてSRMの根本原因がどこにあるかを探っていけばよいでしょう。
10のSRM調査の指針
最後の章に、SRM発生時に調べるべき10の指針を示してくれています。最後の図と合わせて見ながら、これらを調べていけばよいでしょう。
Examine scorecards : 分析時のフィルタがミスってないか調べよう
Examine user segments: あるユーザセグメントだけに起こってないか調べよう
Examine time segments: ある時間セグメントだけに起こってないか調べよう
Analyze performance metrics: A/Bテスト時のログのパフォーマンスメトリクス（ページのロード時間などに差がないか）を調べよう
Analyze engagement metrics: EngagementがTreatmentで高いなら、Engagementが低いユーザが原因で起こっていると考えられる。そのユーザを調べよう
Count frequency of SRMs: SRMが複数のA/Bテストで発生してるなら、原因はA/Bテストシステムである可能性が高い
Examine A/A experiment: A/Aテストで発生してるなら、原因はA/Bテストシステムである可能性が高い
Examine severity: TreatmentとControlのサンプル比率が大きく偏っていたなら、ログ収集およびログ処理時にユーザが除外されている可能性が高い
Examine downstream: データの収集から集約までのパイプラインを確認してみよう
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の論文を読んでいました。
その論文の問題設定に関わるこの図が少し気になっていました。
これは何かというと、
このシミュレーションでは、サンプルサイズ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")
結果は以下のようになり、だいたい同じような図が描けました。
論文よりも、False positiveの確率が低くなっているのは、私のシミュレーションでは計算時間を減らす＆簡略化するために10個のサンプルが集まる度に検定を行っているためだと思います。 これを1個ずつにすれば、検出される確率は大きくなるため、論文ではそのようにしているのかと思います。
手を動かすことで、論文の問題設定が少しクリアに理解できた気がします（先は長い）
CHI 2019 : When Do People Trust Their Social Groups ? を読んだ
Facebook のグループ機能に関するデータ解析の論文を最近読みました
自分的要約
- Facebookのモチベーションとしては、ユーザが安心して使うための信頼できるグループを増やしたい。じゃあ信頼できるグループってどんなのか？から入る
- グループを使用している10,000人のFacebookユーザをサンプリングし、アンケートを行う。妥当な回答を得た6,383人を対象に分析を行う
- アンケートとは、ユーザ自体の他人への態度（他人を信頼することができる気質かどうかなど）に関するアンケートと使っているグループでの態度に関するアンケートを実施し、グループの信頼スコアを定め、定量的に分析する
- これらのアンケートにより得られたデータとFacebookの保有する観測データから構成される特徴量をもとに、信頼スコアを予測する回帰モデルを作り、何が信頼に効くかを評価する
- 結果的には、(1)個人の態度は重要、(2)グループのサイズが小さくて、昔から使われてて、均質的なグループが重要 (3)グループ内の人のネットワーク構造は重要であることを示した
- 得られた結果を使って、Facebookがプラットフォーマーの立場として、信頼できるグループ作りに役立てる
以下は、論文の流れにそってつらつらと説明する。
背景知識
- グループの中での信頼関係というのは、メンバーの満足度もあがるし、メンバーのパフォーマンスも上がるし、対立も減らせるし、良いことづくめ（当たり前なんだがきちんと参考論文を引用しているのがすごい）
- Facebookでは、14億人がGroupを毎月使っている
- 関連研究では、個人の一般的な他人を信頼するかの傾向が、特定のグループにおける信頼に影響すると言っている。グループといっても構成される人によるという話。
- 一般的には、ダンバー数150を超えると、認知限界がきて維持が難しくなる（らしい）
過去の研究サーベイがかなり充実していたので、また興味があるときに読むと良さそうです。
データとサーベイ
まずユーザは以下のようにサンプリングしている
- グループをアクティブに使っているUSの10,000人をサンプリング
- グループは5人以上のグループでかつ、28日間に1つ以上の何らかのやり取りが観測されたものを使っている
- 多少のサンプリングバイアス（性別や年齢）が入ってしまったらしい
これらのユーザにサーベイ（アンケート）を広告経由で招待して実施。大項目としては、(1) 個人の他人への態度 と (2) 所属しているグループがどれだけ信頼できるかを質問している。 質問内容は下記の表のとおり。ざっくりいうと、人を信頼する派か？リスクを取るタイプか？など。どうやら、World Value Surveyという何か標準化されているものを使って質問を作ったらしい。こういうのいつか参考になるかもしれない。5段階のリッカート尺度で回答してデータを集める。
（ちなみに、個人に関する情報やグループ内のポストはすべて匿名化されており、このサーベイを実施ことも厳しく監査されてる様子）
別途、グループはどういうタイプのものが多いかもアンケートを取っている。カテゴリは以前Facebookが調査したものを使っている。結果としては、89%が以下の5つのグループに該当するらしい
• Close friends and family (e.g., extended family) -> 20%
• Education/Work/Professional (e.g., college, job)
• Interest-based (e.g., hobby, book club, sports) -> 34%
• Lifestyle/Identity-based (e.g., health, faith, parenting)
• Location-based (e.g., neighborhood/local organization)
アプローチ
- アンケートデータと行動ログ（like数や使用時間など）を特徴量として使う
- 10,000人からアンケートが妥当でかつ、行動ログと合わない人などを除いて、6,383人までデータをサンプルを落としている
- 手法は、オーソドックスに重回帰分析とランダムフォレストとロジスティク回帰を使っている。特徴量の追加を繰り返すことで、決定係数の改善幅を見ていくスタイル
結果
Resultsの章はかなり事細かく記載している。CHI論文らしい感じ。
アンケート項目の基本統計量やアンケート間の相関値を確認する（Table 2）と、グループに対するアンケート（下表）は高い相関を示していることがわかる。
その結果を踏まえて、目的変数となるグループの信頼スコアは、グループに関する4つのアンケート内容のスコアの平均値として使う（といっても、あとから別々にも評価している）
まず、「個人の他人への態度」についてのアンケートの特徴量だけで予測できるかをやってみる。Table 3が結果。
結果をみると、「個人の他人への態度」についてのアンケートの特徴量全部入りで決定係数0.14まで上昇している。そもそも性格的に人を信じるタイプかどうかということだろうか。
ここから、Facebookお手製の特徴量をどんどん入れて決定係数を改善していく。それらの特徴量をまとめているのが、Table 4。
まず1つ目のグループに関する基本的な特徴量を入れると、決定係数が0.08増加したと報告している。
最も効いた特徴量はグループサイズ。それと、グループがPublicかPrivate(FacebookでいうSecretとClose Group)であること。グループサイズは多きすぎる知らない人増えそうだし、PrivateグループはPublicよりは見られないからある程度の安心はあるよねと納得できる。
これらの特徴量で信頼スコアがどう変わるか図示したのが下の図（Figure 1）。
disposition to trust (信頼への気質)によって、信頼スコアの低下の傾きの大きさが違う結果を示していた。この値が低い人ほど、大きく降下していくことを示している。この結果がでても、個人の気質はコントロールできないし、どうして制御するのかは難しい問題である
2つ目にグループのカテゴリに関する特徴量を入れる。
グループの5つのカテゴリの各信頼スコアをみてみる（Figure 2）と「Close friends and family」が高い結果が出ていて、直感的にも正しい。このようなグループカテゴリを特徴量としていれると、決定係数が0.05増加したと報告している。
3つ目にグループのアクティブ度合い。
サーベイに使った28日間のグループ内でのアクティビティ（滞在時間、投稿数、Likeの数、コメント数など）の平均値を特徴として入れると、決定係数が0.04増加したらと報告している。グループ内での交流が盛んなほど信頼できるグループだよねという直感的にも正しい。
4つ目にHomogeneityとhomophily の特徴量を入れる。
Homogeneity（均一性）は、グループ内に所属する人が互いにどれだけ似ているかを測る。論文では、性別のエントロピーや年齢の標準偏差を計算している。homophily （同類性）は個々の人がグループ内の他人にどれだけ似ているかを測る。論文では、性別や年齢をビン化した距離のアプローチを使っている。
これらを特徴としていれたが、あまり改善はなかったと報告している。性別や年齢がバラけていても、信頼スコアには寄与しないのは、家族グループとかは完全にそうだしなーという感想なのでそう言われたらそうな気もします。
最後の5つ目の特徴量として、Network structureの特徴量を入れる。
これはいろいろと工夫した5種類ほどの特徴量があり、Network density（グループ内のメンバー間で友達となっている数の合計を全組み合わせ数で割った数）やpaticular degree centrality（メンバーが持っている友達の数をグループサイズで正規化したもの）など。このNetwork特徴が最も決定係数を改善していて、決定係数を0.10も改善したと報告している。だれもお互いに知らない素なグループよりは、密にあるほうが良いというのは直感的であるが、一番効くというのは驚いた。
最終的にすべての特徴量を入れて、決定係数が0.26、MSEが0.53まで精度をあげている。さらに追加実験で、観測データのみ（アンケートデータは使わずに）でモデルを組んだところ、決定係数が0.15、MSEが0.59になったと報告している。アンケートデータは将来に渡って使えるとは限らないので、こういうふうにロバスト性をチェックするやり方はとても良い。
Figure 4に各特徴量の重要度をまとめている。重要度は計算したい特徴量を抜いて、MSEがどれだけ悪くなってしまうかの比率で定義している。Network Structureの特徴を抜くと、22%も悪くなってしまうことがわかる。こういう可視化わかりやすいと思うので、機会があったらやってみたい。
アンケートをとってから28日後までに、グループのメンバーサイズやつながりの数が変化があったかをグループの信頼スコア別に評価している。 面白いのは、信頼スコアの高いグループほど、メンバーサイズが増加していないことがわかる。（Figure 5の左） これは、メンバーサイズの増加率が停滞してくることが、信頼スコアにおいては良いグループになってくることを示唆している。こういうのが定量的に現れるのは面白い。
最終的に、得られた結果をFacebookがどう活かすが最後に述べられている。
- プラットフォーマーとしての立場として、Group Adminに信頼スコアを提供するなどを考えている。
- グループの推薦ロジックの改善に役立てる
- グループサイズに応じたり、個人の信頼への気質でロジックを変更できるだろうと考えている
- グループ内の知り合いを探しやすくして、友達のつながりを増やすことなど
感想
個人的には人間の潜在的な心理状態は、サービス提供社が保有するログだけからじゃわからないけど、アンケートも加えると、そのログにラベルが付いた状態で解析できる分、掛け算効果でログの情報量が増える印象。何より分析が面白くなる。このような理想的なストーリーはいつも頭に入れておこうと思う。
2019GWにやったこと
ただのGW記です。令和になったGWは10連休ということでしたが、お互いの実家に帰省。息子と遊んだりでのんびり過ごしました。
GWは普段とは異なるインプットをしようと思い、気になってた本を読んだり、Webサーフィンして調べものをしていました。全体的にキャリアや組織論に関することを調べていました。
以下は読んだ本や参考になった記事。
CAREER SKILLS ソフトウェア開発者の完全キャリアガイド
CAREER SKILLS ソフトウェア開発者の完全キャリアガイド
- 作者: ジョン・ソンメズ,まつもとゆきひろ,長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2018/06/22
- メディア: 単行本
- この商品を含むブログ (2件) を見る
これまでのキャリアを振り返ると、データ分析周りでエンジニア、リサーチャー、データサイエンティストというロールで仕事をしてきましたが、個の競合優位性を高めるために、次に何をプラスしようかと考えていました。 この本は下のSOFT SKILLSの著者ジョン・ソンメズの2018年に出た本です。
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログ (8件) を見る
20万語を超える本なので、全部読むのではなく、気になった部・章だけ読めるように設計されています。自分は5章のキャリアの進め方を中心に読みました。
スペシャリストとゼネラリスト論できっぱり言い切ってくれている箇所があり、気に入っています。
ソフトウェア開発者の多くは、すべてのスペシャリストがゼネラリストでもあるのに対し、ゼネラリストは決してスペシャリストではない
自分の分野全体についての一般的な知識の広い裾野ができてなければ、優れたスペシャリストになることは非常に難しい
また、スペシャリストを目指すときの選択肢としても、スモールスタートで特定の言語のフレームワークやライブラリの専門家を目指すようなイメージを勧めています。
大きすぎる専門分野を選ぶくらいなら、小さすぎて特殊すぎるものを選ぶようにしよう
サイドプロジェクトをしようという話もおもしろかった。
ソフトウェア開発者としてのキャリアを伸ばす最良の方法は間違いなくサイドプロジェクトだ。
まず第一にどんなサイドプロジェクトを手がける場合でも、そこから大きくなくても収益を上げる方法を考えることをお勧めする
これまでサイドビジネスとして、趣味でもあるボードゲームの制作を行い、サークルとしてピクテルを制作したり、海外版Imagineを流通させてきましたが、そろそろ別のサイドプロジェクトを持つことを考えるきっかけになりました。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
前々から評判のよかった本を読めました。たしかに前評判どおりの内容の濃さでした。
特に社会学者の話で、「社会人はコミュ力大事！」という理由もなく通説になっていることを3つの不確実性（他者理解の不確実性・伝達の不確実性・成果の不確実性）に分解しているのを見たときに、「あーこれでコミュ力なんで大事かがやっと人にきれいに説明できる」と思いました。
というふうに気づきの多い本でした。何度か読んで、脳に刷り込んでいきたいです。
岩波データサイエンス Vol.3
- 作者: 岩波データサイエンス刊行委員会
- 出版社/メーカー: 岩波書店
- 発売日: 2016/06/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
もはやX周回遅れ感がありますが、今のチームメンバーの分析思考のなかに、因果推論の基本事項がデフォルトインストールされている感じがしていたので、そろそろ議論の中でその視点から価値出せるコメントができるようにと思い、精読しました。 傾向スコアの強力さは複雑な共変量を1次元に落とし込むシンプルさと説明力だと解釈できたり、差の差法やABテストの操作変数からの見方がやっと腑に落ちたので、がんがん使っていきたいと思います。
ワーク・ルールズ！
- 作者: ラズロ・ボック,鬼澤 忍,矢羽野 薫
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2015/07/31
- メディア: 単行本
- この商品を含むブログ (10件) を見る
これも周回遅れ感があるが、Hontoライブラリに眠っていたのを読んだ。が、特に今となっては何か新しい視座を得ることはそこまでなかったので、流し読みしました。また組織論をキャッチアップしたいときにいずれ戻ることはあると思います。
プロダクトマネージャーとか
キャリアの話の続きで、データ分析周りしてて、ゆくゆくはプロダクトマネージャーのキャリアもあり得るだろうなと考えていて、以下の記事がわかりやすかった。中のリンクも読んで、自分に足りてなそうな視点を拾っていきました。
プロダクトマネージャーは特にビジョナリーが大事なのは強調されているが、UXデザインの知識も必要であることが気になりました。大学時代に認知心理学とかを学んで以来、知識がストップしてるので、リフレッシュしたいなーとは思っていますが、なかなかどう習得したらいいのかわからない。実践経験？
つづく
INSPIREDとジョブ理論の評価が高そうなので、また引き続き読書しようと思います。
1st Shiny Contest に参加しました
Shiny Contest とは？
Shinyとは、さまざまなinput形式に基づき動的にグラフを作成し、Webアプリやダッシュボードとして簡単に公開できる人気の高いRライブラリです。
Rが好きな理由の一つに、Shinyのことを言うRユーザは多いのではないでしょうか（私の希望的観測）。
本題のShiny Contestとは、1月7日にRStudio社の公式ブログで発表された第1回目のShinyアプリのコンテストです。
参加資格としては、
- RStudio Cloudでソースコードを公開すること
- shinyapps.io にデプロイすること
- コードやデータは自由に公開できること
を満たすアプリであればだれでも参加できます。
参加するために、RStudio CommunityにBlogを投稿する必要がありますが、アプリの紹介とデプロイしたアプリのURLを書いて投稿完了となります。
締め切りは3/8まででした。実は私がこのコンテスト知ったのは、2月末ごろにRStudio社のツイートがRetweetされていたのをたまたま見て知りました。
ABテスト用のサンプルサイズ計算アプリを投稿してみた
このコンテストを知る前から、自身の統計の勉強も兼ねて、ABテストのシミュレーションに使用するためのサンプルサイズ計算Shinyアプリを作っていました。
ちょうどコンテストのことを知ったときくらいに、アプリはできていたので、いろいろと機能を加えて投稿しようと考えました。
ABテスト用のサンプルサイズ計算アプリはすでに世の中にたくさんあります。しかし、このとき自分がなぜいまさらShinyアプリを作ろうと思ったのは、既存のアプリでは満足できなかったからです。例えば、
- Type Ⅰ / Type Ⅱエラーのサマリーした表が欲しかった。有意水準と検出力を人に理解してもらうためでもあります。検出力が小さいとこの箇所のパーセントが小さくなりますと人に説明することを想定しています。
- サンプルサイズ計算までの各パラメータをまとめてhtmlのテーブルに出力したかった。htmlテーブルだと、社内のConfluenceに秒でコピーペーストでき、各パラメータを動かしたときの必要なサンプルサイズの結果をすぐにお伝えすることができるからです。
- 有意水準と検出力を可視化したプロットが欲しかった。この効果量だと、A群とB群の分布がこうなるんですよと人に見せることをを想定しています。
上記のように、人に説明することを想定して、自分の理解も深めようと考えアプリを作成しました。
実装したGithubはこちらにあります。
また、RStudio Communityに投稿したポストはこちらです。
実は自分が投稿する数日前に、下記のブログの作者もサンプルサイズ計算のためのShinyアプリを投稿していました。
このアプリのコードを読んで、アイデアをいくつかもらい、自身のShinyアプリにも追加で実装しました。 この記事でも、結果を誤解されないように丁寧に項目を精査している旨が書かれており、非常に参考になりました。
結果発表
4/5にRStudioから結果が発表されました。
当初の予定では、3/22までに発表すると予定されていましたが、予想以上に投稿数があったたため、発表日を延長したみたいです。
上記の公式ブログにも各種統計情報が掲載されていますが、136個の投稿があり、4人のWinnerが選ばれました！
選ばれたアプリをぱっと眺めているだけでも、Shinyでどうやって動いてるんだ？と思うものがあり、見てるだけで非常に楽しいです。一度は目を通すと勉強になるかと思います。
気になったShiny App
69 Love Songs: A Lyrical Analysis
Best Design ということでWinnerに選ばれたアプリです。開くとわかりますが、フォントといい、可視化の色使いといい、クールな見た目のアプリです。
ぱっと見て複雑な処理はそこまで多くなさそうなので、どうやって実装しているかをあとでチェックしたいと思います。
Pet records
こちらもWinnerに選ばれたアプリです。自身のペットの医療やワクチンのトラッキングアプリのようです。アイデアがユニークなのと、見た目のビジュアルも美しく、見ていて楽しくなるアプリです。
R Package Explorer
開くとわかりますが、もはやShinyアプリの見た目ではありません笑。
HTML Templateを駆使しているとのことですが、RのcomponentをどのようにHTMLの中に入れてコードを書いているのか気になりますので、こちらも要チェックです。
ubeRideR
自身のuberの走行データを用いて可視化しているアプリです。こちらもHTML Templateを使用しているとのことですが、Shinyアプリの一線を超えた見た目に驚きました。
おわりに
Shiny Contestによって、世界中からさまざまなアイデアを持ったShiny Appアプリが集まってきました。 提出する前にすでに投稿済みのアプリを眺めていましたが、非常にユニークなアプリが多く、見ているだけで楽しかったです。
投稿されたものについては、ほぼすべての実装がRStudio Cloud上でソースコードが公開され、すぐに実行することができるようになっています。 これを機に、気になったShinyアプリを見つけ、ソースコードを追うなどして深くShinyを勉強できるかと思います。
また、一からShinyを学びたい人は、今は非常に日本語の資料も増えてきています。
特に、@Np_Ur_ さんの100本ノックやShiny Advent CalendarやShiny本からはじめると非常にスムーズに学べるかと思います。
次回のShinyContestでもなにか出せるようにネタを作っておこうと思います。そして、日本からもどんどん提出していきましょう。
参考
私が実装するにあたり、既存のABテストに関わるShinyアプリをいくつか参考にしました。
RStudio conf 2019で発表していたABテストのモニタリングツールをShinyで作っている話です。 Building an A/B Testing Analytics System with R and Shiny
ABテスト用にサンプルサイズの計算結果をもとにシミュレーションしてくれるアプリです。 https://gallery.shinyapps.io/CampaignPlanner_v3/
2018年導入してよかったこと・振り返り
今年も終わります。昨年のまとめに続きに今年も振り返ってみます。
昨年の導入してよかったもの＋習慣とかの振り返りを追加した感じです。
習慣
ワーク管理を更新
ツールを増やして、以下で運用中。
- 一次受け
- Google Keep：すべてのメモ
- Pocket : Web系の気になる記事等の一時保存
- To Do管理
- Trello : To Do管理。カンバンっぽく使っている
- 共有
- HackMD：Markdownで他人に共有したいときに使っている
- まとめ先
他にも、KanbanFlowやScrapboxも使い始めてるが、ツールが多すぎると逆に面倒になりがちなので、使い方を考えている。
論文をiPad + Papersで読むようになった
iPadを調達して、論文を読むために、学生特権でPapers3を購入した。論文・PDF管理はそれに一任できて、問題は起こってないので、来年もこのままいく。
投資信託
博士課程を終えて、時間ができたのもあり、記事をみたり本を読んだりして勉強して、いろいろと申し込んだ。この辺の知識は知っているか知らないかで人生の後から損する系なのでコツコツ情報収集しないとなと思った。
アウトプットの習慣
- はてぶ : 12件
- Qiita : 5件
であった。あまり数が多いほうが良いとかも思わないが、毎年+1以上で増やしていきたいと思っている。 書きかけの記事もあったりするが、質もあげていきたいので、コツコツ書く習慣を継続する。
転職活動した
転職エントリはまた別日に書くとして、転職活動は自分の悶々と考えていたキャリアプランをクリアにし、外を知ることで自分の立ち位置や今後どういうポジションの人になるのか考えるを良い機会であった。同じ業界のさまざまな人と話せるのはそれだけで楽しかったりしますしね。
朝型生活
会社にいくときは、7時30分に出社して、16時30分に帰るのをベースにした。 家に帰って、家族でご飯を食べて、子供をお風呂にいれて、子供が寝たあとは、夜は2時間以上時間ができるので、集中して1タスク以上取り組むみたいな感じ。
今年の後半は、有給消化の関係で、適当な生活時間になったが、来年もほぼこのベースを続けたい。
LINE Pay
お財布いらずで買い物できるし、貯まるポイントでお買い物できるのは良い。使える場所もめちゃくちゃ増えてるし。
動画で学習
Amazon Primeもそうだが、Youtube Premiumのおかげで広告なしでオフライン動画を見れる。 英語もGoogleのおかげで字幕付きで見れるし、これからはYoutubeでキャッチアップすること増えるだろうなーと思っている。
モノ
Huawei p20-lite
スマホを2年ぶりに買い替えた。以前のスマホよりカメラの性能が大きく上がって満足。キャリアもキャンペーンに乗っかりUQに変更した。
Baby Smile 電動鼻水吸引器 メルシーポット
Baby Smile 電動鼻水吸引器 メルシーポット S-503
- メディア: Baby Product
子供鼻水吸いのための導入。先輩型のおすすめどおり買ってよかった。
大和屋 すくすくチェアプラス テーブル付
大和屋 すくすくチェアプラス テーブル付 ナチュラル 7か月~
- 発売日: 2017/10/13
- メディア: Baby Product
テーブルの高さと同じくらいで、子供を固定できて、成長してもイスや足置き場の高さを調整できる。
シャープ 過熱水蒸気オーブンレンジ 2段調理
シャープ 過熱水蒸気オーブンレンジ 2段調理 31L レッド RE-SS10B-R
- メディア: ホーム&キッチン
一人暮らし用のレンジから買い替え。毎日使う妻が嬉しそうだった。パンも焼けたりで、生活の質が上がる良いお買い物でだった。
バンキンス 油が落ちるスリーブビブ
子供用に毎日使っている。夏は暑いかもだが、それ以外の季節なら汚れを服につけなくてとても良い。
象印 炊飯器 5.5合 IH式 極め炊き
象印 炊飯器 5.5合 IH式 極め炊き ブラウン NP-VQ10-TA
- メディア: ホーム&キッチン
一人暮らし用の炊飯器から買い替え。値段も安いのに一気に美味しくなるからもっと早めに買ってよかった。
メディアやアプリ
ゲームオブスローンズ
Amazon Primeでたまにコツコツみてる。まだシーズン5見終わったところ。ハマる理由として、キャラの濃さと毎回最後のシーンが「えっ？」って感じなところ。
Kindle Unlimited (無料体験のみ)
マンション関連の知識をつけたくて、1ヶ月だけ使った。読める本はそこそこ面白いのもあったが、継続して使うにはもう少し新書だったりを充実してほしいと思った。古い本は、情報が古かったりするので、あまり読む気になれなかったり。
Grammarly
カンタンに英文の文法チェックをしてくれる。精度もそこそこ良いので、英文書いたら必ず通すようにしている。Macのデスクトップ版を使っている。
2019年の導入予定
マンション
購入するかどうかはわからないが、子供が大きくなる前に決めていきたいと思っている。今はいろいろ調べ中。
Amazon Echo でのスマートな生活
購入したものの、継続して使いこなすほど使ってないので、また改めて考えてみる。TVの電源を消すアプリ作るところからかな。
子供用のおもちゃ
最近はおもちゃで面白いの増えてる（自分はほとんど買ってないのだが）ので、自分がむしろ興味がある。 というのも、ボードゲームと同じようにおもちゃによる知育にゆるく興味があるので、なんか良さげなおもちゃをビックカメラで探してる。
