2.3　流量卖方同买方常见技术对接模式

在程序化广告实际业务中，经常会出现流量卖方的各种不同的广告资源同买方需要进行技术对接。其中依据媒体类型及对接方式的不同，会采用不同的技术方案，如下表所列。不同的技术方案存在各种不同的特点、问题、注意事项及对接周期。下面就一些大家需要重点关注的点进行详细介绍。

注：服务端对接方式下除App端媒体广告流量外，PC与移动Web媒体广告流量都需增加CookieMapping。
SDK：软件开发工具包(Software Development Kit)的英文缩写。
API：应用程序编程接口(Application Programming Interface)。
VPAID：Video Player Ad Interface Definition的缩写，视频播放器广告接口定义，它定义一个广告和视频播放器之间为了实现更多的交互体验而增加的通信协议。后面会有展开介绍。
VAST：VIDEO AD SERVING TEMPLATE的缩写，后面会有展开介绍。

2.3.1　PC/移动Web媒体

PC/移动Web媒体主要采用JS（JavaScript）广告位代码、API的方式进行技术对接。下面我们分别来看一下这两种技术模式不同的特点。

1. JS代码
   媒体（广告流量卖方）通过排期系统投放买方系统的JS代码。广告的展示及用户浏览网页的相关数据的获取，均由该JS代码完成，从而解决了双方CookieMapping的问题。此方式技术对接周期较快，一般1～2个工作日就能完成，但这种方式由于媒体方丧失了对流量的控制权，若不是广告投放预算足够大，媒体方一般不会支持。
2. API
   API主要是服务端接口对接的方式，目前业内大都会采用在OpenRTB标准协议基础上进行定制的方式。双方需要进行CookieMapping。此方式技术对接周期较长，一般1～2个月才能完成。这种方式由于媒体卖方可对流量进行控制，故是较为常见的技术对接方式。

2.3.1　移动App媒体

对于移动App媒体主要采用SDK、API的方式进行技术对接。下面我们分别来看一下两种技术模式不同的特点。

1. SDK
   广告的展示及用户手机的相关数据的获取均由SDK代码完成。SDK采用自己的设备ID规范，不需双方统一设备ID规范。此方式技术对接周期快，但存在一个App新版本发布的更新周期，一般3个月左右。采用这种方式由于媒体卖方丧失了对流量的控制权，故稍大一些的媒体卖方一般均不支持该模式。
2. API
   API主要采用的是服务端接口对接的方式，大都会采用基于OpenRTB标准协议进行定制的方式。双方需要遵守统一的设备ID规范。此方式技术对接周期较长，在媒体方技术已准备好的情况下，也至少需要1个月才能完成技术对接（若媒体技术未准备好，则可能需要花近半年的时间进行改造，改造的核心就是媒体每次广告曝光机会需请求服务器申请精准的广告，而不是之前提前按排期下发获取广告）。这种方式由于媒体卖方可对流量进行控制，故是常见的技术对接方式。

2.3.2　视频

视频媒体广告常用“页面广告位嵌代码”及API方式进行对接。API对接方式的问题及注意事项同上述的PC及移动App媒体的API对接模式，这里就不再展开介绍了。而 “页面广告位嵌代码”模式主要采用VAST或VPAID作为协议规范来进行技术对接，下面就给大家简单介绍一下。

1. VAST实用知识
   VAST是Video AD Serving Template的缩写，中文译为视频广告投放模板，是用于在线视频媒体获取视频广告的一种通信协议，描述了视频广告响应的XML结构。VAST使广告响应可以用于任何广告服务器（但凡接触过视频广告或者视频广告程序化的同学一定都听过“VAST”这个词）。如下图所示为协议文档中的原图截图，其对视频广告播放器通过VAST协议拉取广告的基本流程进行了描述。

