廣告行業(yè)有一個趨勢，凡是在海外比較流行的廣告模式和技術(shù)，總有一天在國內(nèi)也會蓬勃發(fā)展起來，比如說oCPM廣告模式以及激勵視頻廣告，當(dāng)然也包括現(xiàn)在的Header Bidding或者說開放 Bidding。

第一次接觸到Header Bidding，大概在2022年左右，恰同學(xué)少年，風(fēng)華正茂，書生意氣，揮斥方遒。那時我還在百度搞國際化商業(yè)化廣告變現(xiàn)，所以對這個新的技術(shù)解決方案有一定的研究和了解。沒想到一晃5年，Header Bidding 在國內(nèi)終于有點動靜了。

要想了解一個技術(shù)方案，首先要了解這個技術(shù)方案所面對的核心痛點或者問題。把問題清楚的寫下來，問題就解決了一半。

Header Bidding的存在的痛點及其產(chǎn)生的由來

1.海外Header Bidding 的由來

海外HeaderBidding起源于桌面廣告領(lǐng)域——這項技術(shù)方案發(fā)起的初衷是為了對抗Google的Ad Exchange dynamitc bidding。Google靠自己的DFP（Doubleclick For Publisher）幾乎壟斷了桌面廣告領(lǐng)域，DFP要求廣告主必須要接入其RTB的廣告交易平臺，而不允許廣告主和流量直接對接。同時壟斷者在分配流量的時候主要做兩件事，一是出價不透明，容易偏袒自己內(nèi)部的廣告主；二是分成比例較高。在這等情況下，媒體和廣告主都不太滿意。

只要有利可圖，就一定會有人去做。于是，就有了Header Bidding的廣告模式。

桌面廣告領(lǐng)域率先推出了Header Bidding，頭部競價。最早的發(fā)起者是 appNexus。AppNexus希望聯(lián)手其它的SSP/ADX，一起通過開放的方式，撼動DFP的壟斷地位。因此該技術(shù)方案，獲得了很多程序化購買SSP/ADX的支持。

Header Bidding 新建一套廣告主與媒體流量方的對接協(xié)議，讓每次的廣告的請求優(yōu)先請求支持Header Bidding的廣告主或者DSP。媒體流量方獲取廣告返回之后，又用Header Bidding返回的廣告的價格作為底價去請求DFP等其他廣告聯(lián)盟平臺。若其他廣告網(wǎng)絡(luò)無高于此價格的廣告返回，則曝光Header Bidding 的廣告，若有返回高于此價格的廣告，則曝光DFP等廣告聯(lián)盟的廣告。

Header 是“標(biāo)頭”和“首標(biāo)”的意思，意味著支持Header Bidding的廣告主有優(yōu)先選擇流量優(yōu)先出價的權(quán)利，從實際的鏈路邏輯上來看也是這樣，具體邏輯如下圖：

在這里必須要補(bǔ)充一個知識點，就是聯(lián)盟的廣告模式，每次廣告展示的價值是多少錢，無論是桌面廣告聯(lián)盟還是移動廣告聯(lián)盟，在2022年之前都是沒有返回給媒體流量方的，但他們支持以某個底價的方式去請求廣告，若有廣告返回，則表明這個廣告的底價是高于某個值，但實際具體多少，并沒有清楚的告訴媒體流量方。

2. 國內(nèi)的Header Bidding要解決的痛點：

國內(nèi)聯(lián)盟廣告的核心痛點就是每次廣告聯(lián)盟返回給媒體流量方的廣告信息是不能直接知道當(dāng)次曝光的廣告價值。

國內(nèi)移動互聯(lián)網(wǎng)發(fā)達(dá)程度遠(yuǎn)超英美，PC流量已經(jīng)增長停滯，聯(lián)盟的廣告模式主要也是以移動端流量為主。國內(nèi)主要的聯(lián)盟廣告平臺主要有百度聯(lián)盟，字節(jié)的穿山甲以及騰訊的優(yōu)量匯，當(dāng)然，也有其他規(guī)模小一定的聯(lián)盟，比如快手聯(lián)盟，手機(jī)廠商流量聯(lián)盟等。

