写给运营商与电视网络

广告时段本来就在，只是大部分是空的

机顶盒、IPTV 和流媒体应用里都带有广告时段，而直客销售从来不可能把它们全部卖完。剩下的部分由我们以程序化方式填充：在贵公司的时段规则之内、在贵公司设定的底价之上，并且排在贵公司自有销售团队之后，而不是之前。

技术对接文档 →
广告插播组（ad pod）· 90 秒广告时段 竞品隔离已开启 · 频次已设上限
SSAI
服务端拼接
OpenRTB 2.6
原生 ad pod 竞价
VAST 4.2
VMAP 时段规则
100%
本示例填充率

哪些始终由贵公司掌控

运营商不信任程序化，原因不在钱，而在于担心失去话语权：订阅用户付费观看的内容里会出现什么，得自己说了算。所以这些控制项都放在贵公司这一侧，而“未填充”始终是一个正当答案。

控制项

时段规则
由贵公司制定，由我们执行 广告插播组（ad pod）的总时长、广告条数、单条广告最长时长，以及广告时段可以出现的位置，都由贵公司决定。我们只在这些规则之内填充，填不满就如实返回未填满的 pod。
行业类别屏蔽
在竞价前生效 贵公司的屏蔽名单在竞价之前就过滤掉需求，而不是等广告已经出现在屏幕上之后再处理。
竞品隔离
按 pod 生效，可配置 默认每个广告时段内同一广告主、同一行业类别各只出现一次，订阅用户不会连着看到两家银行的广告。
底价
按广告位与地区分别设置 设定一个价格下限，低于这个价格就不卖。未填充是一个可以接受的结果。
直客订单
完整保留 贵公司自有销售团队始终优先。程序化填的是直客销售没有卖掉的那部分，而不是跟自有团队抢量。

不会打断视频流的广告投放

广告时段一旦卡顿，损失就已经超过这次曝光本身的价值。下面这些设计都是为了让广告时段与正片难以区分。

播放

SSAI
用贵公司的拼接器或我们的 服务端插入让广告与正片走同一套转码档位，广告时段不会出现缓冲，也不会出现清晰度跳变。
直播与 SCTE-35
支持 直播流中的时段标记会触发请求；迟到的出价直接丢弃，而不是拖延回到正片的切换点。
客户端
支持 如果贵公司的播放器本来就会自己发起广告请求，我们按标准的 VAST/VMAP 请求应答。
超时
≤ 300 ms 到时已经决出的结果就投放。我们绝不会为了多等一个出价而拖住视频流。

先从今天还没卖出去的库存开始

一个地区、一个频道，或者只是直客销售团队顾不上的那些广告时段。这已经足以看到真实数据，而不必动到目前正常运转的部分。