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

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

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

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

1.海外Header Bidding 的由來(lái)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

聚合SDK Waterfall 與 Header Bidding的不同點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

2) 廣告請(qǐng)求耗時(shí)過長(zhǎng)

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

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

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

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

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

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

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

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

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

作者：PMCoder之路

來(lái)源：PMCoder之路