程序化策展（Curation）：卖方侧打包数据与库存的新中间层

在程序化广告生态中，传统的角色分工相对稳定：需求方（DSP）、供给方（SSP）、居中的交易市场（Ad Exchange），以及横跨两端的数据管理平台（DMP）。然而，在过去两三年里，一个原本处于边缘的角色逐渐被推到了台前，那就是策展者（Curator）。正因如此，在媒体（Publisher）的投放计划和 SSP 的产品矩阵中，我们越来越频繁地看到 Curation 或 Marketplace 2.0 的身影。

本文是生态与渠道系列的第 2 篇（Marketplace 2.0）。 全系列 4 篇：

程序化广告生态全景

程序化策展（Curation）

零售媒体网络（RMN）

广告出海地区分层

一句话定位：策展（Curation）是在卖方侧将受众数据与库存打包成 curated Deal ID，交由需求方一键激活的新中间层。

需要首先界定的是，策展机制运行在既有的程序化生态之上，它并非一种全新的底层协议。关于生态角色的全景可参考生态全景；广告竞价中 deal 的几种交易模式（RTB / PMP / PD / PG）与 Deal ID 机制详见交易模式；而供应链透明度（schain）的底层逻辑则在专文中有深入探讨。本文将聚焦于探讨「策展」这一层究竟为整个交易链路新增了哪些核心能力。

TL;DR

策展（Curation）：在卖方侧将「受众数据 + 库存 + 规则」打包成一个 curated Deal ID，并交由需求方一键激活；需求方无需在 DSP 中配置复杂的受众定向，即可直接采买这一封装好的流量。
三股力量合流的产物：其一，SPO 促使需求方缩短供应链跳数并寻求可信路径；其二，Cookieless 时代令第三方 cookie 退场，使得数据在卖方侧（第一方或授权数据）激活比在买方侧更为高效；其三，交易 deal 化使得 PMP 与 Deal ID 成为成熟管道，策展仅需向其中注入新的数据组合。
与买方 DMP 定向的根本区别：传统链路中的受众定向在买方（DSP 协同 DMP）完成，而策展则将定向逻辑前置到了卖方（SSP 或 Curator），即卖方侧定向（sell-side targeting），让数据贴着库存流转，而非由买方拿着人群包在全网盲目寻址。
策展者的角色定位：涵盖了 SSP 自带的策展产品、独立策展平台与数据方，以及代理商自建的 curation seat；它介于 SSP 与需求方之间，且通常复用 SSP 的基础设施。
轻量级的协议落点：curated deal 在底层最终表现为 OpenRTB 协议中的一个 pmp.deals[] 条目（包含 Deal ID、底价及内建定向），需求方在 DSP 中直接凭 Deal ID 参与广告竞价，同时在 schain 中通常会新增一跳节点。
核心价值：在 cookieless 环境下提供更优的数据激活方案，构建更短且更可控的供应路径（打包即 SPO），并显著降低需求方的接入成本。
面临的争议：引入了额外的供应链抽成（curation fee 叠加于 ad tech tax 之上），带来了透明度隐患（难以核验 deal 内部的库存与数据质量），并伴随着数据来源与授权合规的风险；其长远发展取决于效率提升是否能覆盖新增的成本。

Open Table of contents

1. 传统链路的痛点：数据在错误的一侧
2. 策展的核心机制：将定向搬到卖方侧
3. 行业爆发的动因：三股力量的合流
4. 协议落点：轻量级的 curated Deal ID
- 4.1 需求方如何解析 Deal ID 背后的定向含义？
5. 核心价值与行业争议：是效率引擎还是供应链抽成
6. 常见误解与技术正解
延伸阅读

1. 传统链路的痛点：数据在错误的一侧

回顾传统程序化广告的受众定向流转过程（正如在生态全景 §4 中探讨 DMP 时所述），其核心逻辑可以概括为以下三个步骤：

需求方首先在 DMP 中圈定目标人群包（例如「近 30 天浏览过运动鞋的用户」）；
随后将该人群包同步并激活至 DSP；
DSP 进而在全网发起实时竞价（RTB），针对每个 bid request 中的用户标识进行比对，若命中人群包则触发广告竞价。

这套机制在第三方 cookie 时代运转良好，但随着行业演进，它正面临两个日益致命的痛点：

