在程序化广告生态全景里，文中把客户端 SDK 称作”整条链路的扳机”，Header Bidding（头部竞价） 是它带来的最大变革。这篇文章把它讲透：它替代的旧逻辑是什么、一次客户端竞价（Prebid.js）的完整链路怎么跑、为什么又要把竞价搬到服务端（Prebid Server），以及 C2S vs S2S 这两种架构在 cookie 匹配率、延迟、成本、控制权上各让了什么步。
最后落到工程：Prebid Server 本质是一个高并发、低延迟的”扇出（fan-out）“服务——这也是为什么不少 Golang / 高并发岗位的 JD 会点名它。
TL;DR
- Header Bidding 要替代”瀑布”：旧的 waterfall 按预估 eCPM 顺序询问需求源，价高者未必得、延迟高、对买方不透明。
- 核心思路三个词：提前、并行、公平。在调用媒体 Ad Server 之前，于页面头部并行向多个 SSP 同时询价，按真实出价取最高，再喂给 Ad Server 做最终决策。
- 客户端（Prebid.js / C2S）：竞价在浏览器里跑。cookie 匹配率高（用户浏览器里有各买方 cookie）→ CPM 高；但每多接一个 adapter 就多一份 JS 和一次请求，拖慢页面。
- 服务端（Prebid Server / S2S）：把并行询价搬到服务器，浏览器只发一次请求。快、轻、可接更多 bidder；但服务器没有用户 cookie，匹配率下降，要靠 cookie syncing 弥补。
- 结果传递靠 key-value：Header Bidding 自己不投广告，而是把胜出价编码成
hb_pb等 targeting key，借 Ad Server 的 line item 机制落地。 - Prebid Server 是工程重头：一个把请求扇出到 N 个 bidder adapter、在统一超时预算内并行收口、再做币种 / 底价 / 隐私合规处理的服务，PBS 有 Go 与 Java 两套实现——高 QPS、ms 级延迟、优雅降级是它的核心命题。
- 现实多是混合（hybrid）：一部分 bidder 走客户端、一部分走服务端，按匹配率和性能分流。
Table of contents
Open Table of contents
1. 它要替代的旧逻辑：瀑布（waterfall）
Header Bidding 之前，媒体 Ad Server（典型是 Google Ad Manager / 早期 DFP）用瀑布流卖剩余库存——按事先排好的优先级，一个一个顺序询问需求源：
问广告网络 A（历史预估 eCPM $5）→ 要不要？不要 →
问广告网络 B（历史预估 eCPM $3）→ 要不要？不要 →
问广告网络 C（历史预估 eCPM $2）→ ……直到有人接单或兜底三个致命问题：
- 按”预估 eCPM”排序，不是按真实出价：排在最前的网络 A 这一次可能只愿出 $2，而排在后面、本愿出 $8 的网络 C 根本没机会被问到——价高者未必得，媒体白白漏钱。
- 顺序询问 = 高延迟：一个个串行问，每一跳都要等上一跳超时或拒绝，链路越长越慢。
- 对买方不透明：买方不知道自己排在第几顺位，也无法和别人公平竞争同一次曝光。
一句话：瀑布的病根是”按历史顺位、串行询价”。Header Bidding 的全部价值，就是把它改成”按真实出价、并行竞价”。
2. 核心思路：提前 + 并行 + 公平
Header Bidding 把”卖剩余库存”这件事，从 Ad Server 内部抢到浏览器前端、并改成并行：
在页面加载时、调用 Ad Server 之前，用一段 JS（典型是 Prebid.js）同时向多个 SSP / 交易所发出竞价请求，在超时内收齐所有真实出价，取最高的那个，再作为”门槛价”交给 Ad Server 做最终决策。
三个关键词：
- 提前（header）：竞价发生在页面
<head>里、Ad Server 调用之前——这正是”头部”竞价的含义。 - 并行（parallel）：所有需求源同时被询价，不再排队，延迟取决于最慢的一个而非所有之和。
- 公平（unified）：大家面对同一次曝光、站同一条起跑线，按真实出价比高低，而非按预估顺位。
算笔账：同一次曝光，瀑布 vs Header Bidding
设三个需求源 A / B / C，按历史 eCPM 排序是 A（$5）> B（$3）> C（$2）；但这一次它们的真实出价是 A $2、B $4、C $8：
| 机制 | 发生了什么 | 媒体到手 |
|---|---|---|
| 瀑布 | 按历史顺位先问 A → A 这次出 $2、有填充 → 命中即停 | $2 |
| Header Bidding | A / B / C 并行报真实价 $2 / $4 / $8 → C 价高者得 | $8 |
差距 +300%：C 按历史 eCPM 排在最末、瀑布根本问不到它，可它这次恰恰出价最高。Header Bidding 让真实价同台，才把这笔钱捞回来——这就是”提前 + 并行 + 公平”省下的真金白银。
3. 客户端 Header Bidding：Prebid.js 的完整链路
Prebid.js 是开源的客户端 Header Bidding 库，事实上的行业标准。一次客户端竞价端到端是这样：
注意第 4、5 步：Prebid 自己不投广告，而是把竞价结果翻译成 Ad Server 能识别的 key-value，借 Ad Server 现有的决策机制落地。
文字版分解：
- 页面加载，Prebid.js 启动，读取广告位（ad unit）和接好的 bidder adapter 配置。
- 并行询价：
pbjs.requestBids()同时向所有配置的 SSP 发出 bid request，各 SSP 内部跑自己的竞价。 - 收口 + 超时：在
PREBID_TIMEOUT（通常 1000–1500ms）内收齐能回的出价；超时未回的直接丢弃——超时是性能与收益最直接的旋钮。 - 选最高价 + 写 key-value：Prebid 选出最高价，用
pbjs.setTargeting把它编码成一组 targeting key 挂到广告请求上：
hb_pb = 6.20 # 价格分桶（price bucket）
hb_bidder = sspB # 中标 bidder
hb_adid = a1b2c3 # 对应 creative 的 id
hb_size = 300x250- 调用 Ad Server：浏览器的 GPT（Google Publisher Tag） 携带这些 key-value 调用 GAM。
- 最终决策：Ad Server 用
hb_pb去匹配预先建好的 line item（按价格分桶建的订单），让 Header Bidding 的价和直采订单、自家 AdX 一起做 decisioning；谁的 eCPM 高谁赢。 - 渲染：若 Header Bidding 的某个 bidder 胜出，Ad Server 返回的 creative 会触发 Prebid Universal Creative 去把缓存的中标素材渲染到页面。
工程精髓在第 4–6 步：Header Bidding 不绕开 Ad Server，而是把自己”翻译”成 Ad Server 听得懂的 key-value，复用它的 line item 与 decisioning。这也意味着——媒体要在 GAM 里预先建一大批按价格分桶的 line item（比如每 $0.10 一档），
hb_pb的分桶粒度必须和 line item 对齐，否则价格匹配会错位。
4. 服务端 Header Bidding：Prebid Server（S2S）
客户端方案有个硬伤：每接一个 bidder，浏览器就多一份 adapter JS、多一次出站请求。接 5 个 SSP 还行，接 15 个，页面在加载关键路径上就被拖垮——延迟、流量、电量全是用户在买单。
Server-to-Server（S2S）Header Bidding 的解法是把”并行扇出询价”这件重活，从浏览器搬到一台服务器上——这台服务器的开源实现就是 Prebid Server（PBS）。
浏览器侧从”扇出 N 个请求”塌缩成”1 个请求”，扇出的活儿移到 Prebid Server 内部并行完成。代价是服务器不在用户浏览器里，拿不到各买方的 cookie。
流程的差别只在前半段：
- 浏览器里的 Prebid.js（或轻量 stub）只向 Prebid Server 发一次请求；
- Prebid Server 在服务端把请求扇出，并行调用所有配置的 bidder adapter；
- 在服务端统一超时内收齐、聚合，做币种换算 / 底价 / 隐私合规等处理；
- 把最高价（或一组候选）返回浏览器；
- 后半段和客户端一样：写 key-value → 调 Ad Server → 决策 → 渲染。
Prebid Server 有两套开源实现：PBS-Go 和 PBS-Java。 高流量媒体 / SSP 多选 Go 版——这也是”Golang + 高并发 AdTech”岗位常点名它的原因，第 6 节细讲。
5. C2S vs S2S：到底各让了什么步
两种架构不是谁取代谁，而是一组权衡。核心矛盾是一句话：把竞价放在浏览器（离用户近、有 cookie）还是放在服务器（快、可扩展、但没 cookie）。
| 维度 | 客户端 Prebid.js（C2S） | 服务端 Prebid Server（S2S） |
|---|---|---|
| 竞价在哪跑 | 用户浏览器 | 媒体 / SSP 的服务器 |
| 浏览器请求数 | 每个 bidder 一次（N 次） | 仅 1 次（到 PBS） |
| 页面延迟 / 性能 | 差——adapter JS + N 次请求堆在关键路径 | 好——扇出在服务端并行 |
| cookie 匹配率 | 高——浏览器里有各买方 cookie | 低——服务器没有，需 cookie syncing 弥补 |
| 可接 bidder 数量 | 受性能限制，通常 ≤ 5–10 | 可接很多，扇出在服务端 |
| 典型成交价（CPM） | 偏高（匹配率高） | 偏低（匹配率损耗），靠规模与速度补 |
| 控制 / 可调试 | 前端可见、易调 | 黑盒在服务端，需日志 |
| 维护成本 | 页面里堆 adapter | 维护一套高并发服务 |
5.1 绕不开的痛点：cookie syncing
S2S 最大的损耗来自 cookie 匹配率。买方（DSP / SSP）靠自己域名下的 cookie 认出”这是谁”。客户端竞价发生在用户浏览器里，请求天然带着各买方的第三方 cookie，匹配率高；而 Prebid Server 跑在媒体的服务器域名下，它手里只有自己的 ID，认不出对方的用户。
弥补办法是 cookie syncing（cookie 同步）：Prebid Server 通过 /cookie_sync 和 /setuid 端点，借用户浏览器发起一轮重定向 / 像素，把”PBS 的用户 ID ↔ 各 bidder 的用户 ID”在 PBS 的 uids cookie 里对应起来。下次 S2S 请求就能带上各 bidder 认得的 ID。
但 cookie syncing 正在结构性失效：Safari ITP、Firefox ETP 早已封杀第三方 cookie，Chrome 也在收缩。匹配率下降是 S2S（乃至整个第三方 cookie 体系）的长期趋势，这也把行业推向第一方数据与统一 ID（UID2 / ID5 等）作为替代——这部分留给身份专题展开。
5.2 现实：混合（hybrid）才是常态
实际生产里很少非此即彼。媒体通常两套并跑：把匹配率敏感、出价高的核心 bidder 留在客户端，把长尾的、性能敏感的 bidder 放到服务端——按”这个 bidder 在客户端还是服务端更划算”逐个分流。Prebid.js 原生支持把部分 bidder 标为 S2S，无缝混合。
6. 工程深挖：Prebid Server 是个什么系统
从工程视角，Prebid Server 是一个典型的”扇出 / 收口（scatter-gather）“高并发服务——它的难点不在业务逻辑，而在用一个固定的延迟预算，把一次请求同时打到几十个外部 bidder、再把能回的结果在预算内收齐。这也是它和”百万 QPS 广告服务”同属一类工程问题的原因。
核心命题：在一个固定的超时预算里，向 N 个外部系统并发取数、能收多少是多少、且任何一个慢 bidder 都不能拖垮整场。这正是 Go 的 goroutine + context 超时模型擅长的场景。
几个值得讲的工程点：
- 扇出并发模型：一次请求并发调用 N 个 bidder。Go 版用 goroutine 各自发 HTTP、用
context.WithTimeout套一个全局 auction 超时，外加每个 bidder 的 per-bidder timeout；主流程用WaitGroup/ channel 收口，到点即返回，不等慢的。这是”扇出 + 截止时间（deadline）“的教科书模型。 - 超时预算是硬约束：整个 auction 通常只有几百毫秒。预算要在”等更多 bidder 回来（多赚）“和”别拖慢页面（体验）“之间切。慢 bidder 的尾延迟（p99）直接决定能否在预算内收到它的价。
- bidder adapter 是适配层：每个 adapter 把 Prebid 的统一 OpenRTB 请求，翻译成对应 SSP 的私有字段，再把对方响应翻译回统一格式。Prebid Server 内置了几百个 adapter——可维护性、隔离性（一个 adapter 崩了不能影响别人）是工程重点。
- 横切关注点：币种换算（统一成结算币种再比价）、floors（底价模块）、bid 响应校验、隐私合规（TCF/GDPR consent、US Privacy 字符串的解析与 gating，呼应 TCF 那篇）、以及 Prebid Cache（PBC）——视频 VAST / 大体积 creative 不便回传浏览器，先缓存、只回一个
hb_cache_id。 - 无状态 + 水平扩展：PBS 本身基本无状态（除 cookie sync 的
uids），靠水平扩容扛 QPS；可观测性（每个 bidder 的超时率、响应时延、no-bid 率）是调优的眼睛。
一句话给工程师：Prebid Server 把”程序化竞价”抽象成了一个’带截止时间的并发聚合’问题。理解它，基本就理解了高并发 AdTech 后端的缩影——这也是为什么相关 JD 会拿它当试金石。
7. 竞价价落在哪：媒体 Ad Server 的决策
Header Bidding 跑完得到的胜出价，不直接投广告——它被翻译成一个 price priority（价格优先）line item，由 hb_pb 的金额带着，进入媒体 Ad Server（GAM）做最终决策。Ad Server 的活儿是 decisioning（分配）：在直采保量单、各种程序化、Header Bidding、兜底广告之间，挑出”既满足合约、收益又最高”的那一个。
对 Header Bidding 来说，有两点必须知道：
- 保量直采天然压在它之上。GAM 的 line item 按优先级分层（Sponsorship > Standard > … > Price Priority > House），Header Bidding 只活在”价格优先”这一层。哪怕 HB 这次出价更高，只要上层还有没投满、且定向匹配的保量单，曝光仍可能先给保量单——这正是交易模式那条优先级瀑布的 Ad Server 实现。
hb_pb分桶必须和 line item 对齐。每个价格档（如每 $0.10）对应一个 price priority line item；粒度不一致就会价格落错档、静默漏收（见第 9 节）。
媒体 Ad Server 本身是个值得单独展开的大角色——它的 line item 优先级体系、decisioning 流水线、dynamic allocation 与统一竞价、以及作为高 QPS 决策系统的工程内核，完整拆解见专文《媒体 Ad Server 深挖：GAM 的 decisioning、line item 与 dynamic allocation》。这里只需记住：Header Bidding 不绕开 Ad Server，而是把自己翻译成它听得懂的 line item，借它的决策落地。
8. 关键工程权衡
把散落各处的取舍集中一下：
- 超时（timeout）：客户端 1000–1500ms、服务端更短。调小→页面快但丢竞价、少赚；调大→多赚但拖慢渲染。还要配 failsafe timeout：到点 Prebid 还没收齐，也得放行去调 Ad Server，绝不能卡住页面。
- price granularity（价格分桶）：
hb_pb的分桶粒度（如每 $0.10 一档）必须和 GAM 里的 line item 一一对齐，否则价格匹配错位、要么少卖要么投错。 - SDK / adapter 体积：客户端每多一个 adapter 就多一份 JS。体积和 bidder 数量是收益与性能之间最直接的旋钮——这也是 S2S 存在的根本动机。
- key 长度限制：GAM 的 targeting key 有长度上限（历史上 20 字符），Prebid 的
hb_*key 在多 bidder 下要用缩写形式（如hb_pb_sspB）规避截断。 - auction 机制：现代 Prebid 默认一价。这与行业从二价倒向一价、堵 last look 是同一股潮流——统一、透明、赢家付自己出价。
- 首屏 / 懒加载：把竞价绑定到 viewability（广告位快进视口才竞价），既省请求又提升可见率，但要权衡填充延迟。
8.1 一个真实的超时调优：别用一个全局 timeout 套所有 bidder
“timeout 设多少”是 Header Bidding 最被拍脑袋的旋钮。问题在于：各 bidder 的延迟分布天差地别，一个全局 timeout 对所有人是同一条死线，但对收益的影响却各不相同。 看一组有代表性的数（5 个 bidder，按真实时延分布画像）：
| bidder | p50 | p95 | 平均贡献 eCPM | 全局 800ms 下的命运 |
|---|---|---|---|---|
| A | 120 ms | 280 ms | $2.10 | 稳进 |
| B | 200 ms | 450 ms | $3.40 | 稳进 |
| C | 350 ms | 1100 ms | $6.80 | p95 超界 → 约一半请求被丢 |
| D | 90 ms | 180 ms | $1.20 | 稳进 |
| E | 600 ms | 1500 ms | $0.90 | 几乎全超时，却仍发了请求拖慢页面 |
一个全局 800ms 同时犯了两个方向的错：
- 误杀慢但值钱的 C：它 p95 要 1100ms，全局 800ms 下约一半曝光拿不到它 $6.80 的报价——这是收益里最肉疼的漏损。
- 纵容慢又不值钱的 E：它几乎每次都超时被丢，但客户端 adapter 已经实打实发出了请求，占着关键路径的带宽和 CPU，把本可成交的 A/B/D 一起拖慢（§9 开头那个事故就是这么来的）。
正确做法是按每个 bidder 的 p95 分桶、分别给 per-bidder 预算，并把不达标的移到 S2S：
快档（p95 < 300ms）：A、D → 客户端，per-bidder 300ms
中档（p95 < 500ms）：B → 客户端，per-bidder 500ms
慢但高价（C）： → 移到 S2S，单独给 1200ms per-bidder 预算
（S2S 的慢不占浏览器关键路径）
慢又低价（E）： → 直接下掉，它的期望收益盖不住它的延迟成本前后对比的逻辑很清楚：C 从”约一半丢弃”变成”几乎全收”，把它 $6.80 里被漏掉的那部分捞回来；E 被移除后，A/B/D 的填充率回升。净效果通常是整体 eCPM 上行、而页面 p75 加载时间反而下降——因为你拿掉了”既慢又不赚”的纯负担，又把”慢但值钱”的挪到了不挡路的服务端。
一句话原则：timeout 不是一个数字，而是一张按”延迟分布 × 期望收益”决策的表。 全局 timeout 是”一刀切”的偷懒；per-bidder 预算 + C2S/S2S 分流，才是把延迟预算花在刀刃上的姿势。这也正是 §6 里 Prebid Server 给每个 adapter 套独立 per-bidder timeout 的意义所在。
9. 工程实战：几个绕不开的坑
一个典型的收益事故：某媒体上线一个新 bidder 后整体收入不升反降。排查发现这个 bidder 的 p95 响应要 1200ms，而 auction timeout 设在 1000ms——它几乎每次都超时被丢，却又在客户端实打实发起了请求、拖慢了页面，导致别的本可成交的 bidder 也跟着掉填充。把它移到 S2S、并单独给更宽的 per-bidder 预算后，才转正。慢 bidder 不只是”自己不赚”，它会拖累整场。
其余高频坑：
- 超时设置拍脑袋：不看各 bidder 的真实时延分布就定 timeout，要么误杀慢但值钱的 bidder，要么放任拖慢页面。应按 p95/p99 分 bidder 调。
- price granularity 与 line item 不一致：Prebid 改了分桶、GAM line item 没跟着改，价格落不进对的档位，静默漏收。
- cookie sync 没做 / 做漏：S2S 上了却忘了配 cookie sync，匹配率惨淡，CPM 上不去还以为是 bidder 不行。
- 重复计费 / auction 偏差：客户端与服务端混合时，同一次曝光在两套里都被记一遍，对账对不上。
- 隐私合规漏判：TCF consent 没正确透传给 bidder，要么违规、要么被 bidder fail-closed 拒掉，无声丢量。
10. 常见误解 ↔ 正解
这一节专治”听起来对、其实差一点”的高频误区——也是面试里最容易露馅的地方：
| 常见误解 | 正解 |
|---|---|
| Header Bidding 自己会投广告 | 不投——它把胜价写成 hb_pb，借 Ad Server 的 line item 落地 |
| Header Bidding 绕开了 Ad Server | 恰恰相反，它复用 Ad Server 的 decisioning，把自己翻译成 line item |
| HB 这次出价最高就一定拿到曝光 | 还要在 Ad Server 里和保量直采比，保量优先级更高（见 §7） |
| S2S 一定比 C2S 好（更快就更赚） | 快，但 cookie 匹配率低、CPM 可能更低；常态是混合 |
| 接的 bidder 越多越赚 | 客户端每多一个 adapter 拖页面；慢 bidder 还拖累整场（见 §9） |
| timeout 调大就多赚 | 过大拖慢渲染、伤可见率；要按 p95/p99 分 bidder 调 |
| Prebid 是二价拍卖 | 现代 Prebid 默认一价 |
| cookie syncing 能长期解决匹配率 | 它在结构性失效（ITP/ETP），趋势转向第一方 / 统一 ID |
11. 速查表
- 替代瀑布：waterfall 按预估顺位串行问；Header Bidding 按真实价并行竞价。
- 三个词：提前（调 Ad Server 前）、并行（同时询价）、公平（真实价比拼）。
- 结果落地：胜出价写成
hb_pb等 key-value，借 Ad Server 的 line item 决策，不绕开它。 - C2S（Prebid.js）：浏览器里跑，cookie 匹配率高、CPM 高，但拖页面、接不了太多 bidder。
- S2S（Prebid Server）：服务端扇出，快、轻、可接很多 bidder，但没 cookie、靠 cookie syncing 补，匹配率走低。
- Prebid Server：带截止时间的并发”扇出/收口”服务，Go / Java 两套实现，高 QPS + ms 级延迟 + 优雅降级。
- 常态是混合：核心 bidder 走客户端，长尾走服务端。
- 旋钮：timeout / failsafe、price granularity、adapter 体积、一价机制。
Header Bidding 的本质，是把卖方侧的竞价从一个黑箱顺位，改造成一场公开、并行、按真实价决胜的拍卖。Prebid.js 把它放进浏览器，Prebid Server 把它搬上服务器——理解这两者的取舍，基本就握住了现代卖方变现技术栈的主轴。
延伸阅读
按”全局 → 端上扳机 → 决策落地 → 透明度”的顺序串起来读最顺：
- 程序化广告生态全景：先看全局，Header Bidding 在卖方链路里的位置。
- App 广告 SDK 深挖：App 侧的同源物 In-App Bidding 与聚合（Mediation）——机制一一对应，但端上多了内存 / ANR / 崩溃 / 弱网的约束。
- 媒体 Ad Server 深挖：
hb_pb喂进去之后，decisioning / line item / dynamic allocation 是怎么拍板的。 - 程序化交易模式：RTB / PMP / PD / PG：保量为何天然压在 Header Bidding 之上。
- last look 与拍卖透明度：Prebid 默认一价、堵 last look 背后的那股潮流。
- IAB TCF Explained：Prebid Server 里 consent 透传与隐私合规的协议基础。
再是规范与一手资料：
- Prebid.org. Prebid.js — Getting Started：客户端 Header Bidding 的官方实现与配置参考。
- Prebid.org. Prebid Server Overview：PBS-Go / PBS-Java 两套实现的架构与扇出模型。
- Prebid.org. Prebid Server Cookie Sync：
/cookie_sync与/setuid的 S2S 匹配率弥补机制。 - Prebid.org. Price Granularity：
hb_pb分桶必须与 GAM line item 对齐的那个旋钮。 - IAB Tech Lab. OpenRTB 2.6 Specification：bid request / response、扩展字段与 consent 携带的权威定义。
- Google Ad Manager Help. Unified pricing rules：2019 年 GAM 切到统一一价竞价的官方说明。
附录：术语表
- Header Bidding（头部竞价）：在调用媒体 Ad Server 之前、于页面头部并行向多个 SSP 询价、按真实出价取最高的卖方变现技术。
- Waterfall（瀑布）：按预估 eCPM 顺序串行询问需求源、命中即停的旧机制；Header Bidding 要替代的对象。
- Prebid.js：事实标准的开源客户端 Header Bidding 库，跑在浏览器里。
- Prebid Server（PBS）：把并行询价搬到服务端的开源实现，有 Go / Java 两套；高 QPS 的”扇出 / 收口”服务。
- C2S / S2S：客户端到服务端 / 服务端到服务端两种 Header Bidding 架构。
- bidder adapter：把 Prebid 统一的 OpenRTB 请求翻译成某 SSP 私有格式、再翻译回来的适配层。
- fan-out / scatter-gather（扇出 / 收口）：一次请求并发打到 N 个外部 bidder、在固定超时预算内能收多少收多少的并发模型。
hb_pb/ targeting key：Header Bidding 把胜出价编码成的价格分桶等键值对，借 Ad Server 的 line item 落地。- price granularity（价格分桶）：
hb_pb的取值粒度（如每 $0.10 一档），必须与 GAM 的 price priority line item 一一对齐。 - line item（订单行）：媒体 Ad Server 里表达一笔需求的基本单位，带优先级；Header Bidding 落在 price priority 层。
- cookie syncing（cookie 同步）：PBS 通过
/cookie_sync//setuid把自身 ID 与各 bidder ID 对应起来，弥补服务端没有买方 cookie 的匹配率损耗。 - timeout / failsafe timeout：竞价收口预算 / 到点强制放行去调 Ad Server 的兜底超时。
- Prebid Cache（PBC）：视频 VAST / 大素材不便回传浏览器，先缓存、只回
hb_cache_id。 - floors（底价）：Prebid Server 的底价模块，比价前过滤低于底价的出价。
- 一价 / 二价拍卖：成交价 = 自己出价 / 第二名 + 增量；现代 Prebid 默认一价。
- GPT（Google Publisher Tag）：GAM 的客户端标签，携带
hb_*key-value 调用 Ad Server。 - eCPM：把不同计价归一成”每千次曝光等效收入”，Ad Server 比价的核心指标。