21 世纪啤酒与尿布的故事

太长不读

今天老婆让我出来买尿布，顺手拿走了旁边的一罐啤酒

结完账，坐在小板凳上喝着小酒，拿出手机刷刷剧再回家报道！

突然，视频中间给我弹出了一个广告，“老板，卫生巾了解一下！有了孩子别忘了娘啊”

我 X. 这软件监控我！卸掉它至少一天

夺命追踪版

事后，收到推送的我顿觉惶恐，脑子里面有好几个问题围绕着我

• 视频软件是如何知道我需要这个广告的

• 是哪个***把信息告诉这个视频软件的

• 为啥视频里的广告可以根据用户不同，看到的不一样

辗转难眠，于是乎一杯无糖黑咖啡，一台 MAC，一个 Google

一场疯狂的搜索追踪断案即将展开

首先，我怀疑超市老板有最大的嫌疑，老板知道我买了尿布，然后作为广告主把广告信息给了这个视频软件也就是媒体主，然后视频软件就把那个视频加上了广告推送给了我，一切这么顺理成章，老板就是罪魁祸首！

冷静细细分析好像也有一些问题，这些问题都让上面的逻辑不符合常理，比如

• 超市老板又是如何知道我要看这个视频软件的

• 囊中羞涩的小广告主（超市老板）又要如何找到适合自己的广告位；

• 交易效率低下，多个媒体主与多个广告主之间交叉沟通，费时费力

• 大媒体主的非显著广告位要如何销售；

• 拥有较少流量的小媒体主要如何获得广告；

老板和视频软件之间一定有中介！就像购房者和买房者中间的房产中介一样！

啊，我找到了他们的名字！ADN（AD Network），存在与媒体主和广告主之间，扮演着类似中介的角色，将众多长尾资源收集后建立联盟，ADN 便掌握了定价权，将这些资源位统一售卖给广告主。广告主有了投放需求后，会找到这个联盟去购买广告，而不用再和每家媒体去对接。

那么那个视频软件一定有一个联盟，果然，这玩意一搜索就出来了，XX 引擎广告投放平台。

所以超市老板登录了这个平台，然后购买了广告，投放给了我!

这种场景让我不由想起了当年各种房产中介满根错节，五颜六色混战的时代，比如每个中介手中的房源是有限的，并不能完全满足购房者的需求。报的价格也是有高有低。这种信息差让有些中介赚到盆满钵满！

会不会广告也有这些问题，比如

• 超市老板如何知道我在用这个软件，难道他有钱到每个 ADN 都买了广告位？

• 每个 ADN 联盟拥有着媒体主和广告主的资源有限，并不能够完全满足广告主的精准投放需求；

• 由于 ADN 联盟掌握着自主定价权，当有多个 ADN 同时存在时，其缺乏统一的价格标准，尤其是在多个 ADN 之间需要交易广告资源时，混乱的价格体系导致交易效率低下，且因为每个环节都存在付费的情况，也会使流量成本大幅增加；

犯罪份子肯定不止上面几个，刨根问个底

果然，让我发现了 ADX 这个线索，ADX 对接了媒体主的广告资源，将资源情况（如位置、大小、素材要求）和用户基本情况（如设备、地域）传送给广告主进行竞价；根据竞价策略选取相应的广告主作为胜出者；竞价结束后，再将胜出者的广告传给媒体主进行展示，同时告知广告主，促成交易。

可是逻辑还是不够通顺

• 超市老板真愿意花大价钱，比过其他老板，给我投个卫生巾广告？

• 超市老板要如何判断 ADX 传送过来的广告位值多少钱，是否和自己的目标用户匹配

• 超市老板要对接那麽多 ADX，耗时耗力，资金不雄厚是干不成这件事的

顺藤摸瓜，我找到了弄竞价机制的 ADX，进一步拆解出问题，既然是问题，那就是市场需求，肯定就有一帮人来帮助解决解决广告主也超市老板和媒体主的问题，我感觉我离真正幕后的元凶已经不远了

顺气自然地，我发现了下面这两位主角

DSP（Demand-Side Platform）, 连接广告主和 ADX，帮助广告主也就是超市老板解决对接多个 ADX 和识别用户并出价的问题。DSP 会与市面上绝大多数 ADX 进行对接，那么广告主只要对接一个 DSP 就可以了，极大的节省了广告主的时间精力；此外 DSP 通过一些技术手段，能够对 ADX 传送过来的用户进行识别，判断这些用户与广告主目标人群的匹配程度，基于这个用户的价值去进行出价，因此又帮助广告主解决了识别人群和出价的问题：

