前面几篇拼出的程序化生态，角色分工相对稳定：买方（DSP）、卖方（SSP）、居中的交易市场、横跨两端的数据层（DMP）。但过去两三年，一个原本边缘、定位模糊的角色被推到了台前——策展者（curator）。在越来越多的媒体投放计划、SSP 产品页与行业讨论里，你都会遇到 Curation / Marketplace 2.0 这个词。
它究竟是又一层营销包装，还是真解决了问题？本文从工程实现与交易结构两个角度把它讲清楚：策展到底是什么、为什么偏偏现在才火、它与买方在 DSP 里做的定向有何本质区别、在 OpenRTB / schain 中如何落到字段，以及它究竟是化解了痛点、还是又叠了一层抽成。
范围划界：策展跑在既有生态之上，不是新协议。角色全景见生态全景；deal 的几种卖法（RTB/PMP/PD/PG）与 Deal ID 机制见交易模式；供应链透明度（
schain）见专文。本文只讲「策展」这一层新增了什么。
TL;DR
- 一句话：策展 = 在卖方侧，把「受众数据 + 库存 + 规则」打包成一个 curated Deal ID，交给买方一键激活。 买方不用自己在 DSP 里配复杂定向，直接买这个「已经调好味的」deal。
- 它是三股力合流的产物：① 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里通常多加一跳 node。 - 价值：cookieless 下更好用的数据激活、更短更可控的供应路径（打包即 SPO）、买方接入成本低。
- 争议：又多了一层抽成（curation fee 叠在 ad tech tax 上）、透明度（deal 里到底混了什么库存和数据？质量能不能核验？）、以及数据从哪来、授权合不合规。它能不能站住，取决于「省下的 > 新增的那层税」。
Table of contents
Open Table of contents
1. 先看老链路的痛点：数据在错误的一侧
回顾传统程序化的受众定向是怎么做的（生态全景 §4 讲过 DMP）：
- 买方在 DMP 里圈好人群包（“近 30 天看过 SUV 的人”）；
- 把人群包同步激活到 DSP；
- DSP 在全网竞价，对每个 bid request 里的用户查「他在不在我的人群包里」，在的就出价。
这套在第三方 cookie 时代跑得通，但有两个越来越致命的问题：
- cookie 退场，匹配崩了。买方的人群包靠第三方 cookie / 设备 ID 去和 bid request 里的用户对齐；这个标识一没，人群包在开放网里的匹配率坍塌，DSP 认不出这个人是谁（详见后 Cookie 身份层）。
- 数据离库存太远。真正了解一块库存的其实是卖方（媒体的第一方数据、上下文、以及授权的第三方数据），可定向却在买方侧做，隔着整条链路，损耗大。
策展的核心洞察就一句：既然数据和库存都在卖方那头，那就把定向也搬到卖方那头做。
2. 什么是策展：把定向搬到卖方侧
策展层（琥珀色）插在 SSP 与买方之间：它把受众数据在卖方侧贴到库存上，输出一个「已经调好味」的 curated Deal ID。对比上方那条虚线旧路径——买方拿人群包去全网找人、在 cookieless 下匹配率坍塌——策展让数据贴着库存走，而不是买方隔空去匹配。
拆开这张图，策展做的事其实就三步：
- 拿到数据：curator 手里有一批可用的受众信号——可能是媒体的第一方数据、授权来的第三方数据、或纯上下文（内容语义）信号。
- 贴到库存上：在卖方侧（SSP / curator 的基础设施里），把这些信号应用到一批库存上，筛出「符合条件的曝光」。
- 打包成 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](/_astro/curated-deal-flow.C-VD1gTn_Z1zXI2V.svg)
从协议看，curated deal 和普通 PMP deal 走的是同一条路：配置期由 curator 在卖方侧把「数据 + 库存」封装成一个 Deal ID，运行时 SSP 在 bid request.imp.pmp.deals[] 里带上它，DSP 认出后按约定出价。差别不在字段，而在这个 deal 里的定向是谁、在哪一侧建的。
几个落点：
- 买方视角：DSP 里多了个 Deal ID，出价逻辑和普通 PMP 一样——认 Deal ID、比
deal.bidfloor、出价。定向的复杂度被隐藏在了 deal 背后。 - 供应链视角：curator 作为链路上新的一手，通常会在
schain里追加一个 node。这也是买方评估「这条策展路径可不可信、透不透明」的抓手——能不能在schain里看清 curator 是谁、有没有sellers.json声明。 - 数据视角：定向逻辑（哪些信号、怎么匹配）跑在 curator / SSP 侧，买方看不到内部——这正是下面「争议」的技术根源。
5. 价值 vs 争议：它到底解决了问题还是加了层税
策展究竟是利大于弊还是弊大于利，业内至今争论不休。这里不做站队，诚实地两面来看：
价值一侧：
- cookieless 下更好的数据激活：数据贴着库存、在卖方侧用第一方 / 授权数据激活，不依赖买方侧那条正在崩的 cookie 匹配。
- 天然的 SPO：一个 curated deal 就是一条「打包好、相对可信」的供应路径，契合买方砍跳数的方向。
- 接入成本低：买方不用自建复杂人群体系，买个 deal 就能拿到定向流量；对中小买家尤其友好。
争议一侧：
- 又多了一层抽成：curator 要收 curation fee，直接叠在本已沉重的 ad tech tax 上。如果省下的效率 < 新增的这层税，策展就是净损耗。
- 透明度黑箱：买方买的是一个「调好味的」deal，但里面到底混了哪些库存、用了什么数据、质量如何，往往看不清。这与整个行业「把信任换成可核验」的方向是拧着的——它反而新增了一个需要信任的黑箱。
- 数据来源与合规：curator 用的第三方数据从哪来、授权链是否干净、在 GDPR/各地隐私法下站不站得住，是悬在头上的合规风险。
关键判断：策展能不能长期成立，取决于它站在历史正确的一侧还是错误的一侧。cookieless 下「数据贴库存」的方向是对的；但「黑箱 + 多一层税」的形态是错的。 大概率的演化是：策展作为一种能力活下来，但会被迫朝可核验（deal 内容可审计、
schain/sellers.json可追溯、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/日志核验，不能只凭「策展」二字背书 |
7. 一张速查表
| 概念 | 一句话 | 关联 |
|---|---|---|
| 策展 Curation | 卖方侧把「数据+库存+规则」打包成 curated Deal ID | §2 |
| sell-side targeting | 定向动作发生在卖方，而非买方 DSP | §2 |
| curator（策展者） | SSP / 独立平台 / 数据方，坐在 SSP 与买方之间 | §2 |
| 三股驱动力 | SPO + cookieless + deal 化成熟 | §3 |
| curated Deal ID | 协议上就是一个 pmp.deals[] 条目，定向已内建 | §4 / OpenRTB |
| schain 多一跳 | curator 作为新一手，通常在 schain 追加 node | §4 / schain |
| curation fee | 叠在 ad tech tax 上的新一层抽成 | §5 |
| 透明度黑箱 | deal 里混了什么数据 / 库存，买方常看不清 | §5 |
一句话收尾：策展是 cookieless 把「数据该在哪一侧激活」的答案从买方推向卖方的结果。 它复用了最成熟的 deal 管道，方向是对的；但它当前「黑箱 + 多一层税」的形态，注定要被行业「把信任换成可核验」的大势往透明的方向推。
延伸阅读
- 程序化交易模式：RTB / PMP / PD / PG：策展复用的 PMP / Deal ID 管道，先读它。
- 程序化广告生态全景：DMP、SPO、ad tech tax——策展的三个背景坐标。
- 后 Cookie 身份层：为什么买方侧人群包会崩，逼出「数据贴库存」。
- 供应链透明度（下）：OpenRTB schain：怎么核验 curator 这多出来的一跳。
- OpenRTB 协议精讲：curated deal 落在
imp.pmp.deals[]的确切位置。
资料：
- IAB Tech Lab. Sellers.json & SupplyChain Object：核验 curator 身份与路径的标准。
- IAB Tech Lab. OpenRTB 2.6 Specification：
pmp/deals[]对象。
附录：术语表
- 策展（Curation）/ Marketplace 2.0：在卖方侧把「受众数据 + 库存 + 规则」打包成 curated Deal ID 的做法。
- curator（策展者）：执行策展的角色，可为 SSP、独立平台或数据方。
- sell-side targeting（卖方侧定向）：受众定向发生在卖方而非买方 DSP。
- curated Deal ID：策展打包出的交易标识，协议上是一个
pmp.deals[]条目。 - curation fee：策展层收取的费用，叠加在 ad tech tax 之上。
- SPO（供应路径优化）：买方收敛供应路径、砍冗余跳数——策展与之天然契合。
- cookieless：第三方 cookie / 设备 ID 退场的大背景，把数据激活推向卖方侧。