：交易模式（下）——Header Bidding 的革命)
上一篇我们讲完了单 SSP 内部的交易模式演化——
从最早的人工合约，到 OA、PMP、PD、PDB 的逐步成熟。
但有一个问题我们一直没回答：
媒体方接入了多个 SSP 之后，这些 SSP 之间怎么协调？
现实中，大媒体可能同时接入 5-10 个 SSP 和 ADX——
Google AdX、字节穿山甲、腾讯优量汇、Magnite、PubMatic……
每一次曝光机会，应该送给谁竞价？
这个问题催生了程序化广告史上最具革命性的技术——Header Bidding（头部竞价）。
它让整个行业的格局重新洗牌——媒体方收入暴涨 30-50%，Google 的垄断被打破，独立 SSP 借势翻身。
这一篇我们讲清楚这场革命。
同时，用一张完整的决策树把所有交易模式串起来——读完这篇，你会拥有程序化广告交易模式的完整地图。
一、先看完整的交易模式决策树
讲具体内容之前，先看这张图——程序化广告所有交易模式的完整决策树：
图片来源：参考《程序化广告：个性化精准投放实用手册》梁丽丽
整个生态可以用3 个决策维度串起来：
- 是否竞价？—— 决定走"竞价路径"还是"非竞价路径"
- 竞价路径下：是否 First Look？—— 决定是 HB 还是普通 RTB
- RTB 路径下：是否公开？—— 决定是 OA 还是 PMP
- 非竞价路径下：是否保量？—— 决定是 PDB 还是 PD
最终落地5 种交易模式：
| 编号 | 模式 | 简称 | 中文 |
|---|---|---|---|
| ① | Header Bidding | HB | 头部竞价 |
| ② | Programmatic Direct Buying | PDB | 程序化保量 |
| ③ | Preferred Deal | PD | 首选交易 |
| ④ | Private Marketplace | PMP | 私有竞价 |
| ⑤ | Open Auction | OA | 公开竞价 |
💡关于 Deal ID：上图中编号 ②、③、④（即 PDB、PD、PMP）都通过 Deal ID 实现交易——Deal ID 是媒体方和广告主达成"私有约定"的唯一标识。后面第七节会详细讲。
记住这张图——这一篇的所有内容都是在填这张图的细节。
二、为什么需要"跨 SSP 的交易模式"
2.1 现实中的媒体方接多个 SSP
上一篇我们讲单 SSP 内部的演化——
但现实中，大媒体很少只接一个 SSP。
一个典型的大媒体可能同时接入：
- Google AdX（最大的 ADX，覆盖最广的广告主）
- Magnite（独立 SSP，独立性强）
- PubMatic（独立 SSP，视频广告强）
- 字节穿山甲（覆盖中国广告主）
- Meta Audience Network（覆盖 Meta 系广告主）
- 甚至自营的广告系统
为什么要接这么多？
很简单——接得越多，竞价的人越多，价格越高。
不同 SSP 服务不同的广告主群体：
- Google AdX 上有大量欧美电商广告主
- 字节穿山甲上有大量中国 APP 广告主
- Meta Audience Network 上有 Meta 系的电商广告主
一家媒体如果只接 Google AdX，就只能拿到欧美广告主的钱——
错过了其他广告主的预算。
2.2 多 SSP 协作的核心问题
但是，接多个 SSP 立刻带来新问题：
同一个广告位曝光机会，应该送给哪个 SSP 竞价？
如果按顺序询问，问错了顺序就错失最高价；
如果同时询问，技术实现又很复杂。
这就是"跨 SSP 协作"要解决的核心问题。
最早的解决方案是Waterfall（瀑布流）——但它有严重缺陷。这就是 Header Bidding 诞生的背景。
三、传统方案：Waterfall 瀑布流
3.1 Waterfall 是什么
Waterfall（瀑布流）是 2010-2017 年广泛使用的多 SSP 协作方案：
媒体方按"预设顺序"依次询问SSP，
第一个出价 ≥ 底价的 SSP 中标。
就像一个串行的问询队列——从第一个开始问，问到有人买为止。
3.2 为什么叫"瀑布流"
因为流量像水流一样，逐层往下流：
- 第一层 SSP 先挑（有兴趣就买）
- 没买的"漏下来"到第二层
- 第二层再挑
- 一层一层往下流
每一层 SSP 都从上一层"漏下来"的流量里挑——就像瀑布。
3.3 Waterfall 怎么工作
我们用一个具体例子展开。
场景：一家媒体接入了 3 个 SSP，按"历史 eCPM"排序：
| 排名 | SSP | 历史 eCPM |
|---|---|---|
| 1 | SSP A | $5.0 |
| 2 | SSP B | $3.0 |
| 3 | SSP C | $2.0 |
eCPM（Effective Cost Per Mille，有效千次曝光成本）：每 1000 次曝光的收益。
历史 eCPM 反映这个 SSP “平均能给媒体方带来多少收入”。
媒体方设置底价为 $2.0。
当一个广告位有曝光机会时：
Step 1: 把流量送到 SSP A（排名第一） ↓ SSP A 内部竞价后，给出价 $4.0 ↓ $4.0 ≥ $2.0（底价）✓ ↓ SSP A 中标，成交！ → 这次曝光以 $4.0 卖给了 SSP A看起来很合理——但有个隐藏问题：
SSP B 这次实际能出 $5.0，但它根本没机会出价——因为 SSP A 已经成交了。
媒体方损失了 $1.0 / 千次曝光。
3.4 Waterfall 的核心缺陷
Waterfall 有 4 个严重缺陷：
缺陷 1：基于"历史"排序，错失"实时"机会
排序是按 SSP 的平均出价能力做的——但每一次具体曝光，实际出价可能截然不同：
- 某些特定时段，SSP B 出价比 SSP A 更高
- 某些特定用户，SSP C 出价比 SSP A 更高
- 但 Waterfall 不管这些，永远按预设顺序问
结果：错失大量"非典型"高价机会。
缺陷 2：错失最高价 ⭐ 最严重
这是 Waterfall 最致命的问题：
第一个出价超过底价的 SSP 直接中标——
后面的 SSP 即使能出更高价，也没机会。
继续上面的例子：
- SSP A 出 $4.0 → 立刻成交
- SSP B 实际能出 $5.0 → 没机会
- SSP C 实际能出 $2.5 → 没机会
媒体方少赚了 $1.0——
而且这种损失每次都在发生。
缺陷 3：延迟高
Waterfall 是串行询问：
- 问 SSP A：100ms
- 没成交，问 SSP B：100ms
- 没成交，问 SSP C：100ms
最坏情况下：300ms才能拿到广告。
而 Header Bidding 是并行询问——
所有 SSP 同时回复，整体延迟 = 最慢的那个 SSP 的延迟（也是 ~100ms）。
用户体验差异巨大。
缺陷 4：长尾流量被压价
排序靠后的 SSP永远只能拿到"漏下来"的流量——
- SSP A 总是先挑，挑走的都是优质流量
- SSP C 拿到的都是 SSP A 不要的"次品"
- SSP C 的广告主体验差，出价更低
- 形成"强者恒强、弱者恒弱"的恶性循环
这种格局让Google AdX（通常排第一）越来越强，
独立 SSP（如 Magnite、PubMatic）越来越被边缘化。
3.5 真实数字：损失 30-50% 的收入
行业研究表明：
Waterfall 模式下，媒体方损失的"机会成本"约 30-50%。
换句话说，如果换成 Header Bidding，
媒体方收入可以提升 30-50%。
对一个年收入 1 亿美元的大媒体来说——每年多赚 3000-5000 万美元。
这就是为什么 Header Bidding 一出现，整个行业的媒体方都疯狂拥抱它。
四、Header Bidding 头部竞价
4.1 历史背景
Header Bidding 不是 Google 推出的——
而是由独立 SSP（Magnite 前身 Rubicon Project、PubMatic 等）联合推动的。
为什么？
因为它们厌倦了 Waterfall 体系下被 Google AdX 压制——永远只能拿"漏下来"的流量。
它们的策略很聪明：
既然按顺序竞价不公平，那就让所有 SSP 同时竞价。
时间线：
- 2014-2015 年：技术开始萌芽
- 2017 年：大规模应用爆发
- 2019 年：Google 也被迫调整自己的规则适应（详见第九节）
这是程序化广告史上最大的一次行业格局重塑。
4.2 Header Bidding 是什么
Header Bidding（头部竞价）的核心思想：
让所有 SSP/ADX 同时收到竞价请求，再统一选最高价中标。
类比：
| 模式 | 类比 |
|---|---|
| Waterfall | 单面试：一个一个谈，谁先签谁中 |
| Header Bidding | 群面：所有人同时报价，价高者得 |
所有 SSP 站在同一起跑线上公平竞争——这就是 Header Bidding 的革命性。
4.3 First Look：Header Bidding 的"优先权"
回到我们一开始的决策树——在"是否竞价"的"是"分支下，有一个决策叫是否 First Look？
First Look（优先查看权）是 Header Bidding 的核心特征：
HB 在所有其他 RTB 竞价之前，优先竞价。
也就是说，当一个广告位有曝光机会时：
Step 1: 先走 Header Bidding（First Look） ↓ 所有 HB 参与的 SSP 同时竞价 ↓ 如果有出价 ≥ 底价 → 中标 ↓ 如果没有 → 进入普通 RTB 流程 Step 2: 进入普通 RTB（OA / PMP） ↓ 按原有流程竞价HB 享有"先看权"——只有 HB 没卖出去，才轮到普通 RTB。
这就是为什么决策树里把"是否 First Look"作为第二层决策。
4.4 Header Bidding 怎么工作
具体的工作流程：
用户访问页面 ↓ 页面 <head> 标签里嵌入的 JavaScript 启动 ↓ JavaScript 同时向多个 SSP 发送竞价请求 ↓ 所有 SSP 在限时（~100ms）内返回出价 ↓ JavaScript 把所有出价汇总，选最高价 ↓ 把最高价传给 Ad Server ↓ Ad Server 决定最终展示关键点：
- 并行竞价：所有 SSP 同时收到请求
- 统一时限：100ms 后所有出价必须返回
- 真正的最高价：从所有出价中挑最大值
4.5 为什么叫"Header"
因为最早的实现方式是在 HTML 的<head>标签里嵌入 JavaScript 代码——
这段 JavaScript 在页面加载时就开始竞价，
比传统的"页面加载完才开始问 SSP" 早得多。
所以叫 “Header” Bidding。
虽然后来出现了 Server-side 实现（不在 head 里嵌代码），
但名字保留了下来。
4.6 Header Bidding 解决了什么
回顾 Waterfall 的 4 个缺陷，看 Header Bidding 怎么解决：
| Waterfall 缺陷 | Header Bidding 解决方案 |
|---|---|
| 基于历史排序 | 每次都实时竞价，不再依赖历史 |
| 错失最高价 | 所有 SSP 同时出价，真正的最高价中标 |
| 串行延迟高 | 并行竞价，总延迟 = 最慢的那个 SSP |
| 长尾 SSP 被压价 | 所有 SSP 公平参与，打破"先来后到" |
4.7 两种实现方式（简略）
Header Bidding 有两种主流实现：
| 类型 | 全称 | 在哪执行 |
|---|---|---|
| Client-side HB | Client-side Header Bidding | 用户的浏览器里 |
| Server-side HB | Server-side Header Bidding | 媒体方的服务器里 |
简单对比：
| 维度 | Client-side | Server-side |
|---|---|---|
| 实现位置 | 浏览器 JavaScript | 后端服务器 |
| 页面性能 | 慢（浏览器要发几十个请求） | 快（只发一个请求） |
| 透明度 | 高（所有出价都能看到） | 中（经过中间层） |
| 移动端体验 | 较差 | 较好 |
现代大型媒体通常用混合方案——部分 SSP 走 Client-side，部分 SSP 走 Server-side。
注：这两种方式的工程细节较复杂，本文不展开。
五、RTB 分支：OA 和 PMP（回顾）
如果一个广告位没走 Header Bidding，就进入普通 RTB 流程。
RTB 内部按"是否公开"分两种——这两个我们上一篇详细讲过，这里只回顾它们在决策树里的位置：
5.1 OA 公开竞价
OA（Open Auction，公开竞价）——决策树编号 ⑤：
- 所有签约 DSP 都能参与
- 价高者得
- 通常用 GSP（广义二价）机制
- 适合长尾流量
5.2 PMP 私有竞价
PMP（Private Marketplace，私有竞价）——决策树编号 ④：
- 媒体方邀请制
- 只允许特定 DSP 参与
- 通常底价更高
- 适合优质流量
详细内容见上一篇 “(5) 交易模式（上）”。
六、程序化直接交易：PDB 和 PD（回顾）
如果走"非竞价"分支，就进入程序化直接交易（Programmatic Direct）流程——
媒体方和广告主事先约定价格。
按"是否保量"分两种：
6.1 PDB 程序化保量
PDB（Programmatic Direct Buying，程序化保量）——决策树编号 ②：
- 事先约定单价 + 投放量
- 媒体方保证投放量
- 优先级最高
- 适合大促、新品发布
6.2 PD 首选交易
PD（Preferred Deal，首选交易）——决策树编号 ③：
- 事先约定单价
- 但不保证投放量——广告主有"首选权"，可挑可不挑
- 优先级次于 PDB
- 适合不想竞价的优质广告主
详细内容也见上一篇 “(5) 交易模式（上）”。
七、Deal ID：私有化交易的"钥匙" ⭐ 新概念
这一节讲一个全新的概念——
回看决策树，编号 ②、③、④ —— 也就是PDB、PD、PMP—— 都通过Deal ID实现。
那么 Deal ID 到底是什么？
7.1 什么是 Deal ID
Deal ID（Deal Identifier，交易标识）是一个唯一的字符串标识符：
Deal ID 是媒体方和广告主之间私有约定的凭证。
一旦有这个 ID，DSP 就知道：“这是我和这家媒体约定好的特殊交易”。
举个具体的 ID 例子：
Deal ID: NYTIMES-LUXURY-CARS-2026-Q1这个 ID 可能代表：
- 媒体方：纽约时报
- 广告主类型：奢侈品汽车
- 时间范围：2026 年 Q1
- 约定内容：固定价 $8 CPM，每天保 50 万次曝光
7.2 为什么需要 Deal ID
问题来了，在 RTB 的洪流中（每秒几十万次竞价请求），
DSP 怎么知道"这次曝光机会是普通竞价，还是我和媒体方有特殊约定"？
Deal ID 就是这把钥匙：
- 没有 Deal ID → 普通公开竞价（OA）
- 有 Deal ID → 检查这个 ID 对应什么约定 → 按约定出价
没有 Deal ID，私有化交易（PDB、PD、PMP）根本无法实现。
7.3 Deal ID 怎么工作
完整流程：
Step 1: 媒体方和广告主达成约定 ↓ SSP 生成一个 Deal ID（如 "NYT-LUX-2026Q1"） ↓ 把 Deal ID 同步给广告主的 DSP Step 2: 这个广告位有曝光时 ↓ SSP 发出竞价请求时，把 Deal ID 也包含进去 ↓ 竞价请求示例（简化版）： { "广告位": "纽约时报首页 banner", "用户": "高净值男性", "Deal ID": "NYT-LUX-2026Q1" ← 关键字段 } Step 3: DSP 收到请求 ↓ DSP 查询：这个 Deal ID 是什么？ ↓ 发现：这是我和纽约时报的约定，单价 $8 ↓ DSP 按约定出 $8 Step 4: SSP 收到出价，按约定模式（PMP/PD/PDB）成交Deal ID 是私有化交易的"通行证"——
没有它，DSP 不知道这是"私有约定"，就会按普通竞价处理。
7.4 为什么 HB 和 OA 不需要 Deal ID
回到决策树，为什么编号 ①（HB）和 ⑤（OA）不在 Deal ID 框里？
很简单：
- OA 是公开竞价——所有 DSP 公平竞价，没有"私有约定"
- HB 是头部竞价——本质也是公开竞价，只是"先于 RTB"
- 两者都不需要"特殊标识"——按公开规则走即可
只有私有化交易（PMP、PD、PDB）需要 Deal ID，因为它们有"特殊约定"，必须用 ID 来识别。
八、用决策树走一遍 3 个真实场景
读完前面的内容，我们用决策树走 3 个真实场景，让你真正掌握这张图的用法。
场景 1：双 11 大促锁定流量
广告主：某电商，要在双 11 当天做品牌营销
需求：必须保证 1 亿次曝光，价格可以贵一点
决策树路径：
是否竞价？ → 否（要确定性，不要竞价的随机性） ↓ 是否保量？ → 是（必须保 1 亿次） ↓ → ② PDB 程序化保量结果：广告主和媒体方签 PDB 合约，
约定"单价 $7 CPM，双 11 当天保 1 亿次曝光"。
通过 Deal ID 实现。
场景 2：奢侈品广告主想要 VIP 房间
广告主：某奢侈品手表品牌
需求：只想在高端财经媒体露出，不想和低质广告主竞价
决策树路径：
是否竞价？ → 是（接受竞价，因为不需要保量） ↓ 是否 First Look？ → 否（不需要跨 SSP 头部竞价） ↓ 是否公开？ → 否（只想在 VIP 房间里，不要公开竞价） ↓ → ④ PMP 私有竞价结果：媒体方邀请这家奢侈品广告主进入 PMP “VIP 房间”，
和其他 5 家奢侈品广告主一起竞价。
通过 Deal ID 识别身份。
场景 3：大媒体想多 SSP 同时竞价
媒体方：某大型新闻网站，接入了 8 个 SSP
需求：让所有 SSP 同时竞价，拿到真正的最高价
决策树路径：
是否竞价？ → 是（要实时竞价） ↓ 是否 First Look？ → 是（用 HB 跨 SSP 同时竞价） ↓ → ① HB 头部竞价结果：媒体方在页面<head>嵌入 Prebid.js（开源 HB 框架），
所有 8 个 SSP 同时竞价，价高者得。
不需要 Deal ID（因为是公开竞价）。
通过这 3 个场景，决策树的用法应该完全清楚了。
九、完整演化时间线
把上一篇和这一篇的内容合在一起，
程序化广告交易模式的完整演化：
| 时间 | 模式 | 编号 | 性质 |
|---|---|---|---|
| 2000 年代 | 人工合约 | - | 传统手工 |
| 2008 | OA 公开竞价 | ⑤ | 单 SSP 内部 |
| 2012 | PMP 私有竞价 | ④ | 单 SSP 内部 |
| 2014 | PD 首选交易 | ③ | 单 SSP 内部 |
| 2015 | PDB 程序化保量 | ② | 单 SSP 内部 |
| 2017 | HB 头部竞价 | ① | 跨 SSP 革命 |
| 2019 | Google AdX 改回一价竞价 | - | 后续调整 |
两条主线：
- 2008-2015：单 SSP 内部的精细化（从公开竞价 → 私有 → 不竞价 → 保量）
- 2017 至今：跨 SSP 的革命（让所有 SSP 公平同时竞价）
十、单 SSP + 跨 SSP 的总结
最后做一个总结性判断：
1. 单 SSP 内部演化（2008-2015）的本质：
从"完全竞价"逐步走向"完全约定"——
给广告主和媒体方更多控制权和确定性。
2. 跨 SSP 革命（2017）的本质：
从"按顺序串行问"变成"所有人同时报价"——
让市场回归公平、回归真正的最高价。
3. 两条演化线的共同主题：
程序化广告的所有演化，都是为了在
自动化效率、价格效率、确定性
这三者之间寻找平衡。
每一种新模式的诞生，都是因为前一种模式在这三者中某一方面失衡。
理解了这个本质，你就理解了程序化广告的工程精髓。
下一篇预告
讲完了所有角色、所有交易模式，程序化广告的"骨架"和"规则"都已经完整。
但还有一个绕不开的核心问题：怎么衡量"投得好不好"？
广告主每天面对一堆问题：这次活动效果如何？预算花对地方了吗？哪个渠道 ROI 最高？一个用户看了 5 个广告才下单，功劳算谁的？
下一篇我们讲考核指标，程序化广告的"成绩单"：
- 按投放漏斗串起所有核心指标（曝光、点击、转化、效果）
- 详细讲解归因（Attribution）：为什么"功劳分配"是门艺术
- 广告主在不同投放目标下，应该看哪些指标
- 媒体方关心的另一套指标
下一篇见。
参考资料
- 《程序化广告：个性化精准投放实用手册》梁丽丽 著，电子工业出版社
本文是「程序化广告学习笔记」系列第 6 篇。
系列目录：
- (0) 先看清楚整个江湖
- (1) DSP：广告主的"代理人"
- (2) DSP 身边的 4 个帮手
- (3) SSP 和 ADX
- (4) Ad Network 和 Ad Server
- (5) 交易模式（上）：单 SSP 内部的演化史
- (6) 交易模式（下）：Header Bidding 的革命 ← 当前
- (7) 考核指标：程序化广告的"成绩单"（待发布）
