博客首页|TW首页| 同事录|业界社区
2017-04-11

《大数据基础》《受众数据》之后,我们继续DMP相关的内容:

数据管理平台

数据要想发挥出价值,就需要一个集中采集、存储、处理、分析、输出运用的系统平台。下面我们就数据管理平台的定义、构成及价值意义展开介绍。

1 什么是DMP

DMP(Data Management Platform)即:大数据管理平台。

需要一个大数据平台将线下、线上、内部、外部的海量数据管理起来,并分析处理,为实际业务运用做储备。

2 Data Management 流程

不论是第一方、第二方、第三方大数据管理数据处理流程都是一致的,尤其重要的是运用价值,无运用价值的Data是无用的Data,切不可为了“Big Data”而“Big Data”。大数据处理流程示意图如下:

3 DMP的系统构成

大数据管理平台是完整的,对大数据进行管理的软件系统,其中会包含各种基于大数据的软件功能。

不论是第一方、第二方、第三方大数据管理平台的内部整体架构,及数据处理流程都是一致的。都是需要基础的数据采集、清洗、分析、运用的功能。没有运用价值的DMP是无用的DMP,切不可为了“DMP”而“DMP”。

区分不同DMP平台最大的差别在于:

1)       采集的数据不同差异性

2)       运用方向上功能的差异性

DMP系统从底层数据采集,到上层可视化输出的架构层次,参见如下“DMP架构示意图”:

4 DMP价值意义

几年前,大数据的概念就炒的很火,但当时在广告主实际业务中,并没有能够实现落地。因为当时基础设施还不完善、行业上下游的认知还不一致、大家还没有能力打通数据资产。现在有很多广告主开始做大数据,是因为基础设施已经基本成熟了,接下来就是如何在各个行业中开花结果啦。大数据在营销领域主要可以从这么几个方向上创造巨大价值(但不局限于这些方向)。

  • 消费者洞察、产品建议;
  • 媒介渠道效率分析;
  • DMP对程序化广告的指导;
  • 对管理、战略等业务决策的数据支持。

等等

5 线下DMP

相对线上用户数据而言,线下用户行为数据更加可靠。比如用户去机场,出行意图非常明显。所以如果我们能掌握精准的线下用户数据,并进一步能打通线上和线下用户数据,这样的价值和意义就十分巨大啦。

5.1 线下数据采集

随着线下数据采集技术、各种智能硬件的发展,WIFI、Beacon、摄像头、RFID、NFC等等,新的线下数据采集手段也日新月异。物联网将成为未来工业界升级的关键。而大数据的处理方法、流程不变,变的是“数据采集”的对象和内容:线下用户行为。

5.2 线下行为特点

线下行为相对线上行为,还是有一些比较有意思的特点的:

1)       成本

线上行为更多的是用户动动鼠标或者手指。而线下行为,用户是要出行到店铺现场的。相对来说出行成本大于指间运动成本的,所以相对来说,用户目的性会更强一些。比如用户在网上看车的,同直接去4S店看车的行为做比较,去4S店的,购车意愿和目的性会相对强烈一些。

2)       群体

线上的行为因电脑、手机屏幕的局限性,大多还是以个体交互的居多。而线下购物、逛街等等,很多时候都是几个人一起的。这是线下行为有意思的差异点。所以我们在线下数据分析的时候,也需要多多留意。4S店线下客户分组分析的示例截图如下:

3)       现实

互联网对很多用户而言,毕竟还是个虚拟的世界,很多人会关注一些现实世界中不怎么关注的内容。举个例子:在搜索引擎中搜索奶粉的不一定是妈妈,很有可能是爸爸。所以线下的数据相对而言,更加真实,更贴近现实社会的经济活动。

5.3 消费者洞察

基于线下数据的消费者洞察,相对线上更贴近现实,更代表消费意图,是十分典型的目标受众分析样本。所以对这些典型用户进行调研问卷、线上行为数据采集、线下行为数据采集。然后得出这些典型用户的人口属性、兴趣特征的洞察,对调整产品的定位,以及功能特性,意义巨大。线下店面人群画像示例截图如下:

5.4 渠道效率分析

只要掌握了线下的用户数据,并打通线上数据的设备ID,就能十分轻松地比对线上广告投放,对线下引流到店的贡献。通过这样的线下线上的闭环,大大提升了媒介效率。线下线上闭环分析流程示意图如下:

其实线下的用户数据分析,还能分析各种不同线下渠道的效率。线下经销商客流关联分析示例截图如下:

5.5 数字营销指导

线下到店的人群往往都是产品的重度用户,基于这些用户作为样本,进行行为学习,来寻找更多具备类似特征的潜在客户。并通过程序化广告的手段来进行广告投放。这将使得精准营销的方向更落地,也更实效。线下用户行为指导线上数字营销示意图如下:

6 Data Hub

随着第三方数据供给方的丰富。广告主对这些数据的兴趣和运用的渴望日益强烈。所以很多DMP、DSP、TradingDesk也纷纷提出了“数据集线器”,“数据融合”的概念。

7 Data交易市场

