PyConJP 2015にて発表 https://pycon.jp/2015/ja/schedule/presentation/61/

1. アドネットワークのデータ
解析チームを支える技術
PyConJP 2015-10-10
Takashi Nishibayashi (@hagino3000)
1

2. お前誰よ
ID: hagino3000
Takashi Nishibayashi
Software Engineer
(Web/Mobile App)
Data Scientist 見習い
Shibuya.NI (休眠中)

4. 話す事
立ちあがったばかりのデータ解析チームで何をしてきた
か。どこでPythonを使ってきたか。使っていないか。

5. 話さない事
• 最適化問題の証明
• 広告ブロッカーについて
• 同じ広告がしつこく表示されるのなんとかしたい

6. 1. Ad Networkとは
2. データ解析チームの業務とPython
3. 分析基盤の構築
4. 調査・実験
5. レポート

8. Ad Networkとは
• インターネットのディスプレイ広告領域において、
複数の広告主と複数のメディア(広告枠)を束ねて広
告を配信する仕組み
• メディアには収益をもたらし、かつ広告主のマーケ
ティングを成功させるのが仕事。
• Zucks Ad Networkはスマートフォン用のバナー広
告に特化。現在はCPC(Cost Per Click)課金のみ。

9. Zucks Ad Network
広告主 広告主
広告主 広告主
Web
メディア
Web
メディア
スマホ
アプリ
スマホ
アプリ
オーディエンス
入稿 広告配信
広告表示
CPC収益CPC課金
コンバージョン
サイトへの流入
ゲームのインストールや課金

10. 1. Ad Networkとは
2.データ解析チームの業務とPython
3. 分析基盤の構築
4. 調査・実験
5. レポート

11. データ解析チームのミッション
• 配信ロジックの改良やデータ分析によってプロダク
トの収益性を上げる事
• いい感じに配信できるような仕組みを作る事

12. いい感じとは
広告主
他社よりも低いコストで優良な顧客が
得られる
メディア 他社よりも多く広告収入が得られる
オーディエンス 役に立つ・迷惑ではない
弊社 もうかる

13. どの様な状態を目指すか
• 広告主・配信業者・メディア・オーディエンス全体
の利益が最大化される状態
• 誰かが一人勝ちするような施策はまずい

14. 取り組む問題
情報の少ない新規キャンペーンについ
てコンバージョン率を求める
(クリック単価調節)
マルチタスク学習・転移学習
広告枠と相性の良い広告を探す 多腕バンディット問題
人と相性の良い広告を予測する ロジスティック回帰
広告予算の有効活用 線形計画問題

15. 業務内容
• データ分析基盤の構築
• チーム用のAWSアカウントを作る所から運用まで
• データを使える様にする、取得するデータを増やす
• 本番環境で検証しやすくする仕組み作り
• 配信ロジックの差換、組み合わせ、枠指定適用
• 施策の検討 → 実験 → 実装 → リリース → 結果レポート
作成

16. Pythonの使い所
• データの取りこみ、バッチ処理
• boto, BigQuery Python
• 調査・実験・レポート作成
• Jupyter Notebook, NumPy, SciPy, Pandas,
Matplotlib, Cython
• サーバープロビジョニング
• Ansible

17. Not Python
• 広告配信サーバー (Scala)
• 広告表示スクリプト (JavaScript)
• バッチ処理 (Gauche)
• 管理画面 (PHP)
• 計測サーバー (PHP)

18. 状況
• 解析チームは3人
• アドネットワーク全体ではエンジニア10人以上
• チームができて半年程
• まだまだ坂を登り初めたばかり

19. 1. Ad Networkとは
2. データ解析チームの業務とPython
3.分析基盤の構築
4. 調査・実験
5. レポート

20. 背景
• 何も無い所からスタート
• 配信ログはS3に上がっているが……
• 簡単に見る方法は無い
• データを見れるようにしないと仕事にならない

21. 方針
• とりあえずGoogle BigQueryに突っこむ
• 最新のデータを使った調査実験をいつでも可能にする
• 限られた人間が手で叩く程度ならBigQueryの利用金額
は気にならない
• 配信システムに影響を与えないようにする
• AWSのアカウントを分離し、S3経由でログを貰う
• 雑に作ってまずは動かす
• BigQuery周りは後々便利な仕組みが出てくると予想

22. 前処理
配信
サーバー
計測
サーバー
ログ
計測
サーバー
配信
サーバー
ログ
S3
前処理
SNS
トピック
SQS
キュー
GCP
Cloud
Storage
ログ
BigQuery
テーブル
テーブル
テーブル
解析チーム
AWS既存AWS
通知
通知
この辺がPython
300GByte/day

23. 稼動後
• 取りこみサイズは300GByte/day程度
• インスタンスを増やせばデータ量増加には対応で
きる。スケールアップでコア数増やしても良い
• 台数増えてインスタンスの管理が嫌になったら
Google AppEngineに引っ越せばいい
• マルチコア全てを使いきれるプログラムは楽しい

