极光笔记 | 当前最佳实践：Header Bidding 与瀑布流混合请求技术

通过这篇文章您讲将了解：
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 开发者的广告变现需求为主的程序化广告交易技术，其运作方式类似于“竞拍”，具体工作原理为：开发者作为“拍卖方”，同时向多个广告网络发起询价，广告网络同时竞价并向开发者及时返回价格，出价最高者赢得该次广告展示机会。

具体流程如下：

1. 移动应用发起广告请求前，先向各个支持应用内头部竞价的 Ad Network 发起 Bid 询价。
2. 各个 Ad Network 根据移动应用提供的数据计算出本次展示的 Bid Price 出价。
3. 移动应用根据各个广告平台返回的 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 模式中增加头部竞价流程，具体实现方式如下：

1. 移动应用在请求广告前，向支持头部竞价的 Ad Network 发起  Bid 询价。
2. 在 Ad Network 返回 Bid 询价结果后，移动应用将 Bid 询价结果与传统的 Waterfall 的 eCPM Floor 进行重新排序。
3. 最后，移动应用采用排序后的 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年，是中国领先的客户互动和营销科技服务商。成立之初，极光专注于为企业提供稳定高效的消息推送服务，凭借先发优势，已经成长为市场份额遥遥领先的移动消息推送服务商。随着企业对客户触达和营销增长需求的不断加强，极光前瞻性地推出了消息云和营销云等解决方案，帮助企业实现多渠道的客户触达和互动需求，以及人工智能和大数据驱动的营销科技应用，助力企业数字化转型。