为什么CTV同意与众不同

网页和移动端同意体验共享一个常见前提：用户可以轻松阅读小号文字、精准点击控件并进行滚动。而由D-pad遥控器操作的"10英尺用户界面"完全打破了上述假设。这对同意设计产生了直接影响：

• 输入成本很高。用户难以方便地输入长文本信息，这就限制了您可以期待的定制程度。
• 多用户设备是常态。一台电视可能由成人和儿童共同使用，无法可靠地判断当前的观看者是谁。
• 持久标识符有限。各平台的标识符各不相同：Roku使用RIDA，Amazon Fire TV使用Fire Advertising ID，Android TV暴露一个Advertising ID，tvOS对识别能力进行了严格限制。这些标识符均可被重置，其中一些甚至可以被完全禁用。
• 应用容器限制。大多数CTV平台在沙箱中运行应用，这限制了CMP可注入的内容、可使用的存储类型，以及可用的UI外观结构。

实际适用的隐私法律

并不存在专门针对CTV的隐私法律，这意味着CTV应用和SSP受制于那些已经涵盖各类数字服务的通用框架：

• GDPR和ePrivacy在欧盟和英国——只要CTV应用在设备上放置存储或读取设备信息（包括广告ID），就适用这些框架。
• CCPA / CPRA在加利福尼亚州，将设备标识符和观看历史视为个人信息，并就这些数据的"销售"与"共享"赋予用户选择退出的权利。
• LGPD在巴西、PIPL在中国、DPDP Act在印度，这些法律对CTV观众的适用方式与对网页用户的适用方式相同。
• COPPA在美国，对于面向家庭的CTV应用以及任何存在合理理由相信有儿童观看的库存，都尤为重要。

上述法律中没有一部将CTV排除在外，也没有一部接受"这是电视"作为跳过同意的理由。问题不在于是否需要收集同意，而在于如何以用户能够用遥控器实际完成的方式收集同意。

IAB Tech Lab的CTV同意框架

IAB Tech Lab已发布相关规范，使程序化CTV变现能够与同意机制兼容。其中最重要的部分包括：

• 全球隐私平台（GPP）——它是TCF和USP字符串的继任者，从第一天起就被设计为在单一同意信号中表示多个司法辖区，并可在服务器端竞价请求中顺畅传递。
• OpenRTB 2.6及更高版本——包含了用于传递GPP字符串、敏感类别标志以及用户loggedInState的字段，使买方能够在竞价阶段尊重同意。
• App-ads.txt和sellers.json——在这个欺诈和虚假陈述常见的渠道中，对于库存身份验证至关重要，并且也间接相关，因为买方越来越拒绝为未携带可验证同意信号的CTV库存出价。

如果您的CTV变现堆栈不支持GPP，或在竞价请求中不传递同意字符串，许多DSP会直接放弃该展示机会，而不愿冒着缺乏合法依据的风险进行购买。

设计真正可用的CTV同意体验

优秀的CTV同意首先是一个UX问题，其次才是一个法律问题。以下几条在实践中始终有效的原则：

1. 一次性在开头显示告知。在首次启动时、发出任何广告调用之前展示隐私告知，而不是藏在设置菜单里。
2. 使用大尺寸、适合遥控器的点击目标。两到三个按钮，每个至少占屏幕宽度的四分之一，并具有在D-pad导航下仍清晰可见的高对比度焦点状态。
3. 与"接受"处于同一层级提供真正的"拒绝"选项。将拒绝藏在子菜单中是教科书级的暗黑模式，在网页场景中已招致执法行动——监管机构不会放过CTV。
4. 支持平台所提供的语音确认。在Alexa、Google Assistant和Siri可用设备上，语音确认通常是最易于访问的给予同意的方式。
5. 提供持久的偏好设置界面，使用户能够从主菜单通过两次或更少的点击抵达。
6. 绝不以同意作为访问内容的门槛。广告支持的档位可以以接受广告为前提，但付费档位与免费档位之间的选择必须是真正有意义的——而不是伪装成Cookie墙。

服务器端广告插入与同意链路

大多数优质CTV库存都通过服务器端广告插入（SSAI）交付，广告在出版商的服务器端被拼接到视频中，终端设备从不直接调用广告服务器。SSAI造就了一条必须被小心处理的同意链：

• 应用在设备上收集同意并生成GPP字符串。
• GPP字符串在会话初始化时被传递给SSAI供应商。
• SSAI供应商在每一个上游请求中将该字符串转发给广告服务器或SSP。
• SSP将该字符串包含在发给买方的OpenRTB竞价请求中。

这条链中任何一处的断裂——缺失字段、陈旧缓存的字符串、不转发GPP的SSAI供应商——都会让下游买方实质上在盲买。在GDPR辖区，这对链条中的每一方都构成法律风险敞口。

儿童与CTV

CTV渠道为家庭广泛使用，监管机构对可能有儿童观看的屏幕上的追踪行为持负面看法。切实的保障措施包括：支持平台级别的儿童模式、为儿童内容提供仅上下文定向的广告体验，并确保任何受COPPA管辖的应用运行一条与普通受众完全独立的同意和广告选择管道。FTC已多次表明，当内容明显针对儿童时，它会将"我们不知道那是儿童"视为一种无力的辩护。

CTV出版商现在应当做什么

1. 审计您当前的同意信号。确认您的CTV应用实际产出同意字符串，并且该字符串能够在每一次竞价请求中到达SSP。许多出版商在检查后才发现，他们依赖的是默认的"1YNN"或空字符串。
2. 采用GPP。仅依赖TCF或USP字符串已不足以应对跨辖区库存。迁移到GPP，让单一信号同时覆盖欧盟、英国、美国各州法律以及新兴框架。
3. 重新设计首次启动体验，在下一次应用更新前围绕一个适合遥控器的同意UI进行重构。
4. 端到端记录您的同意链条——从应用经由SSAI直到买方。监管机构已开始明确要求这张图表。
5. 培训您的广告运营团队识别哪些库存已获同意、哪些未获同意，以便在缺失同意信号时能够提供仅上下文定向的替代方案。

结语

CTV不是一块隐私法律的真空地带，而"没人监管电视"这一设想在每个主要市场都已被证伪。好消息是，构建模块——GPP、OpenRTB 2.6、具备SSAI感知能力的同意转发，以及适合遥控器的UX范式——都已经存在。率先采用它们的出版商，将是在买方开始拒绝一切其他库存时仍能继续销售优质CTV库存的那批人。客厅屏幕是同意管理的下一片疆域，将其视作下一个前沿的运营者，将在市场的其余部分追赶上来时收获广告预算的回报。