之前在上一篇文章當中介紹到了網際網路廣告當中幾個關鍵參與方與平台，可以回顧一下。（在整個程式化交易的生态當中不僅僅隻有以下四方，為了能夠讓讀者看起來比較清晰，在後面的章節會逐漸完善各個環節的參與方）
Publisher 把廣告展示機會發送給Ad Exchange & SSP , Ad Exchange & SSP 經過處理後，會分發給各個 DSP & TD 等Ad Server,由Ad Server進行廣告内容的填充。
Publisher 與 Ad Exchange & SSP 的資料互動方式有兩種: API 或者 SDK的方式，本文将會詳細的介紹API的對接方式。
Publisher 即媒體，在當有使用者打開應用進入到有廣告位的頁面的時候（比較比如打開應用時的開屏廣告），媒體想要有廣告展示給使用者。這個時候媒體就會将資料發送給SSP, 在SSP收到來自APP的資訊後，根據自身服務的處理，最終會告知APP使用何種廣告進行填充，如下圖：
既然有雙方在進行通信，則一定需要一門共通的格式來約定雙方通信當中所需要包含的資訊。在這裡介紹一下在RTB當中經常會用到的兩種資料交換格式Protocol buffer與JSON。
protocol buffer 是Google提供的一種語言中立，平台中立，可擴充的用作序列化的資料體。開發者可以自己定義自己需要的結構化資料，并直接在自己熟悉的源代碼當中使用，如C#， C++， Python ， Go, Java。一般用于通信協定，資料存儲。來一段簡單的例子：
（以上例子來自于 developers.google.com）
Json，也屬于一個輕量級的資料交換格式，術語ECMAScript的一個子集。在Json的世界當中，以Key/Values的形式來進行資料的儲存。
Protocol buffer 與Json都可以用做資料交換格式的定義，沒有最好最壞之分，下面列舉一下他們雙方的差別：
Protocol Buffer優點： 二進制格式，體積小，傳輸快，向後相容性好。缺點：通用性差，自解釋性差。
Json 優點：格式簡單，可讀性高。 缺點：檔案大小比Protocol buffer大。
畢竟技術沒有真的對錯，以上隻是粗略描述了2個資料格式。
不管在選擇使用哪種資料格式，都會涉及到具體資料傳輸對象的約定。通用的結構體一般會采取遵從iab (Interactive Advertising Bureau) 的OpenRTB 項目的協定。目前該協定的OpenRTB 3.0正在收集各方的意見。市場上用的比較多的還是2.X版本。
如之前描述到的，當APP上的一個展示機會出現時，APP需要将該Request進行發送。按照OpenRTB 2.4 的協定，大緻需要發送如下的對象。
（圖檔來自于OpenRTB-API-Specification-Version-2-4-FINAL）
簡單列舉部分需要發送的資料對象如下：
• id
發送一個請求的唯一辨別符。
• Imp
發送目前展示機會中的展示對象。
• Site
發送目前開發者的網站資訊對象。
• App
發送目前APP的具體資訊。
• Device
發送産生該展示機會的裝置對象。
• User
發送目前展示機會的該裝置的Human對象。
• Test
發送目前請求是否為測試請求，通用以0表示正式請求，1表示測試請求。
• At
Auction Type, 用于表示該請求采用的First Price 或者Second Price + 作為競價成功标準。
• Tmax
目前請求要求的最大響應時長。
• cur
結算貨币類型。
不難看出，媒體需要向外發出的資訊如果簡單的來講，就是 誰在什麼開發者的什麼媒體的什麼廣告位上産生了一次曝光展示機會。 作為媒體的同學來講，如果把這些資訊的都向外發送的話，是否會讓别人知道太多的資訊？ 我們下面來對誰在什麼媒體的什麼廣告位上産生了一次曝光展示機會。 進行撥洋蔥式的解析。
首先,在什麼裝置上。一講到裝置，以前的一些媒體朋友總會擔心一旦傳輸裝置資訊就是将自己的使用者資訊給傳輸掉了。實際上不會，根據iab的規則，這裡的使用者指的是 Device對象。一般會需要以下的資訊：
• ua
• geo （經緯度，視不同的APP功能可能有的APP不會發送）
• ip
• make (裝置的品牌，如 Apple )
• model （裝置的類型， 如ipad）
• OS (裝置作業系統)
• OSV (作業系統版本)
• hwv (裝置硬體版本)
• h （裝置螢幕高度）
• w（裝置螢幕寬度）
• device (裝置ID， 一般采用的是可以SHA1或者MD5的方式來加密傳輸 IMEI, Android id 或 IDFA)
其次，描述在什麼開發者的什麼媒體上，這裡一般描述的資訊就是開發者的id，名稱，分類，以及APP自身的名稱， Bundle（如App Id或 com.com.adxing）, 分類.
再細化到，什麼廣告位上。 這裡iab提供的是一個Imp(Impression)對象，其中可以包括現在市面上的主流廣告形式，如Banner, Video, Audio, Native。 以Banner 為力，如果這次廣告展示機會是一個Banner的廣告展示機會，則在Banner對象當中會描述出這個Banner廣告位的寬度，高度，可接受最大寬度，可接受最大高度，可接受最小寬度，可接受最小高度，禁止投放的廣告類型（如JavaScript），可接受的廣告物料類型（如jpg, gif）。
綜上，一次展示機會被媒體發出的僅僅隻會是和廣告相關的資訊，而并沒有帶上任何和該APP業務相關的資訊。
作為Request接收方的SSP, Ad exchange 或DSP ,在接受到一次廣告展示機會後同樣也要通過自身的業務處理後，選擇一個最合适的廣告物料告知到APP側。這一部分就是我們通常說到的Response ,還是按照iab的标準來看，需要提供以下的資訊。
主要有這麼幾個内容構成：
Response 的ID
• Seatbid
席位回應的内容
• bidid
• Cur
回應出價的貨币機關
• nbr
未回應的原因
廣告展示的物料的具體資訊展現在Seatbid對象當中，可能會根據不同的SSP或者Ad exchange 約定不同的具體内容。但歸納以下一般會告知媒體以下的資訊：
• price
該物料的出價。
• site_url
該物料的落地頁位址。
• creative_elements
該物料的具體内容，如圖檔的URL, 視訊的URL等。
• click_tracking_urls
當物料被點選時，需要上報的位址。多為第三方監測位址。
• imp_tracking_urls
當物料被有效展示時，需要上報的位址。
在APP擷取到這些資訊後，按照與SSP或Ad Exchange約定的形式進行展示即可完成廣告的一次展示。
從新回顧一下最早我們講到這張圖，整個廣告傳輸的内容無非就是按照約定的資料傳輸格式，按照約定的内容，由APP告知誰在什麼開發者的什麼媒體的什麼廣告位上産生了一次曝光展示機會， 由Ad Serving處理後，告知APP針對這一次展示機會，需要展示什麼樣的廣告内容，以及當廣告物料被點選和被展示時，需要做出何種上報行為。
本期我們就說到這裡，下一期我們來聊一聊在整套互動體系上，如何用阿裡雲的一些功能來規劃一個廣告互動流程。