这一篇介绍Header Bidding。
什么是Header Bidding？
Header Bidding（因为它最初是在网页Header里安装一段代码，所以叫Header Bidding）也叫Advance-Bidding、Pre-Bidding、Bidding，中文名叫头部竞价，竞价。
头部竞价可以将广告请求同时发送给不同广告需求方（如ADX、SSP、Ad Network），让多个广告需求方竞价，并通过竞价排序选出胜出者，胜出者再与Ad Server里的其他交易竞争，最终决定出最后的胜出者，才可以获得广告展示机会，这个过程是进行了两次拍卖，逻辑如：
Header Bidding出现的原因
Google依靠DFP（DoubleClick for Publishers）垄断了Web端的广告变现，90%媒体主都依赖DFP进行变现，媒体主不能直接对接广告需求，对于使用DFP的流量，谷歌的ADX有优先选择权，而其他的ADX只能等谷歌ADX挑剩后再竞价：
可以说天下苦Google久已，所以广告技术公司推出Header bidding，允许媒体主直接同时对接不同的广告需求方（如ADX、SSP、Ad Network），实现多方获利：
- 媒体主能提高收入
- 广告技术公司能获得优质的流量
只有谷歌很受伤，这块的收入下降很多，后面Google也跟推出Open Bidding应对。
Header bidding的发展过程如下：
- 2014年：AppNexus（现为Xandr）推出了一种称为“Prebid”的客户端竞价技术，这被认为是现代header bidding的起源之一。Prebid允许发布者在页面加载之前进行广告位的拍卖，使得更多的广告需求方（如ADX、SSP、Ad Network）能够参与竞价。
- 2015年：随着技术的进步和市场需求的增加，header bidding开始在行业内流行。PubMatic、Rubicon Project等公司也开始提供自己的header bidding解决方案。
- 2016年：Google Ad Manager（当时称为DoubleClick for Publishers，DFP）引入了对header bidding的支持，这大大推动了这种技术的普及，因为Google是数字广告市场的重要参与者。
瀑布流 vs 头部竞价（Header Bidding）
- 在没有Header Bidding之前，采用的是瀑布流（WaterFall）的形式，对流量做分层，分组，优质的价格高些，一般的就价格低些，然后按设定的广告需求方的顺序结构，每个都询问，不要就下一个，直到广告有出价，形式如下，想瀑布一样，所以称为瀑布流
- 有Header Bidding后，它会向所有广告需求方发（如ADX、SSP、Ad Network）送竞价请求，跳过DFP，媒体主和广告技术公司都获益。
| 特性 | 瀑布流（Waterfall） | 头部竞价（Header Bidding） |
|---|---|---|
| 请求方式 | 逐级请求，按优先级顺序传递 | 同时向多个平台发送请求 |
| 效率 | 较低，存在延迟 | 较高，减少延迟 |
| 收益 | 可能较低，受优先级限制 | 较高，通过竞争最大化收益 |
| 透明度 | 较低，难以掌握所有竞价信息 | 较高，竞价信息更透明 |
| 技术复杂度 | 较低，易于实现 | 较高，需要技术支持 |
Header Bidding的工作原理
Header Bidding的基本工作流程：
- 脚本嵌入：发布商在网页的<head>部分插入Header Bidding的JavaScript代码。
- 竞价启动：当用户访问页面时，Header Bidding脚本立即触发，向预先配置的多个广告需求方发送竞价请求。
- 同步竞价：这些需求方同时进行竞价，基于用户数据、广告位的价值等信息提出各自的出价
- 选中最优广告：所有竞价结果汇总到发布商的广告服务器，广告服务器会和其他广告做对比，选择出价最高或最适合的广告进行展示。
- 广告展示：胜出的广告被加载到网页的广告位上。
客户端 vs. 服务器端 Header Bidding
Header Bidding有客户端和服务端之分：
- 客户端（Client-Side Header Bidding）： 在用户浏览器中运行JavaScript代码直接向不同广告需求方（如ADX、SSP、Ad Network）发送竞价请求。优点是实现简单，但容易影响加载速度。
- 服务端（Server-Side Header Bidding）： 广告请求先从浏览器发送到专用服务器，在从专用服务器发送到不同广告需求方（如ADX、SSP、Ad Network）， 专用服务器收到后再返回给浏览器。优点是对用户体验影响较小，但需要更多的服务器资源和技术集成。
应用内竞价
头部竞价起源于Web端，后面在移动端（APP）上有广泛的应用，专属名称叫应用内竞价，也叫In App Bidding，In App Header Bidding，其实就是头部竞价在应用内使用的意思。
Header Bidding在APP的变现上应用很广泛。
常见的Header Bidding解决方案
- Prebid.js：最流行的开源Header Bidding框架。
- Amazon Transparent Ad Marketplace (TAM)：亚马逊的Header Bidding解决方案。
- Google Open Bidding：虽然Google称为Open Bidding，但本质上也是一种服务器端竞价技术。
- 其他供应商：如Rubicon Project、AppNexus、Criteo等。
Header Bidding的优缺点
| 优点 | 缺点 |
|---|---|
| 提高收益：通过让更多需求方参与竞价，发布商可以获得更高的广告收益，因为每个广告展示的机会都得到了最大化的竞价。 透明度：Header Bidding提供了比传统方法更高的透明度，发布商和广告主都能看到更真实的市场需求和广告库存的价值。 公平竞争：所有参与竞价的需求方站在同一起跑线上，避免了瀑布流中某些广告源因优先级不同而产生的劣势。 减少流失：在瀑布流中，如果前面的广告源未能响应或出价不够高，广告位可能会空置或展示低价值广告。Header Bidding减少了这种情况的发生，提高了填充率。 |
技术复杂性： 集成Header Bidding需要较高的技术支持，包括配置脚本、优化竞价流程等。 数据隐私： 在传输用户数据给需求方时，可能涉及用户隐私合规性的问题，例如GDPR或CCPA。 广告服务器集成： 需要确保Header Bidding与现有广告服务器（如Google Ad Manager）无缝协作。 |
如有疑问，可以在文章底部留言或邮件(haran.huang@ichdata.com) 我~
