Slide 1
Slide 1 text
広告配信の
データ基盤をつくる
mytk
Slide 2
Slide 2 text
● 本名: 三好 正剛
● 2018年 新卒入社
● 現在は広告配信関連のシステム
・ロジック・データ基盤・BIの
開発などに従事
mytk (まいたけ)
Slide 3
Slide 3 text
● pixiv Adsについて
● 広告データ基盤をつくる (基礎の話)
● pixiv Adsの配信ログをつくる (応用の話)
● まとめ
話すこと
Slide 4
Slide 4 text
pixiv Adsについて
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
pixiv Ads
● pixiv上に広告を表示する
● 1日あたり数億リクエストを捌く
● Google Cloudで稼働
※掲載面はイメージです
Slide 7
Slide 7 text
● 社員やクライアントが広告配信実績を確認するため
○ 消化金額・Imp・クリック・CV・etc…
○ 消化金額の誤差は許容されない
● 広告配信ロジックに活用するため
○ 例: 日別予算を1日かけて均等なペースで消化する仕組み
● 広告配信状況をモニタリングするため
広告配信にはデータ基盤が必須
Slide 8
Slide 8 text
● 社員やクライアントが広告配信実績を確認するため
広告配信にはデータ基盤が必須
Slide 9
Slide 9 text
広告データ基盤をつくる
Slide 10
Slide 10 text
全体像
BigQuery Looker
Cloud Logging
Cloud SQL
GKE
Datastream
Slide 11
Slide 11 text
全体像
BigQuery Looker
Cloud Logging
Cloud SQL
GKE
Datastream
配信ログ
Slide 12
Slide 12 text
全体像
BigQuery Looker
Cloud Logging
Cloud SQL
GKE
Datastream
広告DB
Slide 13
Slide 13 text
全体像
BigQuery Looker
Cloud Logging
Cloud SQL
GKE
Datastream
レポート
Slide 14
Slide 14 text
【ファクト】
集められた測定値 (事実)。広告リクエストの記録。
【ディメンション】
分析の切り口 (次元)。例えば広告の詳細データ。
Star Schema
Slide 15
Slide 15 text
Star Schema
ファクト
Slide 16
Slide 16 text
Star Schema
ファクト
ディメンション ディメンション
Slide 17
Slide 17 text
Star Schema
Slide 18
Slide 18 text
ファクトをつくる
Slide 19
Slide 19 text
ファクトをつくる
重複処理・イベント単位でのデータ結合
Slide 20
Slide 20 text
ファクトをつくる
配信イベントの統合
Slide 21
Slide 21 text
ディメンションをつくる
数十個のテーブルを
少数のディメンション
に集約する
Slide 22
Slide 22 text
ディメンションをつくる
階層構造になることもある
Slide 23
Slide 23 text
pixiv Adsの
配信ログをつくる
Slide 24
Slide 24 text
配信ログ
Slide 25
Slide 25 text
配信ログ
Slide 26
Slide 26 text
なぜ配信ログをつくるのか？
- クリックやCVはImpと紐づけて初めて計測できるから
- 例: クリックはImpから一定期間内に発生する必要がある
- 分析のほとんどがファクト間の関係を見るから
- 例: 「Imp日」別に「クリック件数」を集計する
- ファクトが1つにまとまっているほうが扱いやすいから
配信ログ
Slide 27
Slide 27 text
クリックに紐づくImpは、48h以内に発生している必要がある
配信ログの更新バッチ
Slide 28
Slide 28 text
クリックに紐づくImpを、48hにわたって探索する必要がある
配信ログの更新バッチ
Slide 29
Slide 29 text
確定値バッチ: 1日ごとに直近数日の配信ログを更新 (更新漏れなし)
速報値バッチ: 10分ごとに直近2hの配信ログを更新 (更新漏れあり)
配信ログの更新バッチ
Slide 30
Slide 30 text
Lookerではディメンションとファクトと紐づけて利用する
配信ログによるレポーティング
Slide 31
Slide 31 text
負荷や費用を抑えるための配信ログの設定
● タイムスタンプによるパーティショニング
● クリック (clicked) ・CV (converted) の
フラグによるクラスタリング
● サンプリング用ハッシュ値によるクラスタリング
配信ログによるレポーティング
abs(mod(farm_fingerprint(event_id), 100))
Slide 32
Slide 32 text
- Looker上では「WHERE clicked OR converted OR ハッ
シュ値 = 0」する (料金1/10程度、実際は割合可変)
- Impのようなほとんどの指標は、1/100サンプリングで集
計した値を100倍して計算
- Click, CVは誤差が許されず、件数も少ないため、全件取
得するようにして誤差をなくす
配信ログによるレポーティング
Slide 33
Slide 33 text
集計処理クエリ (LookMLで遮蔽される)
配信ログによるレポーティング
select
100 * countif(suid_cluster_key = 0) as count_imp,
countif(clicked) as count_click,
countif(converted) as count_cv
from `配信ログ`
where (clicked or converted or suid_cluster_key = 0)
Slide 34
Slide 34 text
まとめ
Slide 35
Slide 35 text
基本的な設計は一般的なデータモデリングにしたがう
● Google Cloudを活用したデータ管理
● Star Schemaの採用
まとめ
Slide 36
Slide 36 text
プロダクト独自の要件にあわせて工夫を加えていく
● 広告配信実績を横断的に確認できる配信ログ
● 鮮度と精度を両立できる更新の仕組み
● パーティショニングとクラスタリングの工夫
まとめ
Slide 37
Slide 37 text
分析データ基盤の複雑化を防ぐためには優れた設計を取り
入れる必要がある。しかしその後はプロダクトの状態や課
題に応じて工夫することが大切といえる。
データ基盤は、学ぶことも、考えることもどちらも重要！
まとめ