博客首页|TW首页| 同事录|业界社区
2017-07-03

1.各方需求交易撮合标准化

从商业模式及行业规范的角度来看,我们可以说RTB用了一套标准化的流程和方法来“撮合程序化广告交易的各方需求”。就像炒股那样将股票的交易及价值评估标准化数字化货币化。让各方正确理解各自需求并高效匹配,并形成充分竞争的机制。完全以市场化自由竞争的方式满足各方需求,盘活剩余的广告库存(Inventroy)、提升数字营销精准的效率和效果,达成多方共赢。

媒体方流量的接入系统SSP也可以让媒体设定相应的媒体属性(媒体所属分类等等信息)、广告位属性(尺寸、可投物料规格)、价格诉求(底价等等)、投放广告主行业渠道的诉求(允许或禁投行业渠道等等)、禁投广告主及某些业务保护设置等等。

程序化买方DSP在系统中设定广告主属性、创意物料、用户体验目标、对不同Adx的优先策略、不同交易模式(OpenAuction、PrivateAuction、PreferredDeals)的运用、计价的方式(CPM、CPC等等)、出价的高低、需求量等等将广告主的需求标准化。

这样在双方都充分标准化、充分表达需求的基础之上,由Adx通过公平竞价的机制将整个交易过程标准化、货币化。

2. ADX-DSP审核流程及注意事项

最新发布的广告法对虚假信息的发布惩罚及追责还是十分严厉的,所以在广告主资质及广告素材的审核方面各方都是十分的严格的。广告法规定的责任主体是:最终发布信息的媒体;因为谁发布的违规的信息就该罚谁。所以从媒体、SSP、Adx、DSP、广告主这个链条上的每个环节应该都需要遵守该广告法的规定。当然由于整个链条过长,很多环节由于其规模及意识及资源等等不能很好地把好审核这关,所以从控制的角度来看,一定是从交易最集中的Adx口去卡是最容易卡最容易惩罚的。所以在RTB的链条中你会看到Adx在执行中成为了审核工作的主要把关者(而传统采买中媒体是主要的把关者)。各Adx平台及各行业相关审核注意事项存在一定的时效性,故在此中就不再展开阐述。可点击查看不同行业相关审核规范的细节

下图是整体的审核流程图示例,从图上可以看出主要是广告主资质及广告素材物料的上传及审核、DSP方审核、Adx方审核:

3.ADX创意渲染机制需注意(偏技术)

站在DSP立场同Adx技术对接是对于各Adx创意渲染机制需要十分注意,弄明白这些问题可以帮助我们更好地处理各种实际的问题及需求:

  • 在Adx平台广告投放时,是创意Host在DSP的CDN呢?搞明白这个问题,对于评估CDN的成本、动态创意、IOS创意地址https升级都十分的有价值(为了保护用户隐私,IOS10以上已开始要求所有的网络请求都走https。但同时https也将增加CDN的成本。)。
  • 客户及4A代理公司TradingDesk经常有要分出不同投放策略的曝光及点击的CampaignID、ChannelID、UserId、Domain、设备ID等等的需求。但是由于很多Adx平台素材中的监测代码上传后不能更改了(为了确保审核工作有效性,避免投放的素材及代码不是审核通过的素材及代码。),“曝光宏替换”意味着DSP可以在曝光时变更监测代码中的宏给第三方监测传递数据。还有一种办法就是需要Adx提供一种“EXT宏替换”的方式予以支持。
  • 点击宏替换:“%%CLICK_URL_PRE%%”意味着例如支持一些特殊的Adserving(筷子科技、Sizmek、DCM等,上一章也提到过广告可见性、品牌安全都要Adx这种特性的支持才行。)之类的代码可以定制特殊的点击跳转规则。一般Adx的广告投放都是先跳Adx的平台再跳到DSP平台最后跳到Adserving或监测代码最终到达客户的Landing Page。使用了“%%CLICK_URL_PRE%%”后,可以先跳到DSP的平台或Adserving,然后再跳Adx的平台的点击监测地址。

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《715线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-06-26

DSP同ADX对接首先是商务评估、技术评估决策满足自身业务需要才启动对接,技术对接后,需要将DSP方的广告主及素材行业类目同Adx方做映射,之后是线上真实投放测试。测试没有太大问题的话,就会整理相关审核及执行规范,并组织内部培训,开始走向对销售推介对该Adx逐步起消耗。从这个流程中大家看到平时会关注的关键点,这些点若没有注意或处理好就是未来需要花几倍代价填的坑。

1.商务谈判及评估

l 账期支持的天数?一般账期都是30天,但由于很多广告主尤其4A公司会压DSP账期至少3个月,所以从DSP角度当然希望账期能谈的越长越好,这块是商务谈判的一个要点。

l 是否有客户保护?客户保护清单能否提供?禁投行业是否提供?有些媒体为了保护传统的销售体系的利益,或业务的特殊考虑,对Adx部分有十分严格的客户保护政策,DSP方需根据自己客户的行业特点来选择是否对接。

l 首次接入的资源?如PC banner、视频、移动视频等:广告资源资源也是DSP方评估是否要对接Adx重要依据之一。

l 广告主是否需要审核?DSP方当然希望最好能先投后审的,所以这些点都是必须评估的。

l 创意审核周期:一般我们都知道广告主上午下单,恨不得当天广告就要出量,。所以审核周期是DSP比较关注的一个问题。

l 审核规范文档是否提供?文档是否提供也是细节评估的关键。

l 平台对接接口文档是否提供?技术文档细节评估也是评估工作量及成本的关键。

2.技术评估

l 技术对接方式?OpenRTB、API、VAST?一般都建议采用行业标准OpenRTB的接口协议。

l 媒体支持接入最大QPS?是英文Query Per Second的缩写,意思是每秒的处理请求数,也即是最大吞吐能力。这是评估服务器配置的重要依据,一般一台Bidder服务器在每个竞价请求处理速度小于30毫秒的前提下,正常能稳定处理3000QPS。短时的请求QPS高峰问题不大,但若长期的竞价请求QPS大到5000QPS以上,自然就会拉长每个竞价请求的处理速度,增大超时率及竞价失败率。就需要加服务器啦。所以一般这个上限值是十分重要的一个指标。

l DSP接入的QPS?DSP会根据自己的业务情况决定是否所有的竞价请求都接收,这就需要评估Adx是否支持QPS的限定(有部分Adx刚上线的时候这些功能都不具备)。同时Adx也会根据DSP接入的QPS来评估各DSP消耗能力来决定是否对接。

l 双方服务器所在位置?我们都知道中国主干网的特点,异地的网络通讯势必造成网络上的耗时增加,肯定就会压缩Bidder服务器的处理时长。若DSP为了确保响应速度,只能通过增加服务器集群,通过降低单服务器的QPS来完成。例如:有的媒体华北、华东、华南都有IDC,竞价请求会分别从这个三个IDC发出,这样就会导致不同的IDC的服务器处理竞价成功率各有不同。

l 响应最长时间要求?有些媒体为了保护自身媒体端的用户体验、以及内部不同部门的协调。会提出小于OpenRTB规范的时间要求。例如:有的媒体Adx要求加上网络整体响应时间小于50ms。

l 移动端设备id号是否传递?移动端的流量对接这个是十分重要的点,但是还是有很多媒体因为各种限制不发送设备ID号(例如微信中的广告流量目前就是没有设备ID的)。没有设备ID意味着无法从曝光-点击-到达-转化整个漏斗追溯数据,用机器学习的方式来持续优化。

