SSP Yield 深挖：底价、流量分层与收益优化

媒体（Publisher）接入 SSP、Header Bidding 或聚合平台之后，随之而来的核心诉求往往是：如何将同一份广告库存卖出更高的价格，同时又不会导致填充率断崖式下跌。在广告技术领域，这被称为收益管理（Yield Management）。需要强调的是，收益优化绝非简单地将 bidfloor 向上调高几个量级。粗暴地抬高底价会直接将需求方（Demand Side）拒之门外；而如果流量分层策略出现偏差，则极易导致优质流量被贱卖。此外，若动态底价策略的训练样本存在偏差，昨天看似完美的「最优 floor」，今天可能正在悄无声息地造成收入流失。

正因如此，站在 SSP 或媒体 Ad Ops 工程侧的视角来看，评估一次广告曝光（Impression）到底该卖多少钱，必须以最终的实际收入作为验收标准，而不是仅仅盯着名义上的 eCPM。

本文是 卖侧竞价与决策 系列的第 4 篇（收益优化）。 全系列 4 篇：

1. Header Bidding：Prebid 客户端与服务端架构解析
2. 媒体 Ad Server 深挖
3. 多交易所接入工程清单
4. SSP Yield 深挖

一句话定位：聚焦供给方如何科学地为库存定价与分层，从底价策略到多链路对齐，系统解析收益优化的工程落地与排障逻辑。

需要说明的是，本篇的范围划界主要集中在供给方（Supply Side）如何给广告库存定价与分层。关于拍卖漏斗里 floor 的具体位置，请参考拍卖机制；Header Bidding 与 Ad Server 的决策流程，详见 HB 与 媒体 Ad Server；App 端的多源接入方案，请见对接 Vungle / Pangle / Mintegral；而需求方（Demand Side）的选路逻辑则在 SPO 中有详细探讨。本文不会过度展开 DSP 的 Bid Shading 机制。

TL;DR

• 收益管理的核心目标：Yield 优化的终极指标是整体收入，而非单一的名义 eCPM。其底层逻辑为 (\text{Revenue} \approx \sum (\text{clearing price} \times \text{sold impressions}))。盲目抬高单价往往会扼杀填充率（Fill Rate），导致总账出现负增长。
• 底价策略三件套：主要包括 Hard Floor（低于底价直接出局）、Soft Floor（二价拍卖时代的遗产，在一价拍卖下应尽量弃用）以及 Dynamic Floor（基于上下文预估「刚好能成交的最高底价」）。在 OpenRTB 协议中，这些策略最终落点于 imp.bidfloor 与 deals[].bidfloor。
• 样本偏差与自我实现：动态 floor 的核心风险在于样本偏差。过高的 floor 会筛掉低价成交记录，导致历史清算价在统计上被「人为抬高」，系统若据此继续抬高 floor，便会陷入「越优越空」的自我实现螺旋。
• 流量分层（Tiering）：分层的核心诉求是「优质流量护盘、长尾库存清仓」。相关的分层标签必须在竞价发生前打上，并完整记录到日志中，否则后续的 A/B 实验将完全无法归因。
• 多链路底价对齐：两条典型的卖侧链路都必须严格对齐 floor。在 Web 端，需要确保 Prebid floors 与 GAM 价格线及 hb_pb 分桶保持一致；在 App 端，则需确保 TopON 的统一地板与各源 Adapter 的价格口径严丝合缝。
• 科学的验收指标：评估策略效果时，必须综合考量 Revenue、Fill Rate 以及 Floor Pass Rate，在 A/B 测试中坚决禁止只盯成交 eCPM。

Table of contents

1. Yield 到底在优化什么

虽然供给方常以有效千次展现收入（eCPM）来衡量流量价值，但从全局优化的角度来看，系统的决策目标应当是特定时段内的总收入或利润，而不是单独追求名义上的高单价。

在实际的竞价链路中，每一次广告曝光机会通常会面临三种结局：

为了更直观地理解不同策略带来的影响，我们可以进行一组直觉对照：

我们可以通过一组简单的示意数据（假设同量级机会为 1000 次），来看看不同策略对最终收入的实际影响：

尽管上述数字仅为示意，但其揭示的结论却非常稳定：「eCPM 最好看」的那一档策略，往往并不是总收入最高的最优解。如果数据看板仅仅按照 eCPM 进行排序，运营团队极易被优胜者偏差所误导，从而做出损害整体收益的决策。

