2.2 程序化购买/投放的关键特征
上一节我们介绍了程序化广告的相关规范，相信大家已经能对程序化广告的技术基础有了基本了解了。然而这些毕竟是刚性规范，对于很多流量卖方以及程序化买方，在实际业务开展中还是有点不好拿捏及决策，例如，哪些数据该提供？流量优先级该如何管理？底价该如何设置？所以我们需要对程序化广告中的这些关键点及特征建立清晰认知，尤其是对于卖方诉求、目标人群投放之类的关键特征点的把握，可以帮助我们更好地了解程序化广告。需要再特别强调的是，大家在实际业务中可以根据自身业务诉求及商业化目的，考虑支持、禁止或根据商业需求变通调整关键特征点。也就是说，这些关键特征点为大家提供的是一套可选项的指导，并不代表一定都是需要支持的，而是需要根据自身业务的诉求来进行判断的。
2.2.1 流量按优先级管理
卖方（媒体方）可按不同的程序化购买方式对流量按优先级进行管理。
媒体方一般都有现成的传统广告排期投放系统，可以按位置、时间设定广告投放计划。很多媒体的传统广告排期系统也支持对不同的广告主或者订单安排不同的优先级，也可能根据客户大小在订单层面进行优先级控制（不同媒体排期系统各有不同）。
PDB基本是在现有传统广告排期投放系统中先锁定流量，然后再将流量对接PDB系统进行投放，所以流量的优先级同传统排期订单在一个优先级上（当然也有很多媒体通过ADX系统来对接PDB系统）。
PD、PA、OA是媒体通过传统广告排期系统将剩余流量导入ADX系统进行管理的。所以优先级从高到低一般为：常规订单及预留库存PDB订单>PD>PA>OA> 打底广告。
注：打底广告：为了避免广告位“开天窗”（即出现空白），一般需要媒体方设置打底广告。特别是在程序化广告的模式下，广告的交易是实时进行的，为了避免广告位的浪费，无买家竞价购买时会展示打底广告。所以相对来说打底广告会便宜一些（例如视频媒体经常以游戏或医药行业的广告作为打底广告），有很多媒体会选择阿里妈妈广告联盟或百度广告联盟的广告作为打底广告。
Header Bidding（OpenRTB 2.5中已加入）：在2015年年底至2016年年初，Header Bidding这个词在业内有些热，这是从国外流入国内的一个词，号称是一种新的程序化交易广告技术。Header Bidding实际是AppNexus首先大力推动的，它给Publisher增加了新的开放选择。目前国外DFP（Google Doubleclick For Publisher）依旧是PC网站集成最多的广告平台，AppNexus希望联手其他的SSP/ADX（例如OpenX、AOL等）一起通过这种方式撼动DFP的垄断地位。举个例子帮助大家简单理解一下：媒体原已将流量接入“广告服务商A”（ADX/SSP）进行售卖，当一个广告曝光机会产生的时候，媒体可在调用“广告服务商A”获取广告之前，通过Header Bidding技术提前向其他买家询价，若无其他买家出价则再调用原“广告服务商A”，实现其收益最大化。媒体方通常对接单个ADX/SSP，Heading Bidding可使得媒体方在保持这种合作之外，额外地可主动对接其他的买家(ADX/SSP/AdNetwork等)。目前Header Bidding还是以PC为主，移动端则刚开始尝试。
2.2.2 交易管理
为了帮不同的买方系统及广告主区分出不同流量的交易模式，技术上流量对接时是需要提前在流量中携带相应的Deal ID标识的。买方根据对流量需求的紧迫程度及价值评估来决定是以OA的方式来竞价，还是采用PD、PA的方式，不同的方式买方就需要按约定返回相应的Deal ID标识，以标明用哪种模式获取流量。卖方不仅会通过Deal ID的方式来管理买方的交易模式，还会根据广告主能对该流量使用何种交易模式，进行更细致地约束管理。
通过上面的介绍，我们能发现“Deal ID”的重要性：在Server端对接RTB技术接口时，必须加入该预订量标识（Deal ID），才可完成PDB及PDPA等模式，如下图所示。
Deal ID达成的过程及操作流程如下：
1）卖方挂牌（媒体）在ADX中发布资源库存——价、量。系统操作功能截图如下图所示。
2）买方在ADX预定流量，商定Deal。DSP买家可在ADX平台中自助操作，先从可供预定资源列表中选取可预定的广告资源。系统操作功能截图如下图所示。
然后对该预定资源做相关设置，系统操作功能截图如下图所示。
3）买卖双方商议成功，预定流量达成Deal，系统操作功能截图如下图所示。
4）买方在程序化系统中录入约定的Deal ID，并实时在竞价时由大数据机器学习引擎决定采用何种交易方式参与竞价。
2.2.3 卖方诉求
虽然程序化广告购买是大势所趋，但是还有很多媒体卖方拼死抵抗，尤其是那些已建立了庞大传统销售体系的卖方更难转型。只有市场搅局者希望用新模式重新洗牌（他们才是初期的主要行业推动力）。所以我们要充分理解卖方的诉求才能很好地同卖方打交道，推动行业良性发展。
卖方不会因增加某种业务模式而减少对另一种（成熟）业务模式的收入；
卖方不会因为某业务模式冲击另一（成熟）业务模式的价格；
卖方不会为了迎合买家而贱卖；
程序化广告售卖剩余流量在很多媒体方目前仍是 “增量”收入，占媒体方整体收入的20%～30%，并非传统稳定的收入。
媒体方中的不同工种角色，对程序化广告的态度和核心诉求也不同。所以我们也需要充分理解并合理应对。
卖方销售：关心的是总销售盘量是否会增加，若简单地从一种模式转移到另一种模式，则卖方的动力不大。
媒体运营：用户日活数据不可公开，这是媒体方十分敏感的数据，会直接影响到媒体方在市场中的位置以及媒体商业变现的体量。
媒体产品：用户的体验及隐私数据的保护，是媒体方产品最关心的问题，不能因为程序化广告的加入影响了用户体验（例如响应速度、用户注意力、是否会误导用户）或侵犯用户的隐私数据。
这些都会是行业升级过程中会遇到的阻力。我们只有深刻认识这些问题，才能以多方共赢为出发点找出解决方案。
在价格策略及底价制定方面，存在价格保护的特征。对于存在竞价的场景中，卖方可以通过一些底价规则来保护一些特殊的库存或通过分类售卖、排除策略等设置来排除一些买家。
国内有部分ADX存在类似的价格政策：
大部分视频媒体私有ADX对不同行业都执行不同的底价政策。很多视频媒体ADX都有类似的政策，如游戏、电商、品牌、其他（中小）的广告，其底价均不同。
对于北京、上海来说，稀缺的视频前贴片资源比其他城市的资源底价高出十倍以上（部分视频媒体存在这个现象）。
2.2.4 目标人群投放
对目标人群（TA-Target Audience）进行流量筛选后再投放广告，才能达到我们所讲的“在合适的时间合适的地点推送合适的信息”。这就需要流量方开放用户的行为信息，在流量中携带用户行为的相关数据，所以某种意义上可以说程序化广告购买是流量媒体卖方一种数据变现的方式。
- 用户行为信息保护
一般卖方会根据自己的考虑适度开放用户行为信息，这是程序化购买模式中的一个十分重要的功能。这些信息对精准分析用户的相关属性特别关键，尤其是对于那些存在目标人群分析需求强烈的广告主。这就需要建议卖方开放足够多的信息。
媒体及流量卖方出于自身诉求的考虑，对用户行为数据进行不同程度的保护，在实际广告流量中都有可能会遇到如下情况：
媒体的顶级/子域名。即广告买方在广告流量中只能看到广告是来自哪些媒体的顶级/子域名，而看不到广告位所在的具体页面。例如，有的广告位可能是出现在论坛页面中的，从卖方角度看这部分流量质量并不差，但买方，尤其是一些大型的品牌广告主可能不太喜欢论坛页面中的广告位，感觉不够高大上。作为流量卖方为了能更好地售卖论坛页面中的广告经常会采用这种方式来处理流量，做一定的数据保护。
媒体的频道/栏目。上面在介绍OpenRTB协议标准时已介绍过，协议中约定广告请求可携带的广告位所在页面的媒体频道/栏目，尤其对于视频媒体。这类信息对分析广告位所在页面的内容特征是十分重要的，所以很多时候视频媒体常常会被要求提供此类信息。很多媒体会对不同栏目下的广告流量设定不同的底价及审核规则加以限制，确保自身的利益主张。例如，某些媒体为了提出自身的特点，会对于某些栏目的内容做较大成本投入，如高价购买版权内容、投入大量资金加强内容建设等。这样媒体就会对这些栏目中的广告位设定较高的底价或较严格的审核规范。当然有的媒体会对那些低成本投入的栏目在广告流量中隐藏其栏目信息，以期提高售卖价格。
用户访问的媒体页面的完整URL（强烈建议此模式）。即广告买方在广告流量中能看到广告位所在的具体页面的URL，通过这个URL买方可以分析页面中的内容，对广告位的价值做出较为有效的评估和精准广告投放。在PC端的广告流量中大部分都是这样的。但是由于目前移动互联网行业中对于页面URL还未形成有效的一致做法，移动App中很少能提供广告位所在页面URL或相关页面内容信息，所以这在一定程度上限制了移动App端用户行为分析及广告投放优化。因此如何广告流量中携带广告位所在页面的URL及内容信息，是移动App端急需各方一起推动解决的问题。但若想整个行业中大部分App能达成有效的一致做法需要十分长的时间。这是十分重要的业务突破口及行业升级的方向，现在就看谁能给出有效的解决方案并得到个App媒体的支持，在全行业落实。
当然媒体出于自身利益的考虑，也会对URL进行保护处理。例如，媒体为了避免竞争对手对其内容或有版权的内容进行研究分析，避免内容库的体量被暴露，会对URL进行加密或特殊编码。某种程度上虽然没有提供原始可分析内容的URL，但是加密或编码过的URL也可以为买方提供一些数据，帮助对用户行为进行辅助分析。
买方完全不知道购买的是何处的媒体库存。一般实际业务中较少会出现广告流量中一点媒体信息都不携带的情况，最少需要有媒体域名，在移动端则体现为AppID。因为若广告流量中一点媒体信息都不携带，作为买方有理由怀疑流量的可靠性，放弃购买该流量。
视频媒体的流量中还存在剧目、频道等重要信息；移动端有用户LBS（Location Based Service地理位置定向）位置信息等。
从上述这些内容我们不难发现，买卖双方会从各自的利益诉求出发，合理运用商务及技术手段，不断合作及博弈达成动态的合作平衡。媒体也会在是开放还是封闭，是更在意体验还是更在意经济效益等战略决策方面，随着自身成长阶段的商业战略决策，设定不同的规则。
注：移动端App很少能取得用户阅读页的上下文内容，这对用户行为分析产生了一定限制。
- 广告请求中携带的广告位及用户数据
OpenRTB协议标准中已约定了很多广告请求该携带的相关数据段，这些数据段中的数据是分析用户行为及机器学习建立模型十分重要的因子维度。但刚刚也说了，实际情况是不是所有流量方都能获取这些数据，媒体方会根据自身变现及业务的考虑选择开放哪些数据。大家对这些内容具备一定的认知基础后，方能更好地协调或决策广告流量中应携带哪些数据及进一步的用好哪些数据。
OpenRTB协议标准中已约定的广告请求该携带的广告位相关数据的说明如下：
Banner数据段：尺寸、位置、mimes（说明该广告位支持的多媒体类型，例如Flash、Gif、MP4等）、topframe（0说明广告位在iframe中，1说明广告位不在iframe而在topframe顶级页面框架中）、expdir（若是可扩展的广告位（点击广告，广告会扩展变大的广告位），说明可扩展的方向）等；
Video数据段：mimes、时长、尺寸、位置等；
Native数据段：mimes、尺寸、位置等；
Site数据段：名、域名、类（网站所属类别）、大类（网站所属大类）、页面类（广告所在页所属类别）、URL（该页面的URL）、来源（从哪个页面跳转到该页面）、搜索词、是否移动Web、关键词等；
App数据段：名、AppID、域名、storeurl（该App在AppStore中的地址）、类（App所属类别）、大类（App所属大类）、页面类（广告所在页所属类别）、是否为收费App、关键词等。
OpenRTB协议标准中已约定的广告请求中该携带的用户行为数据说明如下：
Geo（位置信息）：经纬度、国、市、区等；
User（用户信息）：出生年、性别、关键词、浏览器等；
Device（设备信息）：IP地址、设备类型（PC、手机、平板等）、设备ID（IMEI、IDFA、MAC等）、型号、操作系统、操作系统版本、硬件版本、设备屏幕尺寸、设备分辨率、系统语言、设备上网运营商、设备上网方式（WIFI、3G、4G等）等。
- 目标人群投放
在程序化购买模式中存在大量对目标人群数据的使用场景。这些数据主要来源于如下：
之前campaign（广告投放项目）投放的广告主方的第一方数据（点击、到达、转化），访客找回（retargeting）效果较好；
竞品或其他第三方监测收集的之前campaign投放的第三方数据；
DMP（第三方）供应商按广告主提供的相关标签及Look-alike挖掘出的第三方数据；
以上述数据为样本，并结合投放中的执行数据、行为数据挖掘出的人群数据。
需说明的几点：
前提是要有人群数据库及已分析过打好标签的人群数据库；
对某些非目标人群进行排除的广告投放也很常见；
Retargeting效果较好；
割裂的DMP数据、脱离了投放执行环节的数据无法持续优化及提高绩效；
PC端，mapping后积累的cookie才能被使用。
注：上述内容的部分名词解释如下：
Retargeting（访客找回、重定向，有的也称为Remarketing“再营销”）：很多时候，尤其是对一些快消品或电商类的广告投放，我们会发现访客找回的效果较好。用户一旦对某产品服务产生了长期的使用习惯和体验，一般较少会更换。所以我们常常会通过各种手段收集访客的各种维度的数据，并根据这些数据预测用户对某些产品广告的转化效果，来对那些转化较好的用户做访客找回（Retargeting）方式的广告投放。
Look-alike（访客找回、重定向）：定向目标用户时，有的时候为了对潜在用户增加投放量，需根据种子用户的网络行为聚类分析类似的行为，对相似网络行为的用户进行扩量，这种扩量的方式简称为Look-alike。
数据相关的常见词：Data Usage、DMP- Data Management Platform、TA-Target Audience、AP-Audience Platform。
