Header Bidding：程序化交易的一股泥石流
??
什么是Header Bidding?它的目的和原理如何?發(fā)展前景又如何呢?在一個秋風蕭瑟的下午，我們與AppNexus負責Header Bidding產品的Paul Yang相對而坐，向他請教這項今年異軍突起席卷了程序化廣告市場的新技術。我們將從Paul那里捋來的一些皮毛整理成此文，以饗讀者。
先來看看trends.builtwith的統(tǒng)計數(shù)據，感受一下世界范圍內媒體網站對Header Bidding的需求。如下圖所示，從2016年2月到9月，使用此技術的媒體網站的數(shù)量幾乎是爆發(fā)式增長：僅僅一年時間，就有超過40%的頭部網站采用了Header Bidding技術。有趣的是，還有一家著名的SSP公司，因為沒有及時擁抱Header Bidding技術而躺槍，導致股價暴跌。(具體是哪家自己查。)說這是程序化交易的一股泥石流，恐怕不為過吧?
?
?
程序化交易這種透明交易機制的形成和完善，為廣告主的效果和媒體的變現(xiàn)都提供了新的想象空間。然而，這個市場中起決定作用的不只是技術，還有商業(yè)利益上的博弈。隨著Google、Mopub等在Adx市場的地位日趨壟斷，它們幾乎獨攬了實時競價中流量分配的大權，導致廣告主和媒體間的供需出現(xiàn)了不小的問題。在收益***化的驅使下，市場驅使廣告主和媒體聯(lián)合起來打破壟斷，這便催生了Header Bidding技術。
拋開技術細節(jié)，Header Bidding產生的市場原因是什么呢?曾子曰：哪里有壓迫，哪里就有反抗。簡單來說，程序化交易市場看似公平透明，可是壟斷者Google、Mopub等在分發(fā)流量時，一來徇私舞弊(都會偏袒自己的內部廣告主)，二來捐稅太重(Mopub收取高達40%的費用)，廣告主和媒體的利益受到了損害。其實別的都不用做，只要繞開Adx，就可以多出不少的利潤。
在這樣的利益驅動下，媒體與DSP一個是干柴，一個是烈火，產下了了他們愛情的結晶——Header Bidding：倘若DSP和媒體能夠建立直連，DSP便有機會在實時競價開始之前向媒體直接報價，媒體網站根據出價高低決定中標DSP，如果沒有，再交由Adx進行實時競價也不遲。這樣一來，媒體網站重奪競價權利，有助于提高CPM;DSP的廣告也有處更多自由選擇機會，保證了買方市場;最關鍵的是，如果競價成功，便可把ADX/SSP那一份中介費也給省了。
下面我們回到產品層面，看看Header Bidding的流程究竟有何不同呢。先花一分鐘時間回憶一下傳統(tǒng)的Real Time Bidding的流程。
?
?
1.用戶接觸到媒體網站的廣告位時，前端向ADX發(fā)起廣告請求。(圖中2.1)
2.ADX向各DSP傳送URL(或應用ID)和用戶標識，發(fā)起詢價請求。如果是Web環(huán)境，DSP還要根據cookie mapping查出對應的已方用戶標識。隨后，DSP計算并返回自己的出價。ADX選出出價***的DSP返回給媒體網站。(圖中2.2)
3.媒體網站從勝出的DSP拿到廣告創(chuàng)意并展示。其中2.2, 2.3兩步可以合并為一步，即DSP同時返回出價和廣告創(chuàng)意地址，由ADX返回給媒體。(圖中2.3)
在RTB中，詢價和競價的過程是在服務器端完成的，要繞開ADX，就要在客戶端做點兒手腳，下面是Header Bidding的詢價和決策過程：
?
?
1.用戶訪問媒體頁面，向媒體服務器發(fā)起HTTP請求。
2.媒體服務器將實現(xiàn)Header Bidding功能的腳本hb.js放在HTML的head標簽中，該HTML作為HTTP Response發(fā)給用戶瀏覽器。
3.用戶瀏覽器在解析HTML時，將媒體網站配置好的hb.js下載到本地。在hb.js的控制下，用戶瀏覽器向媒體網站約定好的Bidders發(fā)起本次曝光機會的競價請求，Bidders將報價返回給用戶瀏覽器。
4.在hb.js控制下，用戶瀏覽器將各家Bidder報價信息回傳給媒體網站。
5.媒體服務器同時向ADX或SSP發(fā)送廣告請求。
6.ADX或SSP發(fā)起RTB過程并獲得廣告候選。
7.媒體服務器將Header Bidding出價結果和RTB出價結果放在一起進行排序，出價***者贏得本次廣告展示機會，用戶瀏覽器請求勝出方加載廣告。
注意，上面的***一步有一個容易被忽略的小問題：怎么才能將ADX/SSP返回的廣告與HB返回的廣告競價呢，要知道Google可不會配合你給出報價。這里有兩種辦法：***種方法，是跟ADX談判，曉之以理動之以情，希望它從民族大義出發(fā)配合出價，可這對ADX來說，有點兒被賣了還幫著數(shù)錢的意思;第二種方法，是將HB返回的***價格作為底價，再讓ADX以此底價發(fā)動RTB。這兩種方法各有優(yōu)劣，我就不具體分析了。
簡單說吧，媒體先劫道兒，留下了買路財以后，再放給ADX處理。這是一種什么樣的精神，這是一種肥水不流外人田的精神!而Header Bidding的快速發(fā)展，核心驅動力就在于在客戶端多劫了一道，留下了利潤，吃點兒什么不香啊!
對比RTB與Header Bidding的流程，可能您會有下面的問題：
1.Header Bidding是加強版的RTB嗎?
形式上可以說是如此。當用戶訪問媒體網站之后，媒體網站首先進行Header Bidding，然后進行RTB，將兩次競價結果綜合到一起，價高者勝。
2.Header Bidding和RTB的區(qū)別是什么?
主要區(qū)別在于詢價請求是誰發(fā)出的。在RTB中，詢價請求是由SSP或ADX發(fā)出的;而在Header Bidding中，詢價請求是由用戶瀏覽器(客戶端)發(fā)出的。
3.哪里可以體現(xiàn)出媒體和DSP的聯(lián)手反壟斷?
答案在hb.js中。在Header Bidding過程中，hb.js起核心的控制作用。用戶瀏覽器該向哪個Bidder發(fā)競價請求，都是媒體網站同這些Bidders提前商量好后寫進hb.js的配置中。
4.Header Bidding存在的意義是什么?
作為賣方，媒體網站提高了競價密度，有助于提升CPM;作為買方，Bidders有了新渠道，有助于提升ROI。買賣雙方攜起手來，打破壟斷，降低了渠道費用。
這么說來，有了Header Bidding，程序化交易市場的面貌就能煥然一新了嗎?這未免過于樂觀了。Header Bidding的產生和快速發(fā)展，主要是由于市場博弈的原因，從技術上來看并不見得是***的模式，具體表現(xiàn)在以下一些問題上：
1.客戶端競價的可行性如何
HB采用客戶端競價的方式，媒體網站和廣告主得利，但與之共存的高延時極大的降低的用戶瀏覽該媒體網站的興趣，媒體網站曝光減少，Bidders還愿意來投廣告嗎?
2.HB能否真的突破ADX壟斷
客戶端競價高延時的短板使得HB陷入了一個十分尷尬的境地。不用吧，市場有鏈接買賣雙方的需求，商業(yè)潛力巨大;用吧，對用戶體驗又有傷害。這樣看來，HB并不足以戳中G點。如果 也改用服務端競價，那和RTB還有什么區(qū)別?
要說大家最關心的問題，莫過于HB在中國市場的發(fā)展前景如何。答案倒也簡單：發(fā)展空間不大。因為HB的出發(fā)點，是要打破ADX壟斷，通過劫道提高利潤，但是在國內，大媒體通常是自己開發(fā)SSP，自己對接DSP，媒體打破媒體的壟斷，自己革自己的命，這不是大餅卷手指頭——自個兒吃自個兒么?
如果您想試一試HB方案，可以參考AppNexus的開源實現(xiàn)Prebid.js(http://prebid.org)，這是一款開源且免費的JavaScript框架，它幫助媒體網站輕松實現(xiàn)Header Bidding的部署，并且方便需求方的接入。Prebid.js有以下特性：
- 支持市場中大多數(shù)的Bidders，也包括了大多數(shù)的ad server。
- 針對大多數(shù)媒體網站遇到的問題都有成形的解決方案，例如：高延遲、不公平競價機制和較長的研發(fā)周期等。
- 可以在JSON中配置Bidders，簡化prebid.js配置過程。
- 開源，免費
從技術上看，Prebid.js由若干功能模塊組成，我們也簡要介紹下這些模塊和他們的主要功能，方便碼皇們了解：
- 異步請求模塊
配置Prebid.js，使其擁有一個或多個Bidders(可以是DSP、SSP或廣告網絡等任何可以參與競價的服務)
頁面加載時，Prebid.js異步向這些Bidders發(fā)起競價請求。
- 頁面定時器模塊
可以設置定時器來避免Bidders占用太多時間。若某個Bidder超時，則忽略該Bidder的響應。
- 鍵值對模塊
Bidder返回競價時，Prebid.js將競價和創(chuàng)意ID構建成帶參字符串傳遞給廣告服務器。
- Line Items模塊
在廣告服務器內部，Line Items主要用于參數(shù)解析和競價排序。
- 創(chuàng)意組件
競價排序完成后，該組件用于告知Prebid.js去獲勝的Bidder處加載廣告。
拉拉雜雜說了這么多，簡單總結一下：Header Bidding如泥石流般席卷程序化交易市場，頗有點兒無心插柳的意思。這件事再次提醒我們：廣告技術本質上是為商業(yè)服務的，商業(yè)上是否有新的價值產生，遠比技術上的進步和合理更加重要，此事望諸君切記。
【本文轉自計算廣告微信公眾號：Comp_Ad，已取得授權】