正因如此，一个优秀的 Yield 策略，其核心价值在于：既能确保价值 $20 的曝光机会极少以 $5 的低价被贱卖，又能保证那些只值 $2 的长尾曝光，不会因为一个高达 $8 的全局 floor 而白白流失。

2. 底价：从静态旋钮到动态策略

2.1 OpenRTB 里的两个 floor

在 OpenRTB 协议中，底价主要通过以下两个字段进行传递：

• imp.bidfloor 配合 bidfloorcur：用于设定公开竞价（Open Auction）的基础底价。
• deals[].bidfloor：用于指定某笔 PMP/Deal 交易的专属底价，该价格通常会显著高于公开竞价的底价。

在实际流转中，当需求方平台（DSP）命中特定的 deal 时，系统会优先应用 deal floor；若未命中，则回退使用公开 floor。正如在拍卖机制漏斗的第二层所揭示的那样，任何低于 hard floor 的出价都会被直接剔除，根本无法进入后续的排序环节。

2.2 Hard / Soft / Dynamic

相较于静态配置，动态 floor 能够根据丰富的上下文特征进行实时调整。其依赖的典型特征包括：

• 广告版位与形式（例如，激励视频与普通 banner 的价值差异往往高达一个数量级）
• 设备属性、地域分布与时段特征的交叉组合
• 历史清算价的统计分布（这里通常采用分位数，而不是容易被极端值拉扯的均值）
• 实时竞争强度（如 Header Bidding 的并行报价数量、参与 Bidding 的竞价源总数）
• 广告曝光（Impression）可见性与品牌安全预估得分
• 当前流量是否属于 deal 范畴

动态 floor 的输出直觉非常明确：「再高一点就会导致流拍，再低一点就会把利润拱手让给需求方」。

2.3 和买方 Bid Shading 的对偶

在全面转向一价拍卖（First-Price Auction）的世界里，需求方与供给方（DSP & SSP）的博弈变得更加直接：

• **供给方（Supply Side）**通过动态 floor 来预测「需求方最高愿意支付多少」，从而伺机抬高底价；
• **需求方（Demand Side）**则利用 Bid Shading 算法来预测「赢得这次曝光最低需要多少钱」，从而尽可能地压低出价。

需要强调的是，这两套机制都在贪婪地吞噬历史清算价数据。当 Yield 引擎调整了 floor，必然会改变需求方所观察到的竞价环境，进而触发其 Shading 策略的连锁反应。正因如此，市场是高度耦合的。在 floor 发生突变后，必须留出足够的观察窗口，切忌仅凭策略上线第一小时的 eCPM 表现就草率地下定论。

2.4 Floor 在 Web：Prebid ↔ GAM

在 Web 端的变现场景中，Prebid floors 会在竞价请求进入 Ad Server 之前进行第一轮价格过滤；随后，GAM 内部还会施加 Unified Pricing Rules 或 Line Item 级别的价格门槛。这两层机制如果配合不当，极易出现「打架」的症状：

• 市场（如 HB）虽然报出了 $12 的高价，但由于 hb_pb 分桶过粗，或者 Price Priority Line Item 的设置无法精准承接，最终导致报表上看似有竞价，但实际收入并未落地。
• Prebid floor 设置得极低，而 GAM 的有效门槛却非常高。这会造成前端看似竞争异常激烈，但决策层最终依然面临大量空仓的窘境。

为了避免上述问题，工程团队必须严格核对以下清单：

1. 确保 Prebid 与 SSP 侧的 bidfloor 设置逻辑一致。
2. 保证 hb_pb 的分桶粒度与 GAM Line Item 的价格区间能够一一对应。
3. 明确 Deal floor 与公开 floor 之间的优先级语义，避免高价公开竞价被低价 deal 意外截流。

2.5 Floor 在 App：TopON ↔ 各源

在 App 端的多源对接架构中，TopON 等聚合平台通常允许在广告位维度设定统一地板价，然后再向下分发给 Vungle、Pangle、Mintegral 等不同的竞价源。在此过程中，必须警惕以下风险：

