你的 DSP 或 SSP 接入联网电视：哪些地方会变，哪些该自己构建

联网电视（CTV）广告是在接入互联网的电视上播放的视频广告，通常出现在流媒体应用里由几条广告组成的广告时段中。为网页和应用横幅广告打造的 DSP 或 SSP，要支持这类广告，需要在四个地方做出改变。竞价请求描述的是一整个广告时段，而不是一个广告位。广告以 VAST 响应的形式到达，这是一份指向视频文件的 XML 文档。许多电视应用无法像浏览器那样请求和跟踪广告，所以由拼接服务把广告放进视频流。随后，这项服务代替电视发送广告请求，往往还代为发送跟踪请求，因此你必须换一种方式来识别设备和统计展示。对广告时段的出价和 VAST 支持值得构建到你自己的平台中。拼接则属于发布商，或者属于专门为这项工作而构建的服务。

联网电视广告有什么不同？

在网站上，一个广告请求通常为一个广告位请求一条广告，由浏览器加载这条广告并上报展示。在电视上，观众在流媒体应用里观看节目，广告则像传统广播电视那样成段出现。维护 OpenRTB 竞价协议的机构 IAB Tech Lab 把这样的广告时段称为 ad pod：一条或多条“在视频或音频内容流中连续播放”的广告。

IAB Tech Lab 的 OpenRTB 2.6 规范把 2.6 版描述为“为 CTV 交易引入 Ad Pod”的版本。本文依据的是这份规范以及 IAB Tech Lab 为它编写的实施说明，与本文其他来源一样，均于 2026 年 11 月 2 日查阅。

广告时段以什么形式出现在竞价请求中？

在 OpenRTB 2.6 中，一个时段在竞价请求中以一个或多个展示对象（impression object）的形式出现，podid 相同的展示对象属于同一个时段。实施说明描述了三种时段：

• 结构化时段：卖方事先确定广告位的数量、顺序和每个广告位的时长，每个广告位都是一个独立的展示对象
• 动态时段：卖方确定总时长和广告数量上限，但不固定广告的具体条数，也不固定每条广告的时长，整个时段可以作为单个展示对象到达
• 混合时段：时段的一部分是固定的，一部分是动态的

大多数横幅广告平台从来不需要读取下面这些字段：

• poddur，即广告主在一个动态时段中可以填充的总秒数；以及 maxseq，即该时段最多可容纳的广告条数
• rqddurs，即一份精确广告时长的列表。规范说，它是为直播电视准备的，“在这种情况下，不精确的广告时长会造成不希望出现的‘空播’”
• slotinpod，表示卖方能否保证第一个或最后一个位置；以及 podseq，即该时段在节目中的位置
• mincpmpersec，即时段动态部分中每秒广告时长的底价

每个出价都在 dur 字段中写明其广告的时长。实施说明还指出，买方“应当预期最终的 pod 组建由卖方完成”。如果你为一个时段发送了多个出价，卖方可能使用其中任意数量，从一个都不用到全部使用，并把它们与其他买方的广告混在一起。

每个出价都要附上广告主的域名（adomain）和素材的 ID（crid）。规范把这两者列入用于“广告质量检查或执行发布商限制”的属性。

对 DSP 来说，广告时段改变了出价逻辑。横幅广告的出价方一次为一个展示定价。CTV 出价方则要选出自己哪些广告能放进时段剩余的时间，并按秒为它们定价，而且它无法控制卖方会保留其中哪些。

VAST 响应必须包含哪些内容？

视频广告通过 VAST 投放，IAB Tech Lab 把 VAST 描述为“一种用于向数字视频播放器投放广告的通用 XML 模式”。它的 VAST 页面最后更新于 2024 年 7 月，将 2022 年 12 月发布的 VAST 4.3 列为最新版本。IAB Tech Lab 在 GitHub 上的 VAST 4.x 代码仓库中还有 VAST 4.4，那里的一条维护者说明称它于 2026 年 7 月 22 日发布。VAST 4.4 增加了暂停广告和屏保广告等 CTV 格式。下文的引文均出自 VAST 4.3。

2024 年 7 月，IAB Tech Lab 还发布了一份 CTV 附录，把 VAST 4 的素材 ID 和夹层文件（mezzanine file）引入较早的 VAST 2 和 3。该附录指出，这些较早的版本“至今仍主导着市场”。