在国外,有些ADX会为DSP提供(可直接技术手段对接使用的)Data交易市场。各DMP供给方,可根据自身的数据特点,在Data交易市场中售卖数据。

国内虽然也出现了一些数据交易市场,但都是为“线下数据买卖”提供的交易场所。并不是通过技术手段对接的数据服务交易市场。

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

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

2017-04-10

上篇《大数据基础》我们重点是围绕数据核心“人的唯一性标识”进行的阐述。下面我们将从受众的大数据处理流程及运用层面展开。

1.线上数据、线下数据

用户会在线上、线下产生大量的不同特点的行为数据。

线上数据大体有:

  • 用户浏览网络的行为:指记录用户在PC + Mobile上浏览网络的行为数据。这类数据的主要有:描述哪个用户在哪个时间点、哪个地方,以哪种方式完成了哪类行为,从而了解受众行为偏好。包括:用户ID、用户行为、用户设备、IP、URL、地理位置等等数据。
  • 站内与销售数据:指用户在广告主官网、EDM、电商网站或APP中产生的行为数据,往往对应着非常明确的目标用户及其兴趣。例如:站内流量、搜索、浏览、比价、加入购物车、购买、页面停留时间、注册情况、留言等等数据。
  • 社交数据:指用户在微信、微博、QQ、论坛等社交网络中产生的数据。包括:社交账号数据、受众属性数据(性别、年龄、学历等)、行为兴趣数据等等。

线下数据大体有:

  • CRM系统中的用户数据等等;
  • 用户到店的数据等等;
  • 用户线下的位置、轨迹数据等等。

2.Data的获取来源

一般我们会从数据的拥有方,及获取来源,将数据分为三类(以下是以广告主视角来举例的):

  • 第一方数据:广告主内部数据(CRM)及广告主官网布码、线下店面安装设备收集到的数据;
  • 第二方数据:广告投放方(媒体方、DSP方等)通过广告投放获取到用户对于该广告在媒体上的互动的数据;
  • 第三方数据:同广告主无任何关系,第三方数据供应商提供的数据。例如:第三方监测公司、其他脱敏数据(剔除用户隐私内容)。

数据的类型可以有很多,不仅仅局限于广告投放数据,还包括各种线下、线上、CRM、调研、第三方等等各种数据。

数据的采集、打通、管理、分析、运用成了重点。

跨屏识别方法与挑战

这里提到的跨屏识别,主要指的是跨移动/PC跨设备识别。而不是有些人说的不同App之间(通过设备ID),或者不同Web网站(通过CookieMapping)之间的。

很多监测方或技术商,号称可以跨移动/PC跨设备识别。但实际上,除了只能使用会员账号ID来打通之外,没有别的办法。

有些监测方会使用,用户上网IP的统计学方式,来模糊统计。但由于目前存在大量局域网,使用同一上网IP出口,再加上上网出口“IP漂移”等等问题,这种统计结果准确率有待商榷。

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

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

2017-04-05

摘要:最近群里有同学问广告API对接怎么回事,这里发篇简单的文章介绍一下各种不同的流量技术对接的注意点。

对接各类媒体对应的主要技术方式:

注:除APP端、服务端对接需增加cookie mapping

一、PC/移动Web

1.JS代码(JavaScript)

媒体卖方通过排期系统投放买方系统的JS代码。

广告的展示及用户浏览网页的相关数据的获取均由该JS代码处理。

省去双方CookieMapping的问题。

此方式技术对接快,一般1-2个工作日就能完成技术对接。

但这种方式由于媒体卖方丧失了对流量的控制权,若不是预算足够大,媒体卖方不太支持该模式。

2.API

服务端接口对接,大都采用基于OpenRTB标准协议基础上进行定制的方式。

双方需要进行CookieMapping。

此方式技术对接周期较长,一般1-2个月才能完成技术对接。

这种方式由于媒体卖方可对流量进行控制,是常见的技术对接方式。

二、移动App

1.SDK

广告的展示及用户手机的相关数据的获取均由SDK代码处理。

SDK采用自己的设备ID规范,不需双方统一设备ID规范。

此方式技术对接快,但存在一个App新版本发布的更新周期,一般3月左右。

但这种方式由于媒体卖方丧失了对流量的控制权,若非小媒体,稍大一些的媒体卖方一般均不支持该模式。

2.API

服务端接口对接,大都采用基于OpenRTB标准协议基础上进行定制的方式。

双方需要遵守统一的设备ID规范。

此方式技术对接周期较长,媒体方技术已准备好的情况下一般也需要1个月才能完成技术对接。(若媒体技术未准备好,则可能需要花近半年左右的时间进行改造,改造的核心就是媒体每次广告曝光机会需请求服务器申请精准的广告,而不是之前提前已按排期下发获取广告的模式。)

这种方式由于媒体卖方可对流量进行控制,是常见的技术对接方式。

三、视频

视频广告常用VAST及VPAID作为标准协议规范,下面就给大家简单介绍一下:

1.VAST对接模式,参见文章:《VAST实用知识》

2.VPAID广告播放容器对接模式,参见文章:《VPAID要点》

3.API