• 各个竞价源返回的价格究竟是净价还是毛价？在进行比价前，必须统一折算为「媒体实收」口径。
• 当 Bidding 实时出价与传统瀑布流的历史 eCPM 进行混合比价时，floor 必须作用在同一把标尺上，否则会导致优选逻辑彻底失效。
• 某些竞价源在自身后台还隐藏了额外的 floor 设置。此时，聚合层的「统一地板」极有可能被架空。因此，必须仔细核对各源的官方文档与后台配置，确保链路贯通。

3. 动态 floor 怎么估：方法、反馈与偏差

3.1 从简到繁的三条路

在工程实现上，动态 floor 的预估方案通常会经历从简单到复杂的演进：

对于刚起步的团队，最实用的基线方案是：在完成流量分层后，对每一层提取历史成交价的特定分位数（例如 p60）作为基准 hard floor，随后再根据时段特征进行微调。

3.2 自我实现螺旋（最重要的统计坑）

在动态估价的过程中，最致命的统计陷阱莫过于「自我实现螺旋」。其恶化流程通常如下：

1. 系统初步抬高 floor，导致低出价的需求方直接出局。
2. 留存下来的成交样本全部变成了高价记录。
3. 算法继续使用这些被截断的高价样本去预估所谓的「市场价」，并进一步抬高 floor。
4. 最终导致填充率持续暴跌，但看板上的 eCPM 却依然显得异常漂亮。

为了缓解这一致命偏差，工程侧必须引入以下干预机制：

• 估价模型必须摄入完整的尝试日志（Attempt Log），即包含那些未成交或被 floor 拦截的原始出价，绝不能仅仅依赖最终的成交价。
• 必须在系统中保留一定比例的低 floor 甚至无 floor 的 Holdout 流量，以此来探测并校准真实的全局需求曲线。
• 为 Floor Pass Rate 设定硬性下限。例如，当该指标跌破 35% 时，系统必须触发自动回撤机制。
• 在选取分位数时，切忌盲目追求 p80 甚至更高的激进水位，除非你确信该分层下的需求方出价深度足以支撑这种榨取。

3.3 时间窗与季节性

广告交易市场具备极强的时间周期性。如果简单地用「上周六」的数据去预估「本周二」的底价，必然会导致严重的错价。

• 在电商大促期间，或者 App 获得应用商店推荐位而迎来流量爆发时，整体清算价分布会发生剧烈的平移。此时，floor 策略必须接入事件日历，或者切换到更敏捷的近线更新模式。
• 更新频率的把控同样是一门艺术：更新过慢会导致底价滞后于市场真实水位；而更新过快则会引发策略剧烈抖动，导致需求方侧的 Shading 算法无法稳定收敛，最终破坏整体的竞争生态。

根据一线实战经验，推荐的更新区间为：对于核心流量，采用近线 5～30 分钟的滚动窗口更新 floor；而对于稀疏广告位，则应适当拉长观察窗，或者果断回退到更粗的父层级（例如从广告位回退到版位，甚至应用级默认底价）。

3.4 稀疏库存

当面对长尾 Placement 且样本量不够时，绝不能强行应用高颗粒度的动态估价：

• 应当采用**向上回退（Backoff）**策略，借用更粗层级的统计分位数来兜底。
• 或者将特征相似的广告位进行 Pooling，合并计算以扩充样本池。
• 坚决禁止对样本量过小的细分桶单独执行激进的抬价策略，否则极易引发断崖式的收入损失。

4. 流量分层：护盘与清仓

4.1 分层长什么样

流量分层（Traffic Tiering）的核心逻辑在于差异化运营，其本质是「优质流量护盘、长尾库存清仓」。一个典型的三层架构如下：

在构建分层体系时，维度的组合应当遵循从稳健到激进的递进原则：

1. 广告位与广告形式：这是最稳健的物理隔离维度。
2. 设备属性 × 地域分布 × 时段特征：用于捕获用户维度的价值差异。
3. 可见性与品牌安全分数：依赖实时预估模型，能够精准提纯优质库存。
4. 历史 eCPM 分位：风险最高，极易引发自我实现偏差，因此仅建议作为辅助维度。

4.2 工程要求

为了确保分层策略能够精准落地并具备可观测性，工程侧需要满足以下硬性约束：

• 分层标签必须在流量进入拍卖引擎之前打上，并确保完整写入每一条竞价日志。否则，后续根本无法进行「层级 × floor × 收入」的精细化归因分析。
• 当客户端改版或切换 Ad Unit 时，必须同步迁移后端的流量分层表。如果任由旧 ID 掉入默认层，往往意味着流量正在被静默贱卖，或者直接面临大面积空仓。
• 分层粒度应当遵循「先粗后细」的原则。在绝大多数场景下，划分 3 层已经完全够用；如果盲目扩张到上十层，只会导致每层的样本极度稀疏，进而引发策略的剧烈抖动。

