読者です 読者をやめる 読者になる 読者になる

データ分析エンジニアのブログ

日常のことからプログラミングや機械学習まで@六本木

シリコンバレーのIT企業が利用しているA/Bテスト手法まとめ

データ分析 A/Bテスト

いま注目すべきシリコンバレーの有名なIT企業は新規のデザインや機能が有効かどうかを検証するためにA/Bテストを行っています。 その一方で、日本の企業も含め、A/Bテストを本番環境で導入している企業は非常に少ないです。 加えて、日本で言われているA/Bテストと海外で言われているA/Bテストは少々異なるものだと感じています。 日本のA/Bテストはフォームの最適化やデザインの修正にとどまっている一方で、海外のA/Bテストはプロダクト開発のサイクルの一部分となっています。

プロダクト開発のサイクルの一部としてA/Bテストを取り入れるためには、大量のテストを定常的に回していく仕組みが必要となってきます。 そこでデータドリブンであると言われているようなシリコンバレーのIT企業は自社でA/Bテストの基盤を作成しています。 今回は社内A/Bテスト勉強会で発表するために、シリコンバレーの有名IT企業がどのような手法でABテストを実施しているのかをまとめてみました。 ちなみに対象は以下の4社で、参考にしたのは各企業のブログがほとんどです。

発表したスライド

各企業のA/Bテスト基盤における主な機能

シリコンバレーの各IT企業のA/Bテスト基盤について調べた感想は、部分部分で違った機能を提供してはいるものの、コアとなるような主要な機能はどこもちゃんと取り入れているなという印象でした。

下の表が機能一覧と導入している企業についてまとめたものです。これらの機能がどういったものなのかを簡単に説明していこうと思います。

Metrics You FollowCustom MetricsはLinkedinでしか用いられていない機能なのでここでの説明は割愛します。気になる人はスライドをチェックしてみてください。

f:id:ishitsukajun:20160410230057p:plain

  • 自動集計
    • これは言わずもがなだと思います。手動での集計では手間がかかるため、どの企業もダッシュボードで数値を確認できるようになっていました。
  • コホート
    • コホートはダッシュボード上で確認できる指標を国や性別、OSなどの属性ごとに見ることができる機能です。数値が変化していたときにそれがどの属性やグループで起こっているものなのかを簡単に確認することができます。
  • Group Validation
    • Group Validationはテスト対象と比較対象のグループの割り振りが均等、もしくは意図した通りになっているかどうかをチェックするための機能です。裏側の仕組みにはカイ二乗検定が使用されています。
  • t検定
    • t検定も全てのA/Bテスト基盤に用いられていました。テスト対象と比較対象の指標の値とp値が時系列で確認できるようになっており、p値が0.05以下になると棒グラフのバーが色付けされるようになっているシステムもあります。
  • テスト期間
    • 検出力 (statistical power) が80%になるまでの期間を教えてくれる機能です。A/Bテストの終了までの期間をいつまでにするかの目安として役に立ちます。
  • A/Aテスト
    • A/Aテストはテスト対象と比較対象に全く同じパターンを出す手法です。同じものを見せることでどのくらい値がばらつくのか、誤差の範囲なのかを確認することができます。また、AirbnbではGroup Validationのようにテストの割り振りが上手くいっているかのチェックにもA/Aテストを使用しています。

最後に

今回は社内A/Bテスト勉強会で発表させていただいた内容をブログにさせてもらいました。

この発表は社内向けのものとなってしまったのですが、社内外問わずにA/Bテストの知見を共有したり、みんなでA/Bテストの闇(落とし穴)を共有したりできる場を作れたらいいなと思っているので、勉強会の開催やA/Bテストに興味があれば@ij_spitzまでご連絡下さい!

デモグラフィック属性(性別・年齢)を予測する論文を読んだ

論文 データ分析

読んだ論文

Demographic Prediction Based on User’s Browsing Behavior

  • Microsoftの論文(WWW2007)
  • 引用数は145(2016/03/20時点)

Abstract

ウェブサイトの閲覧データからユーザーの年齢と性別を推定する

提案手法は次の3つのステップから成る

  • デモグラ既知ユーザーのクリックデータからサイトの性別と年齢の傾向を推定する判別モデルを構築する
  • ベイジアンフレームワークを用いてクリックデータからユーザーの性別と年齢を推定する
  • デモグラ属性が近いユーザーは同じようなサイトを訪れるという仮定からスムージングを行う

Introduction

行動に基づくWeb広告は115%売上増、ブランド認知は3%高い

Problem Definition

Teenage: < 18
Youngster: 18 - 24
Young: 25 - 34
Mid-Age: 35 - 49
Elder: > 49

Demographic Prediction

