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

程序化的买方卖方都十分关心程序化交易中的各项技术指标的数据,这样可以量化评估程序化交易环节的效率和损耗,进而可以针对性的进行优化,对于无法优化的就需要提前从成本及计算模型等做相应的特殊处理。

首先大家关注的一个指标就是“竞价成功率”指标,即:“曝光数”/“参与竞价数”。

严格来说这个数据应该是“胜出数”/“参与竞价数”。不过由于技术平台对接的时候将“win notice”接口同曝光接口合并,且在业务执行层面大家还是比较关心“曝光”,仅技术层面较关心“胜出数”同“曝光数”的GAP,若这个GAP很大技术就是需要查的。

在RTB的场景中“竞价成功率”是抬高出价的一个很重要指标,若实际曝光量相比计划曝光量还差很多,且“竞价成功率”较低的情况下,往往会通过提高出价来观察是否提升了“竞价成功率”,从而获取了更多的“胜出”并“曝光”。

当然我们也会发现就算我们开出天价也不可能100%胜出,获得100%的“竞价成功率”。那么排除出价的因素,这是为什么呢?

  • 网络因素:因adx同各bidder之前都是网络通讯的,且要求每个bid 在100ms以内完成。我们也知道网络通讯有一定的不确定性,偶尔网络出现一些拥堵,导致bidder回复需要这个广告,而adx因网络原因没有收到这个回复,自然就影响了“竞价成功率”。而对于广点通、搜狐一些特殊的adx要求50ms以内要完成bid。
  • 广告库存在媒体内部的处理机制有关:不同的媒体内部都有一个广告管理系统,再通过这个广告系统将广告流量通过网络的方式接入到ADX。往往很多媒体同ADX在这部分对接因多出一个系统造成的损耗就在10-15%以上。有些媒体内部的广告系统同自己的ADX由于网络等等考虑也有网络处理时长的要求的,为了保证最终用户等待广告的时间不能太长,以某些移动媒体为例,一些特殊的adx(媒体内部同Adx对接时就要求严格的时间要求)要求40-50ms以内要完成bid才能满足。所以很多时候可能是Adx获取到了该胜出的广告,但是在给到媒体广告系统的路上因为网络等等原因丢失了。当然还有一种情况是媒体方内部对广告有一定的优先级别管理,对于传统采买的大客户订单会保证一定的优先级别和优先消耗的。
  • 一些特殊点位的特殊处理机制:例如:为了保护用户体验及移动端网络等因素导致很多移动端点位需提前拉取广告素材,拉取了广告素材提前缓存,在用户浏览到广告位时才展示广告。大部分开屏点位因为素材较大,且APP启动的时间较短暂,所以肯定会提前拉去素材,而且很多曝光的时间会比竞价的时间晚很多,有的我经历过晚72小时的。同时对于某App信息流点位更有一个特殊的点是,按“可见曝光收费”,因为信息流是一个list,做技术的都知道很多时候用户客户端APP加载list的时候可能是展示1list的时候同时就已经在拉去后面的2、3甚至更多的list了,因为用户是滑动屏幕来浏览更多list的信息的,为了确保用户使用的友好性流畅性这是一种非常常见的处理机制。但是如果用户不浏览更多list的时候,这些提前被拉去的list信息将被丢弃。所以腾讯新闻APP信息流内部的“竞价成功率”也就“1%”左右。
  • 其他的一些审核及素材规格尺寸不符等等因素:例如:素材的尺寸不符合点位的要求;广告主及素材在媒体端审核不通过;广告主及行业是媒体禁投的行业或广告等等。

下面罗列一些的其他相关指标说明:

