広告配信の データ基盤をつくる

pixivに広告を掲載できる運用型広告配信プラットフォーム「pixiv Ads」では、毎月200億件以上のログデータが記録され、加工され、活用されています。ここでは、このデータ基盤の全体像と、今のかたちに変化するまでの開発や意思決定の過程についてお話します。また、広告ログ特有の扱いの難しさや、それにどう立ち向かったかについても触れていきます。

Transcript

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