24. 前処理
配信
サーバー
計測
サーバー
ログ
計測
サーバー
配信
サーバー
ログ
S3
前処理
SNS
トピック
SQS
キュー
GCP
解析チーム
AWS
Cloud
Storage
ログ
BigQuery
テーブル
テーブル
テーブル
既存AWS
通知
通知
AppEngine
前処理
!Task Queue
通知

25. 稼動後にリリースされた物
• 便利そうな物が続々登場してた
• Embulk
• BigQueryのUser Defined Function
• Cloud Data Flow
• Stream Insertの制限緩和

26. プログラムから使う
• pandas.io.gbq
• 一瞬でPandasの世界にいける
• 独自ラッパーを作成欲に勝てる
(MongoDBのクエリは覚えられないがSQLを忘れる
事は流石に無い)
• BigQuery Python
• Pull RequestのReview/Mergeが速くて安心感がある

28. 画面で使う
• BigQuery標準のWebUI
• Google Spread Sheet + Apps Script
• 定期的にクエリを投げてグラフを作ったり
• クエリをセルに入力して実行 → 結果がシートに
張りつく物を用意しておく
• 結果が共有できて便利

29. 分散処理基盤
• 機械学習タスクを日々回すフェーズになったら何ら
かの分散処理基盤が必要になる
e.g. Hadoop
• 時期を見て導入予定
• 人が少ないのでフルマネージドサービス狙い
• Googleから何か出てくる気がする

30. ログ回り
• 使えるようにする仕組みが無いと仕事にならない
• 小さく始めてチームの状況に合せて拡充していけ
ば良さそう
• 今はEC2で動かしてるけど、AppEngineか
CloudDataFlowが気になっている
インスタンスサイズとか数とか考える事を減らし
たい。

31. ログ回り (続き)
• カジュアルに始めるならBigQuery超おすすめ
• 取っていないデータは当然流れてこない
• 欲しければ自らアプリケーションを弄って取れる
ようにする
• 検証のために配信に使ったロジックはログに出す

32. 1. Ad Networkとは
2. データ解析チームの業務とPython
3. 分析基盤の構築
4.調査・実験
5. レポート

33. Why 実験?
• 問題が解けるかわからない
• 期待する動作をするかわからない
• 割に合う効果が出るかわからない
• 本番システムの制約下で動くかわからない
• 最適なパラメータを求めたい

34. とりあえずJupyter Notebook
• もはやこれが無いと仕事ができない体に
• Pythonに限らない
• GoからJava 9まで動かせる
• コマンドラインツールを使った課程、結果も全て残
せる

35. 例:配信スケジュール
• 問題設定
• 広告がm個
• 枠がn個
• 1時間毎に配信量を調節したい (時間枠が24)
• 広告毎に予算があり、予算を越えて配信できない
• 収益が最大になる配信量の組み合わせを求めたい

36. 最適化問題を解く
• 配信数は連続値とみなせる、目的関数および制約が線形
• → 線型計画問題
• Pythonなら有償もしくは無償のソルバーが大抵ある
• PyConJPを見ている感じではPuLPが人気
• 本番に載せる時は他の言語の方が楽な事もあるのでセオ
リーは理解しておきたい

37. DEMO

38. この結果は……
• 解けた
• しかし時間毎の期待収益(eCPM)の増減が激しい
• 時間帯の期待収益の下限を制約に追加しよう
• 再実験
• 続く

39. 例:多腕バンディット問題
• どの広告を配信すると収益が高いか、未知の広告に
ついてはわからない
• 活用と探索
• 活用：収益が高いとわかっている広告を配信
• 探索：収益が未確定の広告を配信

40. DEMO

41. 実験と並行して

42. • e.g. 疎結合にして一部処理はPythonで
• KVSを通した時のレイテンシ、コスト(お金)を確認
• e.g. 状態を更新し続ける必要のあるアルゴリズム
• 強化学習やバンディットアルゴリズム
• 全体で共有? スレッド間に留める?
• 状態更新の遅延に対するロバストネス性を確認
本番システムへの実装イメージを固める

43. 1. Ad Networkとは
2. データ解析チームの業務とPython
3. 分析基盤の構築
4. 調査・実験
5.レポート

44. • 新しい配信ロジックを特定の枠に50%投入した状態
で、新旧ロジックによるキャンペーンの選択結果を
比較
• クリックログについて確率分布
と
を比較して差が大きい枠を抽出 (異常枠)
レポートの例
p(x|conversion = 1) p(x|conversion = 0)

45. 説明
クエリ
結果

46. チームメンバへ共有
• .ipynbファイルをコミットしてGitHubにpushする
• GitHubのWebサイト上でレンダリングされた状態
を見る事ができる

47. まとめ

48. まとめ
• ログ解析基盤はチームに合わせて小さく始めてみた
• BigQuery強い
• フルマネージドサービスを使って実験時間を確保
• Jupyter Notebookがあれば生きていける