从Adx角度看的一些数据指标(所以这些数据都是Adx看到的数据,未必是DSP看到的数据,因为其中存在一定网络损耗):

  • 可发竞价请求总数:Adx的总流量,可发给各DSP的竞价请求总数,可理解为可用库存量。
  • 过滤后的请求量:各DSP在Adx自助平台中可设置定向过滤条件,过滤后的竞价请求数,如过滤某些尺寸或网站等等。
  • 实际发送请求数:各DSP在Adx自助平台中可设置QPS限制,Adx会依据该QPS约束对该DSP发送的实际竞价请求数。该指标显示出DSP实际可见到多少库存量。同时Adx也可评估各DSP消耗能力。
  • 实际发送率 :Adx给各DSP实际发送请求数占总竞价请求数的比率,该指标Adx可评估各DSP消耗能力。(实际发送请求数/可发竞价请求总数)
  • 参与竞价数 :某DSP参与竞价的数量。
  • 参与竞价率 :某DSP出价数占实际发送请求数的比例。通过该指标Adx可评估各DSP购买意愿。(参与竞价数/实际发送请求数)
  • 放弃竞价数:Adx看到的某DSP放弃竞价的数量。(实际发送请求数 - 参与竞价数)
  • 放弃竞价率:某DSP放弃竞价数占实际发送请求数的比率。(放弃竞价数/实际发送请求数)
  • 有效竞价数 :素材及广告主等符合投放约束(可投)并成功响应的竞价数。
  • 无效竞价数 :素材及广告主资质未审核通过、禁投行业及分类、响应超时、解析错误等等原因造成的竞价次数。通过该指标Adx可评估各DSP的技术及执行管理能力,并协助DSP降低该数。(参与竞价数 - 有效竞价数)
  • 响应超时数 :接收到某DSP网络失败或响应超时(一般要求<100ms)的数量。
  • 响应超时率 :某DSP响应超时数占实际发送请求数的比率。通过该指标Adx可评估各DSP的Bidder技术能力及网络状况,并协助DSP降低该率。(响应超时数/实际发送请求数)
  • 解析错误数 :某DSP竞价返回的数据包格式错误等原因造成Adx解析失败的数量。
  • 解析错误率 :某DSP返回包的解析错误数占实际发送请求量的比率。通过该指标Adx可评估各DSP的Bidder技术能力及最新接口规范遵守程度,并协助DSP降低该率。解析错误数/实际发送请求数
  • 竞价成功数 :某DSP成功竞得广告曝光机会的数量
  • 竞价成功率:某DSP竞价成功数占出价数的比率。通过该指标Adx可评估各DSP的出价算法能力、及对热卖资源的争抢,并协助DSP提升该指标。(竞价成功数/参与竞价数)
  • 竞价失败数 :某DSP在竞价中因竞价不是最高导致未胜出的数量。(有效竞价数 - 成功竞得数)
  • 竞价失败率:某DSP竞价失败数占参与竞价数的比率。(竞价失败数/参与竞价数)
  • 流量利用率 :某DSP竞价成功数实际发送请求数的比率。通过该指标Adx可评估各DSP的对流量的利用情况,并协助DSP提升该指标。(竞价成功数/实际发送请求数)