服务端接口对接,大都采用基于OpenRTB标准协议基础上进行定制的方式。具体内容类似上述PC及移动App的内容。

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

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

2017-03-28

近年来整体数字营销行业的发展呈现出三大趋势:

第一个趋势:广告主越来越重视数据资产,他们将自己的大数据沉淀下来,然后建立大数据系统。其实在两年前,很多广告主就想做大数据资产沉淀,但直到现在才有可能真正落实,开始基于数据资产,优化数字营销能力。

第二个趋势:很多企业开始发展自己的大数据技术,结合原有的数据沉淀,自己建设数字营销DSP平台投放广告。

第三个趋势:广告主在打通线上和线下大数据,构建闭环生态方面,也有很大诉求。

可见大家越来越重视数据,大数据越来越成为数字营销、程序化广告的重要基础。大数据就是通过各种数据采集手段采集到线上线下的用户行为数据,经过清洗、分析、管理并结合营销业务,从基础业务运行支撑、报表分析、人群画像、销售自动化、营销精准化、决策支持等等各个方面发挥巨大价值。而大数据是跨学科的领域,会涉及到技术、业务等等很多方面的内容。本章会花较大的篇幅从必备的一些基础知识进行阐述,后续实战的很多内容都是基于这些基础概念和知识的。所以建议大家认真学习。

人的唯一性标识

大数据营销首要的就是分析目标受众,并针对目标受众的特点及其当时的场景进行有效地营销活动。收集的海量数据也是基于人为核心的。所以追踪个体用户行为、对人的唯一性标识是营销大数据的关键。

1.人唯一性标识的方式

标识一个人的方式可谓是丰富多样:

  • 对于真实世界中,日常工作生活中常用身份证件号(身份证、护照等各种证件)来标识一个人;
  • 在医学上常用DNA鉴定的方式类标识一个人;
  • CRM系统中常常以手机号来标识一个人;
  • PC端的Web网站对于用户的浏览行为常常使用CooikeID来标识;
  • 很多网站及服务常用会各种会员ID来标识一个人, 社交中我们常用QQ号、微信号等等;其他各种服务也会存在着各种会员ID。为了避免遗忘这些会员ID我们可能都经常需要一个小软件来帮我们管理这些ID;
  • 手机设备App端常用设备ID来标识一个人。

等等等等,可见对人的唯一性标识极其的复杂且重要。

2.数据互通的核心–ID Mapping

我们可以发现标识一个人的方式实在是花样繁多。大量的用户数据由于其产生和采集的场景区隔性的特点,造成了大量的数据花园围墙。单独的数据孤岛能创造的价值十分有限。所以ID mapping成为数据互通的核心,只有ID首先能打通才有可能联通各个数据孤岛,促进数据流动创造数据价值。

3.PC端识别技术

PC端,用户在互联网上主要是通过浏览器浏览内容,及完成相应的业务操作的,所以Cookie是PC端标识用户的重要技术。相关内容详情请阅读文章《什么是CookieMapping》

4.移动端识别技术

详情请阅读历史文章《移动数据关键ID系列》:

移动设备ID烦恼知多少?【技术类】

IOS体系ID知多少?【技术类】

Android体系ID知多少?【技术类】

媒体注意:Android设备ID大洗牌【行业动向】

蓝瘦香菇的ADX移动ID【技术类】

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

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

2017-03-26

4月15日15点机械工业出版社3号楼1002会议室流水课通知

“大数据基础(上)”

活动时间:2017年4月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年包套餐);

移动端直播地址:

http://mudu.tv/?c=activity&a=live&id=41706

PC端直播地址:

http://mudu.tv/watch/719002

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

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

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

吴俊老师简介:

吴俊老师是中国广告PDB(Programmatic Direct Buy 私有程序化购买)第一人。现任掌慧纵盈高级产品总监,专注于线下数据线上打通营销解决方案,推动数字营销新升级。

更多朋友们对于吴俊老师的了解来自于他此前在品友的工作经历。吴俊老师是原品友负责PDB/移动/流量的产品总监,拥有16年以上IT/互联网行业从业经验和超过5年的程序化广告工作经验。他在2014年负责推动了中国首个PDB广告投放项目(2014中国国际广告节长城奖金奖上海通用汽车私有程序化广告投放案例),通过PDB帮助广告主管理了数亿广告预算投放,在广告主包段的门户及垂直媒体PC和移动端黄金广告位以及视频媒体贴片黄金资源,实现了广告投放的跨媒体联合频控、千人千面;最终有效提升了广告主广告预算的ROI:CPUV降低至少30%以上(即相同的预算覆盖更多的受众);平均CPL降低20%以上(降低销售线索的获得成本,同时广告主反馈后续CPQL验证及后续转化效果也比较好)。

2014年底2015年初在市场反馈十分巨大的视频广告PDB领域持续发力,推动行业内视频广告PDB业务大规模迅速发展,目前市场上已有上海通用汽车、玛氏、欧莱雅、人头马、Burberry、高露洁、黑人、雅士利等等等等不同行业,近百广告主近千视频OTV项目通过PDB方式进行了投放。无论是对效果营销客户还是品牌营销客户,吴老师都有极为广博的经验。

