在程序化广告中，RTB、Header Bidding 和 Unified Bidding 经常一起出现，因此很容易被理解成三种并列的交易模式。
实际上，它们并不处于同一个层级：
- RTB 描述广告展示机会如何被实时买卖；
- Header Bidding 描述发布商如何提前引入多个需求方竞争；
- Unified Bidding 描述不同需求如何在更统一的决策环境中竞争。
理解这三个概念的关键，不是记住定义，而是先弄清楚：它们分别解决了程序化广告流程中的什么问题。
三者最核心的区别
| 概念 | 中文名称 | 主要解决的问题 | 所在层级 |
|---|---|---|---|
| RTB | 实时竞价 | 单次广告展示机会如何实时交易 | 交易机制 |
| Header Bidding | 头部竞价 | 如何让多个需求方在广告服务器决策前参与竞价 | 收益管理与竞价架构 |
| Unified Bidding | 统一竞价 | 如何减少需求方之间的优先级差异，让它们统一竞争 | 拍卖与决策理念 |
| Open Bidding | Google开放竞价 | 如何在GAM服务端引入第三方收益合作伙伴 | Google的具体产品方案 |
一句话概括：RTB 是竞价交易机制，Header Bidding 是组织多个需求方参与竞争的方法，Unified Bidding 是让这些需求尽可能统一竞争的目标。
什么是实时竞价？
RTB 是 Real-Time Bidding 的缩写，中文通常称为“实时竞价”。
IAB Tech Lab 将 RTB 定义为一种实时交易媒体资源的方式：单次广告展示机会被放入实时拍卖，不同买方针对这一次展示提交报价。
这里最重要的关键词是：单次广告展示机会，RTB 通常不是批量购买某个网站一个月的广告位，而是在用户访问页面、APP或联网电视内容时，针对当前这一次广告展示机会进行竞价。
RTB是如何工作的？
一个简化的RTB流程如下：
- 用户访问网站或APP：用户打开页面，请求加载广告位
- 广告位的信息会被发送到ADX：广告位、用户属性、设备信息等被发送到ADX
- ADX向多个DSP发起竞价请求：一个广告位通常会同时发送给多个 DSP。
- DSP计算并竞价：DSP根据广告主的目标、预算、受众匹配度等指标快速计算广告价值，并提交出价
- ADX 完成拍卖：ADX根据拍卖规则（第一价格或第二价格）确定最终获胜广告
- 广告返回并展示：获胜广告创意返回并在用户设备上显示，实现精准触达
整个过程通常在100~200毫秒内完成，否则会拖慢广告和页面的加载速度。
RTB与程序化广告是什么关系？
RTB 是程序化广告的一种交易机制，但程序化广告不等于 RTB。
程序化广告通常包含以下四种交易模式：
| 缩写 | 常见中文名称 | 主要特点 |
|---|---|---|
| PDB | 程序化直接购买 | 通常提前约定资源、价格和投放条件 |
| PD | 优先交易 | 买方可按约定价格优先选择库存 |
| PA | 私有竞价 | 只有受邀请的买方可以参与 |
| RTB | 实时竞价 | 多个买方针对单次展示机会实时报价 |
要注意，这是一种常见的行业归纳，不同平台和市场可能使用 Programmatic Guaranteed、Preferred Deal、Private Auction 和 Open Auction 等不同名称，分类边界也不一定完全相同。
搜索竞价是否属于RTB？
搜索广告同样会在用户发起搜索后快速完成广告竞争，但它与展示广告程序化交易中的 RTB 并不是同一套机制。
搜索广告通常围绕以下因素进行排序：关键词、广告相关性、出价、广告质量、用户搜索环境、平台预测效果。
程序化展示广告中的RTB则通常通过 SSP、ADX、DSP以及 OpenRTB 等协议完成展示机会交易。
两者都具有“实时竞价”的特征，但在广告技术语境中，RTB通常特指程序化广告供应链中的单次展示竞价。
什么是Header Bidding？
Header Bidding 中文通常称为“头部竞价”或“页头竞价”。
它是一种发布商收益管理技术：在把广告请求交给主要广告服务器之前，先邀请多个 SSP、ADX 或广告网络对同一个广告展示机会报价。
Header Bidding 解决的主要问题并不是“能不能实时竞价”，而是：
如何让更多需求方同时获得竞价机会，减少传统瀑布流中的顺序偏差。
为什么叫Header Bidding？
早期的 Header Bidding 通常通过放置在网页 <head> 区域附近的 JavaScript 代码执行，因此得名。
不过，今天判断一个方案是不是 Header Bidding，不能只看代码放在网页什么位置。它的核心特征是：
- 在广告服务器最终选择广告之前发起竞价；
- 同时或近乎同时请求多个需求方；
- 收集不同需求方的报价；
- 将竞价结果传递给广告服务器参与最终决策。
因此，即使竞价代码没有直接写在HTML的 <head> 中，或者部分竞价发生在服务器端，它仍然可能属于 Header Bidding 架构。
Header Bidding是如何工作的？
以客户端 Header Bidding 为例：
- 用户打开页面；
- Header Bidding Wrapper 向多个需求合作伙伴发送竞价请求；
- 各需求方返回报价；
- Wrapper根据规则确定有效报价；
- 报价被写入广告服务器请求中的键值；
- 广告服务器将Header Bidding需求与直销、程序化及其他广告订单比较；
- 最终胜出的广告获得展示机会。
Prebid.js 是常见的客户端 Header Bidding Wrapper，但 Header Bidding 并不等于 Prebid。Prebid只是实现这种架构的一套开源技术。
为什么有人说Header Bidding有“两次拍卖”？
在常见架构中，可以观察到两个决策阶段：
- 第一阶段：Header Bidding Wrapper 收集并比较多个需求方的报价；
- 第二阶段：广告服务器把 Header Bidding 结果与直销订单、Ad Exchange及其他需求比较。
因此，Header Bidding 有时被称为“两阶段拍卖”或“两次拍卖”。
但这个说法只是对发布商决策流程的简化。
实际上，一个 SSP 收到请求后，内部还可能让多个 DSP 参与 RTB，再将最高或最有竞争力的报价返回。因此，从完整供应链看，可能存在多个嵌套竞价，不能简单认为整个过程固定只拍卖两次。
Header Bidding不保证最高报价一定胜出
即使某个需求方报价最高，也不一定最终获得展示。
广告服务器还可能考虑保量订单的优先级，广告定向条件，投放日期等很多因素。
所以，更准确的说法是：Header Bidding让多个需求方更早、更平等地提交报价，但最终结果仍由广告服务器和相关业务规则共同决定。
什么是Unified Bidding？
Unified Bidding 通常翻译为“统一竞价”。
它并不是一个具有完全统一定义的技术协议，而是一种拍卖和收益管理理念：让原本处于不同路径、不同优先级或不同平台中的需求，在更统一的决策层中参与竞争。
传统瀑布流会按固定顺序请求广告需求方：需求方A → 没有填充 → 需求方B → 没有填充 → 需求方C
这种方式存在明显问题：
- 排在前面的需求方可能以较低价格获得库存；
- 排在后面的高价需求方没有竞价机会；
- 历史平均价格不代表当前这一次展示的真实价值；
- 请求链过长会增加广告延迟。
统一竞价希望把流程变成：多个符合条件的需求同时参与竞争 → 统一比较 → 选择最终结果
它强调的是更统一的竞争环境，而不是字面意义上的“整个广告供应链只执行一次拍卖”。
Unified Bidding是否等于只有一次拍卖？
不一定。
即使发布商的广告服务器只进行一次最终统一决策，各个 SSP 或广告交易平台内部仍然可能先执行自己的竞价。
从发布商的最终决策层看，这是一次统一竞争；从完整技术链路看，仍然存在多个嵌套拍卖。
因此，不能用“只进行一次拍卖”作为判断 Unified Bidding 的唯一标准。
什么是Google Open Bidding？
Open Bidding 是 Google Ad Manager 提供的服务端竞价方案。
它允许发布商在 GAM 中邀请第三方 SSP 或收益合作伙伴，与 Ad Exchange及符合条件的广告订单参与实时竞争。
简化后的流程如下：
- 网站或APP向GAM发送广告请求；
- GAM判断符合条件的广告订单和收益合作伙伴；
- GAM通过服务端向多个Open Bidding合作伙伴发送请求；
- 每个合作伙伴在自己的平台中处理需求并返回最有竞争力的报价；
- GAM将这些报价与Ad Exchange及符合条件的广告订单比较；
- GAM返回最终胜出的广告素材。
Google将其描述为：收益合作伙伴可能在自己的平台中运行竞价，再把最有竞争力的报价返回GAM。
Open Bidding与Header Bidding有什么区别？
| 对比项 | Header Bidding | Google Open Bidding |
|---|---|---|
| 主要发起位置 | 浏览器或独立服务端Wrapper | Google Ad Manager服务端 |
| 需求方连接 | 发布商直接集成多个合作伙伴 | 通过GAM的Open Bidding合作伙伴体系 |
| 客户端代码 | 客户端方案通常需要Wrapper代码 | 通常使用现有Google广告请求 |
| 请求延迟 | 客户端方案可能增加浏览器请求和等待时间 | 服务端通信通常减少浏览器端开销 |
| 控制权 | 发布商对合作伙伴和Wrapper通常有更多控制 | 更依赖GAM规则和合作伙伴支持 |
| Cookie匹配 | 客户端环境通常更容易使用浏览器标识 | 服务端身份匹配可能面临不同限制 |
| 报告和结算 | 可能分散在不同平台 | GAM提供较集中化的管理 |
| 适用环境 | Web最常见，也可扩展到服务端 | 支持符合条件的网站和APP库存 |
Google指出，与传统客户端 Header Bidding 相比，Open Bidding通过GAM与第三方合作伙伴进行服务端通信，可以减少客户端集成及部分延迟问题。
但这不代表Open Bidding在所有情况下都优于Header Bidding。选择哪种方案还要考虑发布商控制权、身份匹配能力、技术维护成本和收入分成和平台费用等。
RTB、Header Bidding和Unified Bidding如何配合？
这三个概念可以同时出现在一次广告请求中，如前面Header Bidding是如何工作的里所示。
当用户打开发布商网页时，页面中的 Header Bidding Wrapper 会同时向多个 SSP 发出广告请求；每个 SSP 收到请求后，再通过 RTB 邀请多个 DSP 针对本次广告展示机会进行报价，并将最具竞争力的报价返回给 Wrapper。Wrapper 收集各 SSP 的报价后，将结果传递给 Google Ad Manager（GAM），由 GAM 将这些报价与直销订单、Google Ad Exchange 及其他符合条件的广告需求统一比较，最终根据报价、优先级、定向条件和投放规则选出胜出广告，并将其返回页面展示给用户。
一个广告展示完全可能同时使用 Header Bidding、RTB 和广告服务器的统一决策。
常见的概念误区
误区一：RTB就是所有实时发生的广告竞价
不是。
搜索广告、社交媒体广告和程序化展示广告都可能快速完成竞价，但广告技术行业中的RTB通常指针对单次展示机会进行的程序化实时交易。
误区二：Header Bidding是一种程序化交易模式
严格来说，它更接近一种发布商收益管理和竞价组织方式。
实际的需求仍可能来自公开竞价、私有竞价、广告交易平台或其他程序化交易渠道。
误区三：Header Bidding一定拍卖两次
不一定。
“两次拍卖”只是对Wrapper竞价和广告服务器最终决策的简化描述。需求平台内部还可能存在更多竞价，具体次数取决于技术架构。
误区四：Unified Bidding就是服务端Header Bidding
两者存在重叠，但不能完全画等号。
服务端 Header Bidding 描述竞价请求在哪里执行，Unified Bidding强调不同需求如何参与最终竞争。一个服务端竞价方案未必真正消除了所有优先级差异，也未必包含发布商的全部需求。
误区五：Open Bidding等于Unified Bidding
Open Bidding 是Google提供的一种具体产品实现，而Unified Bidding是更宽泛的行业理念。
不能用某一家平台的产品名称代替整个概念。
误区六：统一竞价一定是价高者胜出
报价非常重要，但最终选择还可能受到广告订单优先级、定向、超时、底价、素材资格和交付规则等因素影响。
“符合全部条件的竞争者中，按照平台规则选出最优结果”通常比“价高者得”更准确。
总结
RTB、Header Bidding和Unified Bidding分别回答了三个不同的问题：
- RTB：一次广告展示机会如何被实时买卖？
- Header Bidding：发布商如何在广告服务器决策前引入多个需求方？
- Unified Bidding：如何让不同需求在更统一的规则下竞争？
- Open Bidding：Google如何在GAM中实现服务端的多方实时竞争？
它们之间不是简单的替代关系，也不是完全独立的交易模式。
在实际程序化广告流程中，Header Bidding可以把请求发送给多个SSP，SSP内部再通过RTB邀请DSP报价，随后由广告服务器对这些报价及其他广告订单进行最终比较。
因此，判断一个竞价架构时，不要只问“它是不是RTB”，还应继续确认：
- 广告请求从哪里发起？
- 哪些需求方获得了竞价机会？
- 竞价发生在浏览器端还是服务端？
- 报价如何传递给广告服务器？
- 最终由谁决定胜出者？
- 还有哪些优先级和业务规则影响结果？
把这些问题理清后，RTB、Header Bidding和Unified Bidding之间的关系也就清楚了。
