Header Bidding

Header bidding 改变了什么

Header bidding 让发布者把每次展示并行地、在广告服务器做最终决定之前报给多个需求源。流程：页面或应用 → 同时向各伙伴发出竞价请求 → 收集到的出价传入广告服务器 → 最终决策 → 胜出素材渲染。

它解决的问题是结构性的。在 header bidding 之前的"瀑布流"模式里，需求源按固定优先级顺序被依次调用，只有上游全部放弃，下游才能看到这次展示——而且通常按估算价而非实际价排序。Google 的交易所还在自家广告服务器内享有最后出价权（last look）。瀑布流系统性地贱卖库存：排在第三位的伙伴永远没机会表明它愿意出双倍价。Header bidding 把队列压平成一场同时进行的竞价，采用它的发布者通常看到可观的收入提升——幅度取决于原瀑布流的定价错得有多离谱。

名字来自最初的实现方式：放在页面 <header> 里的一段 JavaScript，在页面加载的同时扇出竞价请求。占主导地位的开源实现是 Prebid.org 联盟维护的 Prebid.js。

架构选择

**客户端（浏览器）竞价。**页面上的 Prebid.js 容器从用户浏览器调用每个伙伴、在超时窗口内收集出价，把赢家作为键值对转发给 Google Ad Manager，由订单项把它们翻译成对广告位的竞争。优点：出价透明、能访问 cookie/标识符从而匹配率高。缺点：每个伙伴都在用户的浏览器里增加页面负重和延迟。

**服务器端竞价。**浏览器只发一次调用到服务器——Prebid Server、Amazon Publisher Services（TAM/UAM）或同类产品——由数据中心向伙伴扇出。优点：页面轻、可接更多伙伴、超时在服务器端可控。缺点：标识符匹配率更低（服务器没有浏览器的 cookie 上下文）、出价级可见性取决于托管方。

混合架构如今是规模化运营的常态：对延迟敏感、价值高的伙伴放客户端；长尾放服务器端。应用环境通过聚合平台内的 SDK 应用内竞价跑同一套逻辑。

这套竞价动态与 RTB 生态的其他一切相互作用：header bidding 是行业转向一价竞价的主要原因之一——平行竞价的结果再互相喂，让二价逻辑失去了自洽性。

把它运营好

1. **限制伙伴数量。**每个出价方都增加请求、页面负重和尾部延迟。多数发布者发现回报在五到八家精选伙伴附近趋平；再往上加的多是重复需求。用延迟不变下的净增量收入评判每个伙伴。
2. **用实证调超时。**太短丢掉真实出价；太长拖慢广告和内容。客户端超时常见 1000–1500 毫秒，但正确的数字来自你自己的延迟分布——设在出价回收曲线趋平的位置。
3. **在政策允许内做懒加载和刷新。**首屏以下的广告位应在接近视口时才发起竞价——同时提升可视性、省掉浪费的竞价。
4. **维护订单项管道。**广告服务器里细颗粒度的价格桶让出价翻译保持精确；粗桶给每次竞胜悄悄抽税。每次货币、地板或伙伴变更后都要审计。
5. **每月对账净收入。**容器分析报告的是毛出价；伙伴打款时扣掉了费用、差异和未售补量。真正重要的表格，是把广告服务器的竞胜记录和伙伴付款报告拼在一起的那张。
6. **守住用户体验预算。**header bidding 在和内容争抢带宽与主线程时间。把 Core Web Vitals 和收益放在一起追踪——这与 eCPM 优化通用的取舍纪律是同一套。

常见错误

• **加太多出价方。**边际伙伴通常带来重复需求和真实延迟；收益曲线远在伙伴名单之前就趋平了。
• **无视超时与延迟的相互作用。**在办公室快速 Wi-Fi 上调过一次就不管的超时，要么成批丢弃移动端出价，要么让移动页面爬行。
• **测毛出价而不是净收入。**竞胜率和出价密度仪表盘会美化那些发票最终令人失望的伙伴。
• **放任配置腐烂。**过期的适配器版本、被遗弃的订单项、忘掉的测试伙伴，累积成无声的收入泄漏；header bidding 是持续运营，不是一次安装。
• **把客户端 vs 服务器端当意识形态。**正确的切分是按站点、按伙伴的实证结果——匹配率敏感的伙伴配得上浏览器里的位置，其余归服务器端。

FAQ

竞价都改一价了，header bidding 还重要吗？ 重要。一价消除了瀑布流的一个病灶（价格发现），但 header bidding 仍是多个需求源同时而非按特权顺序接触展示的方式。它的贡献在竞争结构，不在定价规则。

我该预期多大的收入提升？ 完全取决于基线。从单一需求源或粗糙瀑布流迁移，两位数百分比的提升很常见；给已调优的配置加第九个出价方收效甚微。用诚实的对照组测试，别信厂商的预测。

客户端还是服务器端？ 通常是都要：少数高价值伙伴放客户端（标识符匹配率对得起那份延迟），其余走服务器端点。没有工程能力的小站常从托管容器或 Amazon Publisher Services 配合 AdSense/Ad Manager 默认配置起步——网站变现路径给出了这些阶段的次序。

跑了 header bidding 还需要 SSP 吗？ header bidding 正是 SSP 竞争你库存的方式——容器里的每个出价方通常就是一个 SSP 或交易所适配器。容器把顺序调用 SSP 变成并行调用；它不取代 SSP。

为什么我的实际收入比容器仪表盘显示的低？ 还是毛与净的问题：仪表盘数的是胜出出价；付款时扣掉伙伴费用、竞价后差异（未渲染或被废弃的展示）和回扣。单个伙伴的差距持续超过几个百分点就值得对账；解释不通的，就该缩小它的角色。