拍卖延迟

拍卖延迟是指从发布商广告服务器发送竞价请求到收到最终决策（获胜出价、创意URL或回传）之间的挂钟时间。这是一个平台级指标，因为拍卖基础设施——交易所、SSP、头部竞价包装器——控制着大部分时间。

延迟不是一个单一数字。它是一个链条：

• 网络往返 — 请求到达竞价者并返回响应。
• 竞价者处理 — 竞价者评估用户、应用底价并运行内部拍卖的速度。
• 包装器瀑布流 — 在头部竞价中，每个适配器等待其超时后下一个才开始运行。
• 广告服务器决策 — 最终选择获胜者的服务器端调用。

用户可见的成本

每增加100毫秒的延迟，页面浏览完成率就会下降。在移动设备上，这种影响更为严重，因为网络条件更差，用户耐心更少。只优化填充率或胜率而不监控延迟的平台，往往会降低可见度，并且讽刺的是，由于更少的广告位完全渲染，有效CPM也会降低。

拍卖延迟 = 收到决策的时间 − 发送竞价请求的时间

所有时间均在平台（SSP、交易平台或头部竞价封装器）上测量。单位是毫秒。

重要注意事项

• 起始点不同。 一些平台从广告调用离开浏览器时开始测量；另一些则从广告进入拍卖引擎时开始测量。请务必查看供应商的定义。
• 超时 ≠ 延迟。 500 毫秒的超时并不意味着每次拍卖都需要 500 毫秒。延迟是实际时间，应远低于超时时间。
• 聚合会隐藏尾部。 平均延迟看起来可能不错，但第 95 百分位可能给用户带来真正的痛苦。请分别监控 p50、p95 和 p99。
• 创意下载不包含在内。 延迟在返回决策时停止，而不是在广告渲染时。渲染时间是另一个指标（通常称为“创意加载时间”）。

单个延迟数字几乎毫无意义。请按分布解读：

• p50（中位数） — 典型用户体验。服务器端竞价应低于200毫秒，客户端头部竞价应低于400毫秒。
• p95 — 最慢的5%竞价。若此值超过超时时间，你将因超时而失去竞价。
• p99 — 极端异常值。通常由单个缓慢的竞价者或网络波动引起。

配合哪些指标使用

• 竞价请求量 — 若延迟突然飙升且竞价请求量下降，说明竞价在请求完成前已超时。
• 填充率 — 若延迟高且填充率也高，你可能运行了过深的竞价，牺牲用户体验换取边际收入。
• 胜出率 — 低胜出率伴随高延迟，通常意味着超时时间太短，竞争性竞价者来不及响应。

常见错误

常见的Slack消息：“延迟看起来不错，平均180毫秒，所以我们可以再加两个竞价者。”先检查p95。如果p95是900毫秒，新增竞价者将使其超过超时时间，你不仅看不到增量收入，还会拖慢每个页面。

降低延迟的杠杆

• 缩短超时时间。 Prebid 和大多数 SSP 允许为每个适配器设置超时时间。从 1000 毫秒缩短到 500 毫秒可直接降低 p95，但可能会丢失一些慢速竞价者。
• 迁移到服务器端竞价。 服务器端头部竞价（例如 Prebid Server、Amazon TAM）消除了客户端瀑布流延迟。代价是对竞价者连接的控制力减弱。
• 减少竞价者数量。 每增加一个竞价者都会增加网络和处理时间。测试边际竞价者是否真的能赢得足够多的竞价，以证明延迟成本是合理的。
• 优化竞价者选择。 根据用户细分的历史胜率使用竞价者“短名单”。不要调用从未在此库存上获胜的竞价者。
• 使用并发竞价。 同时调用所有竞价者的客户端包装器（而不是顺序调用）将瀑布流压缩为一次往返。

增加延迟的杠杆（需谨慎）

• 添加底价或复杂的交易逻辑。 竞价者必须评估的每条额外规则都会增加处理时间。
• 丰富的用户信号。 传递完整的用户 ID、设备图谱或自定义细分会增加请求负载大小和解析时间。
• 多格式竞价。 在同一调用中请求视频、展示和原生广告可能会减慢竞价者决策引擎的速度。

权衡

超时时间与需求深度 是经典的平台权衡。200 毫秒的超时时间可提供出色的用户体验，但可能会排除需要 300 毫秒才能响应的竞价者。1000 毫秒的超时时间可捕获更多出价，但会损害可见度和页面加载。

何时不应追求此指标： 如果您的填充率已超过 95% 且可见度良好，进一步优化延迟可能会因切断有价值的竞价者而减少收入。延迟是一个约束条件，而不是目标。优化到用户体验可接受的程度即可。

拍卖延迟是决定需求深度与用户体验之间权衡的时钟。每个平台决策——超时长度、竞价者数量、服务器端与客户端——都会影响这个数字。

• 关注尾部，而非平均值。 p95和p99揭示了真实情况。
• 将延迟与填充率和胜出率配对。 一个低延迟但未能赢得任何出价的拍卖毫无用处。
• 在用户体验可接受时停止优化。 超过这一点，你就是在用收入换取用户注意不到的毫秒。