CTV / OTT 与 SSAI：大屏程序化插播与变现解析

App 广告 SDK 探讨的是手机进程内的变现扳机。尽管大屏生态同样属于「端上变现」，但其面临的约束条件却截然不同：遥控器交互、客厅场景、长内容流、稀缺的贴片库存以及高度稀疏的身份标识。业内通常将这一领域统称为 CTV / OTT。在实际工程落地中，开发者最常遇到的技术瓶颈往往不是「如何再接入一家需求方平台（DSP）」，而是广告究竟应该在客户端进行插播，还是在服务端直接缝合进视频码流（SSAI）。更为棘手的是，当广告缝合进码流之后，后续的信标追踪、合约履约以及频控策略还能否准确对账。

正因如此，本文将站在媒体（Publisher）、视频平台以及供给方平台（SSP）的工程视角，深度解析大屏广告的插播、交付与对账机制。我们将详细探讨一次中插广告（mid-roll）究竟在哪一层被决策、插入、测量与计费，并解答当遇到「名义 eCPM 很高，但实际却出现 under-delivery 或黑帧」时，应该如何进行全链路排障。

本文是 端上变现 系列的第 5 篇（大屏通道）。 全系列 6 篇：

1. App 广告 SDK 深挖
2. 广告 SDK 隐性成本
3. 广告 SDK 接入实战
4. OEM 系统广告
5. CTV / OTT 与 SSAI
6. Web 变现深挖

一句话定位：站在媒体与 SSP 的工程视角，深度解析大屏广告的插播、交付与对账机制，拆解 CSAI 与 SSAI 的架构选型及排障链路。

范围划界：本篇聚焦大屏如何插播与交付。交易模式为何偏向 PG/PMP 请参见交易模式 §8.1；VAST 播放链路详见 VAST / MRAID 渲染；可见性口径参考广告形式与 MP4 faststart；供应链核验机制见 app-ads.txt。本文不展开探讨具体的 OEM 开机广告（详见 OEM 系统广告），也不会深入某一家 Smart TV OS 的私有 SDK 细节。

TL;DR

• 工程四层模型：在工程实现上，必须明确区分设备层（谁在播）、应用层（谁分发）、码流层（播什么）以及插播层（何时卖）。虽然业务上可以混称 CTV / OTT，但在排障时绝不能混淆层级。
• 稀缺打断售卖：大屏售卖的核心是时间线上的稀缺打断（ad pod），而非可以无限刷新的角标。因此，交易模式高度偏向 PG/PMP，工程 KPI 中的合约 fill 与 break 兑现率往往比名义上的开放竞价 eCPM 更为重要。
• CSAI vs SSAI：CSAI 模式下播放器暂停内容、拉取广告后再续播，具备较高的灵活性且易于对接 VAST，但会导致会话分裂、易被拦截且设备碎片化严重；相比之下，SSAI 模式由服务端将广告缝合进 HLS / DASH 的 manifest 中，播放体验浑然一体且难以被拦截，但要求将决策 SLA、创意 ladder、缝合正确性以及信标校准构建为一条严密的流水线。
• SSAI 失败模式产品化：当面临决策超时或创意未就绪时，系统必须采取 slate（垫片）、缩短 pod 或直接跳过 break 等策略，坚决禁止出现默默黑帧的糟糕体验。
• 信标与计费校准：纯服务端按缝合进度上报「播完」会导致系统性的超计费。必须引入播放心跳或客户端进度进行校准，并将四分位与完成率作为单独的记账依据。
• 身份与频控分层：身份识别需要按设备、登录账号与家庭户进行分层频控；若仅依赖 IFA，极易在客厅场景中造成误伤或创意打穿。
• 核心验收指标：验收的重点在于黑帧与 rebuffer 率、pod 完成率、信标齐全率、合格曝光以及合约 fill，绝不能仅仅盯着 eCPM。

Table of contents

1. CTV / OTT 到底在卖什么

1.1 这几个词别混

需求方买到的通常是某次内容会话中一个 ad pod（广告串）里的一次或多次广告曝光（Impression），涵盖前贴（pre-roll）、中插（mid-roll）、后贴（post-roll），以及暂停广告（pause ad）和部分平台的首页包场（homepage takeover）。由于大屏广告单价高且广告位稀缺，这决定了在交易模式中，CTV 几乎是 PG / PMP 的天下。需要强调的是，大屏售卖的是确定性环境加稀缺打断，而不是海量的开放剩余流量。

