Header Bidding，中文叫头部竞价。不算是什么新的技术能力，国外桌面PC端2016年开始，已经成为了PC联盟广告的标准。始于PC端，但在海外移动互联网场景，去年Google  Admob Open Bidding 和Facebook Audience network  In-App Bidding已经支持这样的竞价方式

广告行业有一个趋势，凡是在海外比较流行的广告模式和技术，总有一天在国内也会蓬勃发展起来，比如说oCPM广告模式以及激励视频广告，当然也包括现在的Header Bidding或者说开放 Bidding。

第一次接触到Header Bidding，大概在2016年左右，恰同学少年，风华正茂，书生意气，挥斥方遒。那时我还在百度搞国际化商业化广告变现，所以对这个新的技术解决方案有一定的研究和了解。没想到一晃5年，Header Bidding 在国内终于有点动静了。

要想了解一个技术方案，首先要了解这个技术方案所面对的核心痛点或者问题。把问题清楚的写下来，问题就解决了一半。

海外HeaderBidding起源于桌面广告领域——这项技术方案发起的初衷是为了对抗Google的Ad Exchange dynamitc bidding。Google靠自己的DFP（Doubleclick For Publisher）几乎垄断了桌面广告领域，DFP要求广告主必须要接入其RTB的广告交易平台，而不允许广告主和流量直接对接。同时垄断者在分配流量的时候主要做两件事，一是出价不透明，容易偏袒自己内部的广告主；二是分成比例较高。在这等情况下，媒体和广告主都不太满意。

只要有利可图，就一定会有人去做。于是，就有了Header Bidding的广告模式。

桌面广告领域率先推出了Header Bidding，头部竞价。最早的发起者是 appNexus。AppNexus希望联手其它的SSP/ADX，一起通过开放的方式，撼动DFP的垄断地位。因此该技术方案，获得了很多程序化购买SSP/ADX的支持。

Header Bidding 新建一套广告主与媒体流量方的对接协议，让每次的广告的请求优先请求支持Header Bidding的广告主或者DSP。媒体流量方获取广告返回之后，又用Header Bidding返回的广告的价格作为底价去请求DFP等其他广告联盟平台。若其他广告网络无高于此价格的广告返回，则曝光Header Bidding 的广告，若有返回高于此价格的广告，则曝光DFP等广告联盟的广告。

Header 是“标头”和“首标”的意思，意味着支持Header Bidding的广告主有优先选择流量优先出价的权利，从实际的链路逻辑上来看也是这样，具体逻辑如下图：

在这里必须要补充一个知识点，就是联盟的广告模式，每次广告展示的价值是多少钱，无论是桌面广告联盟还是移动广告联盟，在2019年之前都是没有返回给媒体流量方的，但他们支持以某个底价的方式去请求广告，若有广告返回，则表明这个广告的底价是高于某个值，但实际具体多少，并没有清楚的告诉媒体流量方。

国内联盟广告的核心痛点就是每次广告联盟返回给媒体流量方的广告信息是不能直接知道当次曝光的广告价值。

国内移动互联网发达程度远超英美，PC流量已经增长停滞，联盟的广告模式主要也是以移动端流量为主。国内主要的联盟广告平台主要有百度联盟，字节的穿山甲以及腾讯的优量汇，当然，也有其他规模小一定的联盟，比如快手联盟，手机厂商流量联盟等。

有做过移动广告变现联盟的同学都知道，国内联盟主要以接入SDK为主，流量变现核心痛点是不知道每次请求获取的广告的价值。媒体方要查看其流量的变现价值通常是T+1的离线报表方式。

联盟SDK在每次返回广告的时候都没有明示价值，这使得媒体流量方无法根据实时的广告价值来对不同的联盟SDK进行选择。很多聚合SDK主要的策略是通过瀑布流方式（Waterfall——下文会详细说明）的进行变现。或者通过配置不同联盟SDK流量比例和优先级进行变现。

通过Waterfall 的方式或者配置不同联盟SDK比例的方式都需要投入大量的人力进行用户的分层和运营策略的配置。而且，联盟的历史变现效率不是一成不变的，导致配置的策略还不一定是最优的。

国内联盟的Header Bidding 就是为了解决这个痛点，目前已有多家主流的联盟广告平台在测试这块的能力。

它驱使每个联盟SDK在每次广告返回的时候不仅将广告曝光所需的素材信息返回，还必须带上当次广告请求的广告价值！媒体流量方可以聚合多个联盟，通过各个联盟返回的广告和价值进行实时竞价，挑选价值最高的广告进行曝光，从而使得流量价值最大化。

