Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

AdServerの仕組み

Weitere Verwandte Inhalte

AdServerの仕組み

  1. 1. AdServerの仕組み 黒田英二 www.facebook.com/kuroda.eiji 7 May 2012 1
  2. 2. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 2
  3. 3. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 3
  4. 4. 媒体にとって よいAdServerとは、 媒体がより かる、しくみ。 4
  5. 5. つまり、よいAdServerとは 1インプレッションを より高く買ってくれる、しくみ。 5
  6. 6. 要するに、よいAdServerとは eCPMが高くなる、しくみ。 effective Cost Per Mille 6
  7. 7. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 7
  8. 8. 広告配信のサイクル 管理画面 リスト作成 リスト配布 広告配信 結果集計 8
  9. 9. 広告配信のサイクル 管理者 管理画面 DBサーバ Webサーバ 集計サーバ 配信リスト作成 DBサーバ レポート作成プログラム リスト作成プログラム 配信サーバ 配信リスト配布 9
  10. 10. AdServerを作る上での肝 配信サーバの性能を最大化 広告配信のサイクルを短くする 何があっても配信を止めない 10
  11. 11. 配信サーバの性能最大化 配信サーバの台数が一番多くなる 性能が2倍違えば、サーバが2倍必要 多少複雑になっても性能を最優先 並列処理可能なリスト作成にコスト を寄せる 11
  12. 12. 広告配信のサイクルを短くする リスト作成→リスト配布→広告配信 →結果集計が一回転 5分以内で一回転することが望ましい 一回転の長さと予算超過の幅は比例 リスト作成、結果集計は並列処理 12
  13. 13. 何があっても配信を止めない 配信が10分止まるなら、10分前に終 わった広告を出す方がまだいい 配信が止まらない仕組みが最優先 多少の複雑化は許容 13
  14. 14. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 14
  15. 15. 管理画面の目的 配信結果をとりこみ、 最新のキャンペーンの情報から、 配信リストを作成できる状態にする。 15
  16. 16. 管理画面を作るとき 実は、一番工数が必要 SSP、DSP、アドネットワーク、 AdServerでは管理画面の機能も異なる 開発手法は普通のWebサービスと同じ トラフィックやサーバ負荷は、それほど 神経質にならなくていい 16
  17. 17. 管理画面の機能 媒体向け機能 管理者向け機能 広告枠の作成 (広告タグ) アカウント管理 レポート レポート 広告ブロック キャンペーン承認 広告主向け機能 媒体承認 キャンペーン作成 経理システム連携 レポート 第三者配信管理 媒体選択 17
  18. 18. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 18
  19. 19. リスト作成の目的 広告枠毎に、 表示すべき広告原稿のリストを 作成する。 ※一部のAdServerはユーザ毎にリストを持っている 19
  20. 20. 配信リスト 全キャンペーンの 広告枠A用リスト 広告原稿 広告枠B用リスト 20
  21. 21. リスト作成を作るとき 並列処理が必須 配信リストのスキーマの決め方が重要 極限まで配信サーバの負荷を減らす ユーザ毎に処理する機能に注意 フリークエンシーキャップ 各種ターゲティング(行動/リタゲ/属性) 配信リストが視覚的に確認できるツールを用意 海外を考えた場合、配信リストの配布方法も注意 21
  22. 22. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 22
  23. 23. リスト配布の目的 配信サーバから 配信リストを参照できる状態にする。 23
  24. 24. 配信リストの配布方法 集中型 配布型 ハイブリット型 24
  25. 25. 配信リスト(集中型) memcachedのようなサーバ型KVSを利用 比較的単純な構成になる KVSによってはスケールアウトできる(Redisなど) 配信サーバとKVS間のネットワーク遅延 KVSダウン時のリスク回避が複雑化 海外含めた複数拠点の対応が複雑化 配信サーバがどのサーバに繋ぐか判断が必要 25
  26. 26. 配信リスト(集中型) 例えば、ミドルウェアにMySQLを選択した場合 配信サーバ 配信サーバ 配信サーバ 配信サーバ 配信サーバ 配信リスト管理サーバ MySQL client MySQL server MySQL client リスト作成サーバ 26
  27. 27. 配信リスト(配布型) 配信リストを物理的に配信サーバに配布する スケールアウトが比較的容易 配信サーバ単独で配信可能 性能を最大限に出せる 海外含めた複数拠点の対応が比較的容易 場合によっては、配布の仕組みを独自で作る 配信リストが大きくなると、転送負荷が増える 27
  28. 28. 配信リスト(配布型) 例えば、ミドルウェアにMySQLを選択した場合 配信サーバ 配信サーバ 配信サーバ 配信サーバ 配信サーバ MySQL server (slave) MySQL server (master) リスト作成サーバ 28
  29. 29. 配信リスト(ハイブリッド型) 集中型と分散型を組み合わせる 分け方は、AdServerの特徴に依存する 配信リストのインデックスと原稿を分ける ノンターゲティングとターゲティングを分ける 有償案件、無償案件、自社広告を分ける 海外案件と国内案件を分ける 主にインフラ視点で最適な配信環境が整えられる 仕組みが複雑になる AdServerに求める機能が変わった場合に、対応が難しい 29
  30. 30. 配信リスト(ハイブリッド型) 例えば、ミドルウェアにMySQLを選択した場合 配信サーバ 配信サーバ 配信サーバ 配信サーバ 配信サーバ MySQL server (slave) 原稿管理サーバ INDEX情報 MySQL server 原稿情報 MySQL server (master) リスト作成サーバ 30
  31. 31. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 31
  32. 32. 広告配信の目的 広告枠毎およびユーザ毎に 広告リストから広告原稿を選び 広告原稿を媒体に返信し 表示回数、クリック数、コンバージョン数 を記録する。 32
  33. 33. 配信の主要機能 広告選択 広告表示 クリック コンバージョントラック 上記アクションのログ管理 33
  34. 34. 広告配信を作るとき デプロイのやり方に注意が必要 瞬断も許されない サーバダウンした時の自動切り離し ログの保管、転送方法に注意 34
  35. 35. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 35
  36. 36. 広告選択のキーポイント 広告配信の中で最大の時間を要す 性能(レスポンス速度)最優先 システムで一意な情報のアクセスは要注意 フリークエンシー情報など ネットワーク経由のアクセス ネットワークの遅延時間と安定性は重要 一元管理サーバのダウン時の対応も必須 36
  37. 37. 広告選択に利用する情報① 媒体社の情報 広告枠の情報 カテゴリ 広告ブロック情報 37
  38. 38. 広告選択に利用する情報② ユーザに依存する情報は各配信サーバ間で同じを持つ 次の情報は集中管理する必要がある フリークエンシーキャップ情報 コンバージョン情報 次の情報は各配信サーバに分散管理でも問題ない デモグラフィック情報 行動ターゲティング情報 リターゲティング情報 これらの情報は、広告表示の度に変化させる必要がない 38
  39. 39. 広告選択のイメージ とある配信サーバ 広告枠 配信サーバ 配信サーバ 広告表示 媒体、広告枠データ デモグラデータ デモグラデータ デモグラデータ 一元管理 行動データ 行動データ 行動データ リタゲデータ リタゲデータ リタゲデータ フリークエンシー フリークエンシー管理 配信リスト 39
  40. 40. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 40
  41. 41. 広告表示のキーポイント Apache等のWebサーバを使う httpsの対応 広告要求と広告表示の2種類がある(後述) 一般的に広告原稿は別サーバから配信 海外配信を考慮し、CDNや複数拠点の対応 Post-Impression Conversionの対応 Post-Impression Conversion: 広告を見た(表示された)ユーザだけをコンバージョンのカウントに含める 41
  42. 42. レスポンスのバリエーション レスポンス先 ブラウザ(JS、iframe経由、imageタグ) スマートフォンアプリ(アプリ用SDK経由) サーバ(APIやサーバ用SDK経由) レスポンスの種類 HTML XML JSON 画像 42
  43. 43. 広告要求と広告表示 広告要求数(Ad Requests) ブラウザ等から広告表示用にAdServerが呼ばれた数 この数をもって広告表示するAdServerもある 広告表示数(Ad Impression) 広告要求に対してレスポンスして、実際にブラウザ 等で広告が表示された数 レスポンスの中に1pxの画像を埋め込んで、その画像 が呼ばれた数をカウントする(ビーコン) 43
  44. 44. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 44
  45. 45. クリックのキーポイント 一度AdServerでリダイレクトしてLPに到達 クリックによる負荷は気にしなくていい リダイレクトは、なるべく1回に抑える LPに到達できないケースへの対応があると ベター Post-Click Conversion用記録 LP: Landing Page, 広告主のページ Post-Click Conversion: クリックしたユーザだけをコンバージョンのカウントに含める 45
  46. 46. クリックURLとLPのURL 昔はクリックURLにLPのURLが含まれている場合があった 現在はクリックURLにLPのURLは含まない 不正防止 URL短縮 動的にLPのURLを変更 デメリット 広告表示してからクリックするまでの時間のギャップに対応 デバッグ等がやりづらい クリック時に複雑な処理が必要 LP: Landing Page, 広告主のページ Post-Click Conversion: クリックしたユーザだけをコンバージョンのカウントに含める 46
  47. 47. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 47
  48. 48. コンバージョンのキーポイン 広告タグとは別にコンバージョン用のタグを発行 コンバージョン用タグは広告主側に設置 用途は2つ CPAのコスト確定 CPC等のコンバージョン解析 複数の成果ポイント設定が必要 Piggy-Backの機能も必須 Piggy-Back: このタグを呼ぶ事で、他のコンバージョンのタグも並行して呼べる機能 48
  49. 49. 成果確定処理 コンバージョンの種類によって処理も変わる 事後確定:成果発生の瞬間には成果を確定せず、事後に ログで付け合せ。確定までに数分∼数時間必要。 都度確定:成果発生時に付け合わせをして成果を確定。 Post-Impression Conversion 表示ログが膨大なので、事後確定が一般的 Post-Click Conversion 都度確定と事後確定の両方が考えられる 49
  50. 50. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 広告配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 50
  51. 51. ログのキーポイント 膨大なログの集計サーバ転送方法 並列処理 一定期間のログが再実行可能 ログは情報の宝だが、保存には莫大な費用 トラブルと調査依頼が集中しやすい 管理画面の次に工数が必要 51
  52. 52. ログの種類 広告要求(膨大) 広告表示(膨大) クリック(少量) コンバージョン(場合によって肥 大) 52
  53. 53. リアルタイム性が必要な集計 予算に関する数値 CPM時の広告表示 CPC時のクリック CPA時のコンバージョン数 配信割合の変更 フリークエンシーキャップの計算 リターゲティングの対象ユーザ特定 53
  54. 54. 事後集計が可能なもの 要求数(リクエスト数) デモグラの類推 予算に関係しない数値 例)CPC時のコンバージョン数等 外部データとの照合等 54
  55. 55. 並列処理の重要性 集計の並列化が最も重要 配信よりも先に集計を考える サービス設計時に熟慮が必要 仕様的妥協が必要になる場合も この処理時間が一回転の速さに直結 55
  56. 56. 再集計の重要性 トラブルが起きた時に必要 例えば2日前の1日分のデータを再集計 幾つかの齟齬は不可避 再集計により予算オーバー/未達 各数値が変動 最大限事実に近い数値の提示が重要 56
  57. 57. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 57
  58. 58. 仮に500億imp/月の場合 平均とピークの差について考慮 配信サーバの1割が故障でも稼働 58
  59. 59. 100,000req/sが必要 平均 秒間imp ≒ 20,000imp/s 50,000,000,000 / 30 / 24 / 60 / 60 = 19,290 最大 秒間imp ≒ 40,000imp/s 地域(国)や媒体にも依存するが、平均とピークの差は1.5倍∼3倍 必要 秒間imp ≒ 45,000imp/s 1割の配信サーバがダウンしていても、最大負荷に耐えられるようにしておく。 必要 秒間req ≒ 100,000imp/s impの1.2倍のリクエスト(要求)が来るとすると、impの2.2倍が必要。 59
  60. 60. サーバの台数等 配信サーバ 1台2,000/秒の処理能力 50台必要 集計も50,000行/秒の処理能力は必要 ログ1行200バイト 要求と表示の両方のログを保存すると 19MB/秒,1.6GB/日のログが増える 60
  61. 61. 目次 概要 AdServerの構造 管理画面 リスト作成 リスト配布 配信 広告選択 広告表示 クリック コンバージョン 結果集計 規模感 まとめ 61
  62. 62. AdServerは1日にして成らず 新しいAdServerの場合、リリース後の安定までに半年、長 ければ1年は必要。 その間、昼夜問わずアラートメールが飛んできて対応しなく てはいけない。海外旅行など不可能で、電波が届かないとこ ろに行くのも躊躇する程だ。 エンジニアのモチベーションだけで乗り切れるものではな く、会社の明確なビジョンとサポートが必要になる。 会社と個人の相当の覚悟があって、初めてスタートラインに 立てる。 62
  63. 63. おしまい 63

Hinweis der Redaktion

  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

×