程序化广告系列 (6)：交易模式（下）——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 还是普通 RTBRTB 路径下是否公开—— 决定是 OA 还是 PMP非竞价路径下是否保量—— 决定是 PDB 还是 PD最终落地5 种交易模式编号模式简称中文①Header BiddingHB头部竞价②Programmatic Direct BuyingPDB程序化保量③Preferred DealPD首选交易④Private MarketplacePMP私有竞价⑤Open AuctionOA公开竞价关于 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历史 eCPM1SSP A$5.02SSP B$3.03SSP C$2.0eCPMEffective 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 A100ms没成交问 SSP B100ms没成交问 SSP C100ms最坏情况下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 推出的——而是由独立 SSPMagnite 前身 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 LookHeader Bidding 的优先权回到我们一开始的决策树——在是否竞价的是分支下有一个决策叫是否 First LookFirst Look优先查看权是 Header Bidding 的核心特征HB 在所有其他 RTB 竞价之前优先竞价。也就是说当一个广告位有曝光机会时Step 1: 先走 Header BiddingFirst Look ↓ 所有 HB 参与的 SSP 同时竞价 ↓ 如果有出价 ≥ 底价 → 中标 ↓ 如果没有 → 进入普通 RTB 流程 Step 2: 进入普通 RTBOA / 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 HBClient-side Header Bidding用户的浏览器里Server-side HBServer-side Header Bidding媒体方的服务器里简单对比维度Client-sideServer-side实现位置浏览器 JavaScript后端服务器页面性能慢浏览器要发几十个请求快只发一个请求透明度高所有出价都能看到中经过中间层移动端体验较差较好现代大型媒体通常用混合方案——部分 SSP 走 Client-side部分 SSP 走 Server-side。注这两种方式的工程细节较复杂本文不展开。五、RTB 分支OA 和 PMP回顾如果一个广告位没走 Header Bidding就进入普通 RTB 流程。RTB 内部按是否公开分两种——这两个我们上一篇详细讲过这里只回顾它们在决策树里的位置5.1 OA 公开竞价OAOpen Auction公开竞价——决策树编号 ⑤所有签约 DSP 都能参与价高者得通常用 GSP广义二价机制适合长尾流量5.2 PMP 私有竞价PMPPrivate Marketplace私有竞价——决策树编号 ④媒体方邀请制只允许特定 DSP 参与通常底价更高适合优质流量详细内容见上一篇 “(5) 交易模式上”。六、程序化直接交易PDB 和 PD回顾如果走非竞价分支就进入程序化直接交易Programmatic Direct流程——媒体方和广告主事先约定价格。按是否保量分两种6.1 PDB 程序化保量PDBProgrammatic Direct Buying程序化保量——决策树编号 ②事先约定单价 投放量媒体方保证投放量优先级最高适合大促、新品发布6.2 PD 首选交易PDPreferred Deal首选交易——决策树编号 ③事先约定单价但不保证投放量——广告主有首选权可挑可不挑优先级次于 PDB适合不想竞价的优质广告主详细内容也见上一篇 “(5) 交易模式上”。七、Deal ID私有化交易的钥匙 ⭐ 新概念这一节讲一个全新的概念——回看决策树编号 ②、③、④ —— 也就是PDB、PD、PMP—— 都通过Deal ID实现。那么 Deal ID 到底是什么7.1 什么是 Deal IDDeal IDDeal Identifier交易标识是一个唯一的字符串标识符Deal ID 是媒体方和广告主之间私有约定的凭证。一旦有这个 IDDSP 就知道“这是我和这家媒体约定好的特殊交易”。举个具体的 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 年代人工合约-传统手工2008OA 公开竞价⑤单 SSP 内部2012PMP 私有竞价④单 SSP 内部2014PD 首选交易③单 SSP 内部2015PDB 程序化保量②单 SSP 内部2017HB 头部竞价①跨 SSP 革命2019Google 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) 考核指标程序化广告的成绩单待发布