SSP（Supply-Side Platform）， 帮助媒体主进行广告位的管理，并与 ADX 进行对接帮助媒体主处理和 ADX 的各种对接问题，从而帮助媒体主提高广告位的曝光率、填充率与价格。

真相只有一个！而他们就是罪魁祸首，来人啊，上狗头铡！

待って

超市老板怎么能够确保我看了广告回去店铺买卫生巾呢？

差点就冤枉你了，原来还有一个元凶躲在背后！

DMP： 为 DSP 搭建数据基石，助力 DSP 准确识别用户，精准定位受众，主要通过 cookie 或设备 ID 对用户进行标记，通过跨域追踪的方式全方位分析用户的行为，以人群属性为主要标签对人群进行细分，当 ADX 传送过来用户的基本信息后，DSP 就会将这个用户与自己 DMP 里的用户进行匹配，看这个用户是否是广告主的目标人群，如果匹配的话，DSP 就对这个用户出价，并将价格传送给 ADX。

我悟了，让我们把背后的真个真相串起来看！

超市老板贪小便宜，把我的数据卖给了 DMP 数据管理公司

视频软件把广告位交给了 SSP 平台

而真正希望我买卫生巾的人另有其人！

而这些东西就这么神奇的工作在了一起，让我买了尿布和啤酒，就接到了卫生巾广告！

原来我一个人的羊毛背后这么多人来薅！

你以为故事到这就结束了吗...

作为 IT 人士，我没有放过追踪那个技术问题

• 难道每次媒体播放视频之前会把广告和视频剪辑在一起，然后播放给我？那背后的人力得多大啊，比较播放量这么多

好了，下面的过程对非技术爱好者惨不忍睹。劝你对自己善良一点，到此为止

我首先扒了下原视频，通过浏览器 Inspect/Network 分析了视频请求，了解到我们看到的这种视频跟大家理解的常规 MP4 格式不太一样。

**HTTP Live Streaming (HLS) 是一项由 Apple 开发的技术，**用于流式传输直播和点播视频。尽管 HLS 最初是为向 iOS 设备传送视频内容而开发的，但它已经扩展为也支持其他设备。 HLS 使用 HTTP 协议，使用户能够从他们的常规 Web 服务器流式传输媒体，而不是使用专门的流媒体服务器。

打开它的 M3U8 文件，可以看到下面的格式定义，里面定义了一个播放列表和元数据信息，另外还把视频分成了好几段。

如果愿意亲自动手尝试，可以用 FFmpeg 转换 MP4 到 HLS 文件

http://d2qohgpffhaffh.cloudfront.net/MediaTailor/AWSE_Logo_15sec.mp4

有了 HLS 视频文件，动态插入广告是不是容易一点了，前人种树后人乘凉，看看人家还做了啥

SCTE 35 是由 ANSI 和电缆与电信工程师协会创建的标准，它制定了在流中插入内联提示音的指南。也称为标记，这些信号指示内容分发者可以将内容插入或拼接到流中的位置

SCTE 35 应用于 QAMP/IP、Title VI/TVE 和直播或时移传送，是广告、节目和内容分发控制的核心信号标准。它最初是为广告插入而设计的，但 SCTE 35 标记的数字特性为其使用带来了更大的灵活性。

当 SCTE 35 标记出现在节目中时，它向广播公司发出信号，他们可以将其他内容拼接到提要中。

当我把 SCTE3 协议应用到 HLS 的时候，发现播放列表长成了下面的样子

EXT-X-CUE-OUT 给出了在什么时候播放广告的信号！

这个信号就提示播放器或者服务端该播放广告了。

播放器将信号换成广告资源就是 CSAI, 客户端广告插入技术。

服务端将信号换成广告资源就是 SSAI, 服务端广告插入技术。

广告资源从哪加载呢？

Google AD Manager 提供了 VAST 模版技术提供了一种参考。图入下

OK，现在掌握了插入广告的所以条件，那接下来实现插入就是一个细节问题了，google 当中，发现 AWS 的 Mediatailor 针对 SSAi 提供了一个解决方案

MediaConvert + MediaPackage + MediaTailor， 流程如下

完美，一切搞定！

哦不，忘记把尿布带回去报道了！

参考文献

• https://aws.amazon.com/medialive/

• https://docs.aws.amazon.com/medialive/latest/ug/how-medialive-works-channels.html

• https://developer.apple.com/documentation/http_live_streaming/understanding_the_http_live_streaming_architecture

• https://docs.amazonaws.cn/en_us/mediaconvert/latest/ug/ad-avail-blanking.html

• http://d2qohgpffhaffh.cloudfront.net/MediaTailor/VASTDemo.xml

• https://docs.aws.amazon.com/mediaconvert/latest/ug/including-scte-35-markers.html
  

关注我们

作者： 马里杰、肖亦凡