在电视上，VAST 中最重要的是两部分：

• 夹层文件（mezzanine file），即“原始的高质量视频文件”，发布商的系统用它为每种屏幕制作相应的版本。VAST 4.3 指出，夹层文件“在广告拼接的执行中是必需的”，拼接服务可能会拒绝不带夹层文件的响应
• UniversalAdId，一个在系统之间始终跟随素材的标识符。VAST 4.3 要求线性广告（即在节目中间播放的那种广告）必须带有它，CTV 附录则以扩展的形式把它加入 VAST 2 和 3。拼接服务用它来判断某条素材是否已经转换过

在 VAST 4.3 描述的拼接流程中，拼接服务从未见过的素材必须先经过转换才能播放，所以该时段会播放另一条广告来代替它。VAST 4.3 指出，夹层文件的首次下载“可能需要数小时”。AWS 为 MediaTailor（它把广告拼接进视频流的云服务）描述了同样的规则：“如果某条广告尚未转码以匹配内容，MediaTailor 将跳过插入它”，这条广告则会被准备好，供下一次请求使用。

因此，一条新素材在每个拼接服务上都可能错过最初几次播放机会。VAST 4.3 指出，素材只要有任何改动，就应当获得新的标识符。素材本身没有变化时，不要更改标识符，这样每个拼接服务只需转换它一次。

对于验证代码，VAST 4.3 推荐使用 Open Measurement（OMID），并“强烈反对使用 VPAID”，VPAID 是在视频广告内部运行代码的旧方式。它把 SIMID 列为互动广告中 VPAID 的替代方案。VAST 4.3 把互动代码与视频文件分开，这样与拼接服务配合工作的播放器即使无法运行代码，也仍然可以播放视频。要确保每条电视素材都能作为普通视频正常播放。

当服务器把广告拼接进视频流时，会有哪些变化？

许多电视应用无法像浏览器那样请求和跟踪广告。VAST 4.3 描述了另一种方式，称为服务端广告插入（SSAI）或广告拼接。应用向拼接服务请求视频流，拼接服务向广告服务器请求广告，广告被拼接进内容，这样观众收到的是“一条连续的流”。

OpenRTB 2.6 在展示对象中加入了 ssai 字段，用来说明拼接和跟踪有多少是在服务器上完成的。它的取值从“全部在客户端”到“全部在服务端”。在中间那种情况下，视频在服务器上拼接，跟踪像素则由设备触发。默认值 0 表示状态未知，所以不带这个字段的请求，在这一点上什么也说明不了。

当广告请求和跟踪请求都来自服务器时，许多观众看起来像是共用同一个 IP 地址。VAST 4.3 警告：“对于正在接收跟踪信息的广告服务器来说，这些报告看起来与无效流量相似。”它规定，拼接服务提供方必须在跟踪请求中通过 X-Device-IP 和 X-Device-User-Agent 两个请求头发送设备的 IP 地址和 user agent，而且这些值必须与原始广告请求中的值一致。

对你的平台来说，这意味着：

• 当流量经由拼接服务到达时，要从这些请求头和竞价请求中获取设备信息。此时连接到你的 IP 地址属于拼接服务，所以不要把它当作设备的 IP 地址
• 对于不带 X-Device 请求头到达的服务端流量，要向卖方问明情况
• 核实卖方是否列在发布商的 app-ads.txt 文件中。IAB Tech Lab 的规范把 ads.txt 扩展到了来自“联网电视应用商店”的应用
• 频次上限和受众要基于设备 ID。VAST 4.3 指出，拼接服务“无法访问 cookie”。在 OpenRTB 2.6 中，ifa 字段携带一个广告 ID，预期它来自设备的操作系统；lmt 字段则表明何时必须限制跟踪

展示如何统计和计费？

OpenRTB 的实施说明比较了统计可计费事件的几种方式。对于音频和视频，它们推荐使用 VAST 的展示（impression）事件。计费通知 URL（burl）对横幅广告很好用，但“不推荐用于音频/视频”。

实施说明还建议出价方跟踪竞价与计费通知之间的延迟，因为花费目标、频次上限和预算平滑都取决于它。在实施说明的合理延迟表中，采用服务端拼接的音频或视频那一行写的是“非常长或未知”。