1.2 四层模型（排障用）

为了避免口头上的 CTV 概念将问题混为一谈，我们需要把一次「大屏广告机会」拆解为四个层级：

① 设备层     Smart TV / Stick / Console / 投屏
② 应用层     流媒体 App / FAST 客户端 / 操作系统频道
③ 码流层     HLS / DASH 内容 + DRM + ABR ladder
④ 插播层     CSAI 或 SSAI：何时 break、插什么、如何计费

当收入漏斗发生断裂时，排障的第一步是定位层级：是 ④ 插播层没有决策到创意，还是 ③ 码流层的缝合与档位崩溃，亦或是 ② 应用层的播放器信标丢失。切忌一上来就将责任归咎于「需求方平台（DSP）出价低」。

1.3 与手机 App 变现对照

对比可知，CTV 售卖的是客厅时间线上的稀缺打断，而非手机屏幕角落里可以随意刷新的横幅广告。

2. 为什么程序化在大屏「长这样」

大屏程序化之所以呈现出当前的形态，主要受制于以下几个核心因素：

1. 库存极度稀缺：一部剧集通常只有有限的几个中插（mid-roll）机会，无法像信息流那样无限下拉刷新。如果强行增加 ad break 的密度，将直接导致用户弃剧率飙升。
2. 体验硬约束：大屏对播放体验的要求极为苛刻。如果 pod 过长、音量突变、竞品相邻，或者同一个创意反复打穿，平台方会为了保护用户体验而主动砍掉变现机会。
3. 品牌预算主导：广告主（Advertiser）在大屏投放时，强烈要求优质环境、保量交付以及品牌安全，这使得 PG / PD / PMP 成为主流交易模式。
4. 履约是工程问题：PG 模式下的 under-delivery 往往不是因为销售团队「没卖够」，而是由于决策超时、创意未转码或缝合失败，最终导致 break 被迫跳过。
5. 技术债集中在插播层：如果系统无法妥善处理 stitch 或信标校准，那么接入再多的需求方平台（DSP）也仅仅是「账面上可竞价」，无法转化为真实的收益。

正因如此，公开竞价（RTB）虽然存在，但通常只作为剩余流量的填仓手段，或是特定开放市场的实验性项目。在工程优先级上，必须首先将 SSAI（或稳定的 CSAI）流水线以及合约履约做扎实，随后再去追求开放层的收益（Yield）。

这与卖方 Yield 的逻辑高度一致：在大屏上尝试「抬价」之前，必须先拷问 break 是否能够稳定兑现，毕竟一个空的 break 根本不存在所谓的 eCPM。

3. CSAI vs SSAI：插在哪一层

3.1 CSAI（Client-Side Ad Insertion）

在 CSAI 模式下，播放器在到达 ad break 时会自行暂停内容播放，向外部请求广告，待广告播完后再恢复内容续播：

3.2 SSAI（Server-Side Ad Insertion）

对比前一种方案，SSAI 模式在服务端将广告直接缝合进媒体的 playlist 或 manifest 中，播放器只需消费「一条连续流」：

内容源 ──┐
         ├──► Ad Decisioning ──► Creative 就绪（转码 ladder）
广告需求 ─┘            │
                       ▼
              Manifest Stitch（HLS / DASH）
                       │
                       ▼
                   播放器（一条流）
                       │
                       ▼
         播放心跳 / 客户端进度 ──► 信标与对账

3.3 选型与混合

在实际业务落地中，往往会采用混合架构：

• SSAI 为主、CSAI 兜底：在旧设备或服务端缝合失败时，回退到客户端插播；
• 点播 SSAI、部分互动位 CSAI：根据场景灵活切换；
• 最危险的中间态：表面上采用了 SSAI，但信标上报却全靠猜测，这会引发严重的对账灾难。

在进行架构选型时，核心考量清单应包括：直播业务占比、设备碎片化程度、反拦截诉求，以及团队是否具备 manifest 工程与观测能力，而不是盲目跟风「业界都在上 SSAI」。

4. SSAI 流水线：决策、转码、缝合、信标

4.1 Ad decisioning

在 break 到达前（点播场景可预取，直播场景常依赖 cue 前置窗口），系统需要向媒体 Ad Server、SSP 或交易对手请求创意。

输入（最小集）

• 内容、频道或节目 ID，以及 break 类型与剩余时长预算。
• 设备信息、地理位置、内容评级与品牌安全要求。
• 用户、设备或家庭标识，以及对应的频控余量。
• 竞品隔离、互斥规则以及序列规则（即同一 pod 内的播放先后顺序）。
• 交易约束条件：PG 余量、Deal ID 以及底价（floor）。