Cookie 退场导致匹配率坍塌：需求方的人群包高度依赖第三方 cookie 或设备 ID 来与 bid request 中的用户进行对齐。一旦这些底层标识缺失，人群包在开放网络中的匹配率便会急剧下降，导致 DSP 无法有效识别当前用户（详见后 Cookie 身份层）。
数据与库存的物理距离过远：事实上，真正了解某一块广告曝光（Impression）价值的往往是供给方（包括媒体的第一方数据、上下文语义以及授权的第三方数据）。然而，传统的受众定向却在需求方完成，这种跨越整条交易链路的操作不可避免地带来了巨大的数据损耗。

正因如此，策展机制应运而生。其核心思路在于：既然高价值的数据和库存都沉淀在供给方，那么理应将受众定向的动作也前置到卖方侧来执行。

2. 策展的核心机制：将定向搬到卖方侧

策展层（琥珀色）插在 SSP 与需求方之间：它将受众数据在卖方侧贴附到库存上，并输出一个 curated Deal ID。对比上方那条需求方持人群包全网寻址且在 cookieless 环境下匹配率坍塌的虚线旧路径，策展机制让数据紧贴库存流转，从而避免了需求方的隔空匹配。

深入剖析上述架构图，策展的核心运转流程可以归纳为以下三个关键步骤：

获取受众信号：策展者（Curator）首先汇聚一批高价值的受众信号，这些信号可能源自媒体（Publisher）的第一方数据、经过合规授权的第三方数据，或者是纯粹的上下文（内容语义）特征。
数据贴附库存：随后，在卖方侧（即 SSP 或 Curator 的底层基础设施中），系统将这些受众信号直接应用于特定的广告库存之上，从而精准筛选出符合定向条件的广告曝光（Impression）。
封装交易 Deal：最后，策展者将「经过筛选的库存 + 设定的底价 + 交易规则」统一封装为一个 curated Deal ID，并将其交付给需求方。需求方只需在 DSP 中将该 Deal ID 绑定至具体的投放活动，即可直接采买到已经完成定向的优质流量，彻底省去了自行配置人群包的繁琐步骤。

需要强调的是，这正是 sell-side targeting（卖方侧定向） 的本质所在：受众定向的动作被彻底前置到了供给方，而非由需求方在竞价末端去完成。

3. 行业爆发的动因：三股力量的合流

事实上，策展底层的技术支撑早已存在（PMP 与 Deal ID 均是成熟的机制）。它之所以在近期迅速演变为行业热词，根本原因在于三股核心驱动力在同一时间节点实现了历史性的合流：

驱动力	推动策展演进的核心逻辑
SPO	需求方正大力推进供应路径优化以收敛交易跳数；策展作为一种预先打包且相对可信的供应路径，天然契合了 SPO 的战略诉求。
Cookieless	随着第三方 cookie 与 IDFA 的相继退场，需求方侧的人群包匹配率大幅下滑；将数据前置到卖方侧（依托第一方或授权数据）进行激活，成为了更为可靠的替代方案。
Deal 化成熟	PMP 与 Deal ID 的交易管道已经历了多年的市场验证，底层基础设施极为完善；策展仅仅是向这一成熟管道中注入了「数据 + 库存」的全新组合。

由此可见，策展并未凭空发明全新的底层协议，而是在「数据究竟应在哪一侧激活」这一核心命题上，受制于 cookieless 的行业倒逼而给出了新的解答，并顺势复用了 deal 这条畅通无阻的既有交易链路。

4. 协议落点：轻量级的 curated Deal ID

从底层协议的视角来看，策展机制几乎是完全透明的：它最终仅仅体现为 OpenRTB 协议中的一个 pmp.deals[] 条目。

curated deal 的生命周期：左侧琥珀色面板「① 卖方侧策展（配置期）」自上而下三步——curator 选定受众数据（第一方/授权三方/上下文）、贴到一批库存上筛选、封装成 curated Deal ID（内建定向 + 底价 + 规则）；中间一条粗箭头标注「Deal ID」指向右侧蓝色面板「② 实时竞价（每次曝光）」：SSP 在 bid request 的 pmp.deals[] 里带上这个 Deal ID → DSP 认出它 → 按约定出价（定向已在卖方做过，买方无需再配人群包）；右侧再挂一个小卡片说明 schain 里通常多一跳 curator node；底部注解：和普通 PMP deal 在协议上没有区别，区别只在『deal 里的定向是谁、在哪一侧建的』——买方看到的只是一个 Deal ID 从协议层面剖析，curated deal 与常规的 PMP deal 遵循着完全相同的流转路径：在配置期，策展者于卖方侧将「数据 + 库存」封装为一个 Deal ID；在运行期，SSP 会在 bid request.imp.pmp.deals[] 字段中携带该 ID，DSP 识别后即可按约定参与广告竞价。两者真正的差异不在于协议字段，而在于 deal 内部的定向逻辑究竟由谁、在哪一侧构建。

