NO AD NO LIFE

ベンチャー企業の広告エンジニアのブログ

広告の基本 - 広告サーバの機能

はじめに

今回は,どのように広告配信が行われるのかについて,主な機能の紹介とともにまとめました. 広告サーバの目的については,以下のエントリを確認してください.

inchom.hatenadiary.jp

広告サーバの定義

前回のエントリで広告サーバの定義ができていなかったため,ここで広告サーバの定義を明確にしておきます. 広告サーバとは,広告を入稿でき,広告を配信でき,配信記録をレポートできるシステム(サーバ群)のことを指しています.

より具体的には,広告管理画面,配信リスト作成サーバ,広告配信サーバ,ログ集計サーバをまとめたシステムとして定義しています.

広告配信の流れ

下図に広告が入稿されてから配信記録がレポートされるまでのもっとも基本的な流れをまとめています.

f:id:inchom:20160214194318p:plain

以下に,それぞれについて細かく説明していきます.

広告を入稿

広告主あるいは代理店は,配信したい広告を広告管理画面を通して入稿します. ここで設定する情報は一般的に以下のようなものになります,

  • 広告名
  • 課金種別(インプレッション課金/クリック課金/コンバージョン課金)
  • 単価
  • 遷移先URL
  • 広告タイトル文
  • 広告説明文
  • 画像URL

上に挙げたものは最低限のものですので,実際にはターゲティング用の設定や,その他広告サーバごとに個別の設定をすることができます.

広告を入稿すると,コンバージョンタグと呼ばれるものが発行されます. コンバージョンタグは,コンバージョンポイントと呼ばれる商品購入時などに表示されるページ(「購入ありがとうございました」というようなページ)に貼付けることで,タグ経由でコンバージョンの計測ができます.

広告配信候補リスト作成/更新

入稿された広告情報を参照して,一定時間おきに広告配信候補リストの作成/更新が行われます. 広告配信候補リストとは,下図のように,入稿された広告の集合から,どのメディアのどの枠,どのセグメントのユーザに何の広告を配信するかを定義したものです.(Indexと呼ばれることもあります)

f:id:inchom:20160214212159p:plain

このような処理をする理由は,広告配信サーバは極めて高速に広告を選択/配信する必要があるため,可能な限り配信サーバ側で処理をさせないようにするためです. 配信サーバ側でどのメディアに配信するかを広告情報や統計データから逐一計算するのは計算コストが高すぎるため,この処理を間に挟まなければ最大でも50msec程度の応答性能が必要な配信サーバでは全く使い物にならないものになってしまいます.

この処理は,広告サーバの肝の部分でありシステム全体の性能に極めて大きな影響を及ぼします.

処理性能という意味では,リストのデータ構造が複雑であったり,複数のデータを読み込まなければ最終的な結果が分からない,などとなってしまうと配信サーバ側の計算コストが上がってしまい,応答遅延に繋がります.反対に,データ構造を簡潔にしすぎると,枠やセグメントのパターンごとにデータ量が倍々で増えていってしまい,データ容量を圧迫するといった問題が起きる可能性があります.

広告自体の収益性という意味では,統計データの更新頻度が遅かったり,データ量が足りない,あるいは,収益性の予測ロジックの精度が低かったり,そもそも配信候補リストに載せづらい設計になっている場合は,広告枠やユーザに対して収益性の高い広告を選択できません. 統計データの更新頻度は理想的には5分以内にしたいところですが,これはシステム全体のサイクルを5分で回すことと同義であるため,リリース後に頻度を高めるのはなかなか難しいです.そのため,システム設計時に慎重に検討する必要があります.

広告配信

広告配信では,広告候補リストを参照して,広告配信サーバが,枠やユーザごとにどの広告を返すかを選択します. ここは,可能な限り処理をシンプルにすることや,並列処理可能にすることで,処理性能を高める必要があります. また,重要な点として,処理性能が追いつかない場合には,サーバの台数を増やすことで簡単に対応できるような設計にしておく必要があります.

消化予算やユーザ情報(フリークエンシーなど)といったどうしてもリアルタイムで参照する必要性がある情報に関しては,ボトルネックならないように注意し,プロセスキャッシュや同一サーバ内にオンメモリ型のDBを立てるなどして頑張りましょう.

また,配信が絶対に止まらないように,単一障害点をなくしていくことも必要になります. 具体的には,データストア周りを冗長化させておいたり(大抵の問題はデータストア周りで起きます),資金や体力的に余裕があれば常に別系統のシステムをスタンバイさせておくなどといった対処をするのが理想的です.

同様に,配信に問題が起きた場合に,問題が起きたことに気づけるようにしたり,どこが問題なのかをすぐに発見できるようにするツール群の整備もしておく必要があります.

統計データを更新

ここでは,ユーザの課金行動(インプレッション,クリック,コンバージョン)のログデータを集計します. ここでの統計データとは,主に二つのデータのことを指しています.

一つは,管理画面のレポート用に,広告ごとのインプレッション数,クリック数,コンバージョン数などといったものの集計データです.これは,主に広告主や代理店が広告の効果を把握するために使われます.より具体的には,効果の悪い広告を停止して,新しい広告を入稿したり,広告の良い広告の単価を上げることで配信量を増やすなどといったことに使われます.ここでの効果は,CTR(クリック率)やCVR(コンバージョン率),CPAなどで測られることが多いため,これらの情報も集計されます.

また,コンバージョン数が増えると単価が上がり,収益性が高まることから,コンバージョンログを可能な限り多く集め,クリックなどに紐付けるように工夫する必要があります. 間接コンバージョンを取る仕組みを作ったり,オフラインの購買データを取得できるようにすることで,測定可能なコンバージョンを増やすことができます.

もう一つは,上記よりもより細かい統計データです.広告単位だけでなく,どのセグメントのユーザやコンテンツ,あるいはより細かい単位で,効果測定を行うために使用されます.このデータは,広告配信候補リストを作成/更新するために使われます.管理画面のレポートとは,全く別系統の集計システムで動作している場合もあります.

レポートを閲覧

広告主や代理店は,管理画面上の配信結果のレポートを閲覧することで,広告の効果を把握します. 広告の効果がコストに見合わない場合は,対象の広告の配信を停止し,別の画像や文言を使った広告を再度入稿するなどといったことをします. 一般的に,広告入稿の頻度は高い方が良いとされ,管理画面のユーザビリティやレポートの更新頻度が,この頻度に影響するため,力を入れる必要がある部分でもあります.

おわりに

今回は,どのように広告配信が行われるのかについて,主な機能の紹介とともにまとめています.

前回エントリで挙げた重要な要素をより具体的に書くと,以下のようになります.

  • 収益の機会損失を失くすこと
    • (ほぼ)絶対に止まらない
    • 障害復旧が早い
    • 高速な配信
  • 収益性の高い広告の配信
    • 統計データの更新頻度を高める
    • 収益性の予測精度を高める
    • 広告入稿の頻度を高める
  • 高精度の成果計測
    • 取得可能なコンバージョンログの数を増やす

実際には,全てを実現するのは,資金的,時間的に難しいと思うので,優先度を付けて設計していくことが必要になるかと思います.