输出

• 排序完整的 ad pod（包含多条广告及其各自时长）。
• 是否允许使用 slate（垫片），以及是否允许缩短 pod。
• 每个创意的就绪句柄（绝不是临时返回一个 VAST URL 要求现场转码）。

需要强调的是，决策超时是严肃的产品策略问题，绝不能仅仅作为日志里的错误装饰：

为了保障交付，决策链路的 SLA 必须被明确写入 PG 履约的 SLO 中。例如，严格规定「在 break 到达前 (T) 毫秒，必须返回可缝合的 pod」。

4.2 Creative 与转码 ladder

大屏场景下的自适应码率（ABR）档位繁多，通常是分辨率、码率与编码档的组合。SSAI 几乎总是要求广告与内容的 ladder 严格对齐（即采用同套 rendition）。如果未能对齐，将引发一系列体验灾难：

• 切入广告时码率发生跳变，直接导致 rebuffer（缓冲卡顿）；
• 音频采样率或声道不一致，引发爆音或明显的静音感；
• 部分设备由于硬件解码不支持特定档位，最终导致黑屏。

因此，工程实现上必须把握以下要点：

• 创意必须提前转码并分发至广告 CDN，决策引擎只允许返回「已就绪」的创意 ID；
• 新创意在冷启动阶段必然存在转码延迟（transcode lag），PG 排期必须预留就绪缓冲时间，绝不能在投放当天（T-0）才上传母带；
• 必须严密监控创意未就绪率，以及「因创意未就绪导致的 break 降级率」。

关于视频起播与容器层的底层细节，可参考 MP4 faststart；在 CTV 场景下，这些细节缺陷会通过 ladder 与 stitch 被成倍放大。

4.3 Manifest stitch

以 HLS 为例（DASH 同理，操作对象为 MPD），缝合逻辑如下：

• 点播场景：在 ad break 处精准插入广告 segment 列表，或者生成会话级别的多版本 playlist；
• 直播场景：在滑动窗口中根据 cue 实时替换或插入片段，且该窗口必须与 CDN 的缓存策略保持高度一致。

缝合正确性的核心检查清单包括：

1. 广告时长累加必须与媒体时间线保持连续，坚决避免播放器 duration 发生跳动；
2. 直播的进出点必须与 SCTE-35（或等价信令）严格对齐；
3. DISCONTINUITY 或编解码切换标记必须能被目标播放器正确解析；
4. 缝合失败时必须能够平滑回退到内容 segment，绝不能留下空洞的 playlist；
5. 个性化会话的 playlist 必须具备正确的缓存键，严禁将用户 A 的广告错误地缝合给用户 B。

4.4 信标与计费：SSAI 的「测不准」问题

在 CSAI 模式下，通常由播放器根据 VAST tracking 规范进行打点；但在 SSAI 模式中，播放器往往并不知道「当前播放的这段流是广告」，这就衍生出三种信标模型：

为了确保计费准确，日志中必须包含以下最小字段集：break_id、pod_seq、creative_id、quartile、completed、playhead、beacon_source（server 或 client）以及 stitch_ok。品牌广告主在验收时，看重的正是这些详实的数据，而不是一句空洞的「SSAI 已上线」。

此外，可见性与合格曝光的口径依然需要回归 MRC 与验证体系（详见可见性与广告验证、广告形式）。在大屏场景下，「在播」并不等同于「在看」，但工程底线是必须首先做到「声称播完」与真实的 playhead 进度完全一致。

5. 直播 vs 点播：两套时序

需要补充的是，线性数字替换还需要将「广播时刻表上的广告位」与数字决策系统精准对齐。这是一条独立的产品线，绝不能与 AVOD 的中插（mid-roll）共用同一套超时假设逻辑。

6. 身份、频控、供应链

6.1 身份分层

如果仅仅依赖 IFA 进行频控，往往会遭遇典型的失败场景：同一个家庭拥有三台设备并共享一个内容账号，最终导致创意频繁打穿，或者在某些设备上「到处触达不到」。

6.2 Pod 内规则

大屏的 pod 通常伴随着严格的竞品隔离、类别互斥、序列控制（例如汽车广告不能紧接另一支汽车广告）、最大时长限制以及响度规范。必须明确的是，这些都是决策层的硬性约束，绝不能留到缝合之后再去被动补救。