具体到不同参与方的落点如下：

需求方视角：DSP 系统中仅仅是新增了一个 Deal ID。其出价逻辑与常规 PMP 毫无二致：系统识别 Deal ID、校验 deal.bidfloor（底价），随后完成出价。所有复杂的定向逻辑都被巧妙地隐藏在了这个 deal 背后。
供应链视角：作为交易链路上的新增节点，策展者通常会在 schain 对象中追加一个 node。这也顺理成章地成为了需求方评估「该策展路径是否可信、透明度是否达标」的核心抓手：即能否在 schain 中清晰追溯策展者的真实身份，以及其是否具备规范的 sellers.json 声明。
数据视角：底层的定向逻辑（包括采用了哪些受众信号、具体的匹配算法如何）完全运行在 Curator 或 SSP 侧。由于需求方无法透视这一内部黑箱，这也直接埋下了后文所述「透明度争议」的技术伏笔。

4.1 需求方如何解析 Deal ID 背后的定向含义？

这往往是初学者最容易产生困惑的环节：既然竞价请求中的 pmp.deals[] 仅包含一个简陋的编号与底价，那么需求方究竟是如何得知 12345 这个 ID 代表着「运动鞋意向人群」的？

答案其实非常直接：这种映射关系并非通过实时竞价请求来传递。在协议层，Deal ID 本身是「哑」的，一个典型的 deal 对象结构如下所示：

"pmp": {
  "deals": [
    { "id": "12345", "bidfloor": 18.0, "bidfloorcur": "USD", "at": 1 }
  ]
}

如代码所示，除了编号（id）、底价（bidfloor / bidfloorcur）以及结算方式（at）之外，OpenRTB 协议根本没有预留任何用于描述「定向规则」的字段。单凭这段 JSON 数据，需求方绝对无法推断出 12345 究竟定向了「运动鞋意向人群」还是其他群体。

事实上，deal 的具体含义在实时竞价发生之前就已经完成了同步。在任何一次广告竞价启动前，需求方与供给方必然会经历一个「建 deal 与谈 deal」的筹备阶段（这是一个 out-of-band 的业务层交互，而非竞价协议本身）。deal 的业务含义正是在这一步被确立并传递的，典型的同步渠道主要包括以下三类：

Curator 或 SSP 的策展目录（Marketplace / Deal 目录）：策展者会在平台上列出所有可用的 deal，并附带详尽的业务说明。例如：Deal 12345｜运动鞋意向人群 · 美国 · CTV · 底价 $18 CPM · 数据来源 XX。
DSP 端的 Deal 管理控制台：需求方将获取到的 Deal ID 录入 DSP 系统（许多 DSP 甚至支持直接从 SSP 自动同步 deal 列表与元数据），为其添加易于理解的备注名称，并将其绑定至特定的投放计划（Campaign）。
传统的线下沟通方式：通过一封正式邮件或一份规格说明书（Rate Card），销售人员直接向需求方明确「12345 对应的定向人群与底价标准」。

正因如此，当进入运行期（即每一次广告曝光时），SSP 在 bid request 中只需携带 "id":"12345"；而需求方则依赖其在配置期预先存储的映射关系（12345 → 运动鞋意向人群）来「翻译」这一编号。请求中的 12345 仅仅是一把触发 DSP 查询映射表的钥匙，真正的业务含义早已沉淀在系统内部。

需要警惕的是，这份定向说明本质上只是一种「商业承诺」，而非「可验证的技术事实」。这正是策展机制陷入「黑箱」争议的技术根源：