从DSP角度看一些数据指标(所以这些数据都是DSP看到的数据,未必是Adx看到的数据,因为其中存在一定网络损耗):

  • 可用流量总数:Adx的总流量,可发给DSP的竞价请求总数,可理解为可用库存量。(某些Adx可给DSP在自助系统中显示该数)
  • 过滤后的请求量 :DSP在Adx自助平台中可设置定向过滤条件,过滤后的竞价请求数,如过滤某些尺寸或网站等等。(某些Adx可给DSP在自助系统中显示该数)
  • 实际接收请求数: DSP实际接收到的竞价请求数。一般:DSP实际接收请求数<Adx实际发送请求数;DSP同Adx尽量配合希望减少GAP。
  • 实际接收率 :DSP实际接收到的竞价请求数占Adx可发竞价请求总数的比率。一般DSP会依据这个来评估Adx QPS及DSP QPS。实际接收请求数/可发竞价请求总数
  • 参与竞价数 :DSP参与竞价的数量。
  • 参与竞价率 :DSP出价数占实际接收请求数的比例。通过该指标DSP可评估某投放策略设置的出价是否太低或定向太窄。 参与竞价数/实际接收请求数
  • 放弃竞价数 :DSP放弃竞价的数量。 实际接收请求数 – 参与竞价数
  • 放弃竞价率 :DSP放弃竞价数占实际接收请求数的比率。 放弃竞价数/实际接收请求数
  • 有效竞价数 :素材及广告主等符合投放约束(可投)并成功响应的竞价数。
  • 无效竞价数:素材及广告主资质未审核通过、禁投行业及分类、响应超时、解析错误等等原因造成的竞价次数。通过该指标分析DSP自查投放的素材及广告主资质及行业是否合规,尽量降低该数。(参与竞价数 - 有效竞价数)
  • 响应超时数: DSP网络失败或响应超时(一般要求<100ms)的数量。这个数DSP通过Bidder是收集不到的,只能经常同Adx对数或在Adx的DSP自助后台中才能看到。
  • 响应超时率 :DSP响应超时数占实际接收请求数的比率。这个指标重点可评价网络状况,并尝试通过优化网络来降低该率。 响应超时数/实际接收请求数
  • 解析错误数: DSP竞价返回的数据包格式错误等原因造成Adx解析失败的数量。这个数DSP通过Bidder是收集不到的,只能经常同Adx对数或在Adx的DSP自助后台中才能看到。并尝试通过对比最新的接口规范来看是未按新规范开发还是Adx流量未按规范处理。
  • 解析错误率 :DSP返回包的解析错误数占实际发送请求量的比率。通过该指标可评估DSP及Adx对最新接口规范遵守程度,DSP通过对比最新的接口规范来看是未按新规范开发还是Adx流量未按规范处理,来降低这个比率。(解析错误数/实际接收请求数)
  • 竞价成功数 :DSP成功竞得广告曝光机会的数量。
  • 竞价成功率 :DSP竞价成功数占参与竞价数的比率。通过该指标DSP可评估投放策略的出价及出价算法能力、及对热卖资源的争抢,并并找出什么原因导致竞价成功率低。并不断优化。这也是DSP运营执行中项目运营执行人员及算法十分关注的指标。(竞价成功数/参与竞价数)
  • 竞价失败数: DSP在竞价中因竞价不是最高导致未胜出的数量。(有效竞价数 - 成功竞得数)
  • 竞价失败率:DSP竞价失败数占参与竞价数的比率。(竞价失败数/参与竞价数)
  • 流量利用率 :DSP竞价成功数实际接收请求数的比率。通过该指标DSP可对Adx流量的利用情况,并找出什么原因导致利用率。 (竞价成功数/实际接收请求数)

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

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

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-19

7月15日15点机械工业出版社3号楼10层会议室流水课通知“RTB”

以下为7月份的活动安排,我们不见不散:

活动时间:2017年7月15日 周六下午 15:00——17:00

活动详细安排:

14:50-15:00 签到与自我介绍

15:00-16:30 吴俊老师分享

16:30-17:00 全体同学自由social时间

在讲解过程中,如果你有任何问题,可随时提问。

活动地点:北京 西城区 百万庄大街22号机械工业出版社3号楼10层会议室

乘车路线:地铁6号线 车公庄西站 D西南口出。

报名方式:

第一步:添加微信号:13121124046(伍刀刀);

第二步:填写报名表,并缴纳200元报名费(单次体验票¥200,欢迎大家选购超实惠的¥1920年包套餐、或¥4188VIP年包套餐);

第三步:活动当天来到活动现场签到参与。

另外,为了满足无法亲临现场同学的需求,此次活动我们增加了线上同步直播及视频回看。

如何参加线上直播及视频回看?

第一步:添加微信号:13121124046(伍刀刀);