有做過移動廣告變現(xiàn)聯(lián)盟的同學(xué)都知道，國內(nèi)聯(lián)盟主要以接入SDK為主，流量變現(xiàn)核心痛點是不知道每次請求獲取的廣告的價值。媒體方要查看其流量的變現(xiàn)價值通常是T+1的離線報表方式。

聯(lián)盟SDK在每次返回廣告的時候都沒有明示價值，這使得媒體流量方無法根據(jù)實時的廣告價值來對不同的聯(lián)盟SDK進(jìn)行選擇。很多聚合SDK主要的策略是通過瀑布流方式（Waterfall——下文會詳細(xì)說明）的進(jìn)行變現(xiàn)。或者通過配置不同聯(lián)盟SDK流量比例和優(yōu)先級進(jìn)行變現(xiàn)。

通過Waterfall 的方式或者配置不同聯(lián)盟SDK比例的方式都需要投入大量的人力進(jìn)行用戶的分層和運(yùn)營策略的配置。而且，聯(lián)盟的歷史變現(xiàn)效率不是一成不變的，導(dǎo)致配置的策略還不一定是最優(yōu)的。

國內(nèi)聯(lián)盟的Heeder Bidding 就是為了解決這個痛點，目前已有多家主流的聯(lián)盟廣告平臺在測試這塊的能力。

它驅(qū)使每個聯(lián)盟SDK在每次廣告返回的時候不僅將廣告曝光所需的素材信息返回，還必須帶上當(dāng)次廣告請求的廣告價值！媒體流量方可以聚合多個聯(lián)盟，通過各個聯(lián)盟返回的廣告和價值進(jìn)行實時競價，挑選價值最高的廣告進(jìn)行曝光，從而使得流量價值最大化。

國內(nèi)的Header Bidding 準(zhǔn)確的來說是In-APP Bidding 或者Open Bidding。這個Bidding 的邏輯，會使得廣告媒體的變現(xiàn)效率有所提升，同時也加劇了國內(nèi)多家聯(lián)盟廣告平臺的競爭，真正到了拼刺刀的環(huán)節(jié)。

聚合SDK Waterfall 與 Header Bidding的不同點

不同用戶量級的公司變現(xiàn)策略有很大的不同。我們先來了解下大部分變現(xiàn)媒體公司的做法。

一般的流量媒體方進(jìn)行變現(xiàn)都會聚合接入多個廣告SDK的邏輯來變現(xiàn)。百度2022年的時候在海外變現(xiàn)就搞了一個聚合廣告SDK—DAP。運(yùn)營策略和思路都很時髦，放在現(xiàn)在的國內(nèi)也是一騎絕塵的。只可惜成了前浪和先驅(qū)。

流量媒體會使用聚合SDK進(jìn)行變現(xiàn)，常用的廣告策略是Waterfall，即瀑布流。瀑布流存在的基礎(chǔ)是廣告SDK只提供基于某個價格為底價獲取廣告的接口能力（媒體以底價請求廣告聯(lián)盟，聯(lián)盟后臺返回的廣告必須高于底價）。

由于廣告聯(lián)盟SDK在返回廣告的時候是沒有返回當(dāng)次曝光的廣告的預(yù)估價值（即eCPM），但聯(lián)盟支持以某個底價去請求廣告的，所以，為了追求流量價值的最大化，衍生出一種叫瀑布流（Waterfall）的變現(xiàn)策略邏輯。

流量媒體方根據(jù)不同廣告聯(lián)盟最近的變現(xiàn)效率表現(xiàn)設(shè)置Waterfall排序。

Waterfall的廣告策略方案，主要解決兩個問題：

1）不斷的分價格段位去試探不同廣告聯(lián)盟SDK的廣告填充率。

不同的聯(lián)盟SDK廣告價值的分布是不同的，媒體流量方根據(jù)歷史的經(jīng)驗設(shè)置請求優(yōu)先級（請求順序），對廣告聯(lián)盟進(jìn)行分層請求。