国内的Header Bidding 准确的来说是In-APP Bidding 或者Open Bidding。这个Bidding 的逻辑，会使得广告媒体的变现效率有所提升，同时也加剧了国内多家联盟广告平台的竞争，真正到了拼刺刀的环节。

不同用户量级的公司变现策略有很大的不同。我们先来了解下大部分变现媒体公司的做法。

一般的流量媒体方进行变现都会聚合接入多个广告SDK的逻辑来变现。百度2015年的时候在海外变现就搞了一个聚合广告SDK—DAP。运营策略和思路都很时髦，放在现在的国内也是一骑绝尘的。只可惜成了前浪和先驱。

流量媒体会使用聚合SDK进行变现，常用的广告策略是Waterfall，即瀑布流。瀑布流存在的基础是广告SDK只提供基于某个价格为底价获取广告的接口能力（媒体以底价请求广告联盟，联盟后台返回的广告必须高于底价）。

由于广告联盟SDK在返回广告的时候是没有返回当次曝光的广告的预估价值（即eCPM），但联盟支持以某个底价去请求广告的，所以，为了追求流量价值的最大化，衍生出一种叫瀑布流（Waterfall）的变现策略逻辑。

流量媒体方根据不同广告联盟最近的变现效率表现设置Waterfall排序。

1）不断的分价格段位去试探不同广告联盟SDK的广告填充率。

不同的联盟SDK广告价值的分布是不同的，媒体流量方根据历史的经验设置请求优先级（请求顺序），对广告联盟进行分层请求。

分层请求的优点是，能够根据当前媒体场景流量的情况获取价值更高的广告。有同学会问题，能不能同时以某个底价去请求广告呢？结论如下图，当然是不可以。若以15元的底价来请求联盟A和联盟B，这时候两个联盟都有返回，你无法更有效的判断哪个广告价值更高。

举例个例子，比如有多家广告平台，P1的ecpm为20，P2的eCPM为18，Waterfall顺序就是：P1 > P2。通常集成5-8家广告平台，通过广告分层的方式尽可能保证填充率和提升收益。如上图，多个SDK只是顺序和请求策略配置不同，基本的逻辑是一样的。

Waterfall 能相对较好的解决不同联盟平台变现效率差异以及提升填充率的问题。但这里又带来了2个新的比较重要的问题：

1）历史的变现效率不代表当次真实的广告价值，所以你设置的优先级不一定对。

由于广告主投放都是实时生效的，很难排除某些广告主为了在某个广告平台上获取更多流量而提升出价。比如联盟A优先级第一，当次请求20块，有广告返回，当次曝光机会给了联盟A。但是实际上联盟B由于广告队列的变动，广告价值当次实际上有25，但是由于历史优先级比联盟A低而无法获取当次广告的曝光机会。

2）广告请求耗时过长

为了更好的精细化运营同时使得获取的广告价格分布更加“准确”，Waterfall的广告请求通常是串行来请求的，这个使得广告请求到返回的耗时非常长，无法满足某些场景下及时广告曝光的诉求。

应用闪屏的广告曝光是500毫秒-1s必须返回，信息流场景的返回时长限制则是毫秒级别的。Waterfall的广告策略模式会让广告请求到曝光的时长增加很多，在很多场景下都无法满足快速填充广告的诉求。（短时间内的预加载可以稍微缓冲一下这个问题）

Header Bidding 或者说实时Bidding 解决了以上的流量媒体变现的这个两个问题。

Bidding的协议，要求联盟广告平台在SDK 或者 API 后台上返回每次广告请求的曝光价值，这样就在联盟变现场景上产生了类似实时竞价RTB的逻辑。

媒体流量方可以根据自己的需求选择需要接入的广告联盟SDK，从而更好的提升广告的变现价值和填充率。

同时，Header Bidding 使得联盟聚合平台有更多操作的空间，无论从变现效率的能力、策略和数据，都有很多优化的点。

不过，由于HeadeBidding 在国内才刚刚开始，预计在较长的时间段内，应该是Bidding 与 Waterfall 并存的情况。

开放Bidding的变现方式对于联盟平台也不一定是坏事，比如像Google Admob Open Bidding，可以通过Open Bidding 获取到其他联盟的广告变现效率和素材情况，从而进行针对性的优化，再结合其丰富的广告主资源，就可以做到强者恒强。

对于媒体流量方而言，可以知晓每次广告请求的最大价值，同时可以对用户价值更好的识别，那么在增长LTV这个点上就有一个更好的预估，能更好更精细化的做用户增长策略。

关于这两点，我们留待后面更详细描述。

文章太长~感谢读完！有什么想法欢迎大家下方评论区留言，我们一起交流～

文章未完待续……

-END-