l 移动端设备号ID是否符合规范?安卓端IMEI/IMEI MD5,IOS端IDFA/IDFA MD5?符合规范一致的设备ID才能确保DSP能跨媒体投放广告做频次控制、打通各方数据。在第三章中大数据基础也详细阐述过。

l 第三方曝光及点击监测是否支持?支持的条数?这些都是广告主十分在意的问题。

l 接口文档是否规范?是否存在个性化的定义?对于个性化的定义会增加对接工作量及难度。

3. 技术对接

技术对接主要确保流程及功能的正确性,少量的数据GAP比对。

  • 审核及投放接口开发
  • 审核及投放接口线下联调

4.类目及数据映射

Adx及媒体方面为了从价格政策、禁投行业等等都会从类目进行设置规则。而各DSP放为了确保用户使用的体验一致性一般会使用单一的类目,这样就DSP方就需将DSP方的类目同Adx的类目做好映射才能完成对接确保后续的广告可投放。

  • 创意类目映射
  • 广告主行业类目映射

5.线上广告测试

流量的对接一定是需要线上正式环境投放测试才能对比数据GAP,确保对接的正常无误。

  • 财务预算申请
  • 广告主审核接口
  • 素材审核接口
  • 线上流量投放测试

6.内部审核规范更新

线上测试完成后就是内部执行规范及文档的更新工作。

  • 广告主审核规范及资质要求更新
  • 素材审核规范及格式要求更新

7.DSP内部培训

内部规范及文档整理好即可组织对执行及销售层面展开培训推介资源起消耗。

  • 执行、审核规范培训
  • 资源特点、售前推介培训

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《715线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-06-20

随着RTB这种网络展示广告新兴交易模式的出现,广告投放产业链由媒介人员人工方式同媒体(或广告网络)人工方式的谈判、购买、投放广告触达受众的传统购买方式逐步转变为基于大数据的指导,通过程序化的方式对接广告交易平台Adx对目标受众进行精准的广告投放。如下图所示,数字营销领域正在快速升级:

什么是RTB?

RTB即:Real Time Bidding(实时竞价)英文单词的首字母缩写。

从字面意思我们可以看到两个关键:

  1. 实时:整个广告交易的过程100毫秒以内完成,对最终用户完全是无感知的,一眨眼的功夫就完成了。
  2. 竞价:多个买家参与出价竞争的,十分类似炒股。

由此我们能发现如此精细化、迅速且复杂的交易过程不可能通过人为传统购买的方式能够执行的。必须都是通过程序化的方式通过大数据计算机系统来完成的。

竞价整体流程

整体的流程如下:

  1. 首先十分重要的一个前提是媒体方将广告资源接入到Adx(Ad Exchange广告交易市场)系统中,一般接入媒体广告流量的系统常称作SSP(Supply SidePlatform供给方平台)。
  2. 当用户通过PC电脑浏览器、手机上的浏览器访问媒体的页面,或者手机上直接打开媒体APP页面时,在媒体页面中的广告位被展示时需要展示广告。
  3. 这时媒体系统向Adx发送广告请求(这个我们经常称之为广告曝光机会),同时会携带很多用户行为数据:例如:广告位基本信息(网站、媒体频道、尺寸、页面URL等等)、该用户ID、用户上网浏览器 & IP地址等等信息。
  4. Adx会向各DSP发起竞价请求(常称为Bid Request),并同时将刚刚媒体提供的用户行为数据一并传送。
  5. DSP根据该用户ID在自己的进行分析比对并通过算法决策和人群匹配:确定投放什么尺寸的广告、确定投放哪个产品广告、并通过对该用户及曝光机会评估价值决定出价。这里的逻辑较为复杂我们将在后面DSP实战相关内容中详细阐述。
  6. DSP返回匹配的广告物料(包含相应的各方的监测代码)及出价给到Adx(常称为Bid Response),Adx会判定所有出价中最高的那个DSP胜出,将竞价成功的信息(常称为WinNotice)通知胜出的那个DSP。同时将胜出DSP需展示的广告物料给到媒体方。
  7. 媒体方收到需展示的广告后将该广告在广告位展示,用户浏览到该广告。
  8. 最后媒体方展示完广告后,根据监测代码向各方发送监测数据(Adx、DSP、第三方监测)。

成交价的相关规则

一般来说Adx对胜出者(DSP)的成交价遵守的原则为“第二高价成交”,主要是为了防止DSP方通过不断降低出价的套路来探测成交价。

当然也有极少数的Adx以“第一高价”成交的,即按胜出者的出价成交。

虽然大家说的是“第二高价”成交,实际的成交价是按第二高价+1分钱来结算的。

以“第二高价”成交这种方式可以鼓励买方出更高的价,使媒体卖方获得更大的收益。同时因买方无法提前预测成交价(“第二高价”),所以出价买方的最好竞价策略就是依照自己对标的物的评价而给出标价,因此不管是从单方收益还是从整体资源配置考虑,它使得对其他竞争对手的出价情况、投标策略和整体市场评估变得多余。每个出价者只需将他的努力和注意力放在从自身方面对商品价值的评价上,因此大量节省了脑力劳动和费用支出。这种节约可以导致更好的资源配置,并增加可被买卖双方分享的总收益。

注意:虽然是一次广告曝光机会的竞价请求,出价是按CPM(即千次曝光)计的,winnotice返回的也是按CPM(即千次曝光)计的(所以DSP方的报表中展示消耗时需要除1000),此处需小心。

底价(floor price):一般大部分媒体的不同广告位都会设相应的底价,在Adx发出的每个广告竞价请求(Bid Request)中都会携带该底价信息。出价都是要高于该底价的才算有效出价,设置底价也是为了保护流量售卖方的利益。当然买方肯定希望底价越低越好,而且尤其对于视频媒体由于其传统对不同的行业执行不同的价格政策,所以很多视频媒体会依据不同的行业设定不同的底价。大家肯定会好奇啦,这个不同行业不同底价在Adx方该怎么呢?其实特别的简单。一般DSP要投放广告前需要将广告主的资质(广告物料)及所属行业分类提前上传到Adx进行审核的,这样Adx只要根据广告主或广告物料上已归属的行业就可以依据不同的底价来判定该出价是否为有效出价。

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《715线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-06-12

品牌安全(Brand Safety)也是近来品牌广告主(尤其是国际大品牌的客户)时常关注的。广义角度讲“广告可见性(Viewability)”也可作为“品牌安全(Brand Safety)”的一项评估指标之一。

推动力动因

品牌广告主比较在意广告传播的美誉度,不希望广告被展示在与产品服务及品牌形象想悖的媒体环境中。例如:航空公司的品牌广告不要展示在介绍空难的内容页面中、品牌广告不要出现在色情暴力的网站等等。如果处理不好这个问题,可能是广告预算也花了,反倒可能让用户对品牌产生负面的感受,带来一些不好的传播效应。

所以对于很多国际大品牌客户,陆续开始关注品牌安全(Brand Safety)相关的产品及服务。这类产品一般我们称之为广告验证服务或平台。常见的一些公司及产品有:Sizmek、Adbug、RTBAsia、IAS等等。

常见模式

一般这类品牌安全服务按其在广告投放中被运用的阶段会分为两大类:

1. 广告投放后的验证报告