協調フィルタリングはデータがsparseなため難しい

ユーザー属性を用いた予測は精度が悪いため、今回の手法を提案する

Webpages’ Demographic Tendency Prediction

Demographicが既知のユーザーのクリックデータからサイトのDemographic Tendencyを予測する

  • Pr(c | wj) = Σ rij * ui(c) / Σ rij
  • 10ユーザー以上に読まれなかったウェブサイトは信頼性に欠けるので除去した
  • 手法はSVR
  • 特徴量
    • サイトの単語データ
    • サイトの階層構造に基づいて、SVMで分類を行いカテゴリの素性を作成

Users’ Demographic Prediction

Pr(c | ui) ∝ Pr(c | {w})
               ∝ Pr({w} | c) * Pr(c)
               ∝ Π Pr(wj | c) * Pr(c)
               ∝ Π Pr(c | wj) * Pr(wj) / Pr(c) ∝ Π Pr(c | wj)

Demographic Prediction by Leveraging Similarity among Users and Webpages

サイトの数は膨大であり、ユーザーのクリックは少ないためスパースな行列が出来上がる

そこで推薦などにも有用な次元削減の手法であるLSI(SVD)を用いる

さらにユーザーとサイトの類似度を元に近傍の平均を取ってスムージングする

  • Smooth Webpages’ Demographic Tendency Prediction
    • ベクトルのコサイン距離による類似度とサイトの単語内容による類似度からスムージング
  • Smooth Users’ Demographic Prediction
    • ユーザーのコサイン距離が近いT個のユーザーベクトルの平均でスムージング

Conclusion

性別では80%、年齢では60%のF値での精度が得られた

予測精度としてはTeenageが47%、Elderが52%と低い

Feature Researchとしては職業や学歴、地域などDemographicの拡張を計画している

感想

性別推定は80%で比較的実用的なレベルだが、年齢推定は精度が60%と難しいタスクだなという印象。

スムージングで精度が20%ほど向上していて、推薦と同じようにスパースな行列をどうやって処理するかで精度にかなり違いが出てくる。

またTeenageとElderという分類しやすそうなものの精度が悪くなっているので、新たな特徴量を追加すれば若干精度は良くなりそうだと思った。

退職しました

日常

TL;DR

新卒で入社したソシャゲの会社を1月末で退職することになりました.

今は有給を消化しながら, ブログを書いています.

2月からは六本木にあるニュースアプリの会社でデータ分析エンジニアとして働きます.

前職について

新卒で去年の3月入社だったので, 約11ヶ月間ほど正社員のエンジニアとして働いていました.

入社してから3ヶ月くらいは社内全体のインフラやシステムを見る部署にいて, 社内用サービスやツールの開発をしていました. ほぼ個人開発だったので, AWSのネットワーク設計からシステム構築まで経験できたことは非常に勉強になりました. また良かった点として, 使用する技術は比較的自由に選べたので, MEAN環境でのWEB開発でAngularやNode.jsに触れられたのも楽しかったです.

その後は分析の部署に異動して, 社内共通の分析基盤システムの構築, 集計用ツールの開発, 集計業務などをやっていました. 分析基盤は比較的大き目のシステムだったので, 設計してレビューの流れを繰り返しやらせてもらったことはとてもありがたがったです.

以下主な退職理由の抜粋.

  • 切磋琢磨し合えるエンジニアや尊敬できるエンジニアがいなくなった
  • 周囲のエンジニアとの技術ドメインの違い
  • 今後のエンジニアとしてのキャリアを考えたときにデータ分析を強みにしていきたいと思った

新卒で入って1年も経たずに辞めるのかよとか言われそうですが, 内定をもらったときから考えるともう2年ほどになりますし, それから研究があったり色々な人にあったりと自分の進むべき方向もちょっとずつ変わってきたというのも感じていたので, 自分としてはちょうどいいタイミングだったのかなと思います.

これから

冒頭にもあった通り, 六本木にあるニュースアプリの会社で働きます.

会社を選んだポイントとしては,

  • データ分析に強みを持っている
  • 自社でプロダクトを持っていて分析を活かしたプロダクト改善ができる
  • 技術ドリブンな会社である
  • 一緒に働きたいと思えるエンジニアが多かった

という感じです.
今後ともよろしくお願いします.


P.S.
ブログタイトル変えました(・ω・)

社内LT会を開催してみた話

日常

はじめに

皆さんもエンジニアならLTをした経験があったり, LTという言葉は聞いたことがあると思います.
よく勉強会やカンファレンスで行われているショートプレゼンのようなものです.

2015年の6月から社内LT会の開催を始めて, 今月のLTが4回目の開催でした.
今回の記事では, LT会を始めた背景や, どのように運営をしていったかという点について書きます.

