通過這篇文章您講將瞭解：
- Header Bidding 的發展史
- Waterfall、Header Bidding 的邏輯及優劣勢
- 爲什麼說 Header Bidding 與瀑布流混合請求技術是當前最佳實踐
PART 01、Header Bidding 的起源
Header Bidding（頭部競價，又稱 Pre-Bidding 或 Advance Bidding）是一種程序化交易廣告技術，最初起源於海外網頁端廣告頭部競價。2015年廣告平臺 AppNexus 希望聯手其它的 SSP/ADX 一起通過開放的方式撼動 DFP 的壟斷地位。其方案就是將代碼嵌入在網頁代碼的 Header 片段中，同時向不同的廣告交易平臺發送廣告請求，並按照返回價格進行“價高者得”的競價，從而獲得更高的收益。因代碼嵌在網頁 Header 代碼片段塊裏，從而叫 “Header Bidding”。
此後，頭部競價在 PC 端被廣泛採用，到了2016年已經成爲國外桌面 PC端聯盟廣告的標準。而隨着越來越多的用戶轉向移動端，這種競價技術也逐步被引入到移動應用中，幫助移動應用發佈商和開發者提升廣告收益。因此 Header Bidding 也被稱爲 In-app Bidding（從，即更精準的角度來說移動端的該技術應該叫 In-app Bidding，但由於大家已經習慣了叫 Header Bidding，兩者也是常常混着用）。
國內的 Header Bidding 一直不慍不火。一是改變 Waterfall 的習慣很難，或者說 Waterfall 還沒有讓大家不滿到馬上拋棄的狀態；二是 Header Bidding 應用起來比較簡單，但需要各方對自己的技術架構進行一些調整，在沒有明顯利益的情況下大家並不願意接受頭部競價。直到2021年 Header Bidding 模式在國內開始逐漸得到普及應用。
PART 02、瀑布流（Waterfall）歷史使命與弊端
何爲瀑布流（Waterfall）
對於移動開發者而言，如果僅集成一個廣告網絡 SDK，應用的廣告填充率和 eCPM 都難以達到開發者的變現需求。因此，爲了接觸到儘可能多的潛在買家，許多開發者開始在應用中添加多個廣告網絡 SDK。而這也催生了廣告聚合平臺的誕生（這個話題以後有機會我們再展開聊）。
開發者接入多家的廣告源後問題來了，流量改該怎麼分配呢？同一個廣告請求（ad request）到底是該發給 Facebook，還是 google 還是 vungle 還是其他人呢？這時候就涉及到調解平臺的算法邏輯了。通常，根據各廣告平臺的 eCPM 歷史數據排個排序，這個排序就是 Waterfall。廣告請求優先發給排序中的第一順位廣告平臺，若沒有填充（fill），就下一個，沒有填充就再下一個，如此循環往復，直到有填充才停止往下請求。 Waterfall 剛出來的時候真的是一個超級棒的概念，很好地解決了開發者流量變現最大化的問題。
Waterfall 的這種有序請求和填充廣告的模式，在一定程度上保障了高價值的廣告網絡或買方可以優先獲得廣告展示的機會，並且幫助開發者解決了廣告管理的效率問題。
瀑布流（Waterfall）不足
雖然傳統 Waterfall 是一種有效的變現模式，在一段時間內它也爲開發者流量變現最大化做出了巨大貢獻。但它也存在一些不足，但是隨着開發者追求成本效益最優的需求越來越強烈，它的缺點也逐漸顯現。
- 無法選出實際最高出價*
當開發者無法針對 Ad Network 的廣告位設置底價時，往往會根據 Ad Network 廣告位的歷史平均數據來估算 eCPM 並調整 Waterfall 順序。由於通過歷史數據預估本次展示的收益，當優先級低的 Ad Network 即使當次出價高也無法得到展示機會。
- 廣告加載耗時長
在 Waterfall 模式中，串行請求會增大廣告展示耗時，平均請求一次至少在100ms 以上，多次請求會造成前端展示延遲，用戶體驗感較差。由於不同廣告位的環境不同，用戶可接受程度也不一樣，需要分廣告位設置整體請求次數/超時時間。
*** 維護成本高**
開發者要實現精細化的變現運營，往往針對每個廣告位都需要維護一套 Waterfall 配置，同時在 Waterfall 的不同層次要設置不同的 Ad Network 廣告位和低價，這樣將帶來運營成本的提高。且由於季節性問題，eCPM 的數值會發生變，需要運營同學手動維護，成本較高。
*** 存在“暗箱”問題**
在 Waterfall 模式中，廣告網絡優先級的排序至關重要，優先級排序靠後的廣告網絡極有可能得不到廣告展示的機會。因此，一些廣告網絡可能會事先與開發者達成交易，佔取 Waterfall 有序列表中的頭部位置，以獲得優先訪問開發者廣告庫存的機會。
*** 數據匱乏**
由於 Waterfall 模式中每次廣告請求僅有一家廣告網絡參與出價，開發者也無法獲得更多家的出價數據來進行深度分析、以更科學的方式優化廣告收益。
PART 03、Header Bidding
Header Bidding 的原理
Header Bidding 實際上是以滿足 APP 開發者的廣告變現需求爲主的程序化廣告交易技術，其運作方式類似於“競拍”，具體工作原理爲：開發者作爲“拍賣方”，同時向多個廣告網絡發起詢價，廣告網絡同時競價並向開發者及時返回價格，出價最高者贏得該次廣告展示機會。
具體流程如下：
- 移動應用發起廣告請求前，先向各個支持應用內頭部競價的 Ad Network 發起 Bid 詢價。
- 各個 Ad Network 根據移動應用提供的數據計算出本次展示的 Bid Price 出價。
- 移動應用根據各個廣告平臺返回的 Bid Price 出價，選擇出價最高的 Ad Network，該 Ad Network 將贏得本次展示機會。
![]()
不難發現 Header Bidding 讓 APP 開發者能夠直接對接更多的買家，它驅使每個聯盟 SDK 在每次廣告返回的時候不僅將廣告曝光所需的素材信息返回，還必須帶上當次廣告請求的廣告價值！媒體流量方可以聚合多個聯盟，通過各個聯盟返回的廣告和價值進行實時競價，挑選價值最高的廣告進行曝光，從而使得流量價值最大化。
Header Bidding 的優勢
相比傳統的 Waterfall（瀑布流模型），Header Bidding 的優勢有：
- 競價更公平
所有 Network 同時競價，對廣告主來說是一種更公平的競價技術。
- 競價更激烈
所有Network同時競價，原先排在 Waterfall 底部的 Network 依然有機會出高價贏得展示。
- 媒體收益更高更透明
允許多個廣告網絡針對同一個廣告展示同時競價，最高出價者獲得展示機會，採用第一價進行結算，可以確保開發者每次展示收益最大化。
廣告平臺（Ad Network）在 Bidding 時，會返回 CPM 價格，開發者可以清晰地知道每一次廣告展示帶來的收益。同時，因爲競價的過程是實時透明的，相較於歷史平均 CPM 數據來說，實時 CPM 出價對每一次展示的預估更爲精準，從而使開發者的每次展示都能夠以更真實的價值進行售賣。
- 響應更快
與 Waterfall 模式按順序進行廣告請求、一次只請求一個廣告網絡的流程相比，Header Bidding 實時、並行的競價模式減少了廣告調用與等待的時間，可以減少 Waterfall 模式的延遲問題，讓廣告可以更快地被投放和展示。
Header Bidding 的當下無奈
從上述分析可以看到 Header Bidding 使得媒體端無論從變現效率的能力、策略和數據，都有很多優化的點。即使對於廣告平臺好處也是不少，如能夠讓自己更公平地獲得流量等。
按道理說大家都應該都用 Header Bidding 代替 Waterfall 了，但理想很豐滿，現實就有點骨幹。現在國內市面上的廣告平臺還是基本上以 Waterfall爲主，支持的 Header Bidding 的廣告平臺數量還不多。就如國內領頭的廣告平臺穿山甲現在還是不支持對外的 Header Bidding 功能。
Header Bidding 的當下無奈也折射出商業複雜性】當下的無奈也折射出商業複雜性，每個公司做任何決策都要考慮很多方面的利益——技術架構的調整、既得利益的重新分配、公司能力的重組、行業上下游的推動等等。
不過隨着行業的發展我們還是堅信最終 Header Bidding 會替代掉Waterfall。而且事情的交替也都存在過渡週期，當下的無奈只是暫時的。
PART 04、Header Bidding與瀑布流混合請求技術
目前，在 Header Bidding 未完全代替 Waterfall 之前，國內是 Header Bidding 和 Waterfall 並存的狀態。好在這兩種模式並非是你死我活的對立，而是可以靈活結合的。在 Waterfall 模式中增加 Header Bidding 競價流程，進一步提升廣告收益。
其核心邏輯是在 Waterfall 模式中增加頭部競價流程，具體實現方式如下：
- 移動應用在請求廣告前，向支持頭部競價的 Ad Network 發起 Bid 詢價。
- 在 Ad Network 返回 Bid 詢價結果後，移動應用將 Bid 詢價結果與傳統的 Waterfall 的 eCPM Floor 進行重新排序。
- 最後，移動應用採用排序後的 Waterfall 進行請求廣告。
如此，既能規避掉一些 Waterfall 的不足，優先利用 Header Bidding 的優勢來獲取更高收益；同時又能避免由於支持 Header Bidding 的廣告平臺不是那麼多，純接 Header Bidding 的話導致填充率不足，從而影響整體收益。
針對如上理論分析，極光廣告聚合平臺 Adpub 與旗下合作的10家讀書類媒體做過對比實驗：
廣告請求模式模式分析實驗結果(10家平均數據)Waterfall傳統的老方式，每個廣告預算平臺都支持收益爲 AHeader Bidding新方式，較多平臺還不支持收益爲 A87%Header Bidding+Waterfall《極光Adpub》優勢互補，Bidding不要的Waterfall保底填充收益爲 A125%
從如上結果可以明顯看出 Header Bidding 與瀑布流混合請求技術的收益優勢。大邏輯上肯定是所有廣告平臺都支持 Header Bidding 後是最好的，但在這個過渡期兩者結合不失爲當前提升收益的最佳實踐路徑。
目前極光 Adpub 廣告聚合平臺採用的就是 Header Bidding 與瀑布流混合請求技術，爲開發者提供最佳的變現方案，提高廣告收益和降低變現的運營成本。
從最初的單接一家廣告平臺，到後面的聚合多家，然後到用 Waterfall 請求技術，再到 Header Bidding 及 Header Bidding 與Waterfall 的混合請求，行業在不斷向前發展，對應的是社會資源的更優的重組。未來，或許有更多更靈活的組合模式，兼顧多方利益，實現共贏。
訪問 https://www.jiguang.cn/adpub 立即註冊體驗~
關於極光
極光（Aurora Mobile，納斯達克股票代碼：JG）成立於2011年，是中國領先的客戶互動和營銷科技服務商。成立之初，極光專注於爲企業提供穩定高效的消息推送服務，憑藉先發優勢，已經成長爲市場份額遙遙領先的移動消息推送服務商。隨着企業對客戶觸達和營銷增長需求的不斷加強，極光前瞻性地推出了消息雲和營銷雲等解決方案，幫助企業實現多渠道的客戶觸達和互動需求，以及人工智能和大數據驅動的營銷科技應用，助力企業數字化轉型。