这种验证报告,在传统媒体采买的模式下也可以出的,不一定非要在RTB的范畴。不过因RTB中的长尾流量更多,所以尤其是国际大品牌客户,会关注此类服务及报告。但是投放后出的报告,就是“事后诸葛亮”啦。已经花出去的广告预算,也没法子再收回来啦。所以大家更多的希望,能尝试在广告投放环节中,运用上品牌安全这项服务。市面代上表性的,新兴广告环境验证公司有:Sizmek、IAS、Adbug、RTBAsia等等。

2. 广告投放环节

所以行业上下游,都在尝试如何在广告投放的环节,就加入品牌安全服务。

1)Bid前(Pre-Bid)

最常见的是在DSP收到广告竞价邀约时,出价之前,DSP先询问这类广告环境验证服务,该次广告竞价请求的曝光机会对该广告主的品牌是否安全?广告环境验证服务返回不安全,则DSP放弃竞价。若返回安全,DSP同时结合其他算法,评估该广告曝光机会的价值并出价。若竞价胜出,则广告最终将被展示。整个从广告环境验证服务询问,到返回结果的过程,必须在20-30毫秒内完成,否则整个竞价环节无法在100毫秒内完成。这样就对广告环境验证服务提出了很高的要求。一般都会在DSP方的机房,部署一台前置服务器,来提供服务,降低中间的网络损耗。这种模式的好处是广告主的预算节省啦,不过增加了广告环境验证服务的成本,也增加了DSP方在竞价前的等待时间,成本会增加,因等待造成的竞价失败率也会增加。

2)Bid后(Post-Bid)

由于成本等原因,不可能在所有的DSP端都部署服务器的,那么还有一种模式极像AdServing代码的模式,竞价之前广告环境验证服务不参与。而是在DSP竞价成功之后,回吐的素材是广告环境验证服务的AdServing代码(很像上文Viewability数据收集的代码模式,这种模式上面也提过了,目前仅少量ADX平台(例如:google、TANX)中的部分媒体流量兼容。该代码在展示广告时,会分析广告曝光机会对广告主品牌是否匹配、是否存在品牌安全的问题?如果没问题则正常展示广告,若有问题则展示一个同该广告主品牌无关的公益广告。其实这点某种程度上也没能节省广告预算,只是减少了负面影响罢啦。

机制及现状

上面介绍完相关的概念和逻辑后,下面简单介绍一下大概的技术机制。同广告可见性采集数据类似,品牌安全服务主要通过技术手段监测广告曝光时的媒体内容页的URL,以及同时抓取页面中的内容全文。当然很多的时候品牌安全服务为了提高分析处理的效率,并非在广告展示的时候,而是单独会起一组爬虫程序,先去抓取全网的URL,分析这些URL中的全文分词,分析找出敏感词并打上标签(特别像搜索引擎技术),这些标签大都同品牌安全有关,例如色情、暴力、战争、灾难、敏感时事等等。上面这是数据采集及打标签的环节,下面就是服务输出结果的环节啦。在结果输出环节,品牌安全服务不论是在出具报告时,还是在Bid前(Pre-Bid)的时候,只要比对广告被展示(或将被展示)的页面URL,就能得出相应的标签(在上一个环节被打上的标签),这样就能通过标签的结果得出统计报告,或判断是否对广告主品牌有问题。

但目前因技术成熟度(是否所有URL都能被分析、分词的准确性、标签的合理性、及同广告主的匹配性等问题)、网络环境等问题,导致目前品牌安全的服务还不是很稳定,且大部分只能监测PC上的部分媒体环境。当然相信随着广告主方的不断推动,媒体方也会慢慢配合,目前遇到的种种问题终将会有效地被解决。但这个肯定是需要一个漫长的过程的。所以大家还是需要根据自己的实际情况来运用这些服务。

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《6.17线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-06-05

什么是MRAID

MRAID(Mobile Rich Media Ad InterfaceDefinitions)是IAB为移动富媒体广告定义的一套通用API规范,APP可通过支持这些API来增加广告的富媒体特性。这是一组标准化的命令集,设计用于与HTML5及JavaScript一起配合使用,主要用于富媒体广告与APP之间进行通信的。

简单说就是利用H5的代码,可以调用移动手机本地的一些API,实现诸如:小变大扩展创意、摇一摇、重力感应游戏等等富媒体特效。

注:IAB中MRAID的地址:

Mobile Rich Media Ad Interface Definitions (MRAID)

截至本文完稿时MRAID的正式版本为2.0,最新的MRAID3.0Draft刚提交审核,具体内容可参看如下URL:

http://www.iab.com/wp-content/uploads/2015/08/IAB_MRAID_v2_FINAL.pdf

https://www.iab.com/news/iab-tech-lab-releases-mraid-3-0-public-comment/

http://www.iab.com/wp-content/uploads/2016/11/MRAID-V3_Draft_for_Public_Comment.pdf

MRAID示例:点击动态扩展的banner广告,点击APP中的banner广告后,广告展开可进行全屏动态展示。再一次加强曝光,展示完后将直接跳转至landingpage页面。(期间不会弹出新浏览器页面,用户体验流畅。)

图5‑6 MRAID点击动态扩展banner广告示例截图

MRAID协议简介

现以《MRAID-V3_Draft_for_Public_Comment.pdf》为例给大家概要性地介绍一下该技术接口协议,这些介绍也是让大家对该规范感性上有一个基本的认识。当然因为是技术规范,内容可能有些偏技术,大家不用太过深究,仅仅是为了让大家有个基本的感性概念(所以截图及部分内容尽量以原文档原文为主,若大家没有兴趣且将来会不涉及相关技术工作的,只要记住“MRAID是移动端富媒体交互广告规范”即可,可跳过下面的内容,直接继续后续阅读即可)。限于篇幅,详细的规范内容我们将不做展开,如果某些技术同学,出于工作需要及好奇,可依据上述提供的文档地址下载原始文档进行研究。,图5‑7所示为该规范文档的封面截图,放这个截图的目的也是为了让大家对该规范的正本有个感性认识(不至于受到一些“李鬼”的干扰。)。

图5‑7 MRAIDv3文档封面截图

注:MRAID 3引入了一些新功能,主要有:

1.先展示预加载的广告;只有当正式广告准备好才展示,确保广告正确无误地显示给用户,确保广告效果。

2.通过一个广告的可见性测量的接口,使得监测广告可见性成为可能。

3.充分整合VPAID允许视频富媒体交互体验,能在移动端加强广告MRAID的用户体验。

4.提供能够发现是否启用设备位置的访问接口,同时进一步提供有关位置的信息。

5.对广告程序提供了音频的测量接口,通过改接口广告程序可检测设备的声音是否启用、以及设置在什么音量。

6.在初始化时,监测MRAID规范兼容Web容器的相关属性是否达标,以确保广告展示的兼容性,确保更好的展示效果。

该协议首先介绍一些常用词,这些常用词会帮助我们理解MRAID,并运用好:

l host: 宿主,即移动App提供MRAID广告展示的容器,并支持MRAID的API。这个宿主的实现形式可以是一个广告SDK,也可以是具备这些功能特点的APP。

l MRAID Implementation: 实现MRAID协议并对广告提供的富媒体交互的功能。包括广告中的可监测MRAID能力、开启MRAID能力、并使用这些MRAID服务的JS代码。

l SDK: Software Development Kit(软件开发包)首字母缩写。对于MRAID,SDK指的是实现MRAID功能的代码及框架库。可以给到移动APP开发者直接使用的程序包(用于发布MRAID广告)。

l SDK provider: SDK提供者,简单说就是为移动APP开发者提供这套技术或者服务的供应商。

l ad container: 广告容器或广告位,即在App中用于展示广告的区域(容器)。App开发者可将该广告容器作为固定广告位展示,也可以同媒体内容混在一起展示。且App中同时可以放置多个这样的广告容器。

l webview: webview简单说就是App中可以嵌一个小浏览器,是移动端App中可以展示web内容,及运行JavaScript的技术。MRAID不一定必须使用webview(技术大牛完全可不使用webview,而自己来实现),但webview是一种典型的MRAID宿主。广告容器包含webview,webview用于解析广告素材的HTML内容,并在webview中将广告渲染展示出来。

l native layer: 即同本地App通讯及操作的层。因为MRAID提供的很多富媒体交互特效,都需要同手机底层API通讯。这些都需要广告容器支持MRAID来实现的。然后MRAID广告代码只要直接调用JS代码,即可实现对手机底层API的调用。

l ad: 广告文件包,在该协议中,ad泛指所有富媒体广告创意素材相关的类库、代码、图片等等。包括要在手机环境展示MRAID广告的所有MRAID的功能。

协议中描述了富媒体广告的交互过程,如图5-8所示,用一个最简单且典型MRAID的“可扩展广告”来展示MRAID整体运作流程:

图5‑8用最简单且典型MRAID的“可扩展广告”来展示MRAID整体运作流程示意图

1) 首先广告容器初始化并加载完广告文件,容器将状态变为“default”(广告代码可以读取容器的状态),向广告代码发送“ready”事件。广告代码可以在容器状态变化,或事件触发时完成一些特殊的特效,例如:视频广告加载即自动播放等等特效。

