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