以下为本两次活动——《大数据基础》讲解提纲:

——160页ppt

授课时间:分为2次课,分别放在4月份1次课、5月份一次课。

主要内容:

DMP价值意义

什么是DMP

Data类型

DataManagement 流程

DMP的系统构成

数据互通的核心 –ID mapping

移动设备ID专题

Cookie原理

什么是cookie

种cookie的流程

种cookie的指令

跨域名cookie不可被获取

CookieMapping的重要性

Cookiemapping率的重要性 –mapping率越高数据利用率越高

cookiemapping原理

单向cookie mapping

双向cookie mapping

cookie mapping发起方及时机点

DMP对程序化广告的指导

线下DMP

线下数据采集

消费者洞察

渠道效率分析

数字营销指导

Datahub

data交易市场

市面上常见的第三方数据供应商,及其特点

DMP系统案例分享

Trading Desk & DMP & PDB(PMP)案例:某知名乳品大数据驱动数字营销管理系统

线下DMP系统案例分享

某大型国际知名车企全国4S线下到店大数据管理系统

专有线下DMP+DSP案例

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

2017-03-22

备注:增加玩咖ADX、更新猎豹移动信息:十分感谢同学们的积极反馈,已根据反馈的信息更新内容。这些内容将随书籍印刷出版。

一般会根据ADX对其主要媒体资源的拥有关系,我们会将ADX分为:

  • 公共(也有称为“公开”)综合ADX:ADX不拥有媒体资源,十分典型的中间撮合买卖双方的角色。常见的有:baidu的BES、阿里的TANX、google的ADX、360的MAX等等。这类ADX的特点是流量大、价格低,但流量质量参差不齐,大量以长尾的流量为主,当然也有少量垂直领域头部媒体(自己没有建立ADX的媒体)的剩余流量。
  • 私有ADX:此类ADX从属于主要的媒体方,以媒体方的资源为主体。典型的例如:几大门户类媒体的ADX(腾讯、新浪、搜狐等等)、视频类媒体的ADX(youtu、IQIYI、乐视等等)、新锐移动媒体的ADX(小米、陌陌等等)等等。这类ADX中的流量质量因是媒体自己的流量,相对质量好一些。当然价格会稍微贵一些。(有的时候出于为了拉低整体买方成交成本的诉求,这类ADX也会在自身的流量之外,会引入外部的其他一些较为便宜的媒体流量。)

下面所列为常见的ADX

(注:排名不分先后。相关内容因有一定时效性,其中的内容请读者不用太过追究,请以各ADX最新的数据为准,此稿仅供参考。主要目的是希望大家能通过该表对各ADX的大体情况有个初步的概念。而且市场上的ADX还有很多,就不一一都罗列了。)

公共综合类ADX(PC、Mobile、视频)

移动为主的公共综合类ADX

媒体私有ADX(PC、Mobile、视频)

移动为主的媒体私有ADX

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

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

2017-03-19

卖方诉求

虽然程序化广告购买是行业大势所趋,但还是有很多媒体卖方拼死抵抗,尤其是那些已建立了庞大传统销售体系的卖方更难转型。只有市场搅局者希望用新模式重新洗牌(他们才是初期的主要行业推动力)。所以我们要充分的理解卖方的诉求才能很好地同卖方打交道,推动行业良性发展。

  1. 不能因增加某种业务模式,而减少另一种(成熟)业务模式的收入
  2. 不能因为某业务模式,冲击另一(成熟)业务模式的价格
  3. 不能为了迎合买家,贱卖
  4. 程序化广告售卖剩余流量在很多媒体目前仍是 “增量” 收入,在整体收入20-30%左右,并非传统稳定的收入。

(一)价格保护

对于存在竞价的场景中:

卖方可以通过一些底价规则保护一些特殊库存或通过分类售卖或排除策略排除一些买家

典型案例:

1. 大部分视频媒体私有adx对不同行业都执行不同的底价政策:

游戏、电商、品牌、其他(中小)

很多视频媒体Adx都有类似的政策

2. 对于北上稀缺的视频前贴片的资源底价为天价:

部分视频媒体存在这个现象。

(二)卖方核心诉求

媒体卖方中的不同工种角色对程序化广告的态度和核心诉求也不同。所以我们也需要充分理解并合理应对。

  • 卖方销售:关心的是总销售盘量是否会增加,若简单的从一种模式转移到另一种模式。卖方的动力不大。
  • 媒体运营:用户日活数据不可暴露,这是媒体十分敏感的数据。会直接影响到媒体在市场中的位置以及媒体商业变现的体量。
  • 媒体产品:用户的体验及隐私数据的保护,是媒体方产品最最关心的问题。不能因为程序化广告的加入影响了用户体验(例如:响应速度、用户注意力、不能误导用户),或侵犯用户的隐私数据等等。

这些都会是行业升级过程中会遇到的阻力。我们只有深刻认识才能以多方共赢为出发点找出解决方案。

目标人群投放(TA-Target Audience)

对目标人群进行筛选流量投放广告是才能达到我们所讲的“在合适的时间合适的上下文场景推送合适的信息”。这就需要流量方开放用户的行为信息。在流量中携带用户行为的相关数据,所以某种意义上可以说程序化广告购买是流量媒体卖方一种数据变现的方式。