4.3 Deal 层与公开层

在处理 PMP 交易与公开竞价的协同关系时，底价的设定必须层次分明：

• Deal floor 的核心使命是保护已经谈妥的优质供给，并维护与核心客户的商业关系。
• 公开 floor 则主要负责消化剩余库存，并在开放市场中持续发现真实价格。

需要特别警惕的是，绝不能将公开 floor 激进地抬高到全面超越 deal floor 的水平。一旦发生这种情况，deal 交易将彻底丧失除「优先供给」之外的价格优势。这不仅会严重挫伤核心需求方的积极性，更会迫使他们利用 SPO 策略去寻找更短、更廉价的交易链路，最终导致优质预算的全面流失。

5. 和卖侧决策链路怎么咬合

5.1 Web

在 Web 端的变现架构中，一次完整的请求流转如下：

请求
  → 附加分层标签 / 计算动态 floor
  → Prebid 或 SSP 扇出（触发 floors 模块进行价格过滤）
  → 进入媒体 Ad Server（在保量订单与 price priority 之间进行博弈）
  → 决出胜者（高价成交 / 空仓 / 展现 house 广告）
  → 竞价日志回灌

在这条复杂的链路中，有三个关键节点必须严密对齐，否则极易造成收入漏损：

1. HB 最高出价 vs 动态 floor：如果系统设定的 floor 盲目高于全场真实的最高出价，必然会导致大量请求直接沦为空仓或被迫展现廉价的 house 广告。
2. 僵尸保量订单的优先级侵占：必须警惕那些早已完成进度但依然占据高优先级的保量订单，它们会无情地截走原本可以高价成交的 HB 请求（具体机制详见 Ad Server 篇）。
3. 价格分桶与 Line Item 的映射错位：如果 hb_pb 的分桶粒度与 GAM 中配置的 Line Item 无法精准咬合，那么即便前端拿到了高价，这个价格也无法顺利进入最终的决策层。

5.2 App（TopON）

相比于 Web 端，App 端基于 TopON 等聚合平台的流转链路则呈现出另一番景象：

请求
  → 触发 TopON 广告位策略（应用统一地板或分段底价）
  → 并行发起 Vungle、Pangle、Mintegral 等多源竞价
  → 将实时 Bidding 价格与传统瀑布流的历史 eCPM 进行混比
  → 广告展示 / 触发回调
  → 聚合层、源侧与媒体侧进行三角对账与日志回灌

在 App 聚合场景下，Yield 优化的抓手通常表现为：广告位的统一 floor 设置、各竞价源的流量权重分配、Bidding 的超时窗口控制，以及至关重要的混比价格口径对齐。关于超时控制与比价尺度的深入探讨，详见对接文的相关章节。

需要特别提醒的是，在引入新的竞价源并准备放量之前，必须严密监控该源在目标流量分层上的 Floor Pass Rate 以及实际带来的增量收入。切忌陷入「又多接了一家源，收入肯定会涨」的盲目乐观之中。

6. 工程落地：闭环、实验与指标

6.1 最小闭环

要让 Yield 引擎真正运转起来，工程团队必须构建一个严密的反馈闭环：

1. 离线分析：按流量分层聚合历史清算价与完整的尝试日志（Attempt Log），通过分位数计算或模型推理，生成候选的 floor 策略表。
2. 近线分发：将候选表编译为 SSP、TopON 或 Prebid 可识别的配置格式，并实现分钟级的动态下发。
3. 在线执行：实时请求获取对应的 floor，将其写入竞价请求或用于过滤无效 bid，最终完成拍卖决策。
4. 日志回灌：完整记录最终成交价、因未过 floor 而被拦截的最高出价、超时事件、no-bid 原因以及精确的分层 ID，为下一轮离线分析提供弹药。

6.2 A/B 怎么做才不算自欺

在验证收益优化策略时，实验设计的严谨性直接决定了结论的可靠性：

这里有一个极其经典的指标误读案例：「实验组的 eCPM 暴涨了 18%，但总收入却下跌了 6%」。面对这种数据，正确的决策应当是判定实验失败，或者迅速缩小抬价的流量范围，而不是被 eCPM 的虚高蒙蔽双眼，盲目推向全量。