上图所示流程的大体说明如下：
1）视频媒体的视频播放器在需要展示广告时会向媒体端的广告服务器发起请求拉取广告。
2）媒体端广告服务器根据广告系统广告上刊的排期设定，决定展示哪个广告，并采用VAST协议的XML结构返给视频播放器端。具体XML内容示例如下面的代码所示。同OpenRTB的代码示例类似，还是希望大家能大概认识，以便实际工作中不被忽悠。
VAST 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><!—代码简单解读：此处为广告时长，例子中15秒-->
<TrackingEvents><!—此处安置视频广告播放不同事件的监测代码，支持多条代码-->
<Tracking event="midpoint"><!—midpoint：代表视频广告播放已过中点，即完成50%-->
<![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><!—此处安置视频广告素材文件，包括说明文件格式及尺寸-->
<MediaFile delivery="progressive" type="video/x-flv" width="640" height="480">
<![CDATA[ http://www.i.com/1.flv]]>
</MediaFile>
</MediaFiles>
</Linear>
</Creative>
</Creatives>
</InLine>
</Ad>
</VAST>

3）媒体视频播放器会同时向自己的广告服务器及监测方的地址（根据VAST中的“Tracking”数据段中的监测代码设置）发出监测数据。
大家可能会有疑问，如果我们需要媒体方访问我方程序化广告系统提供的VAST，该如何处理呢？VAST还支持VAST Redirect（VAST重定向），即一个VAST广告响应可指向另一个VAST服务（有时称为下游VAST响应）。具体交互流程如下图所示。

对上图所示流程大体介绍如下：
1）视频播放器向媒体端广告服务器发起请求拉取广告。
2）在媒体排期中设定返回“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> 

3）视频播放器收到上述VAST返回的内容后，知道了需要再“重定向”请求另外一个广告服务器获取广告内容。即根据VASTAdTagURI中的提供的广告URI（Uniform Resource Identifier统一资源标识符）去拉取广告。这个广告URI即外部的程序化广告服务器的URI。
4）程序化广告服务器根据计算结果将相应的广告VAST内容返回给到视频播放器，返回的就是标准的VAST内容。
5）媒体视频播放器会同时向自己的广告服务器及监测方的地址（根据VAST中的“Tracking”数据段中的监测代码设置）发出监测数据。
注：截至本书完稿时VAST最新标准是4.0。
下面说明几个我们在实际工作使用VAST时应注意的几个要点问题及事项：
1）Flash的跨域调用安全信任问题：现在大部分视频媒体的视频播放器还是为Flash为主，少量使用HTML5的

crossdomain.xml具体内容
<cross-domain-policy>
<allow-access-from?domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

大家都可以使用上述代码检测crossdo main.xml文件是否存在，以确保项目执行时不出现各种坑。
2）VAST技术对接模式下是否还需要CookieMapping？因VAST技术对接模式下的广告请求是直接从视频媒体播放器中发出的，所以不存在多域名CookieMapping的问题。关于CookieMapping将在第3章详细介绍。
3）VAST技术对接模式下媒体为什么不接受退量？正是因为VAST技术对接模式下的广告请求是直接从视频媒体播放器中发出的，大部分媒体不支持VAST返回空时，再去请求广告，很多媒体都是直接播放打底广告的。所以很多大的视频媒体是不能接受VAST对接模式下返回空的情况出现的（即我们常说的返量或退量）。当然一些小媒体为了获得更多预算会接受（实操时，返量就会用打底广告或其他变通方式进行处理）。
4）VAST技术对接模式下如何传递参数？例如设备ID、频道剧目信息等。我们会在URL的参数中加入我们需要的各种参数，具体URL示例可参见如下代码。
VAST 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

5）ADX服务端Sever To Server（OpenRTB）对接模式中，仅少数视频媒体ADX支持采用VAST作为广告返回格式，但是其他大部分视频媒体都是上传的创意及监测代码，且创意Host在媒体方。支持VAST模式返回创意的，可以支持富媒体、视频广告播放进度监测等高级功能。例如下面的代码就可以返回一个高交互体验的富媒体广告（例如可以玩游戏等），这个“高交互体验的富媒体广告就是使用application/x-shockwave-flash技术实现的。
VAST富媒体XML示例

<MediaFiles>?<MediaFile id=1 delivery="progressive"
type="application/x-shockwave-flash" width=640 height=480 
apiFramework="VPAID">?...?</MediaFile>
</MediaFiles>

6）VAST支持视频广告播放进度监测，在VAST中的Tracking Event节点可以在不同的事件点放置监测代码，即可收集媒体方发送过来的广告播放进度数据，如下面的代码所示。
VAST“Tracking Event”示例

<TrackingEvents>?<Tracking event="firstQuartile">
<![CDATA[http://adserver.com/firstQuartilePixel.gif]> </Tracking>
</TrackingEvents>

视频广告播放进度相关的监测事件点有：
start：视频广告已播放开始的事件点；
firstQuartile：视频广告至少已播放25%的事件点；
midpoint：视频广告至少已播放50%的事件点；
thirdQuartile：视频广告至少已播放75%的事件点；
complete：视频广告已正常播放完成的事件点。
国内仅部分视频媒体VAST支持这些进度事件，且很少有所有事件都支持的视频媒体。
VPAID要点
所谓VPAID（Video Player Ad Interface Definition），就是视频播放器广告接口定义，它定义一个广告和视频播放器之间的为了实现更多的交互体验而增加的通信协议。因为在视频广告播放时，随着广告视频的播放及用户的参与互动，需要一种技术标准规范来统一这些事件点，让“高交互体验的富媒体广告”更容易被行业内规范规模化地制作出来。简单说就是可投放的“高交互体验的富媒体广告”使用到的正是VPAID的技术接口规范。通过VPAID能达成一些富媒体广告特效，例如广告“开始播放”“被用户点击”“被用户放大”“被用户暂停”等。用户及广告播放的事件，都被传递给广告内部的程序，这样广告内部的程序可以针对这些事件对用户的交互动作进行响应。通过这样的方式来完成整个高交互体验的富媒体广告。大体的交互示意如下图（协议文章中的原文截图）所示，这些交互细节也是为了让大家形成大体的感性认知，故这里就不再展开细节描述了，细节大家可以参考IAB上的专业文档。

那么使用VPAID，可以同视频媒体播放器采用三种方式来投放广告：
1）媒体视频播放器首先可以自己实现一个VPAID广告接口协议容器。这样媒体就可以通过这个VPAID容器播放任何兼容VPAID的广告了，不论是通过VAST Tag方式获取的广告，还是直接被投放的VPAID广告素材。VPAID是一套标准接口协议，若媒体视频播放器是用Flash技术实现的，那么就要用Flash实现VPAID的接口定义。若媒体视频播放器是用HTML5+JavaScript技术实现的，那么就用要用HTML5+JavaScript实现VPAID的接口定义。VPAID广告交互大体流程如下图所示。

由上图可知：
视频播放器请求广告服务器，获取遵循VPAID接口规范的富媒体交互广告程序文件。
广告服务器返回遵循VPAID接口规范的富媒体交互广告程序文件。
视频播放器按VPAID的接口规范播放富媒体交互广告程序文件，并不断根据视频广告播放进度及用户交互事件，同该VPAID富媒体交互广告程序不断通信。
视频播放器向服务端发出监测数据。
2）VAST方式返回VPAID：在媒体视频广告播放器获取的VAST tag内容中返回的是遵循VPAID规范的富媒体交互广告程序文件的URI；媒体视频广告播放器拉取富媒体交互广告程序文件，然后按VPAID的接口规范播放该富媒体交互广告程序文件，并不断根据视频广告播放进度及用户交互事件，同该VPAID富媒体交互广告程序不断通信。大体的集成交互流程示意如下图所示。VAST集成VPAID示例片段可参见下面的代码，该代码示例中的VPAID富媒体广告是采用application/x-shockwave-flash技术实现的。

VAST集成VPAID示例片段

<MediaFiles>?<MediaFile id=1 delivery="progressive"
type="application/x-shockwave-flash" width=640 height=480 
apiFramework="VPAID">?...?</MediaFile>
</MediaFiles>
``
3）移动端MRAID3.0Draft（MRAID，Mobile Rich Media Ad Interface Definitions，
IAB为移动富媒体广告定义的一套通用API规范）规范中也提到在移动端如何实现使用VPAID接口规范来实现富媒体交互视频广告程序，即在使用MRAID协议（关于MRAID的内容将在第5章介绍）编写移动端富媒体交互广告程序时，其中若内嵌播放视频广告时，可以创建一个VPAID标准接口规范来实现视频广告播放过程中的那些交互事件的捕获和响应。例如，广告开始播放、被用户点击、被用户放大、被用户暂停等用户及广告播放的事件。