2) 用户交互触发广告扩展(这里支持可能的交互动作,可以是点一下广告、摇一摇、刮刮卡等等),广告代码调用“mraid.expand”方法,广告容器改变尺寸,最大可以是全屏,加载并显示“关闭按钮”,容器状态变更为“expanded”。

3) 广告代码可以根据需要侦听“stateChange”事件,实现一些特效。例如:广告展示完几秒后自动跳转到LandingPage等等。

4) 用户点击“关闭按钮”,广告代码调用“mraid.close”方法,通知广告容器将尺寸恢复原尺寸,容器将状态变为“default”。等待后续更多用户交互发生。

广告容器的状态主要有5个:

l loading:该状态说明广告容器还在初始化,及加载广告代码中,还不能正常完成交互特效。

l default:该状态说明广告容器处在缺省状态,即没有交互发生之前的状态,该状态下可正常进行交互特效。

l expanded:该状态说明广告容器已经发生交互特效,触发扩展变大。

l resized:该状态说明广告容器,是通过被MRAID2.0的resize()方法调用触发,而改变尺寸的。

l hidden:该状态说明插屏广告转变为关闭后的状态。

各状态间相互影响及转化的关系参见表5-1所列:

表格5‑1常见的几种代码方法对这些状态变化的影响

需注意,对于富媒体的广告特效需调用到手机本地API的特殊功能时,就需要手机本地支持的特性才行,例如:可使用“sms:”协议调起发短信界面、可使用“tel:”协议调起打电话界面、可在本机日历中创建一个日程、可存储图片、可在不全屏的情况播放视频(一般手机中缺省播放视频都全屏的)、支持VPAID的视频播放API、需要获取GPS位置信息、手机APP屏幕状态读取或设置:横屏/竖屏、屏幕角度等等、手机音量变化等等。

注意:原MRAIDv1中预留的本地扩展特性支持的:指南针、重力感应、震动器等等,在最新标准MRAID中已被去除。部分介绍说明如下:

设备传感器 (可选)

在HTML5的最新标准中已经定义了手机传感器的事件,但由于手机内置浏览器内核并不都可以支持最新的HTML5标准,基于此,本协议定义了另外一系列事件,用于给移动端更广泛的支持,设备传感器事件和方法都在MRAID协议基础上直接增加,不产生新的命名空间,由mraid.addEventListener(事件, 处理方法)监听。

事件列表:

shake:手机摇动触发

“tiltChange” ->function(x,y,z):x,y,z分别为对应轴的浮点型旋转向量;手机倾斜角度变化时触发

“headingChange” ->function(heading):heading取值为0-360整数角度,0为正北方向,顺时针累加;手机朝向变化触发

“networkChange” ->function(network):network - String 取值为unknown,offline,cell,wifi;手机网络状态变化触发

注:部分调试工具及样例参考地址如下:

MRAID系列工具包:

Webtester(在web页面中预览MRAID ad效果的工具):

MRAID Test Page

SDKtester(通过SDK嵌入APP中,调试在手机上体验MRAID ad效果的工具):

Mobile App: MRAID Ads SDK Tester

部分效果实现指导文档及demo:

Single-PartExpandable Ad(单体扩展广告):

http://www.iab.com/wp-content/uploads/2015/08/MRAID_Test_Ad-Expandable.pdf

Two-PartExpandable Ad(点击扩展打开落地页广告):

http://www.iab.com/wp-content/uploads/2015/08/MRAID_Test_Ad-Two_Part_Expandable.pdf

Full-PageAd(全屏广告):

http://www.iab.com/wp-content/uploads/2015/08/MRAID_Test_Ad-Fullpage.pdf

Resize Ad(尺寸变化广告):

http://www.iab.com/wp-content/uploads/2015/08/MRAID_Test_Ad-Resize.pdf

Resize AdDesigned to Cause MRAID Errors(尺寸变化设计失误导致的MRAID的错误示例):

http://www.iab.com/wp-content/uploads/2015/08/MRAID_Test_Ad-Resize_Errors.pdf

VideoInterstitial Ad (视频插屏广告):

http://www.iab.com/wp-content/uploads/2015/08/MRAID_Test_Ad-Video_Interstitial.pdf

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《6.17线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-06-01

谈到移动端,对于效果较好且近来火爆的信息流广告是必须介绍的,信息流广告是原生广告(Native Advertising (Native Ads))的“形式原生”典型的代表。

若对原生广告追根溯源的话,其实她是一种营销理念,一种将内容及广告混合起来,以提高营销效果的理念。一般我们将原生广告划分为:

Ø 形式原生(Visually Integrated):这个很好理解,就是广告形式同上下文形式融为一体,最典型的就是信息流广告,用户很容易误解广告也是一个信息内容,从而提升点击率。(LandingPage到达后的转化率,信息流广告并没有特别突出,同Banner差不多,仅仅是前端的CTR高,所以最终转化的绝对数就自然变高了。)

Ø 意图原生(Choice):这个也很容易理解,就是根据用户明确设置的意图,或行为特征表现出的意图,来展示相应的广告,确保不打扰用户。