参考. Wikipediaからの引用

ライトニングトーク(英: Lightning Talks)とはカンファレンスやフォーラムなどで行われる短いプレゼンテーションのこと。様々な形式があるが、持ち時間が5分という制約が広く共有されている。

背景

LT会を開催しようと思い至った背景として以下の3点がありました.

  • 研修の内容を発表したい
  • 社内のエンジニアの交流や勉強会が少ない
  • ノウハウの共有が少ない

一つ目に, 僕は新卒入社だったので研修という名の個人プロジェクト(学んでいくスタイルの世で言う研修とは全然違います)をやっていました.
当然社内の方とランチなどさせて頂いたときに, 何してるの?みたいな感じで聞かれることが多かったので, この際LTで大々的に発表してしまいたいなと思っていました.

二つ目が社内のエンジニアの交流や勉強会が少ないという理由です.
会社の規模としては150人ほどで, プロジェクトも5つほど動いている会社なので, プロジェクト間の交流が希薄だなと入社してきた時に感じました.

最後がノウハウの共有が少ないという点です.
社内でWikiのようなものがなかったり, 社内の資産と言えるような技術があまりなく, 属人化している雰囲気がありました.
僕が個人でやっていた研修も, 他のプロジェクトとは技術領域がかなり違うものだったので, 研修でやっていた技術も共有できたらなと思っていました.

どのように運営をしていったか

LT会を開催するということは決めたものの, 勉強会を主催したりといった経験はなかったので, とりあえず情報を集めることにしました.
実際に開催されている勉強会やLT会に行ったり, Webで情報を探しました.
以下の3つの記事を参考にさせていただきました.

特に参考にさせていただいたのは以下の部分です.

自分の好きなことをやる

自分は新しい技術が好きだったり, エンジニア文化のようなものが好きだったので, LT会という選択肢は間違ってなかったと思います.
またLT会なら個人が好きなことを話せるので, 参加者としても発表しやすいです.

仲間を見つける

参考の記事でも書かれているようにやはり一人で全部やっていくのは大変です.
告知や当日の司会, 会場準備, 買い出しなどやることはたくさんあるので, コアメンバーとして一緒にやってくれる人が必要です.
僕の場合は同期に協力を仰ぎました.
また以前勉強会を運営していた先輩からも助言をいただいたりしながら進めていきました.

無理はしない

開催頻度を考えるときに特に参考になりました.
当初は週1回や月2回なども考えてはみましたが, プレゼンの準備等も含めるとかなり大変になってしまうので, 結局1,2ヶ月に1回というペースに落ち着きました.

勉強会なんて、その気になれば来週からでもできる

これは本当に言葉の通りだと思います.
やる気のない人はいつまで経ってもやらないし, やる人はやります.

まとめ

LT会を開催してみて, 人が全然集まらず開催見送りとなってしまった悲しい時もありましたが, なんとか半年間で4回ほど開催することができました.
ある回で僕がクローリングについて話した時があって, それを聞いた先輩が後日, 「~のLTを聞いて, クローリングやってみようと思って, 勉強始めたよ」と言ってくれたことがありました.
些細なことかもしれませんが, 会社にとって少なからず良い影響を与えることができたと感じることができ, 行動することの大切さが身にしみました.
諸事情があって次回からのLT会の運営は同期に任せることになってしまったのですが, これからも続いてくれるといいなと思います!

2015年の振り返り

日常

2015年の振り返りをしていなかったので, 今年も既に3日目ですが, 月ごとに軽く振り返っていこうと思います.
会社の都合上書かない方が良いこともあると思うので, ちょくちょく抜けていますが, ご了承下さい.

1月

卒論

2月

卒論発表, 卒業旅行で海外3カ国

3月

入社, 友達とサービスをつくるが失敗に終わる

6月

社内LT会の主催を開始, 人工知能学会, AWS Summit

7月

異動(働いていた部署がなくなる), 友達とサービス開発を開始

10月

友達と開発していたサービスが失敗に終わる

12月

台湾旅行

総括

振り返ってみると, 昨年は失敗の年だったなということを身にしみて感じています.
友達と開発していたサービスが二本とも失敗, 入社してから入った部署もなくなる, といった非常に大きな失敗がありました.
個々の失敗は自分の中で腹落ちしているので, ここでは書きません.
最後に新卒で入社して感じた大事な事と来年の抱負を書いて終わろうと思います.

新卒で入社して感じた大事な事

  • 挑戦をする(=失敗をする)
  • 当事者意識を持って, 成果にコミットする
  • 考える(=手を動かして書く)
  • 専門領域を持つ
  • 旅をする

来年の抱負

