'RTB 廣告投放流程詳解'

​

RTB 廣告簡單來說，就是把訪客的每次頁面瀏覽，通過拍賣的形勢賣給廣告主，誰出的價高就把訪客的這次瀏覽賣給誰，然後顯示相應的廣告。RTB 整個過程主要的三個參與者為 AdExchange，SSP（供給方平臺）和 DSP（需求方平臺）。

媒體將 SSP 代碼嵌入到網站或 APP 中，由 SSP 代碼來控制廣告的展示。多數情況下，SSP 和 AdExchange 屬於同一家公司，下面就詳細說說其中的原理和流程。

競價流程

RTB 流程圖

注：下方的編號和上圖中的序號對應

用戶瀏覽媒體網站，媒體網站通過添加的 SSP 代碼向 AdExchange 發起廣告請求。

AdExchange 將這次請求的關鍵信息（如域名 URL、IP、Cookie 等）同時發送給多家 DSP，我們把這個請求稱為 Bid Request。

DSP 收到請求後通過 Cookie、IP、URL 等信息決策是否參與競價，DSP 可以通過 Cookie 來查詢此用戶在自己系統中的歷史行為來推算人口屬性和興趣愛好，如果 DSP 沒有這個能力，則可以通過第三方 DMP 的協助來判斷用戶特徵，以便更合理地出價，如若出價，則向 AdExchange 返回價格、要展示的廣告、跳轉鏈接等信息，我們把這次信息返回稱為 Bid Response。

AdExchange 選出出價最高的 DSP，通知這個 DSP 贏得了競價，並告訴它此次展示的費用（由於在 RTB 中是採用二階定價，即第二高出價，所以DSP 並不知道實際的費用，需要 AdExchange 再通知一次），於此同時，AdExchange 返回給媒體要展示廣告的 html 內容。

廣告的靜態資源（圖片、Flash 等文件）一般是存儲在 DSP 的服務器，所以在加載廣告代碼的時候需要去 DSP 請求靜態資源

DSP 返回靜態資源，完成廣告的渲染和展示。

Cookie Mapping

以上流程的第三步中 AdExchange 向 DSP 傳遞的是 AdExchange 自己域下的 Cookie ID，由於和 DSP 的域名不同，所以 Cookie 不互通，DSP 無法直接使用 AdExchange 傳過來的 Cookie ID，因此還需要額外的步驟建立 ID 之間的映射關係，以 Google AdExchange 為例，具體流程如下：

Cookie Mapping 流程

注：下方的編號和上圖中的序號對應

SSP 會在媒體網站觸發如下的代碼

http://mapping.doubleclick.com/?dsp_id=123x

瀏覽器自動請求 img 對應的地址，其中 123x 是對應 DSP 的編號，由 Google 提供

假如 DSP 提供的重定向地址為http://dsp.com/pixel，Google 就會重定向到以下網址：

http://dsp.com/pixel?google_gid=qwebdghfe&google_cver=1

其中google_gid為 Google 的用戶 ID

用戶瀏覽器 302 跳轉到第 2 步 Google 服務器返回的網址，DSP 通過 URL 中的google_gid參數得到 Google 的用戶 ID， 通過讀取自己域下的 Cookie 獲得自己域名下的用戶 ID，並將他們記錄在數據庫中

DSP 返回一個 1x1 像素的圖片

通過以上步驟，建立起 DSP 和 Google 用戶 ID 的映射關係，當下一次 Bid Request 請求過來的時候，通過查詢這個映射表，來判斷當前請求在自己庫中是哪一個用戶。Cookie Mapping 不止在 DSP 和 AdExchange 之間，也有可能在 DSP 和廣告主網站之間、DSP 和第三方 DMP 之間，總之目的是為了打通不同域名下用戶 ID 的聯繫。

當你在瀏覽網頁看到一個廣告時，不用再好奇為什麼剛巧符合自己的口味，在頁面加載完之前的那幾百毫秒，計算機在幕後已經做了非常多的工作。

作者：耗子吳