Ø 内容原生(Content):品牌要推送对用户有实际价值的内容。(这个有点像PR(公众关系(PublicRelations,P.R.,简称“公关”)、Inbound Marketing(是指让顾客自己找上门的营销策略))

注:IAB关于原生广告的指导地址(可点击文末“阅读原文”进入):

https://www.iab.com/guidelines/native-advertising/

对于原生广告在程序化中的运用,IAB也有相关协议(偏形式原生),作者结稿时的最新版本是《OpenRTB-Native-Ads-Specification-1-1_2016.pdf》。可通过如下地址下载阅读:

http://www.iab.com/wp-content/uploads/2016/03/OpenRTB-Native-Ads-Specification-1-1_2016.pdfhttps://www.iab.com/guidelines/real-time-bidding-rtb-project/

如图所示,为《OpenRTB-Native-Ads-Specification-1-1_2016.pdf》指导文档中的一篇对原生广告形式建议的原文截图,从图中我们可以看出规范中所指导的3种常见的原生广告的模式:在内容信息流中、在社交朋友动态信息流中的、在产品列表中的。从原生广告被看到的位置、内部形式、广告连接及整体信息流视图样式都给出了相应的指导建议。

但是虽然标准有了,一方面该标准约定的还不是很细致,很多地方都留有自定义的空间;另一方面正是因为形式原生,需要广告形式同媒体的内容形式一致,就会导致很难统一标准。这是实际大家在投放移动信息流广告准备素材,及设计原生广告素材上传功能时,都需要小心注意的点。

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《6.17线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-05-22

摘要:前几天有同学找我聊,聊到了她们想搭建DMP系统,对于搭建DMP系统的目标、外部数据是否重要,DMP同CRM系统的关系及如何打通这些数据等等话题。下面我再整理整理分享给到大家。

随着移动互联网的高速发展,大数据的概念已经逐步被大家所接受,被追捧。在实际业务当中逐步被更多地运用起来。然而概念火爆需求旺盛,使得整个市场鱼龙混杂,不论是DMP系统供应商,还是数据提供商,都会有各种的推销。在一阵阵的喧嚣热闹下,使得我们更加地心里没底了。那么如何才能用好DMP这个工具以及大量的各方数据呢?下面我们将从需求、外部数据选择、数据打通等等视角来介绍。

一、立足业务诉求,步步为营

对于DMP系统以及数据,我的观点首先是要想明白、梳理清楚搭建DMP系统的目的。因为首先弄清楚系统目标十分的重要,目标决定了系统的功能、数据源、数据采集打通等等各种环节。另外在大目标这个维度下,我们还需要加入逐级分解需求找出数据模型及业务规则这个维度来梳理。因为虽说互联网已经深入日常工作生活的方方面面,各种细节活动中。而说到底还是一种信息化的方式。就是将我们的工作、生活中各种的数据电子化了,通过这些电子化手段可以让我们利用一些自动化的工具,更好地加速我们的业务开展及数据分析。所以只要能认识到这点就能让我们释然很多。从纷乱的外表看到问题的实质。重点还是业务,而不是电子化的手段或者电子化的数据形式。换句简单点的话来说就是,关键是我们是否能搞明白如何通过XLS建立什么样的维度,以及分析出什么样的数据模板,通过xls模板或者纸的表单能把业务走通走完才是关键。这样两个梳理维度交织在一起由大到小,从上到下。例如建立DMP系统可能有如下这些目标方向:

1.在营销领域:

a.各种营销渠道对后续效果的归因分析;那么是否知道哪些维度和指标来观测及评估渠道贡献是分解需求的关键:例如:广告曝光->点击—>到达->活跃->转化->留存->复购等等。其中哪些数据是已经有的,哪些数据是需要通过数据打通或从外部获取的?等等这些都是需要认真梳理的。

b.对目标受众的分析可辅助制定产品推广策略或营销策略;这个策略可以倒过来看,可以先从现有自己的数据着手,分析出不同产品或现有不同推广活动,到达官网或购买产品服务的用户的分组以及基于这个分组,以及从现有数据中是否能找出一定的特征。例如:之前春季促销带来的大量的是购买某一产品,而且留存及3个月的复购高,这些用户大量集中在什么区域什么时段什么形式或渠道购买的产品服务。然后再根据这些分组再结合CRM或直接进行发放调研问卷,或结合外部的数据来给用户进行的兴趣爱好及可能的转化因素进行明确。这些都是我们要达成的结果,手段可能会是DMP系统。

c.收集分析高转化特征指导广告投放。基于上述b环节的数据可以进一步同媒体或广告渠道进行数据对接,可以采用自动化手段进行广告投放。而怎样投放才算效率高效果好,又是环节a会关注的。所以我们会发现重点是我们要把业务梳理清楚,关键不是DMP系统或工具本身。

可见在营销这个方向上DMP建立的终极目标是优化营销效率,提升ROI。

2.在用户运营领域:营销是给产品服务引流的,所以营销目标同用户运营的目标密不可分的,用户运营的很多数据维度及模型可能都是衡量营销效率及效果的重要指标项。广义上可能会经常将用户运营同营销放在一起来说。用户运营领域十分重要的就是CRM系统以及运营内容同用户响应度及转化度之间的关联这些数据及模型都是我们需要重点分析梳理的。对于这些问题我们可以按5W1H标准的描述事件的思路来指导梳理:WHO(谁)、WHAT(什么内容)、WHEN(何时)、WHERE(何地)、WHY(为什么)、HOW(如何的互动的方式)。以及这些不同的维度的用户互动及留存转化的模型如何?或者对用户的利润贡献率、单笔消费额度、消费频度、互动频度等等对用户进行分组,再以这个分组为主要分析线索来分析内容、服务、产品的用户使用频度周期等等。有了这些数据结果才能有效地指导用户运营的后续计划安排。在这个过程中我们肯定会遇到不同系统间数据如何打通,是否需要外部数据补充等等问题。

3.财务管理或供应链管理等企业管理的领域:其实我们企业管理的核心就是依据产品及服务销售节奏,合理地配备人财物。供应链的管理,使得库存越小、资金周转率越高、资金流转速度越快管理的利润率也就越高是管理领域的重点目标。那么如何使用好数据,并将不同系统间的数据衔接好,不同业务领域的模型衔接好。例如:推广模型同产品转化的模型以及供应链财务模型衔接好,高ROI的营销推广带来的产品销售不一定是供应链财务模型中最优的产品服务。所以根据自身的业务特点这些也都是需要细化梳理的。

以上仅仅选取了企业中的几个典型领域进行了介绍,主要也是以原则和思维模式为主,更多地希望大家能以业务从上到下的梳理,以内部数据为主的方式展开。

二、需求及数据按使用对象、部门、岗位、级别关注点均不同

这个点是我们在梳理DMP系统的功能及模型时不可忽视的,不同级别岗位或部门对数据及需求的关注点均不同。例如:

领导级别的更关心数据的可视化、数据中蕴藏规律的总结、以及以数据作为某些结论或后续计划的支撑依据。

业务执行级别的更关心数据的一致性、联通性、业务功能的闭环性,以及数据的验证性,功能上对数据规律的挖掘空间,可扩展性,外部系统的连通性等等。

业务操作级别的更关心系统操作的便捷性,可执行性,低失误率,高效性等等。

三、立足内部数据,内部数据实在不足时再外部数据补充,在用户各触点处打通各孤岛系统数据

上面已十分强调了立足内部数据及内部业务诉求,不应该被各种外部数据及系统供应商的美妙故事迷惑了眼睛,首先重点要抓住自己的内部数据,只有内部数据梳理清楚了。只有在配合业务需要的分析缺少某些维度时,在寻找外部数据补充时才会有效。对业务而言数据不是越多越好,而是对业务的针对性、配合有效最好。很多时候常常有同学问我各种系统之间或线下线上数据该如何打通。大家可能首先想到的是类似CookieMapping、IDMapping等等技术手段。但实际上大家应该更多的关注同用户接触的接触点,在各触点处,加入一些对用户无感知的数据采集手段,这些数据采集手段需要能兼容各系统数据孤岛的数据ID。具体做法例如:CRM系统中往往都有会员的手机号,那么我们如何将PC官网的Cookie及App的设备ID同CRM系统的会员打通呢,道理很简单就是在用户登录官网或App需要引导用户录入手机号;线下WIFI收集了设备ID同时引导用户在线下WIFI完成某些业务操作录入手机号等等,这样也能在WIFI触点处打通线下线上的数据。诸如此类的做法有很多,这样就可以在某些触点通过多采集些维度的数据来打通各系统孤岛的数据(Mapping的技术仅仅是基础手段,重点还是用户触点的选择),而这些都是需要提前梳理用户触点或推广渠道,然后根据业务需要在用户触点处或推广渠道打通数据。

最后简单小结一下,对于数据及DMP我们切不可为了大数据而大数据,不可贪大求全,一定要以内部数据为主、以业务诉求出发,自上而下逐步梳理、步步为营。外部数据要定位是自己内部数据的补充。数据打通需要重点关注用户触点的梳理。

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《5.28线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-05-15

《样本训练》《回归验证》中介绍了很多DMP基本的算法,下面我们将从实战案例方面为大家介绍,在运用层面DMP主要会有哪些内容。介绍这些案例主要目的也是为了让大家对DMP的主要功能及运用方向有个感性认识,便于在实战中有方向感。

TradingDesk & DMP & PDB(PMP)案例

首先我们介绍一个国内某知名品品牌,大数据驱动数字营销管理系统实战的案例,该系统的建设目标:通过这套系统管理年数亿的数字营销预算。这套系统的基础核心是DMP,但DMP若不结合实际的业务是无法产生巨大效益的。例如该系统案例,就是DMP结合了广告主方的Trading Desk、PDB(PMP),在营销方面运用大数据驱动数字营销的典型场景。Trading Desk主要对接相关DSP系统,并运用DMP来指导管理广告投放,PDB(PMP)主要对接的广告主自采媒体并运用DMP来指导管理广告投放,如图9-15所示。

图9‑15 Trading Desk & DMP & PDB(PMP)整体系统模块示例

下面选取几个业务人员常用的功能点介绍一下,例如“采集代码管理”主要用于生成数据采集代码,采集的数据有:线上广告投放链条上的相关的曝光->点击->到站->站内活动->转化等等数据;还有一些官网上访客的行为数据;还有一些线下到店等等相关的行为数据。界面截图示例如图9-16所示:

图9‑16 DMP中代码中心界面截图示例

同时在代码中心还可支持对相关投放进行关联,一旦使用了跟踪代码,广告主可以快速与广告投放进行效果关联,关联最小粒度为订单层级。在投放报表中直接能看到,到站后的行为效果数据,这样可以轻松地对不同渠道的投放效果进行分析。如图9-17所示:

图9‑17渠道分析功能界面截图示例

当然也可以根据需要,对用户会话时长、曝光转化周期、CookieMapping优先级进行自定义设置,满足多种需求。例如:

l 会话设置:访客数量是基于cookie,而访问次数是基于session,也就是会话时长,默认为30分钟,广告主可根据实际需要进行调整。

l 曝光转化周期设置:用户每次的转化行为,往往是多种渠道共同作用的,而曝光转化也应运而生,默认周期为30天,也就是看过广告的用户,如果在30天内形成转化,会被算作曝光转化,广告主可以在此设置,根据需求进行调整。

l CookieMapping设置:CookieMapping是PC端使用DMP服务的基础,可多维度的设置,灵活满足CookieMapping的需求。比如通过设置CookieMapping的优先级,保证最优质的媒体资源优先进行mapping。

还有自定义人群标签也是较为常见的功能,业务人员可根据业务需求,建立自有的人群标签体系,同时支持针对不同产品线、不同业务线自身人群特性,创建多维度自定义标签。且系统支持多维标签定义后,可导出cookie或者设备id人群包,用以指导广告投放。系统也支持导入自定人群包,直接给广告投放系统使用。

线下DMP系统案例

下面再让我们来看一个某大型国际知名车企,全国4S线下店面大数据管理系统的实战案例。通过线下DMP的建设,有效地管理线下到店的客流数据,并打通线下与线上。为产品功能策划、营销渠道到店浓度分析、以及指导广告投放,提供了大量重要的线下到店人群样本数据。当然线下线上数据打通之后,还可依据业务的需求做很多很多O2O的解决方案。如图9-18所示。

图9‑18线下线上打通解决方案示意

l 线下设备云管理系统即插即用,可远程调试;实时查看各个设备上线情况;安装实施便捷,全国各数据采集点状态及概览统计在可视化视窗中一览无遗。如图9-19所示。

图9‑19线下数据采集设备状态监控

l 基于到店顾客数据的线上行为进行消费者洞察,针对到店顾客画像以及兴趣特征,调整产品定位、功能设计、以及相应的营销广告策略。如图9-20所示。

图9‑20到店顾客人群画像

如图9-21所示,为线下DMP系统的大体功能模块示例,通过这张图大家对线下DMP的主要功能会有个感性认识。

图9‑21线下DMP系统大体功能模块示例

从图9-21中,我们选取部分常用的功能界面截图示例介绍如下:

l 基础分析:店头客流进店率、平均驻留时间、新老客户分层等分析统计。如图9-22所示。

图9‑22店头客户分析示例

l 经销店位置分析:提供到店客流常出现地理位置的热力图分析,为未来活动选址提供建议。如图9-23所示。

图9‑23到店客流常驻地址位置热力图分析示例

专有线下DMP+DSP实战案例

这个实战案例是在线下机场高铁大型公共场所,基于提供WIFI上网的服务之上,建立大型商旅人群的DMP。机场高铁天然就是一个持续不断筛选出新中产高消费人群的,优良场景化的筛子。建立高端人群DMP后,即可通过程序化购买广告的手段,对于这些人群进行精准营销。这样就构建起了专有的机场高铁,线下DMP+DSP实用精准营销的全新模式。如图9-24所示。

图9‑24机场高端人群DMP+DSP示例

机场和高铁站已经是很多大品牌的必争之地,同时若能结合线下场景化的WIFI广告投放 + 线上的联合多屏多次广告触达,通过这种线下线上打通的全新营销模式,可以让品牌借助场景化优势,多屏曝光持续触达,影响消费升级。如图9-25所示。

图9‑25机场场景营销+线上多屏找回

机场高铁的线下DMP不仅仅能区分出商旅人群,还可在此基础上根据更细化的位置,及出行频次等等线下行为数据,并结合线上用户行为数据,对人群再度细分。如图9-26所示。

图9‑26线下行为标签细化

除了上述应用场景,还可以在广告主店面或展位中,架设线下DMP采集到店/展用户数据,可以构建起跨时代的品牌莫比斯闭环:打通线上线下的全新模式。如图9-27所示。

图9‑27线上线下营销莫比斯双环闭环示例

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《5.28线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-05-08

要建立完备的大数据系统,需要扎实完善、高处理效率、高安全性、高稳定性、易扩容、海量存储的技术架构。下面截取部分DMP系统的技术架构图(主要包括应用架构、数据架构、技术架构等)供大家参考,同样对于非技术的同学对此有个感性认识即可。也不做大篇幅的展开了。

应用架构

应用架构主要是从应用功能角度将各模块间关系及分工进行描绘的图纸,主要会从应用集成视图、功能视图这些角度来进行描绘。帮助大家能对系统有个直观的认识,并且帮助各模块协同开发,友好集成。

  • 集成视图:

该视图主要体现出各模块间关系,如图9-28所示,以线下DMP系统为例,大数据平台(BigData)会从各个不同的渠道交换或采集数据。如:通过数据采集网络采集线下扫描设备采集的用户扫描数据、WIFI上网服务Portal的用户登陆认证数据、上网数据、点击流数据等,从企业数据中的普通数据、连锁店、加盟店等线下场景获取扫描数据、认证数据、上网数据等。内部会对各种业务维度位置数据、消费数据、通讯数据等进行交换从而对用户行为进行精准的刻画。在这个例子中,大数据平台以服务线上广告业务作为主要业务运用方向,所以会把广告管理系统视为外部系统(大数据为本体域,业务运用为客体域),进行外部数据交换,打通用户线下ID及线上ID。将用户的线下行为结合线上行为结合起来分析并打上标签,用以指导线上的程序化广告投放。广告系统中会从媒体方、ADX、广告监测中收集各种线上用户行为数据,并将这些线上广告相关的查看、点击、竞价信息等数据灌入大数据系统,从大数据系统中得到人群画像、竞价决策等的数据支持。当然不同的业务运用目的,就会接不同的业务系统交互数据,并将大数据为不同的业务运用目的而服务。

图9‑28 DMP应用架构-集成视图示例

  • 功能视图:

该视图主要描绘DMP基础必备的技术功能,如图9-29所示,大数据平台基础必备的技术功能有数据采集、数据导出、数据分析、数据可视化等。数据采集主要职能是收集数据,主要包括扫描采集数据、校验数据有效性、处理清洗数据、上传数据、备份数据、加密解密、压缩解压缩、ID生成等功能模块。数据导出主要职能是为了服务内外部的数据导入导出需求,主要包括内部ID关联、内部ID及数据导出、外部ID匹配、外部ID及数据导入等功能模块。数据分析主要职能是结合业务运用方向的需求对数据进行分析整理,在该例中以广告为主包含广告投放数据分析、人群画像等功能模块。数据可视化是数据有效输出、为决策提供支持、数据展示价值的重要窗口,其主要包含运维需要的数据采集监控、数据管理需要的数据主体域可视化、数据运用需要的行为域可视化、数据查询等功能模块。

图9‑29 DMP应用架构-功能视图示例

数据架构

若我们要对数据进行清晰的梳理,就必须先画出数据架构,在数据架构中会依据既有数据内容及运用方向画出主题域,并通过对主题域视图的描绘,让大家对系统主要管理的数据维度及各数据之间的关系有一定的认识。这样能有效指导有方向有目的地去收集交换并运用数据。数据我们一般会分为不同的主题域来存储分析,不同的主题域中都有唯一的主域数据对象族,其他的数据都是围绕这个主域数据对象族的客体域数据。如图9-30所示,以人作为十分核心的本体域,包括个体特征、身份证号、群体特征、本体关系网络、标签、数据维度、类别等。作为人本体域存在很多描述的本像数据,如计算机网络中的应用层的QQ及微信、表示层的CookieID、网络层的IP地址、物理层MAC地址,以及电信网络中的手机号、IDFA、IMEI、AndroidID等。相对人本主体的是客体域,即与人关联的物或非本体的数据或行为等,其包含个体特征及群体特征等,对于该例中以广告为主要业务运用方向,以广告作为主要描述的客像数据,如计算及网络中的应用层的广告ID及行为语意表达等。人本体及网络广告及行为数据客体通过时空交互,这些关联关系的数据均记录在交互域中,如计算及网络中的应用层的邮件记录及上网记录及广告行为、网络层的DHCP上网IP自动获取记录、物理层客户端位置及设备位置,以及电信网络中的终端位置、通话记录、基站位置等。只有通过如此严谨且丰富的数据区隔,我们才能有效地分析数据,找出其中有价值的内容。

图9‑30 DMP数据架构-主题域视图示例

技术架构

技术架构往往是我们要开始系统工程开发及构建之前,从技术实现角度划分出不同技术开发组件及模块的重要工序,这样做才能确保开发分工的协同性及系统功能实现的完整性。其中十分重要的就是组件视图的描绘。一般技术开发中必然会划分出不同的技术组件,主要是为了在系统搭建中,提高组件的可复用性,提升重用率,提升系统代码质量,尽量减少“重复造轮子”的浪费。如图9-31所示,我们将DMP系统的技术组件划分为主要负责对资源的管理及操作交互的基础资源层(bd-res)、主要负责业务处理的业务层(bd-mod)、主要负责集成及输入输出接口的接口层(bd-port)、以及贯穿各层的公共工具(bd-util)。公共工具(bd-util)即各层技术开发时大家都会用到的公共工具,如异常处理、类管理、开发调试工具等。基础资源层主要负责对资源的管理及操作交互,如数据库处理(res-db)包含对hbase、jpa、redis等的交互模块,文件处理(res-file)包含对csv、excel、大数据文件dfs、文件系统fs等的交互模块,网络处理(res-net)包含对ftp、http、mail、rest等的交互模块,流处理(res-stream)包含对mns、ons等的交互模块,还有对缓存(res-cache)、大数据计算资源spark(res-spark)、大数据计算emr(MapReduce)资源(res-emr)、通用资源(res-common)等的交互模块。业务层负责业务处理,如基于spark的业务计算模块(包括聚集(gather)、学习(learn)、训练(trans)(训练中包含清洗(clean)、映射(map)、聚类(aggregate))、查询(query)(包含匹配(match)、导出(export)、检索(search))),基于流的业务计算模块(mod-stream),基于mr(MapReduce)的业务计算模块(mod-mr),基于共享内存的业务计算模块(mod-shm)等。接口层主要负责集成及输入输出,如集成接口模块(port-integration)、客户端接口模块(port-cli)、API接口模块(port-api)、WEB接口模块(port-web)等。

图9‑31 DMP技术架构-组件视图示例

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《5.28线下大课堂》面对面为您答疑解惑讲透您关心的问题。

2017-05-02

上篇《样本训练》介绍了很多常用的分类算法,实操我们中该如何评价不同分类器的质量呢?首先要定义,分类器的准确率,指分类器正确分类的项目占所有被分类项目的比率。通常使用回归测试来评估分类器的准确率,最简单的方法是用构造完成的分类器对训练数据进行分类,然后根据结果给出准确率评估。但这不是一个好方法,因为使用训练数据作为检测数据有可能因为过分拟合而导致结果过于乐观,所以一种更好的方法是在构造初期将训练数据一分为二,用一部分构造分类器,然后用另一部分检测分类器的准确率。所以一般会对原始数据进行分割,分割成训练集和测试集。这样做是为了方便验证在训练集上训练得到的模型,是否能在测试集中可取得理想的效果。通常(训练集:测试集)分割比例为6:4或者7:3。训练集用来训练算法,学习其中的变量,测试集用来查看或检验所选算法在测试集上的效果。目前,常见的开源算法类库现成的有很多,只要将这些类库装载到计算环境中使用即可。(数据科学(data science)领域较流行的运行机器学习算法的语言有R、Python。)

衡量算法效果。常见的评价指标有:正确率、召回率和F值:

  • 正确率 = 正确识别的个体总数 / 识别出的个体总数
  • 召回率 = 正确识别的个体总数 / 测试集中存在的个体总数
  • F值 = 正确率 * 召回率 * 2 / (正确率 + 召回率)

举个例子:某池塘有1400条鱼,300只虾,300只蟹。现在以捕鱼为目的。撒一大网,网着了700条鱼,200只虾,100只蟹。那么,这些指标分别如下:

正确率 = 700 /(700 + 200 + 100) = 70%

召回率 = 700 /1400 = 50%

F值 = 70% * 50% * 2 / (70% + 50%) = 58.3%

若把池子里的所有的鱼、虾和蟹都一网打尽,这些指标变为:

正确率 = 1400 /(1400 + 300 + 300) = 70%

召回率 = 1400 /1400 = 100%

F值 = 70% * 100% * 2 / (70% + 100%) = 82.35%

由此可见,正确率是评估算法预测的成果中,目标样本所占的比例;召回率,主要是从关注领域中,召回目标类别的比例;而F值,则是综合这二者指标的评估指标,用于综合反映整体的指标。

  • ROC(receiver operating characteristic)曲线

对于二分分类,原始类分为positive、negative,我们可以标记为p、n。如图9-9所示,排列组合后得到4种结果。于是我们可以得到四个指标,分别为真正(TP)、伪正(FP);伪负(FN)、真负(TN)。

图9‑9二分分类典型四象限示意

对于正、负分类问题,一些分类器得到的结果往往不是0,1这样的标签,如神经网络,得到诸如0.5、0.8这样的分类结果。这时,我们可以人为取一个阈值,比如0.4,那么小于0.4的为负类,大于等于0.4的为正类,这样可以得到一个分类结果。同样这个阈值我们可以取0.1、0.2等等。取不同的阈值,得到的最后分类情况也就不同。例如图9-10所示:

图9‑10正负样本图示例

图9-10中左部的曲线图表示样本为正类的分布图,右部的曲线表示样本为负类的分布图。那么我们从中取一条直线,若假设直线左边分为正类,右边分为负,这条直线也就是我们所取的阈值。可见若我们移动该直线,这样阈值的不同,可以得到不同的结果。但是由分类器推测出的样本分布图始终是不变的。这时候就需要一个独立于阈值,只与分类器有关的评价指标,来衡量特定分类器的好坏。还有在类不平衡的情况下,如正样本90个,负样本10个,直接把所有样本分类为正样本,得到识别率为90%。但这显然没有意义。这就是ROC曲线的主要动机。

ROC空间将伪正率(FPR)定义为 X 轴,真正率(TPR)定义为 Y 轴。这两个值由上面四个值计算得到,公式如下:

TPR:在所有实际为正的样本中,被正确地判断为正的比率。TPR=TP/(TP+FN)

FPR:在所有实际为负的样本中,被错误地判断为正之比率。FPR=FP/(FP+TN)

在实际应用中,我们当然希望尽量把正确的目标人群找出来作为主要任务,也就是第一个指标TPR越高越好。而把负的样本为误判,也就是第二个指标FPR要越低越好。不难发现,这两个指标之间是相互制约的。若我们对于负样本判别标准定义的特别细致严格,一点小的特征都判断为负的话,那么第一个指标就会很高,但是第二个指标也会相应地变高。最极端的情况下,若我们把所有的样本都看做负的话,那么第一个指标达到1,第二个指标也为1。

我们以FPR为横轴,TPR为纵轴,得到ROC空间:

图9‑11 ROC空间示例图

我们可以看出,左上角的点(TPR=1,FPR=0),为完美分类,也就是个高明全对的推断。左边离中线近一些的点A(TPR>FPR), A的判断大体是正确的。中线上的点B(TPR=FPR),也就是B可能全都是蒙的,对一半错一半;右下半的点C(TPR<FPR),这个推断很可能错误。上图中一个阈值,得到一个点。现在我们需要一个独立于阈值的评价指标,来衡量这个分类器如何,也就是遍历所有的阈值,得到ROC曲线。

还是以图9-10为例,我们可以遍历其中所有的阈值,能够在ROC平面上得到ROC曲线。如图9-12所示ROC曲线。

图9‑12 ROC曲线示例图

曲线距离左上角越近,证明分类器效果越好。

图9‑13三种分类器得出的不同ROC曲线示例图

如图9-13所示的示例,是三条ROC曲线,若在0.23处取一条直线。那么,在同样的低FPR=0.23的情况下,最外侧那条线的分类器得到更高的TPR。也就表明,ROC越往上,分类器效果越好。我们用一个标量值AUC来量化她。

  • AUC(Area Under ROC Curve)

如图9-14所示,AUC值为ROC曲线所覆盖的区域面积,显然,AUC越大,分类器分类效果越好。

AUC = 1,是完美分类器,采用这个预测模型时,不管设定什么阈值都能得出完美预测。绝大多数预测的场合,不存在完美分类器。

0.5 < AUC< 1,优于随机猜测。这个分类器(模型)若妥善设定阈值的话,能有预测价值。

AUC = 0.5,跟随机猜测一样(例:抛硬币),模型没有预测价值。

AUC < 0.5,比随机猜测还差;但只要总是反预测而行,就优于随机猜测。

图9‑14 AUC示例图

  • AUC的物理意义

假设分类器的输出是样本属于正类的score(置信度),则AUC的物理意义为,任取一对(正、负)样本,正样本的score大于负样本的score的概率。

  • 计算AUC:

第一种方法:AUC为ROC曲线下的面积,那我们可直接计算面积。面积为一个个小的梯形面积之和。计算的精度与阈值的精度有关。

第二种方法:根据AUC的物理意义,可计算正样本score大于负样本的score的概率。取N*M(N为正样本数,M为负样本数)个二元组,比较score,最后得到AUC。时间复杂度为O(N*M)。

第三种方法:实际上和第二种方法是一样的,但可减小复杂度。直接计算正样本score大于负样本的概率。我们首先把所有样本按照score排序,依次用rank表示他们,如最大score的样本rank=n(n=N+M),其次为n-1。那么对于正样本中rank最大的样本rank_max,有M-1个其他正样本比他score小,那么就有(rank_max-1)-(M-1)个负样本比他score小。其次为(rank_second-1)-(M-2)。最后我们得到AUC。时间复杂度为O(N*M)。即:AUC=((所有的正例rank相加)-(M*(M+1))/2)/(M*N)。详细计算公式见公式9-3。

公式9‑3 AUC公式

另外,特别需要注意的是,对于存在score相等的情况时,对相等score的样本,需要赋予相同的rank(无论该相等的score是出现在同类样本还是不同类的样本之间的,都需要这样处理)。具体操作就是再把所有这些score相等的样本的rank取平均。然后再使用上述公式。

当然实操中往往数据中不可避免的存在一些噪音,所以常会采用一些人工干预设置补偿因子及系数的方式。一方面这样做可以一定程度简化算法及模型,另一方面也大大降低对计算资源的消耗,从而降低成本提升效率。(这也是典型的二八原则做法:大部分80%的问题仅需要20%的投入及特征模型即可解决。)

(转载请注明出处:微信订阅号:ad_automation)

文字表现力有限,欢迎参加《5.28线下大课堂》面对面为您答疑解惑讲透您关心的问题。