(一)用户行为信息保护

一般卖方会根据自己的考虑适度开放,这点是程序化购买模式中的一个十分重要的功能。这些信息对精准分析用户的相关属性特别关键,尤其是若广告主存在目标人群分析强烈的需求,就需要建议卖方开放足够多的信息。

例如:

a.媒体的顶级/子域名

b.媒体的频道/栏目

c.用户访问的媒体页面的完整URL(Full URL)(强烈建议此模式)

d.媒体URL保护处理:

e.完全不提供,买方完全不知道购买的何处的媒体库存。

视频媒体的流量中还存在:剧目、频道等重要信息;移动端有LBS信息等等。

注意:移动端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、2G、3G等)等等。

(三)目标人群投放

在程序化购买模式中存在大量的对目标人群数据的使用。这些数据主要来源于:

a. 之前campaign投放的广告主方的第一方数据(点击、到达、转化),访客找回(retargeting)效果较好;

b.竞品或其他第三方监测收集的之前campaign投放的的第三方数据;

c.(第三方)DMP供应商按广告主提供相关标签及Look-alike挖掘出的第三方数据;

d.以上数据为样本,及结合投放中的执行数据优化行为数据挖掘出的人群数据;

e.目标人群排除也很常见;

需说明的几点:

1.首要前提是要有人群数据库 及 已打过标签分析过的人群数据库;

2.retargeting效果较好;

3.割裂的DMP数据,脱离了投放执行环节的数据无法持续优化及提高绩效;

4.PC端,cookie需mapping后,积累的cookie才能被使用。

相关的常见词:Data Usage、DMP- Data Management Platform、TA-TargetAudience、AP-Audience Platform

本系列历史文章:《程序化广告4种典型模式》​、《流量优先级和交易管理》​、《OpenRTBv2.5》

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

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

2017-03-14

什么是Deep Link

“Deep Link”从字面上理解是“深度链接”,因为移动端的媒体内容页面都是在APP中打开的,最早推出“Deep Link”的主要意图是,为了能让搜索引擎能检索APP中的内文页内容,并在用户检索到内容时,可通过简单点击一个“链接”直接打开该APP的内文页。简单讲就是,可以通过一个简单的“链接”,打开APP并直接进入该APP中的内文页,前提是该APP在该手机上已安装,且该APP需要编程支持该Deep Link的“schema”语法定义。例如:大家可复制如下的淘宝商品及淘宝店铺页的Deep Link链接,在手机浏览器中打开,便可直接进入淘宝APP中的商品页及店铺页:

 taobao://item.taobao.com/item.htm?id=440…

 taobao://shop.m.taobao.com/shop/shop_ind…

可见在移动端广告投放中采用Deep Link技术,省去了用户打开APP、再搜索商品页的中间环节,让用户只需便捷地点击广告,一键就能到达商品购买页面。省去中间多次跳转的环节,减少用户流失,有效提升转化。(当然该APP需要开发改造,编程支持Deep Link。)

APP没安装怎么办?

当然大家会问,若当时手机上没有安装这个APP会发生什么情况呢?在移动端广告投放中,可以采用加一个Mobile Web中间页的方式。在该中间页上安置JS代码来判断(通过Deep Link尝试调用手机APP),若手机上APP没有安装,则跳转到APP下载页面引导用户安装。若APP已安装则打开APP进入内容页。这样通过Deep Link也能有效地唤醒沉睡用户(那些已安装APP但还未持续产生转化的用户。)。

现在也有很多APP服务提供方,不论用户是否已安装APP,为了让用户能更容易的通过各种方式(Mobile Web、APP)触达到产品服务,会对应APP做一套简化版的Mobile Web的服务。由于URL使用的是普通的网站URL,相比Deep Link更容易传播,及被各种网站内容中引用,及被搜索引擎收录。例如,大家可复制如下的淘宝商品页的普通URL,在手机浏览器中打开,便可直接进入淘宝中的商品页(该页面中也有一些JS代码,会判断手机上是否已安装APP,若已安装,会提示用户是否打开淘宝APP):https://item.taobao.com/item.htm?id=44014690052

Universal Link

上面已讲到:很多APP服务提供方已经在提供普通网站URL方式作为中间也载体,便于传播和使用。这也就引出了一个新的规范:Universal Link(通用链接)。在iOS9以前,我们从外部启动App都是通过(Deep Link)一个特殊的URL Scheme实现跳转的。这种方式弊端很明显:我们只能通过scheme://example这种格式的链接来实现跳转,而且现在苹果还对这种方式的跳转加了一个提示框:“是否打开XXX”。对于Web和原生App交互的场景需求量很大的产品来说,这样的跳转方式显然是步骤繁杂的,用户体验并不好。

当然需要强调一下为了保证用户网络安全,该“通用链接”必须是HTTPS协议的。

在APP中添加这个功能很简单,相关参考文档可参考官方文档(点击文末“阅读原文”可直接打开):

https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html

大体的步骤是:

1) 在苹果开发者网站中,打开需要使用Universal Link功能的App中的Associated Domains

  • 首先,我们要在苹果开发者网站中开启App的Associated Domains功能:在Account -> Certificates, Identifiers & Profiles -> App IDs -> YourApp -> Edit中把Associated Domains设置为Enable
  • 然后需要配置一下工程文件,找到Capabilities -> Associated Domains
  • 打开此功能并把“通用链接”的domain加进去,格式为applinks:http://www.example.com/

2) 将 “apple-app-site-association”(一个json文件)上传到服务器中根目录下(因为是HTTPS,所以服务器必须支持SSL;文件名“apple-app-site-association”不可添加任何后缀。),如:https://www.example.com/apple-app-association ,json内容示例如下:

{

“applinks”: {

“apps”: [],

“details”: [

{

"appID": "TeamID.com.domain.App",

"paths":[ "*" ]

}

]

}

}

注意:当APP在设备上第一次运行时,若已开启Associated Domains功能,那么iOS会自动去获取Domain下的apple-app-site-association文件,iOS会先请求https://domain.com/.well-known/apple-app-site-association 。若此文件请求不到,再去请求https://domain.com/apple-app-site-association 。所以若想要避免服务器接收过多GET请求,可直接把apple-app-site-association放在./well-known/目录下。服务器上apple-app-site-association的更新不会让iOS本地的apple-app-site-association同步更新,即iOS只会在APP第一次启动时请求一次,以后除非APP更新或重新安装否则不会在每次打开时请求apple-app-site-association。

3) 在AppDelegate中实现相应的方法,