2015年はエンジニアリングの面ではたくさんの事を学ぶことができたと感じる一方で, データ分析や機械学習でのインプットが少なくなってしまった.
なので今年は特に統計モデリングや深層学習を中心にデータ分析を自分の強みにできるようにしていきたい.
そういった意味で来年は土台づくりの一年にしたいです.

Goオールスターズに参加してきた

日常

10月11日の日曜日に, Goオールスターズという勉強会に参加してきました.

6つのセッションとパネルディスカッションがあり, とても内容の濃い勉強会でした.

懇親会のピザとビールもたくさんあって満足でした.

eventdots.jp

全体

全体としてはGoの思想や特徴といった話が思ったよりもたくさん出ていて, Goを使ったことのない人にも取っ付きやすい内容だったと思います.


Goの主な特徴としては皆さん仰られていましたが, だいたい以下の3つほどだったと思います.

  • シンプルなビルドと単一バイナリによる移植性の高さ
  • Goroutineによる並行処理
  • 高速でリソース消費が少ない

21世紀のC言語とも言われていて, 発表していたメルカリの中の人はC言語で書いていたところを今だとGoで書いていると言っていました.

やはりちょっとしたツールや並行処理が求められるサブシステムのようなものに向いているようです.

ちなみにRustは21世紀のC++とスライドに書かれていました.


また自分はパッケージ管理にgomを用いることが多かったのですが, Goチームからの見解から判断するにバージョン1.5からリリースされているvendoringを使用したほうがいいとのことでした.

vendoringをサポートするGoの思想としては以下のような理由があります.

  • ソースコードだけでビルドできるという利便性を重視
  • バージョン1.xの間は互換性を重視
  • Googleでの問題を解決することが最優先(依存側が追従 or ホスティングのパスで区切る)


パネルディスカッションではフレームワークの話題にもなりましたが, Goで作る規模のものならnet/httpで十分という意見が多かったです.

たしかに大掛かりなWebアプリをGoで書くというのは中々つらそうです.

ジェネリクスについてもインターフェースで十分という人が多かった.

Goによるモバイル・ゲーム開発

Goだけでモバイルアプリを作ろうというGo Mobileを使ったアプリ開発のセッションや, コミケでGo製ゲームを売った話というGo製のゲームエンジンを使用したゲーム開発のセッションもありました.

Go Mobileは開発スピードが早く2ヶ月前の内容が既に古い, ということも仰られていて, ライトなものを自分の趣味で作るにはあまり不自由しないが, 本番投入にはまだ早いとのことでした.

またGoの標準パッケージを使えるのも面白そうだなと思いました.

最後にじゃんけん大会で頂いたGopher君のぬいぐるみ

意外とかわいい。。

f:id:ishitsukajun:20151012021525j:plain:w300

MacエンジニアがWindowsに移行して環境を整えてみた

日常 Tools

最近働き出した会社のPCがWindows固定なので、仕事中はMacを使うことができなくなってしまいました。
できるだけMacのような環境で開発したい、と思い色々やってみたので記事にしてみます。

インストールしたソフトウェア

以前Windowsで開発していたときはVagrantを使わずに、一からVirtualBoxで仮想環境を構築していたのでVagrantの偉大さを感じました。笑

Macっぽい点としては、XtraFinderの代わりにCloverというソフト、Alfledの代わりにLaunchyというソフトを入れていて、それっぽい動きをしてくれます。

また、KeySwapというキーバインドを変更できるソフトを使って、CapsLockとControlの位置、半角と変換の位置を入れ替えてMacのようなキーバインドになるように設定しています。

Windowsでは設定しないとVimすら使えないのは驚きでした。

インストールしたソフトウェアは以下の通りです。

SSHクライアント
TeraTerm

・SFTPソフト
WinSCP

・ノート
Evernote

・ブラウザ
Chrome

スクリーンショット
SnippingTool

Twitterクライアント
TweetDeck

・XtraFinderのようなもの
Clover

・Alfledのようなもの
Launchy

キーバインド変更
KeySwap(Caps→Ctrl, 変換→半角/全角)

テキストエディタ
SublimeText2
vim

・仮想開発環境
VagrantVirtualBox


ソフトウェアの他には、コマンドプロンプトの起動時にバッチファイルを実行してエイリアスを貼る設定などもしました。

Windowsコマンドをあまり使いたくなかったので、dir→ls、copy→cpなどがUnixコマンドで済むようにするためです。

いくらVagrantを使ってLinuxで開発すると言っても、Vagrantの導入時に多少コマンドを打たなくてはならなかったので、以下のURLを参考に設定しておきました。

Macに比べるとどうしても開発しづらいのはしょうがないですが、Windowsでもなんとかなるんだなって感じております。