但凡接触过视频广告或者视频广告程序化的同学一定都听过“VAST”这个词，那么这些小知识你都知道么？
VAST是“VIDEO AD SERVING TEMPLATE”英文首字母的缩写（中文译：“视频广告投放模板”）。主要用于在线视频媒体获取视频广告的一种通讯协议，描述了视频广告响应的XML结构。 VAST使广告响应可以用于来自任何广告服务器。
如上图所示：
视频媒体的视频播放器在需要展示广告时会向媒体端的广告服务器发起请求拉取广告。
媒体端广告服务器根据广告系统广告上刊的排期设定决定展示哪个广告，并采用“VAST”协议的XML结构返回给到视频播放器端，具体XML内容示例如下：
<VAST version="3.0">
<Ad id="244749">
<InLine>
<AdSystem version="2.0">
<![CDATA[ DSP ]]>
</AdSystem>
<AdTitle>
<![CDATA[ 24299 ]]>
</AdTitle>
<Impression>
<![CDATA[ ]]>
</Impression>
<Creatives>
<Creative>
<Linear>
<Duration>00:00:15</Duration>
<TrackingEvents>
<Tracking event="midpoint">
<![CDATA[
http://t.i.com/xxx/t.gif?p=foo
]]>
</Tracking>
<Tracking event="midpoint">
<![CDATA[
http://ad.doubleclick.net/ddm/trackimp/N4517.214565.N4517.214565.029.TE/B7749437.7;dc_trk_aid=273564510;dc_trk_cid=54841467;
]]>
</Tracking>
</TrackingEvents>
<VideoClicks>
<ClickThrough>
<![CDATA[
http://t.i.com/xxx/click?p=foo
]]>
</ClickThrough>
</VideoClicks>
<MediaFiles>
<MediaFiledelivery="progressive" type="video/x-flv"width="640" height="480">
<![CDATA[ http://www.i.com/1.flv]]>
</MediaFile>
</MediaFiles>
</Linear>
</Creative>
</Creatives>
</InLine>
</Ad>
</VAST>
媒体视频播放器会向自己的广告服务器并同时根据VAST中的“Tracking”检测代码向检测方的地址发出监测数据。
上图对理解视频媒体内部的广告服务机制还是十分的一目了然的了。而大家可能会疑问了，如果我们需要媒体访问我方程序化广告系统提供的VAST该是一个怎样的流程呢？VAST支持“VAST Redirect（VAST重定向）”：一个VAST广告响应指向另一个VAST响应（有时称为作为下游VAST响应）。具体交互流程如下图所示：
视频播放器向媒体端广告服务器发起请求拉取广告。
媒体按排期中设定返回“VAST重定向”内容，也就是在媒体的排期系统中上传的素材是一段外部广告系统的（我们常说的）“VAST Tag（VAST标签）”：当被调用时返回含有VAST响应的URI。而这种重定向采用的是“Wrapper（包装）”方式返回的VAST：在VAST的背景下，一个包装就是一个响应，它提供了视频播放器使用所调用一个二次VAST回应的URI。二级响应可能会是另一种包装或一个VAST线内（inLine）响应。具体内容参见如下示例：
<VAST> <Ad>
<Wrapper> ... <VASTAdTagURI> http://i.i.com/vast.tag </VASTAdTagURI> ...
</Wrapper>
</Ad> </VAST>
视频播放器收到上述VAST返回的内容，知道了需要再“重定向”请求另外一个广告服务器获取广告内容。即根据“VASTAdTagURI”中的提供的广告URI去拉取广告。这个广告URI即大家问的程序化广告服务器的URI。
程序化广告服务器则根据计算结果返回相应的广告VAST内容返回给到视频播放器。返回的就是标准的VAST内容。
媒体视频播放器会向自己的广告服务器并同时根据VAST中的“Tracking”检测代码向检测方的地址发出监测数据。
VAST目前最新标准是4.0。不过大家常用的是3.0，该协议的原文地址如下：
https://www.iab.com/guidelines/digital-video-ad-serving-template-vast-3-0/
https://www.iab.com/wp-content/uploads/2015/06/VASTv3_0.pdf
可以通过该url获取协议原文阅读，协议原文我就不一一解读了，这里说明几个我们在日常使用中会要注意到的几个点：
一、Flash的跨域调用安全信任问题
一般现在大部分视频媒体的视频播放器还是Flash为主的，少量使用的HTML5的<Video>标签。而Flash在调用外部域名的文件使用时，需要外部域名根目录下放置一个“crossdomain.xml”允许外部Flash程序使用该域名下文件。同理监测方的域名下也需要安置此文件才能确保数据接受正常。之前很多项目执行时一些小的监测方经常出现该问题。用上述VAST示例：
素材方域名根目录下：
http://i.i.com/crossdomain.xml
监测方域名根目录下：
http://t.i.com/crossdomain.xml
“crossdomain.xml”具体的内容如下：
<cross-domain-policy>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
大家都可以使用该方法检测这个文件是否存在以确保项目执行时不要出现各种坑。
二、VAST技术对接模式下是否还需要CookieMapping？
因VAST技术对接模式下的广告请求是直接从视频媒体播放器中发出的，所以不存在多域名CookieMapping的问题。如果大家不明白什么是CookieMapping，请参看此文：《什么是CookieMapping》
三、VAST技术对接模式下媒体为什么不接受退量？
也正是因为VAST技术对接模式下的广告请求是直接从视频媒体播放器中发出的，大部分媒体不支持VAST返回空时，再去请求广告；很多媒体都是直接播放打底广告了。所以很多大的视频媒体是不能接受VAST对接模式下返回空的情况出现的（即我们常说的返量或退量）。当然一些小媒体为了获得更多预算会接受，但返量就会做打底或变通方式处理。
四、VAST技术对接模式下如何传递参数？例如设备ID、频道剧目信息等等。
例如：这个VAST URL示例，我们会在URL的参数中加入我们需要的各种参数：
http://i.i.com/vast/?u=http%3A//v.163.com/special/cuvocw/dixiashui.html&r=http%3A//open.163.com/&mid=14000&mxd=16000&fp=0&ad=KK.Qj&vat=0&mm=4*5&cha=cuvocw%2Cengineer&epi=water%2Cunderground
五、Adx服务端Sever ToServer（OpenRTB）对接模式中有没有采用VAST作为广告返回格式的媒体？
有的，例如：youtu、iqiyi是支持的，但是其他媒体都是上传的创意及监测代码且创意Host在媒体方。
支持VAST模式返回创意可以支持富媒体、视频广告播放播放进度等等高级功能。
例如，如下的示例，就可以返回一个高交互体验的富媒体广告（例如可以玩游戏等等），这个“高交互体验的富媒体广告”就是使用”application/x-shockwave-flash”的技术实现的：
<MediaFiles><MediaFile id=1 delivery=”progressive”type=”application/x-shockwave-flash” width=640 height=480apiFramework=”VPAID”>...</MediaFile></MediaFiles>
六、VAST支持视频广告播放进度监测
在VAST中的“Tracking Event”节点可以在不同的事件点放置监测代码即可收集媒体方发送过来的广告播放进度的数据：
<TrackingEvents><Tracking event=”firstQuartile”>
<![CDATA[http://adserver.com/firstQuartilePixel.gif]></Tracking>
</TrackingEvents>
同广告播放进度相关的监测事件点有：
-
start: this event is used to indicate that an individual creative withinthe ad was loaded and playback began. As with creativeView, this event isanother way of tracking creative playback.
-
firstQuartile: the creative played for at least 25% of the total duration.
-
midpoint: the creative played for at least 50% of the total duration.
-
thirdQuartile: the creative played for at least 75% of the duration.
-
complete: The creative was played to the end at normal speed.
媒体VAST支持这些进度事件的有；优土、暴风、迅雷、PPTV、凤凰视频、风行；具体支持事件的情况参见下表：
| 媒体 | 技术对接方式 | 是否支持视频完成情况监测 |
| 优土 | VAST | Tracking Event：start、firstQuartile、midpoint、thirdQuartile、complete |
| RTB（Preferred Deal） | 否，商务可推动媒体技术改造升级 | |
| 爱奇艺 | VAST | 否，商务可推动媒体技术改造升级 |
| RTB（Preferred Deal） | 否，商务可推动媒体技术改造升级 | |
| 腾讯视频 | VAST | 否，商务可推动媒体技术改造升级 |
| RTB（Preferred Deal） | 否，商务可推动媒体技术改造升级 | |
| 搜狐视频 | RTB（Preferred Deal） | 否，商务可推动媒体技术改造升级 |
| 新浪视频 | RTB（Preferred Deal） | 否，商务可推动媒体技术改造升级 |
| Letv乐视 | Flash广告播放容器（VPAID） | 可程序化广告方技术升级支持 |
| PPTV | VAST | Tracking Event：start、firstQuartile、midpoint、thirdQuartile、complete |
| 暴风 | VAST | Tracking Event：start、firstQuartile、midpoint、thirdQuartile、complete |
| 风行 | VAST | Tracking Event：start、firstQuartile、midpoint、thirdQuartile、complete |
| 迅雷 | VAST | Tracking Event：start、firstQuartile、midpoint、thirdQuartile、complete |
| 凤凰视频 | VAST | Tracking Event：start、midpoint、complete （商务可推动媒体技术改造升级完全支持） |
（转载：微信订阅号：ad_automation）
2299
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