示例代码如下:

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler{

if (![userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) {

return YES;

}

//读取url地址

NSURL *webUrl = userActivity.webpageURL;

if (![webUrl.path isEqualToString:@"/show"]) {

//path错误,直接从safari打开

[[UIApplication sharedApplication] openURL:webUrl];

return YES;

}

//跳转并显示内容

[[NSNotificationCenter defaultCenter] postNotificationName:@”notify” object:@”hello world”];

return YES;

}

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

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

2017-03-13

《程序化广告4种典型模式》​、《流量优先级和交易管理》​之后我们看看一下程序化广告关键的技术接口协议:OpenRTB_API_Specification

下载地址:

http://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf

是IAB指定的RTB竞价广告协议的规范,主要包括其生态图体系、业务流程和主要的对象模型和数据模型。基本负责流量技术对接的产品技术同学必须参考的文档。

现以《OpenRTB-API-Specification-Version-2-5-FINAL.pdf》为例给大家概要性地介绍一下该技术接口协议:

该协议首先介绍一些常用词,这些常用词也是我们经常会用到的:

常用词定义

RTB:实时竞价处理每个广告曝光机会投标(即,因用户等待广告结果整体处理时间极短,一般要求小于100毫秒)。

Exchange:对每个广告曝光机会之间进行拍卖的服务。(常称为广告交易市场(Ad Exchange))

Bidder:在广告实时拍卖中完成竞价的实体。(在此基础上完善的需求方的业务功能系统,常称之为DSP(需求方平台))

Seat:使用竞价服务代表其利益的交易席位。(竞价购买广告实际的出钱买方,常见的有广告主、广告代理公司等等,实际业务执行中他们可能不参与实际的竞价技术环节,但是他们给DSP下订单、并通过该“席位“的交易同Adx对账确保“透明化”。)(目前国内大部分Adx不支持该特性,仅google的Adx支持。)

Publisher:拥有一个或多个媒体的广告发布者。(是SSP系统的主要使用者)

Site:有广告位要展示的内容网站,包括Web、App等等。

Deal:广告卖方同买方以特殊的交易模式及特定的条款预先约定好的预订量合约。

该协议描述基础的RTB处理时序图:

0.用户打开媒体页面(媒体页面中有广告位需展示广告),媒体端向RTB交易服务(Adx)发起广告请求;

1.Adx向竞价服务方(DSP,广告主可在DSP添加广告投放订单)发起竞价(邀约)请求(传送竞价邀约请求、媒体网站、用户设备、用户相关行为数据等等);

竞价服务方返回竞价信息(竞价、广告素材或广告片段);

2a.Adx结果反馈:win-notice返回成交结果;

若竞价返回包中未含广告片段需要再次提供;

2b.有些Adx会发失败原因(注意:这个不是必须发的)。

3a.有些Adx会发成交账单信息(注意:这个不是必须发的)。

最后广告通过Adx返回给媒体并通过媒体展示给用户。

图上虚线流程:

a.媒体方可在Adx中设定媒体的相关属性设置(分类、底价、禁投行业等等)。

b.DSP可在设置接受竞价邀约流量的响应能力及所需流量过滤设置、创意审核等等。

协议中约定的广告请求对象内实体间的关系图如下:

(上图为“E-R图”即:“实体关系图(Entity Relationship Diagram)”,用于表示各实体对象间关系,“框”符号代表“实体”,“线”符号代表“关系”,“实心菱形”符号代表该“线”是“组成关系”,“实心菱形”所指的“实体”对象由“线”另一端的对象组成(即包含关系)(“0..1”代表符号这端对象被“线”另一端对象包含可0个但至多1个,“0..*”代表符号这端对象被“线”另一端对象包含可0个也可多个,“1..*”代表符号这端对象被“线”另一端对象包含至少1个也可多个)。拿“BidRequest”-“Imp”那个关系举例,通俗的说就是一个“BidRequest”可包含多个且至少1个“Imp”,这个可理解为有的时候为了节省网络开销,一个竞价请求可能会包含多个广告位的竞价信息(出现的场景很可能是用户一次打开内容页面时而同时产生的多个广告位的曝光机会)。)

换一种能直观展示包含关系的图例如下:

各数据段(对象)的简单描述参见下表:

对象(数据段)描述

BidRequest:顶级对象(代表整个竞价请求数据包对象)

Source:该数据段描述该广告曝光机会竞价决策的细节,是否该Adx决策或上游决策等等信息。(例如:header bidding就是由上游媒体决策的。)

Regs:该数据段描述该竞价请求中所有广告曝光机会是否存在任何法律、政府或行业法规的约束,例如:美国儿童在线隐私保护法等等。

Imp:描述特定广告曝光机会的数据段;每个竞价请求至少有1个该数据段

Metric:该数据段描述该广告位历史平均的数据,例如:CTR、广告可见性等等数据。

Banner:若广告位是广告横幅,该数据段描述该横幅广告位的细节(广告形式:横幅广告、横幅中的视频、或视频的旁的横幅广告),内容有:高宽尺寸、支持素材规格(mimes)等等。

Video:若广告位是视频中的广告位,该数据段描述该视频广告位的细节,内容有:高宽尺寸、支持素材规格(mimes)、最小时长、最大时长、序号(例如:一次竞价请求支持多个贴片广告,这个序号用于标识第几个贴片)等等。

Audio:若广告位是音频节目中的广告位,该数据段描述该音频广告位的细节,内容有:支持素材规格(mimes)、最小时长、最大时长、支持的API等等。

Native:若广告位是原生广告,该数据段描述该原生广告位的细节,内容有:支持的API等等。

Format:该数据段描述广告位允许的素材尺寸,例如:高宽比、高宽像素等等。

Pmp:若该该广告曝光机会是否存在已预订的PMP (private marketplace 的合约,该数据段描述用于描述这类合约的细节,内容有:是否私有交易、合约等等。

Deal:该数据段描述该广告曝光机会卖方买方双方预先约定好的合约内容。内容有:底价、成交方式等等。

Site:若是Web上的广告,该数据段描述广告曝光机会所在的网站的细节,内容有:网站名、广告所在页面URL、网站所属类别等等。

App:若是App上的广告,该数据段描述广告曝光机会所在的App的细节,内容有:App名、App是否为付费App、App所属类别等等。

Publisher:该数据段描述该网站或App广告发布者的细节,内容有:名字、域名、类别等等。

Content:该数据段描述广告将被展示的内容页的细节,内容有:关键词、语言等等。

Producer:该数据段描述广告将被展示的内容作者的细节,内容有:名字、分类等等。

Device:该数据段描述展示广告的设备的细节,内容有:ip、设备屏幕尺寸、地理信息等等。

Geo:该数据段描述展示广告设备的地理信息细节,内容有:经纬度、所属国家、所属城市等等。

User:该数据段描述展示广告的用户相关数据,内容有:用户基本的人口属性(年龄、性别)、位置信息、附加数据等等。

Data:该数据段描述展示广告的用户的附加数据,内容有:数据提供方名字、ID、相应的数据包等等。

Segment:该数据段描述附加数据的详细内容,内容有:一组键值对的数据包等等。

BidRequest包数据片段简单示例(一般都是Json(Content-Type: application/json)):

{

“id”: “80ce30c53c16e6ede735f123ef6e32361bfc7b22″,

“at”: 1, “cur”: ["USD" ],

“imp”: [

{

"id": "1","bidfloor": 0.03,

"banner": {

"h": 250, "w":300, "pos": 0

}

} ],

“site”: {

“id”: “102855″,

“cat”: [ "IAB3-1" ],

“domain”:”http://www.foobar.com“,

“page”:”http://www.foobar.com/1234.html “,

“publisher”:{

“id”: “8953″,”name”: “foobar.com”,

“cat”: [ "IAB3-1" ],

“domain”:”foobar.com”

} },

“device”:{

“ua”:”Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13

(KHTML, likeGecko) Version/5.1.7 Safari/534.57.2″,

“ip”:”123.145.167.10″

},

“user”: {

“id”:”55816b39711f9b5acf3b90e313ed29e51665623f”

}

}

协议中约定的买方广告响应对象内实体间的关系及同竞价请求对象相应的对应关系图如下:

(上面介绍“E-R图”符号中有个“剪头”符号,用以表示“剪头”所指的“实体”对象被“线”另一端的对象所关联(关联关系)(“0..*”代表符号这端对象被“线”另一端对象关联可0个也可多个)。拿“BidRequest”-“BidResponse”那个关系举例,通俗的说就是多个“BidResponse”对应一个“BidRequest”,这个好理解一个竞价请求自然会有多个Biider返回“BidResponse”。)

换一种能直观展示包含关系的图例如下:

各数据段(对象)的简单描述参见下表:

对象(数据段)描述

BidResponse:顶级对象(代表整个竞价返回数据包对象)

SeatBid:若出价有特定的买方交易席位,则该数据段描述该席位的细节,内容有:席位名等等。

Bid:该数据段描述出价的细节,内容有:出价、出价针对的广告曝光机会ID、广告素材ID、接收winnotice的地址等等。

BidResponse包数据片段简单示例:

{

“id”: “1234567890″,”bidid”: “abc1123″, “cur”: “USD”,

“seatbid”: [

{

"seat": "512",

"bid": [

{

"id": "1","impid": "102", "price": 9.43,

"nurl":"Conversant",

"iurl": "Conversant",

"adomain": ["advertiserdomain.com" ],

“cid”:”campaign111″,

“crid”:”creative112″,

“attr”: [ 1, 2, 3,4, 5, 6, 7, 12 ]

}

] }

]

}

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

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

2017-03-07

程序化广告有一些关键特征,对这些关键点的清晰认知可以帮助我们更好地了解程序化广告并运用好。

首先我们先来看看大家都经常关心的“流量优先级及交易管理”:

流量优先级管理:

卖方(媒体方)的可按不同的程序化购买的方式对流量按不同的优先级进行管理。

媒体方一般都有现成的传统广告排期投放系统可以按位置按时间设定投放计划。很多媒体的传统广告排期系统就支持对不同的广告主或者订单安排不同的优先级。

PDB基本是现有传统广告排期投放系统中锁定流量再对接PDB系统进行投放,所以流量的优先级同传统排期订单在一个优先级。

PD、PA、OA是媒体通过传统广告排期系统讲剩余流量导入Adx系统进行管理。(对模式及名词不清楚的可参见历史文章《程序化广告4种典型模式-IAB程序化定义系列【基础类】》

所以优先级从高->低一般如下:

常规订单及预留库存PDB订单(也可能根据大小客户在订单层面有优先级控制,不同媒体排期系统具体各有不同。)

->PD:非预留的库存量 + 固定价“First right of refusal”流量筛选

->PA:非预留库存 + 少量Buyers 竞价

->OA:非预留库存 + all Buyers open竞价

-> 最后是打底广告

(打底广告:一般为了避免广告位“开天窗”(即出现空白),一般需要媒体方设置打底广告。特别是在程序化广告的模式下,广告的交易是实时进行的,为了避免广告位的浪费,无人竞价购买时会展示打底广告。所以相对来说打底广告很便宜(例如视频媒体经常以游戏或医药行业的广告作为打底广告),有很多媒体会选择阿里妈妈广告联盟或百度广告联盟的广告作为打底。)

(HeaderBidding(OpenRTB 2.5中已加入):最近这段时间行业内Header Bidding这个词有些热,是从国外流入国内的,号称是一种新的程序化交易广告技术。Header Bidding实际是AppNexus首先大力推动的,它给Publisher增加了新的开放选择。因为目前国外DFP(Google Doubleclick For Publisher)依旧是PC网站集成最多的广告平台。AppNexus希望联手其它的SSP/ADX(例如OpenX、AOL等)一起通过这种方式撼动DFP的垄断地位。其机制简单理解就是媒体可在调用广告服务获取广告之前,通过Header Bidding技术提前对买家询价,若无买家出价则再调用广告服务,实现其收益最大化。一般媒体通常对接单个ADX/SSP,Heading Bidding可使得媒体保持这种合作之外,额外地可主动对接其他的买家(ADX/SSP/AdNetwork等)。目前是以PC的为主,移动则刚开始尝试。)


交易管理:

为了给不同的买方系统及广告主区分出不同流量的交易模式,所以技术上流量对接时是需要提前在流量中携带相应的Deal ID标识。买方根据对流量需求的紧迫程度及价值评估来决定是以OA的方式来竞价还是采用PD、PA的方式,不同的方式买方就需要按约定返回相应DealID标识以标示以那种模式获取流量。卖方不仅会通过Deal ID的方式来管理买方的交易模式,还会根据哪些广告主能使用该流量进行更细致约束管理。

(一)预订量标识(Deal ID)

所以我们能发现“Deal ID”的重要性:技术对接上在RTB技术接口的Server端对接,必须加入该预订量标识(Deal ID),才可完成PDB及PDPA等模式。


(二)Deal达成的过程及操作流程

  1. 卖方挂牌(媒体)在Adx中发布资源库存:价、量

SSP卖家Adx平台中自助操作发布资源,表单界面截图示例如下:

2. 买方在Adx预定流量,商定Deal

DSP买家可在Adx平台中自助操作,先从可供预定资源列表选取可预定广告资源,界面示例如下:

然后对该预定资源做相关设置,操作表单界面示例如下:

3. 买卖双方商议成功,预定流量达成Deal

Adx平台中,DSP自助界面中,已预定流量Deal结果列表界面示例如下:

4. 买方在程序化系统中录入约定的Deal ID,并实时竞价时由大数据机器学习引擎决策采用何种方式参与竞价。

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

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