之前就有不少同學問過我，想用DSP去上游流量ADX競價接流量，然後將流量倒給自己的聯盟以及自己的ADX再售賣給下游買家的一些玩法的問題。

當時我不是特別主張這種做法，所以並未回答細節邏輯，主要因為：

  1. DSP一般同ADX整個競價的處理時長最好控制在100ms以內，一般若跨區域網路通訊時間的至少20ms以上，網路好一些的也要10ms，除非部署在同一個機房能控制在10ms以內。若採用這樣串的方式，最後時間都消耗在網路上，可能會導致大量競價超時，大量的流量無法被使用。計算資源及流量的低利用率，造成投入浪費。
  2. 從宏觀競爭角度看，高度商業競爭的結果會使得商業價值陸續集中在「微笑曲線」的兩端，即第一手的「資源」供方，或第一手的「需求」買方，或是解決某類業務需求的門戶入口平台。可參考之前文章《獨立DSP未來預測（中）——數字營銷2017職業雞湯》中的系列論述。那些在中間靠信息不對稱賺取差價存活的模式做不大也做不長久，當然不排除微觀上存在這樣的公司和服務。
  3. 按我的經驗，國內大部分的流量平台，一般流量接入都會主要使用SSP模塊直接對接媒體的廣告系統，而不是通過ADX對接的，因為不論從價格以及效率上都會有很大損耗的。
  4. 基於上述的幾點，一來技術存在嚴格的約束，二來商業模式做不大也走不遠。所以基於這樣的結論，我當時沒有就一些細節及執行邏輯層面予以詳細的梳理和回答。

可巧最近在程序化廣告實戰的粉絲討論群中，有同學再次拋出這個問題，並表示可能海外會有類似的場景出現。所以我這裡將解答的相關內容整理出來，分享給到有需求的同學們。

如上圖所示，ADX2是ADX1的下游，通過OpenRTB競價介面接入ADX1的流量，ADX1的流量源頭來自SSP的流量接入，ADX1也接了一些DSP（如DSP1）直接競價購買流量。ADX2也會採用OpenRTB競價介面對接其再下游的DSP2，DSP3等，按這位同學的描述，這樣做的好處是，ADX2方能聚合購買需求及消耗量級，提升對ADX1的商務談判力。

這位同學問的問題是：如圖所示，DSP1出價0.8，DSP2出價1.0，DSP3出價0.5，那麼ADX2該對ADX1出多少價？以及若獲勝該對下游DSP如何收費？

這個問題核心的困擾其實在於，因為大家會認為ADX都是按「第二高價」來決策價格，所以若ADX2按DSP2勝出，成交價0.51，若按0.51對ADX1出價（或加上一個利潤係數），最終邏輯上怎麼算都是走不通的。

後來我梳理的結論是，不論這樣的ADX串聯有多少層，最終的按「第二高價」的價格決策引擎只能落在最源頭的ADX1，中間的ADX2隻能按最高價透傳的方式將ADX2下游的最高價買家的出價透傳給ADX1，這樣邏輯上才能走的通。

說到這裡我補充說明一下，其實在IAB官方發布的OpenRTB2.5協議已有個「Source」段，其實就是為了用來解決這類串聯問題的。（大家可參考文章《OpenRTBv2.5-IAB關於程序化模式的定義系列【基礎類】》中關於OpenRTB2.5協議的中文介紹。）

有同學反饋他們在OpenRTB2.4協議中沒有查到這個欄位，確實如此，所以請大家參考OpenRTB2.5協議文檔來設計。大家可點擊文末的「閱讀原文」查看OpenRTB2.5的官方文檔。

下面是我將文檔中關於「Source」段的部分內容截圖如下，供大家快速參考：

所以對於ADX2的設計，只需在ADX2不做第二高價的價格決策引擎即可，僅需做最簡單的價格排序，然後按OpenRTB2.5協議的建議，將ADX2對其下游DSP（圖中示例中DSP2、DSP3）開放的競價介面中加入「Source」欄位即可，當然ADX2也可直接接入SSP資源，遇到SSP過來的資源ADX2還是可以做第二高價決策引擎的，遇到是對接上游ADX（圖中示例中ADX1）通過競價倒過來的量，往其下游給的時候加上「Source」說明（說明價格決策由其上游決定），出價反饋回來後，比價引擎程序可以看到有「Source」段的請求就不過第二高價決策引擎，簡單取最高價，再通過競價介面透傳給上游ADX1去出價，待ADX2收到winnotice後依次反饋給到最終的下游bidder（DSP2）即可，整體處理流程完成。

以上，若就該話題您還有問題想討論的可文末留言或直接進群（文章底部有微信群加入方式、知識星球討論組名「程序化廣告實戰」）中互動。

（轉載請註明出處：微信訂閱號：ad_automation）

本系列文章部分摘自作者新書《程序化廣告實戰》，網上文章較零散，可參考書籍系統學習，各大電商網站（如：《程序化廣告實戰》(吳俊)【摘要 書評 試讀】- 京東圖書）均有售。


推薦閱讀：
相关文章