6.3 供应链与欺诈

CTV 生态高度依赖 app-ads.txt 进行供应链核验，但目前仍面临 bundle 与应用标识口径混乱、设备伪造以及库存洗钱等严峻问题。当需求方（买方）应用 SPO 策略时，面对 CTV 冗长的链路与核验失败，往往会采取更为保守的策略。需要警惕的是，短链路同样存在垃圾流量，评估时不能仅仅盯着节点跳数（hops）。

7. 指标、实验与生产案例

7.1 看板最小集

7.2 实验注意

• 实验的主指标应优先关注履约率、播放体验（如 rebuffer 率）以及合格曝光收入，而不是盲目追求开放竞价的 eCPM。
• 任何涉及 stitch 或 ladder 修改的实验，都必须按设备档位进行切片分析，因为高端电视的流畅表现极易掩盖低端设备的黑屏问题。
• 信标模型的变更必须跑通需求方与供给方的对账差分，绝不能只盯着己方的 dashboard 自嗨。

7.3 生产案例

案例 A：上了 SSAI，eCPM 涨了，投诉也涨了 根本原因在于未对齐 ladder，导致低端电视棒频繁出现 rebuffer。正确的演进路径是：先彻底对齐档位，确保播放流畅，然后再逐步增加 break 密度。

案例 B：信标漂亮，财务扯皮 系统采用纯服务端按 stitch 进度上报完播，但用户实际上早已退出。在引入 playhead 进度校准之前，绝不能将服务端的广告曝光（Impression）作为最终的结算真理。

案例 C：PG 天天 under-delivery 排查发现，决策超时叠加创意未转码，导致大量 break 被 skip 或替换为 slate。必须认识到，系统 SLA 与创意就绪是保量交付的工程前提，这不是销售团队靠后期补量就能挽救的。

案例 D：同一家庭被打穿 系统仅按 IFA 进行频控。正确的做法是将家庭户（Household）维度正式纳入频控键的考量中。

案例 E：直播「播出事故」 由于 SCTE 抖动，且缝合失败时的回退策略未定义，最终导致直播黑帧。直播场景的失败路径必须像广电播控一样进行严密的演练。

8. 常见误区 ↔ 正解

延伸阅读

同支柱（端上变现 · App / CTV / Web）：

• 本站. App 广告 SDK 深挖：手机侧扳机与聚合——和大屏对照读。
• 本站. OEM 系统广告：开机与系统级库存，另一类设备侧变现。
• 本站. Web 变现：GPT / 标签 / 可见性：浏览器侧对称篇。

跨系列相关：

• 本站. 程序化交易模式：CTV 为何偏 PG/PMP。
• 本站. 媒体 Ad Server：决策与保量逻辑在视频侧的同源物。
• 本站. SSP Yield：有稳定 break 之后如何定价。
• 本站. 广告形式全解：可见性计费口径。
• 本站. VAST / VPAID / MRAID 渲染：VAST / VMAP 播放链与错误码。
• 本站. MP4 faststart：progressive MP4 首帧与程序化创意。
• 本站. 供应链透明度：app-ads.txt 与 CTV 核验难点。
• 本站. 供应链优化 SPO：买方如何收敛 CTV 路径。

资料：

• IAB Tech Lab. OpenRTB：视频 / CTV 相关字段。
• IAB Tech Lab. VAST / VMAP：视频广告投放标准。
• ANSI/SCTE 35：直播广告信令（线性/直播插入语境）。
• 各 CTV 平台（Roku、fireOS、主要 Smart TV）广告与 IFA 文档：口径不一，以对接平台为准。

附录：术语表

• CTV / OTT：联网电视广告库存 / 互联网视频分发。
• CSAI / SSAI：客户端插播 / 服务端广告插入。
• Ad break / Ad pod：广告时机 / 一次 break 内的有序广告串。
• Manifest stitch：把广告 segment 缝进 HLS/DASH playlist。
• ABR ladder：自适应码率档位集合；广告需与内容对齐。
• Slate：垫片；决策或创意失败时的填充。
• SCTE-35：直播流中标记广告时机的信令。
• DAI：动态广告插入（常与线性/直播替换连用）。
• Household frequency：按家庭户而非单设备的频控。
• AVOD / FAST / SVOD：有广告点播 / 免费带广告直播频道 / 订阅无广告。
• Under-delivery：合约量未投满——CTV 上常是工程履约失败而非「没需求」。
• Playhead calibration：用真实播放进度校准服务端信标。