分層請求的優(yōu)點是，能夠根據(jù)當(dāng)前媒體場景流量的情況獲取價值更高的廣告。有同學(xué)會問題，能不能同時以某個底價去請求廣告呢？結(jié)論如下圖，當(dāng)然是不可以。若以15元的底價來請求聯(lián)盟A和聯(lián)盟B，這時候兩個聯(lián)盟都有返回，你無法更有效的判斷哪個廣告價值更高。

舉例個例子，比如有多家廣告平臺，P1的ecpm為20，P2的eCPM為18，Waterfall順序就是：P1 > P2。通常集成5-8家廣告平臺，通過廣告分層的方式盡可能保證填充率和提升收益。如上圖，多個SDK只是順序和請求策略配置不同，基本的邏輯是一樣的。

Waterfall 能相對較好的解決不同聯(lián)盟平臺變現(xiàn)效率差異以及提升填充率的問題。但這里又帶來了2個新的比較重要的問題：

1) 歷史的變現(xiàn)效率不代表當(dāng)次真實的廣告價值，所以你設(shè)置的優(yōu)先級不一定對。

由于廣告主投放都是實時生效的，很難排除某些廣告主為了在某個廣告平臺上獲取更多流量而提升出價。比如聯(lián)盟A優(yōu)先級第一，當(dāng)次請求20塊，有廣告返回，當(dāng)次曝光機(jī)會給了聯(lián)盟A。但是實際上聯(lián)盟B由于廣告隊列的變動，廣告價值當(dāng)次實際上有25，但是由于歷史優(yōu)先級比聯(lián)盟A低而無法獲取當(dāng)次廣告的曝光機(jī)會。

2) 廣告請求耗時過長

為了更好的精細(xì)化運(yùn)營同時使得獲取的廣告價格分布更加“準(zhǔn)確”，Waterfall的廣告請求通常是串行來請求的，這個使得廣告請求到返回的耗時非常長，無法滿足某些場景下及時廣告曝光的訴求。

應(yīng)用閃屏的廣告曝光是500毫秒-1s必須返回，信息流場景的返回時長限制則是毫秒級別的。Waterfall的廣告策略模式會讓廣告請求到曝光的時長增加很多，在很多場景下都無法滿足快速填充廣告的訴求。（短時間內(nèi)的預(yù)加載可以稍微緩沖一下這個問題）

Header Bidding 或者說實時Bidding 解決了以上的流量媒體變現(xiàn)的這個兩個問題。

Bidding的協(xié)議，要求聯(lián)盟廣告平臺在SDK 或者 API 后臺上返回每次廣告請求的曝光價值，這樣就在聯(lián)盟變現(xiàn)場景上產(chǎn)生了類似實時競價RTB的邏輯。

媒體流量方可以根據(jù)自己的需求選擇需要接入的廣告聯(lián)盟SDK，從而更好的提升廣告的變現(xiàn)價值和填充率。

同時，Header Bidding 使得聯(lián)盟聚合平臺有更多操作的空間，無論從變現(xiàn)效率的能力、策略和數(shù)據(jù)，都有很多優(yōu)化的點。

不過，由于HeadeBidding 在國內(nèi)才剛剛開始，預(yù)計在較長的時間段內(nèi)，應(yīng)該是Bidding 與 Waterfall 并存的情況。

開放Bidding的變現(xiàn)方式對于聯(lián)盟平臺也不一定是壞事，比如像Google Admob Open Bidding，可以通過Open Bidding 獲取到其他聯(lián)盟的廣告變現(xiàn)效率和素材情況，從而進(jìn)行針對性的優(yōu)化，再結(jié)合其豐富的廣告主資源，就可以做到強(qiáng)者恒強(qiáng)。

對于媒體流量方而言，可以知曉每次廣告請求的最大價值，同時可以對用戶價值更好的識別，那么在增長LTV這個點上就有一個更好的預(yù)估，能更好更精細(xì)化的做用戶增長策略。

作者：PMCoder之路

來源：PMCoder之路