第二步:填写报名表,并缴纳200元报名费;(单次体验票¥200,欢迎大家选购超实惠的¥1920年包套餐、或¥4188VIP年包套餐);

移动端、PC直播地址: http://mudu.tv/watch/967984

第三步:我们会将以您手机号作为唯一识别码加入直播间,给您可以在线直播互动及视频回看的课程地址参与活动。

直播将以视频形式进行,而且能够进行互动,我们将回答您在直播间提出的每个有价值的问题。而且若您时间上冲突,依然可以等有空的时候回看即可。

如您在报名中遇到任何问题,请拨打电话或添加微信:13121124046(伍刀刀)随时联系我们。

以下《广告交易实战-RTB》讲解提纲:

——100页ppt

主要内容:

什么是RTB?

市面上常见的adx,及其特点、资源量盘点

Adx- DSP审核流程

各Adx审核注意事项 – 素材拒审原因示例

各Adx创意渲染差异细节(偏技术)

ADX系统基础操作功能介绍

ADX - SSP卖方基础操作功能介绍

ADX – DSP买方自助基础操作功能介绍

锋暴研习社:由国内知名营销人士吴俊、宋星等人发起,致力于打造一个营销界内的学习社群,开设极具价值的营销系统课程,持续不断的输出原创营销干货,定期举办线下讲座、沙龙活动,使圈内的每个营销人得到快速成长与提升。

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

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-31

6月17日15点机械工业出版社3号楼10层会议室流水课通知“监测&移动”

以下为6月份的活动安排,我们不见不散:

活动时间:2017年6月17日 周六下午 15:00——17:00

活动详细安排:

14:50-15:00 签到与自我介绍

15:00-16:30 吴俊老师分享

16:30-17:00 全体同学自由social时间

在讲解过程中,如果你有任何问题,可随时提问。

活动地点:北京 西城区 百万庄大街22号机械工业出版社3号楼10层会议室

乘车路线:地铁6号线 车公庄西站 D西南口出。

报名方式:

第一步:添加微信号:13121124046(伍刀刀);

第二步:填写报名表,并缴纳200元报名费(单次体验票¥200,欢迎大家选购超实惠的¥1920年包套餐、或¥4188VIP年包套餐);

第三步:活动当天来到活动现场签到参与。

另外,为了满足无法亲临现场同学的需求,此次活动我们增加了线上同步直播及视频回看。

如何参加线上直播及视频回看?

第一步:添加微信号:13121124046(伍刀刀);

第二步:填写报名表,并缴纳200元报名费;(单次体验票¥200,欢迎大家选购超实惠的¥1920年包套餐、或¥4188VIP年包套餐);

移动端、PC直播地址: 617监测及移动

第三步:我们会将以您手机号作为唯一识别码加入直播间,给您可以在线直播互动及视频回看的课程地址参与活动。

直播将以视频形式进行,而且能够进行互动,我们将回答您在直播间提出的每个有价值的问题。而且若您时间上冲突,依然可以等有空的时候回看即可。

如您在报名中遇到任何问题,请拨打电话或添加微信:13121124046(伍刀刀)随时联系我们。

以下《数字营销实战-监测&移动》讲解提纲:

——29页ppt

授课时间:1次课,放在6月份

主要内容:

市面上供应商简单分析

地域GAP

视频广告投放TA浓度KPI注意事项

广告可见性 IAB规范

移动端的特有的一些问题

移动设备ID标准

移动web cookie不稳定

DeepLink

移动端MRAID 富媒体技术

锋暴研习社:由国内知名营销人士吴俊、宋星等人发起,致力于打造一个营销界内的学习社群,开设极具价值的营销系统课程,持续不断的输出原创营销干货,定期举办线下讲座、沙龙活动,使圈内的每个营销人得到快速成长与提升。

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

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线下大课堂》面对面为您答疑解惑讲透您关心的问题。