策展者声称「12345 = 运动鞋意向人群」，但这仅仅是供给方的单方面声明。
需求方无法透视底层逻辑：策展者究竟采用了哪些数据来判定「运动鞋意向」？其匹配算法是否精准？这批库存中是否掺杂了低质流量？无论是底层协议还是 deal 的业务说明，都无法给出确切的答案。
需求方只能依赖事后的间接验证：例如在投放结束后核对转化效果，索取 log-level data 进行深度对账，或者借助 schain 与 sellers.json 来校验供应链路径与策展者身份的合法性。

简而言之，需求方所掌握的仅仅是策展者「声称」的定向规则，而非经过严格核验的客观事实。这也正是下文探讨「透明度黑箱」以及为何「不能仅凭『策展』二字背书」的核心原因。

5. 核心价值与行业争议：是效率引擎还是供应链抽成

关于策展机制究竟是利大于弊还是弊大于利，整个程序化广告行业至今仍争论不休。我们需要从正反两面进行客观审视：

核心价值层面：

Cookieless 时代的破局之道：通过让数据紧贴库存，并在卖方侧利用第一方或授权数据进行激活，策展机制彻底摆脱了需求方侧日益失效的 cookie 匹配链路。
天然契合 SPO 战略：每一个 curated deal 本质上都是一条经过预先打包且相对可信的供应路径，这与需求方极力缩减交易跳数的战略方向高度一致。
显著降低接入门槛：需求方无需再耗费重金自建复杂的底层人群体系，仅需采买特定的 deal 即可轻松获取精准定向的流量；这一特性对中小规模的需求方尤为友好。

行业争议层面：

加剧了供应链抽成：策展者必然会收取额外的 curation fee，这直接叠加在了本已十分沉重的 ad tech tax 之上。如果策展带来的效率提升无法覆盖这层新增的成本，那么该机制便会沦为纯粹的净损耗。
透明度黑箱隐患：需求方采买的虽然是一个封装完美的 deal，但其内部究竟掺杂了哪些底层库存、调用了何种维度的数据、整体流量质量是否达标，往往难以清晰核查。这种不透明性反而给交易链路引入了一个需要盲目信任的黑箱。
数据来源与合规风险：策展者所调用的第三方数据究竟源自何处？其授权链路是否完整且干净？在 GDPR 等全球各地日趋严格的隐私法规框架下，这些数据操作是否经得起审查？这些都是悬在策展机制头顶的合规利剑。

综合来看，将数据贴附于库存的演进方向无疑是正确的；然而，伴随而来的黑箱操作与额外的供应链抽成却难以长久立足。策展作为一种底层能力大概率会沉淀下来，但它必然会被市场倒逼走向全面可核验：即 deal 的内部构成必须可审计、schain 与 sellers.json 必须可追溯、且 curation fee 必须完全透明。这正如供应链透明度运动对整条程序化交易链路所带来的深刻变革一样。

6. 常见误解与技术正解

常见误解	技术正解
策展是一种全新的底层协议或技术	并非如此；它完全复用了既有的 PMP 与 Deal ID 管道，在协议层仅仅体现为一个 `pmp.deals[]` 条目。
策展与需求方在 DSP 中做定向毫无二致	两者的执行位置存在根本差异：策展将定向逻辑前置到了卖方侧（sell-side targeting）。
引入策展机制后便不再需要 DSP	需求方依然需要 DSP 来完成实时出价与预算控制；策展仅仅是前置了定向环节，需求方照样需要在 DSP 中激活 Deal ID。
策展仅仅是 SSP 的另一种包装说法	Curator 可以是 SSP、独立策展平台或数据供应商；它代表的是一种生态角色，而非特指某一类商业公司。
采用策展机制一定能降低投放成本	策展会引入额外的 curation fee；最终是否省钱，完全取决于其带来的效率提升能否盖过这层新增的供应链抽成。
采买 curated deal 即等同于获取了优质流量	Deal 的内部构成往往是一个黑箱，流量质量仍需依赖 `schain` 与底层日志进行严格核验，绝不能仅凭「策展」二字盲目背书。

行业黑话总结：策展（Curation）：在卖方侧打包数据与库存；Curator：执行策展的生态角色；Sell-side targeting：受众定向发生在卖方；Curated Deal ID：策展打包出的交易标识；Curation fee：策展层收取的额外抽成；SPO：供应路径优化；Cookieless：第三方 cookie 退场的大环境。

了解了策展机制如何在卖方侧重塑交易链路后，不妨继续探索整个协议底层的运作细节，详见 OpenRTB 协议精讲。