6.3 看板最小集

为了实时监控 Yield 引擎的健康度，数据看板必须包含以下最小指标集：

7. 生产案例

为了更直观地展示 Yield 优化的实战威力与潜在风险，我们复盘几个典型的生产案例：

案例 A：全站盲目抬 floor，eCPM 创新高，总收入却跌入负值。 某媒体将全局 floor 从 $1.2 激进地上调至 $2.5。表面上看，开放竞价的 eCPM 数据极其亮眼，但 Fill Rate 却惨遭 18% 的断崖式下跌。最终，工程团队紧急介入，将策略调整为：Tier A 核心流量维持 $2.5 的高底价，而 Tier C 长尾流量迅速回撤至 $0.8，整体收入才得以艰难回正。这个血的教训告诉我们：必须先做好流量分层，然后再谈精细化抬价。

案例 B：动态 floor 陷入「越优越空」的死亡螺旋。 某算法团队在预估动态 floor 时，仅仅使用了历史成交价来计算 p70 分位数。运行三个月后，核心广告位的 Floor Pass Rate 暴跌至 25%，大量优质流量白白流失。直到引入了 Holdout 机制并摄入完整的尝试日志（Attempt Log）后，策略才得以平稳回撤。这再次印证了：任何动态估价模型，都必须在机制设计上严防自我实现偏差。

案例 C：前端 HB 竞价异常热闹，GAM 报表却颗粒无收。 排障发现，前端 hb_pb 是按照 $0.10 的精细粒度进行分桶的，但后端的 GAM Line Item 却是按照 $0.50 的粗放粒度建立的。这导致大量处于中间价位的竞价请求直接落空。需要强调的是，前端的 floor 过滤仅仅是上游防线；决策层的价格分桶对齐，同样是 Yield 优化不可或缺的一环。

案例 D：App 端接入全新竞价源，eCPM 飙升但财务对账彻底混乱。 业务团队在未统一比价口径的情况下，直接将新源返回的毛价（Gross Price）混入了以净价（Net Price）为主的传统瀑布流中。这导致聚合层频繁优选出所谓的「假高价」，不仅扰乱了正常的竞价生态，更让后续的财务对账陷入混乱。切记：在比价尺子完全统一之前，绝不要轻易下达任何 Yield 优化结论。

8. 常见误区与正解

Yield 调优口诀：Yield 的本质是收入最大化，而非单纯抬高 bidfloor；一价时代应果断弃用 Soft floor，全面拥抱 Hard 与 Dynamic floor；流量分层务必先粗后细，切忌过度细分引发策略抖动；估价模型必须摄入未成交需求，严防自我实现螺旋；前端 HB 赢价只是起点，必须穿透 Ad Server 决策与计费链路；动态 floor 上线后需严密监控 pass rate 与模型漂移；切勿被虚高的 eCPM 蒙蔽，Fill Rate 与最终 Revenue 才是试金石。

理解了供给方如何通过底价与分层榨取流量价值后，我们不可避免地要面对需求方（Demand Side）的反制措施。在下一篇供应链优化 SPO 中，我们将深入探讨需求方如何通过收敛交易路径，与供给方的 Yield 策略展开激烈的对偶博弈。

延伸阅读

• 本站. Header Bidding：Prebid.js vs Prebid Server：深入解析 floors 模块与 hb_pb 分桶机制。
• 本站. 媒体 Ad Server 深挖：探讨 price priority 与 dynamic allocation 的底层逻辑。
• 本站. 对接 Vungle / Pangle / Mintegral：详解多源超时控制、混比尺子与 TopON 统一地板。
• 本站. 拍卖机制与 Bid Shading：剖析 floor 在拍卖漏斗中的位置及需求方对偶策略。
• 本站. 程序化交易模式：对比 deal floor 与公开 floor 的优先级差异。
• 本站. 供应链优化 SPO：揭示需求方收敛路径的逻辑，及其与供给方 yield 的对偶博弈。
• IAB Tech Lab. OpenRTB 2.6：官方协议中关于 bidfloor 与 deals[].bidfloor 的规范定义。
• Prebid.org. Floors Module：Prebid 官方关于底价模块的工程实现文档。
• Google Ad Manager Help. Unified pricing rules：GAM 统一价格规则配置指南。