kenju's blog

About Programming and Mathematics

DoubleclickのAd Exchange Real-Time Bidding Protocol公式ドキュメントからRTBの仕組みを探る

developers.google.com

Google子会社であるDoubleclickの提供するReal-Time Bidding Protocolの公式ドキュメント、非常に参考になる。 基本的にはAd Exchangeを使っている人向けの開発者ドキュメントなんだけど、RTBやターゲティングの実アプリケーションの例として、 そのRequest/Response構造などのAPI仕様や、データフロー、規約などから学べるところは多い。

自分も全部読んだわけではないけれど、参考になるドキュメントとして共有します。

入札リクエストの処理フロー

Protocol Buffersというシリアライズ手法を使ってリクエストをやりとりしている。

Google のシステムが送信する入札リクエストの実体は、シリアル化されたプロトコル バッファです。このプロトコル バッファは、HTTP POST リクエストのバイナリ形式のペイロードとして送信されます。

入札リクエストの例はこんな感じ:

id: "Mv\2005\000\017.\001\n\345\177\307X\200M8"
ip: "\314j\310"
user_agent: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13,gzip"
country: "US"
region: "US-MA"
city: "Boston"
metro: 506
url: "http://www.example.com/"
detected_language: "en"
detected_vertical {
  id: 22
  weight: 0.67789277
}
detected_vertical {
  id: 355
  weight: 0.32210726
}
adslot {
  id: 1
  width: 300
  height: 250
  excluded_attribute: 7
  excluded_attribute: 22
  matching_ad_data {
    adgroup_id: 3254984134
    minimum_cpm_micros: 2000000
  }
  matching_ad_data {
    adgroup_id: 2646216548
    minimum_cpm_micros: 2000000
  }
  targetable_channel: "all pages,middle right"
  publisher_settings_list_id: "I\034\334o~)\367\034\020\230E#\235w\212"
  slot_visibility: BELOW_THE_FOLD
}
is_test: false
cookie_version: 1
google_user_id: "CAESEIcS1pC2TBvb-4SLDjMqsY9"
seller_network_id: 1
publisher_settings_list_id: "\357\237V\206)\231\3125%|$\032\""
vertical_dictionary_version: 2
timezone_offset: -300
cookie_age_seconds: 7685804

ads_slotに広告枠の情報が丸っと入っている。あとはURLの他、User Agentや地域情報を送って、RTBオークションに使っている。Requestを設計する時とか参考になると思う。

入札リクエストに対するレスポンス

先の入札リクエストをRTBアプリケーションにPOSTした際の、入札結果の仕様。

アプリケーションから送信するレスポンスでは、Content-Type ヘッダーを application/octet-stream に設定し、シリアル化されたプロトコル バッファをメッセージ本文として記述します。このプロトコル バッファが、 realtime-bidding.proto で定義されている BidResponse メッセージとなります。

レスポンス例:

protocol_version: 1
ad <
  html_snippet: "<img src='my-image-adserver.com/1234567'/>"
  click_through_url: "my.click-through.com"
  buyer_creative_id: "my-creative-1234ABCD"
  vendor_type: 113
  category: 3
  adslot <
    id: 1
    max_cpm_micros: 1500000
  >
>
processing_time_ms: 3

Cookie Matching

Cookieを用いたユーザー情報の一元管理の仕組み。

このため、GoogleGoogle 自身のユーザーを識別する際には、広告配信を行う doubleclick.net ドメインに帰属する Cookie を使用しますが、Google が購入者のユーザーを識別する際には、購入者専用の Google ユーザー ID を使用します。この ID は doubleclick.net の Cookie を暗号化したもので、元は doubleclick.net の Cookie ですが同じものではありません。Google では、この Google ユーザー ID を購入者に渡します(元の DoubleClick Cookie が送られることはありません)。

Peering

要するに、RTBのレイテンシを最小限にするためのリージョン設定とGoogleとの協定(Peering)の話。なるほどこういうのもあるんだ。

Google では、遅延と遅延の不安定要素を減らすために、大量のリクエストを受信する RTB 購入者については Google とピアリング協定を結ぶことをおすすめしています。

レスポンスが遅いビッダーはアプリケーション側によって制限される。

入札リクエストが送信されたときのレスポンスの受信期限は、取引ロケーションから測定して 100 ミリ秒です。取引ロケーション側からするとレスポンスの 85% が期限の 100 ミリ秒以内に受信される必要があり、これを安定して達成できないビッダーは抑制されます。

Best Pricticesのページでも、Peeringが推奨されている。Google側としてもクライアントが増えるし、中間リクエストを最適化できるから、要件を満たすビッダーはPeeringを結んだ方が良いんだろうか。

ネットワークの待ち時間とばらつきを軽減するもう 1 つの方法として、Google のシステムとピアリングする方法があります。ピアリングは、トラフィックがビッダーに到達するまでの経路を最適化するのに役立ちます。接続のエンドポイントは同じですが、中間のリンクが変わります。