通过 exp 字段，卖方在请求中说明竞价与展示之间最多可以间隔多少秒，买方则在出价中说明自己愿意等待多少秒。这两个值都只是建议性的。实施说明提醒出价方，不要以为在其出价的 exp 之后才到达的计费通知就不会被计费，因为这取决于与广告交易平台签订的合同。

服务端拼接并没有改变统计规则。VAST 4.3 引用了 IAB 与媒体评级委员会（MRC）共同制定的测量指南：“测量指南要求广告计数采用由客户端发起的方式”。同一段落允许在服务器上计数，“只要计数是基于客户端事件和测量资源发起的”。它不认可由服务器自行启动的计数，因为那种方式“离用户真正看到广告最远”。要问每个卖方：当广告由服务器拼接时，是哪个事件启动了它的展示计数。

哪些该自己构建，哪些已有合作伙伴处理？

CTV 体系中有些部分属于发布商，或属于专为发布商构建的服务。拼接本身就是其中之一。以 MediaTailor 为例，它把观众的信息发送给广告决策服务器，从广告服务器的响应中接收选中的广告，并把它们拼接进视频流。把视频文件转换成每个发布商所需的格式，也属于同一项工作。

另一些部分决定你的平台能赚多少钱，这些值得你自己构建：

• DSP 方面：选出能放进时段的广告，并按秒定价
• DSP 方面：在计费通知迟到时做预算平滑
• DSP 方面：投放带有夹层文件的素材，并附上只在素材本身变化时才改变的素材 ID，放在 VAST 4 的 UniversalAdId 元素中，或放在 CTV 附录为 VAST 2 和 3 提供的扩展中
• SSP 方面：用多个买方的出价组建每个时段，并执行发布商关于哪些广告主可以出现的规则
• SSP 方面：把 pod 字段和 ssai 值传给每个买方
• 两者都需要：从 X-Device 请求头中读取设备信息，并过滤无效的服务端流量
• 两者都需要：以买方和审计方都认可的方式统计展示

如果一家 DSP 只想试一试自己的广告主是否需要 CTV，可以先从一两家已经在销售 CTV 的 SSP 起步，并先对结构化时段出价。问问这些 SSP，它们的 CTV 库存中有多少是以动态时段的形式提供的，因为实施说明鼓励卖方尽可能提供动态 pod。直播电视要求精确的广告时长，可以等到第一批广告活动表明广告主确实需要时再做。

当 CTV 在你的收入中长期占有一定份额时，就把上面清单里的所有内容都自建起来。如果你自己与电视发布商谈交易，或者某个合作伙伴处理广告时段的方式一再决定你的哪些出价得以播出，也同样如此。

该问为我们的平台加入 CTV 的公司哪些问题？

• 系统会读取哪些 OpenRTB 2.6 pod 字段，又如何为动态时段选择广告？
• 系统如何按秒为出价定价，是否遵守 mincpmpersec？
• 我们的素材将使用哪些 VAST 版本，夹层文件从哪里来？
• 我们的素材会带有已注册的 UniversalAdId，还是默认值“unknown”？
• 系统如何处理服务端流量，又从哪里获取设备的 IP 地址和 user agent？
• 每个卖方的展示是如何统计的？
• 当计费通知到得非常晚时，预算平滑如何保持准确？
• 我们先和哪些合作伙伴测试，哪些功能可以以后再做？

amBrain 在其中处于什么位置？

在 AdTech 领域，amBrain 从事 DSP 开发、实时竞价平台和广告交易平台工程方面的工作。它的服务清单上有两句是这样写的：“amBrain 为发布商构建供应方平台（SSP）。”以及“amBrain 构建广告服务器：定向、频次控制和报表。”RTBBidder 是 amBrain 为一家客户开发的需求方平台。

amBrain 自 2019 年起开发软件。它有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”

本文不是案例研究。除了提到 RTBBidder 的名字之外，本文不描述任何客户项目：本文并未声称 amBrain 为任何平台加入过联网电视支持，也不给出关于 RTBBidder 的任何数字，不给出 amBrain 的任何价格或工期。IAB Tech Lab 和 AWS 的内容引自它们自己的文档，本文并不声称 amBrain 与其中任何一方有任何关系。如果 amBrain 在你的候选名单上，就向它提出与其他任何公司同样的问题。