#relationships·Jul 17, 2026·6 分钟阅读
Bid Request vs Bid Response: Key Differences in Programmatic Advertising
出价请求和出价响应是实时竞价中交换的两个核心消息。出价请求是发布商对竞价的召唤；出价响应是买方的回应。理解它们之间的差距对于诊断填充率和延迟至关重要。
核心区别
出价请求由发布商的广告服务器（例如 Google Ad Manager）在广告位可用时发送给需求方。它包含：
- 页面 URL、设备类型、用户 ID
- 广告单元尺寸、底价
- 上下文信号（IAB 类别）
出价响应是买方（例如来自 DSP）的回复。它包含：
- 出价价格（CPM）
- 创意内容（VAST、图片、HTML）
- 用于跟踪的获胜 URL
请求询问“谁想要这个展示机会？”响应则表示“我愿意为它支付 X 金额。”
何时使用哪种
选择竞价请求时：
- 您想衡量供应量（存在多少机会）。
- 您正在诊断超时率（从未收到响应的请求）。
- 您正在审计数据泄露（发送了哪些用户数据）。
选择竞价响应时：
- 您想衡量需求积极性（出价、胜率）。
- 您正在优化创意投放（尺寸、格式合规性）。
- 您正在调试延迟（每个买家的响应时间）。
同时使用两者时：
- 计算填充率 = 响应数 / 请求数。
- 构建记录两者的瀑布流或头部竞价包装器。
它们如何分叉
方向
竞价请求从发布者流向买家。竞价响应从买家返回发布者。
内容重点
竞价请求描述广告展示（上下文、用户、广告位）。竞价响应描述出价（价格、创意、跟踪）。
时间压力
竞价请求没有截止时间（服务器等待）。竞价响应必须在超时（通常为100–200毫秒）之前到达，否则将被忽略。
它们在哪里重叠
协议
两者均在 OpenRTB 2.x 规范中定义，并使用 JSON 或 Protobuf 格式。
竞价ID
两者携带相同的 bidid 或 auctionid，以便交易所进行匹配。
同意信号
两者均可包含 GDPR 同意（TCF 字符串）和 CCPA 退出信号。
真实场景
移动网页填充率低
场景：发布商发现移动网页的填充率仅为50%。
- 发生了什么： 竞价请求量很大，但许多请求没有用户ID（无cookie）。
- 他们检查了什么： 对比了请求日志（缺少
device.ifa）和响应日志（这些请求的竞价响应为零）。
要点： 竞价请求中缺少用户标识符导致买家跳过响应。解决方法：启用符合隐私规范的ID解决方案。
某DSP延迟过高
场景：头部竞价包装器显示某个DSP的响应时间始终超过300毫秒。
- 发生了什么： 该DSP的竞价响应在超时后才到达。
- 他们检查了什么： 对比了竞价请求发送时间戳和竞价响应接收时间戳。
要点： 该DSP需要优化其内部竞价逻辑。发布商设置了200毫秒超时，并排除了响应慢的竞价方。
它们如何一起工作
作为发布商诊断某些广告位为何没有出价时，请检查出价请求是否缺少信号（例如，没有用户ID、尺寸错误）。
作为买方优化出价价格或创意时，请分析出价响应数据，了解哪些创意胜出以及对应的CPM。
作为广告运营团队排查填充率低的问题时，请比较请求量与响应量，以发现超时或过滤问题。
对照速览
| 观察角度 | 出价请求 | 出价响应 |
|---|---|---|
| 方向 | 发布者 → 买家 | 买家 → 发布者 |
| 主要内容 | 展示上下文（URL、尺寸、用户） | 出价、创意、获胜URL |
| 超时相关性 | 无超时（服务器等待） | 必须在超时前到达（例如100毫秒） |
| 典型用例 | 供应分析、数据泄露审计 | 需求分析、创意优化 |
常见误区
混淆请求次数与机会次数
为何混淆是错误的：单次页面加载可能产生多个出价请求（每个广告位一个）。将请求计为“展示”会夸大供应量。
- 正确做法：仅使用出价请求来衡量竞价数量，而非可展示的展示次数。
忽略无出价响应
为何混淆是错误的：出价响应可能是“无出价”（空价格）。某些系统将其计为响应，从而扭曲填充率。
- 正确做法：计算填充率时，仅筛选出
price > 0的响应。
- 正确做法：计算填充率时，仅筛选出
快速检查
测试您是否能区分这些指标。
boolean
出价响应可以在超时后到达并仍然被使用。
请选择答案
仅供学习，不构成投放建议。