博客首页|TW首页| 同事录|业界社区
2016-12-30

为了避免读者误读特别声明:此文是从DSP立场看:DSP投放时在哪些Adx上可做曝光宏替换。

“曝光宏替换”意味着客户及4A代理公司TradingDesk想要分出不同曝光的CampaignID、ChannelID、UserId、Domain等等。

各ADX平台是否支持曝光宏替换?清单如下(列表先后顺序随机,请不要误解为排名):

adview:是

google:是

好耶:否

baidu(BES):仅动态创意和js创意由支持,普通Banner广告不支持

暴风:是

风行:是

佳投:否

广点通:否

inmobi:是

iqiyi:是

乐视:是

灵集:是

新浪:是

sohu:否

tanx:是

腾讯:否

今日头条:是

响巢看看:否

youtu:是

ifeng:是

小米:是

咪咕:是

mopub:是

pptv:是

蜻蜓FM:是

新浪微博:是

互众:否

万流客:是

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

2016-12-29

摘要:为什么PDB是亿元俱乐部的游戏?PDB的课上有广告主方的同学提问她们能不能做PDB业务,我当时就回答了最少每年整体广告预算上亿,单媒体最少千万以上的预算消耗才玩的起PDB,为什么呢?

在展开正题之前,聊个有意思的引子,来引出这个话题:前次PDB的课上有一位广告主方的同学来听课,反馈课程“实际是讲给广告主代理和中下游从业者听的。来的人也是圈内人为主。”;而“通过活动介绍判断为面向甲方讲如何更好投放”。(关于本套系列实战系列流水课程受众群定位的介绍请参见文章《2017程序化广告实战流水课适合谁参加?》,请仔细阅读并评估是否适合自己学习。这里就不再展开。)

针对这位同学的反馈让我想到了这个有趣的话题:“PDB是有钱金主的游戏”。

所以PDB的课程大的代理公司的同学来听的会多一些;希望个人职业发展去往这些头部客户或者服务这些头部客户(亿元俱乐部)的同学会多一些。

为什么说“PDB是有钱金主的游戏”呢?

课上我曾经提到过,可能课程上信息量太大,大家可能容易忽略掉了,这里我再写篇问文章强调一下:

一、PDB业务门槛很高

主要高大上品牌广告主:

1.更注重品牌形象,预算充足(最少每年整体广告预算上亿,单媒体最少千万以上的预算消耗);

2.内部提升广告投放效率诉求强烈

二、PDB的一个首要前提是:广告环境或媒体的要求特别的高,如此高的要求非亿元俱乐部的头部广告主莫属了。

广告主既想要享受到程序化购买的优化手段,又想要满足自己对各类广告环境或媒体的要求。

广告主预算规模若不大,可能全是效果广告预算,可能直接选择SEM购买搜索引擎关键词就够了,根本没必要选择展示广告的程序化投放。更别说PDB模式了。

若单靠SEM买关键词遇到了瓶颈,需要一定的展示广告投放,完全可以直接找选择一些DSP平台进行展示广告投放即可。根本不用选择PDB模式。

当然若广告主觉得普通DSP中的流量太长尾了,希望媒体资源好一些,也可直接选头部媒体自有的DSP投放即可;例如:今日头条、腾讯广点通、腾讯智汇推、新浪扶翼、微博粉丝通、搜狐汇算、网易有道等等。也没必要选择PDB模式了。

只有当广告主每年有上千万投入在黄金媒体广告位上的时候才可能执行PDB模式。

三、PDB第二个重要前提是:技术设施成本高,如果总体广告投放金额不大的话是养不活供应商的

一般广告主方执行PDB项目一般都是要给PDB技术供应方3%左右(广告总投放金额)服务费的。如果总体的广告投放金额不大的话,是养不活技术供应商的。

而且很多玩PDB项目的广告主都是需要自建第一方DMP,这种都是需要大量投放的,所以如果不是有钱的金主是玩不转这个模式的。

四、PDB第三个重要前提是:给单媒体的预算大到媒体能承受技术改造增加以及运营人力增加带来以及增加中间环节造成数据的GAP而带来成本。

一般PDB的项目,尤其移动端固定位的PDB项目媒体方都是需要承受最少两个人2个月的技术改造成本的。

视频媒体视频贴片的广告位相对单一,技术改造成本可能不用每次都增加,但是需要承担因退量而造成的损耗。所以还是要预算大媒体才能接受。

同时媒体还需要承受被“扒光”的风险;日活数据的暴露、作弊成本增加等。

传统广告投放媒体都是按第三方监测数据同广告主进行结算的,一般数据GAP10%以内媒体是能接受的。而PDB模式意味着中间还要增加一个中间环节,势必还要增加10%的GAP。所以若预算不是足够的大,媒体不可能就范的。

PDB项目目前由于执行流程上增加了环节,势必媒体方还需要增加运营AE同学的工作量。

所以上述这些都点直接导致PDB的项目在媒体看来一年没有上千万的预算消耗,肯定是不会同意的。

正式因为PDB是有钱人的游戏,只有有钱的广告主请的起牛逼的4A广告代理公司,所以4A广告代理公司里的同学对PDB也是十分十分的关注。来参加课的同学也特别的多,问的问题也特别的多。

那么最后大家会问了,这么高的门槛,难道有那么多有钱的金主们呀?对的呀,有钱的金主很多的哟否则怎么养活那么多的牛逼的4A公司的呢:)。请看随后附的一些数据吧。可以预见到随着程序化广告的不断成熟,这些预算将在未来的几年都会慢慢变为PDB的预算的。

最后用几个参考数据做为我们今天“有钱人的游戏”的结束吧。

附:易观2016年3月发布的数据来看,2016年近3000亿广告预算规模。原文连接:

易观智库:2016中国程序化购买广告市场年度综合报告-Useit 知识库

附:大金主广告排行榜:

上图摘自:“4A广告门”微信号2016-09-13转载的一篇“21世纪营销”发的文章:《2016年上半年度广告投入排行榜》,文章链接如下:

2016年上半年度广告投入排行榜

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

文字的表现力毕竟有限,欢迎参加“1.7号的线下大课堂”面对面为您答疑解惑讲透“PDB有钱人的游戏”

2016-12-28

摘要:很有必要对这个系列流水课的目标受众和内容再次明确一下,便于大家更好地判断是否适合自己?

一、适合人群

课程设置由浅至深,如果您从2月份的第一次课“程序化广告的行业态势”开始听,那么此课程即使小白也是能听懂的。

课程主要面向的受众主要是整个从媒体、中间方、广告主整体程序化广告行业上下游执行及决策层面的工种的同学。所以该套课程的内容是不同于纯“网站分析”的课程,故一般参加的同学中广告主方的比例三分之一左右。

二、课程框架

本“程序化广告实战”流水课系列内容主要包括但不限于:

行业态势:程序化广告的前世今生,包括演变历史、现状与未来发展趋势、行业玩家比对分析;

私有交易市场及广告业务模式:私有竞价(PA)、程序化合约(AG)、优先交易(PD);

卖方视角的程序化交易:deal达成的过程、卖方价格保护、卖方核心诉求;

RTB:包括竞价机制、国内ADX资源盘点、审核机制;

DSP:包括原理、算法、国内DSP优劣介绍、优化方法论及案例;

PDB:包括基本原理、模式、投放案例、程序化合约+RTB联合模式;

移动端程序化:新的定向方式,包括LBS定向、跨域重定向、原生广告、围栏广告等;

效果监测:pre-click监测、post-click监测、视频广告投放TA浓度KPI注意事项;

DMP系统与实战:国内第三方数据供应商、DMP整体架构、系统案例分享。

课程内容原是应宋星老师邀请于9.24-25一起开的两整天大课的内容,
原价值¥8000的豪华课程内容的精彩回顾:《大数据营销与程序化广告实战》线下大课回顾

而因考虑到大家平时比较忙无法抽出2整天的时间,为了加强互动性,让所有学员能深度参与交流,改为每次2小时的流水课的形式来进行的。

课程专注于剖析“程序化广告实战”业务,深入浅出,从原理到产业上下游;重点是要从业务角度讲清楚各种技术手段、广告交易模式,程序化手段运用的场景和原因。

课程的目的希望能通过深度实战性的剖析让参加完课程的同学能知其然更知其所以然,更加能在实际程序化广告实践中知道各种坑,并知道怎么填这些坑。

主要实战素材来源于我这5年来随着程序化广告的发展,以及同广告主、代理公司、媒体、DSP同学推动实际业务时被大家经常咨询的问题点。加之我有近20年的技术底子,所以对问题的剖析会从技术基础原理为大家讲透讲清楚。

之前在《独立DSP未来预测——数字营销2017职业鸡汤》文章中曾强调过:未来程序化广告这个行业一定是业务化、技术化(自动化)、数据化是重点方向。更加强调技术+数据+业务的跨界融合才能创造更大价值。提升个人的价值。

当然流水课因为每次仅2小时,讲授的内容每次都不同,不可能每次都讲“行业生态”、“媒体特点”、“DSP怎么投”。

DSP、RTB等系列课程偏中小广告主及相关上下游从业者。毕竟RTB的预算占比也就20-30%。

PDB、DMP等系列课程偏高端(亿元俱乐部)头部广告主及相关上下游从业者。不是所有的广告主都能承受这种代价和投入的。

近期的1.7号的课程已安排主要讲透PDB为主。2月份开始从头从“行业生态”开始讲起。可能较适合新学员的导入。

所以希望大家能根据自己的情况来选取相应的课程来学习。

三、课程提纲

最后附上流水课课程提纲:共24课时1080分钟(12次课)

1.广告交易相关基础知识 ——56页ppt

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

主要内容:

广告的形式:展示广告、搜索广告、社交广告、电商引流、信息流广告

结算方式:CPC、CPM、CPT

广告行业上下游大体分布

头部客户:4A代理、供应商、媒体、CRM

中小客户:SEM代理

程序化广告概念及发展历程

程序化广告的定义

程序化广告的发展历程及模式

“传统排期”广告投放(常规投放)

AdNetwork(广告联盟)模式

剩余流量RTB公开竞价

DSP简介

DSP同AD Network(广告联盟网络) 的区别

私有程序化PDB模式

优先交易PD

私有竞价PA

Trading Desk

程序化广告的未来发展预测及分析

IAB关于程序化的相关介绍

程序化4种典型模式

程序化购买/投放的一些关键特征

1、流量按不同优先级进行管理

2、预订量标识(Deal ID)

Deal达成的过程及操作流程截图

3、价格保护

4、用户行为信息保护

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

2.大数据 ——160页ppt

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

主要内容:

DMP价值意义

什么是DMP

Data类型

DataManagement 流程

DMP的系统构成

数据互通的核心 –ID mapping

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案例

3.数字营销实战-监测&移动 ——29页ppt

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

主要内容:

市面上供应商简单分析

地域GAP

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

广告可见性 IAB规范

移动端的特有的一些问题

移动设备ID标准

移动web cookie不稳定

移动端MRAID 富媒体技术

4.广告交易实战-RTB —-100页

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

主要内容:

什么是RTB?

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

Adx- DSP审核流程

各平台审核时长参考

各平台禁投说明

各Adx审核注意事项 – 广告主资质审核:必提资质

各Adx审核注意事项 – 广告主资质审核:相关资质

各Adx审核注意事项 – 广告主资质审核:限投行业补资质可投

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

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

ADX系统基础操作功能介绍

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

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

5.广告交易实战-DSP ——96页ppt 2次课

授课时间:分为2次课,分别放在8月份一次课,9月份1次课

主要内容:

什么是DSP?

国内DSP类型介绍及比对分析:

独立DSP工具+RTB

门户媒体自带DSP

DSP+ADN

独有DMP+DSP

DSP主要优化手段及原理

各种定向方式

内置DMP、打标签逻辑

算法介绍

动态创意

“某品牌人群策略”示例

“某产品DSP投放策划”实战示例

独有DMP+DSP介绍?

DSP投放案例

某大型电商 – App老访客回流推广案

某国际品牌 – 新品上市移动端推广案

DSP系统技术架构

DSP系统投放操作步骤

6.广告交易实战-PDB ——76页 4次课

授课时间:分为4次课,分别放在10月份一次课,11月份1次课,12月份1次课,2017年1月份1次课。

主要内容:

PDB特点及原理

PDB执行流程

单campaign

视频PDB

视频PDB主要投放模式

视频PDB案例

某国际知名汽车集团

某国际知名食品品牌

多campaign

优化逻辑

主要投放模式及效果

多campaign PDB案例

某国际知名汽车集团

新车上市“轰天雷”计划

PDB+RTB

PDB+RTB特点

PDB案例

某国际知名汽车集团

新车上市“轰天雷”计划

某国际知名奶粉品牌

PDB执行流程细节指导示范

四、具体安排

线下流水课:每月至少举办一期(一般周六下午15:00-17:00),地点在北京海淀区中关村创业大街

VIP闭门会议与聚餐:地点也是在北京,具体的时间和地点根据大家的时间确定。

发票:课程可以开具普通发票或增值税发票,增值税发票可开普通和专用,但需要额外支付一定的税费。(VIP年包享特权除外)

报名&咨询方式:添加微信号:13121124046(伍刀刀)进行报名。

支付方式:支付宝或微信转账

课程详情点此进入

年包优惠套餐点此进入

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

2016-12-27

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

文字的表现力毕竟有限,若大家还比较迷糊的话,欢迎参加“1.7号的线下大课堂”可面对面为您答疑解惑讲透您关心的问题。

2016-12-26

摘要:ADX发的广告流量中移动设备ID都是什么样的?这个问题不搞明白怎么做人群ID包定向投放呢?

既本系列《移动设备ID烦恼知多少?》《IOS体系ID知多少?》《Android体系ID知多少?》后我们来看怎么用好这些ID来在ADX的广告流量中进行定向投放吧:

一、分别什么类型的ID?

先说IOS,比较简单,基本只有IDFA,IOS广告流量中没有其他类型的ID(只有十分少量的IOS6一下的版本有MAC地址的流量。):

但是有的大平台发明文IDFA居多、小平台发IDFA MD5居多。

“IDFA原文”基本大家都是“大写带”-””为主,

例子:9C287922-EE26-4501-94B5-DDE6F83E1475

MD5基本都是以“IDFA原文”直接MD5加密摘要并转大写。(目前SHA1加密的量越来越少了。)

所以如果获取了IOS 的人群IDFA原文包需要先全部转大写后MD5后才能对Adx的流量进行定向投放。如果是获取的人群包是MD5加密的就需要需要“以“IDFA原文”直接MD5加密摘要并转大写”才能对Adx的流量进行定向投放。

如果获取到的人群包是MAC地址包就需要想办法找一些数据资源匹配出相应的IDFA原文包或MD5加密包才能对Adx的流量进行定向投放。否则那就是个故事了。

再来说Android,这个就相对IOS麻烦多些了。

1、Android目前还是以IMEI为主,在文章《媒体注意:Android设备ID大洗牌》也已提到,未来随着Android6.0以上版本的普及,用户越来越多地禁止App对IMEI的获取,AndroidID、MAC地址将会逐渐成为国内Android主要广告流量的ID。

IMEI号是一串15位的号码,比如像这样 359881030314356;

由于IMEI(International Mobile Equipment Identity,移动设备国际识别码,又称为国际移动设备标识)同设备绑定了,某种程度上侵犯了用户隐私。所以我往往建议需要进行MD5加密,一般大部分Adx平台MD5的加密规则:“明文直接MD5转小写”。当然有一家比较奇葩是“明文直接MD5转大写”。(目前SHA1加密的量越来越少了。)

2、Android流量中MAC地址目前大部分Adx平台都是发的,而且大部分都是MD5加密的。仅有少数Adx是发的明文。原则上也是建议需要进行MD5加密的,因为MAC地址除非黑客普通用户是不能重置了,意味这MAC地址也是同设备绑定的了,某种程度上侵犯了用户隐私。这里要提一点就是上次那个同学问的问题,不用的平台MD5之前的MAC原文的处理方式多种多样,大家就疯掉了。

目前常见的几种:

明文:大写带“:”、小写带“:”;

MD5加密:(目前SHA1加密的量越来约少了。)

有在上述两种“明文”基础上直接MD5转小写的;

有“明文”先转大写去“:”MD5转大写的;

有直接“明文”去“:”MD5再转大写的;

有转换大写保留”:”MD5再转小写。

总之不把大家逼疯是不肯罢休的。

所以获取到的人群包是MAC地址原文包就需要按上述这些奇葩的加密方式加密了才能对Adx的流量进行定向投放。否则那也投不出来的。

其实说到这里,我倒建议大家能尽量能参考下图MMA监测规范中对于ID定义的指导参考:<MMA China wireless mobile Internetmarketing alliance Appembedded advertising monitoring API standardV.1.1.pdf>;

期待什么时候清静的不逼疯人的行业上下游能形成:)

3、Android流量中目前仅部分Adx平台是发AndroidID的,而且明文和MD5的也基本对半。(目前SHA1加密的量越来越少了。)

二、不同ID是否同时发?

之前发过不同Adx之前各种ID的携带率,大部分ID都是同时发送的。

同时也是针对Android的流量而言的;因为IOS流量只有IDFA,只有十分少量的IOS6一下的版本有MAC地址的流量。

只有极个别的平台是先取“IMEI”,取不到“IMEI”取“AndroidID” ,取不到“AndroidID”取“MAC地址”的。

也仅极个别的平台只发IMEI不发其他ID的。

当然也有个奇葩需要点名的平台就是“广点通”由于微信的政策限制,广告流量是不发ID的。

三、Adx的广告曝光后ID会给第三方监测发么?

目前除了视频媒体Admaster、秒针花了几年的时间搞定了OTV曝光监测回收ID的问题,其他大量的Banner的广告位还不会给Admaster、秒针第三方监测发ID的,各种ID都不会发的。

所以目前在Adx中投放移动端Banner广告的时候,第三方监测是无法根据ID出具准确的频次报告的。秒针会根据广告曝光时的IP、WebView浏览器特征等等特性计算一个“指纹ID”来估算频次报告。而Admaster曾经用过WebView的CookieID出的频次报告就特别的不准确(当然据Admaster自称也可以“广告曝光时的IP、WebView浏览器特征等等特性计算一个“指纹ID”来估算频次报告”)。移动端WebView浏览器中的Cookie极度不稳定我曾经在《移动广告要点知多少?》中有过阐述。

四、各Adx设备ID的未来会怎么走预估?

IOS依旧IDFA为主,遵循MMA规范的“原文直接转大写”输出。

Android其实最好也应该跟IOS一样以IDFA为主了,不过就看是Google针对中国妥协将IDFA从Google Play中移入Android基础中,还是中国工信部同意让Google Play进中国。(这个估计1-2年是指不上了)

Android上若没有IDFA,建议采用遵循MMA规范的MAC地址(原文转大写去“:”再MD5)输出。

最后还是要再次呼吁一下:尽量所有的Adx以及媒体对外开放设备ID的时候尽量遵从统一的标准,研发同学只要多看一眼MMA的规范,就不会出现那么多奇葩的做法,搞的人最后都精神分裂了。《PDB四-数据互通误区多》文中有提到过其中的痛苦。

谢谢谢谢,如果这个ID的问题大家能一同推进解决必定会功德无量的。

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

文字的表现力毕竟有限,若大家还比较迷糊的话,欢迎参加“1.7号的线下大课堂”专门增加了针对移动ID的专题,可面对面为您答疑解惑讲透这些问题。

2016-12-23

谁来渲染创意意味着谁有一定的主动权。例如支持一些特殊的Adserving(筷子科技、Sizmek等)之类的代码。

ADX平台是否由DSP方来渲染创意?清单如下:

互众:否

adview:是

google:是

好耶:否

baidu(BES): 仅动态创意和js创意由DSP方渲染,普通创意平台渲染

暴风:否

风行:否

广点通:否

inmobi:是

iqiyi:否

乐视:否

灵集:仅动态创意DSP渲染,普通创意平台渲染

新浪:是

sohu :否

tanx:是

腾讯:否

今日头条:否

响巢看看:否

youtu:仅动态创意DSP渲染,普通创意平台渲染

ifeng :是

小米:否

咪咕:否

mopub:是

pptv:否

蜻蜓FM:否

新浪微博:是

佳投:否

万流客:是

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

2016-12-22

摘要:移动Android设备体系ID您知道多少?

既本系列《移动设备ID烦恼知多少?》《IOS体系ID知多少?》后我们来详细看一下Android体系中的各种设备ID吧:

虽然Android相对能获取到的ID的权利没有IOS限制的那么严格,但是也正是Android的山寨机横行、2014年Android2.3基于Google Play推出了IDFA、各种ID满天飞可能导致的麻烦问题比IOS只会多不会少。

一、Android6.0带来的噩耗:

另外还有个噩耗是已发布有一段时间的Android6.0(代号棉花糖)推出了“运行时权限”,简单说就是App若需要获取高密级的权限需要每次询问用户是否同意,如下图所示(左申请单权限、右同时申请多权限):

而不是像之前那样在App安装的时候需要的权限全打上了勾,用户也不在意,安装好之后用户也不能取消这些权限。如下图所示:

Android6.0系统还提供了一个用户可以管理应用权限的界面,通过这个界面用户可以把已经授予的权限再关闭,界面长得是这样的:

二、IMEI

只有Android手机才获取的到, IMEI号是一串15位的号码,比如像这样 359881030314356

获取代码如下:

TelephonyManager TelephonyMgr =(TelephonyManager)getSystemService(TELEPHONY_SERVICE);

String szImei = TelephonyMgr.getDeviceId();

需要权限<uses-permissionandroid:name=”android.permission.READ_PHONE_STATE” />

通常用户会因为你向他们要了这个权限而给你一个差评,因为他们觉得你就是在窃取他们的隐私,很明显,你就是在收集一些数据。

注意:Android6.0运行时对此做了权限限制:

其中“READ_PHONE_STATE”权限是用来获取deviceID,即IMEI号码。所以一般建议在完全支持运行时权限之前,将对应的值写入到App本地数据中,对于新安装的,可以采取其他策略减少对统计的影响。

我们大概统计了一下目前Android6.0大体市场占比及IMEI用户关闭获取权限的数据如下:

Android6.0在Android占比20%左右,其中6.0有35%左右的用户会禁止获取IMEI。

三、无线网卡地址:

APP端无线网卡mac地址获取方法:

WifiManager wifiManager=(WifiManager)getSystemService(Context.WIFI_SERVICE);

WifiInfowifiInfo=wifiManager.getConnectionInfo();

String mac=wifiInfo.getMacAddress();

这种方法比较通用。

注意:最近在Android 6.0系统上,这个方法失效了,返回了“02:00:00:00:00:00”的常量。这并不是一个BUG,在google的博客中找到如下一段话:

Most notably, Local WiFi and Bluetooth MACaddresses are no longer available. The getMacAddress() method of a WifiInfoobject and the BluetoothAdapter.getDefaultAdapter().getAddress() method willboth return 02:00:00:00:00:00 from now on.

可以考虑使用NetworkInterface.getHardwareAddress。其原理和cat/sys/class/net/wlan0/address是一模一样的,但是这个是上层API,不需要自己处理底层数据,在Android 6.0上测试通过。

NetworkInterface networkInterface =NetworkInterface.getByName(”wlan0″);

byte[] mac =networkInterface.getHardwareAddress();

问题:

1.如果重启手机后,Wifi没有打开过,是无法获取其Mac地址的。(可以考虑授予CHANGE_WIFI_STATE权限,开关一次wifi刷一下。)

2.有一些定制系统的目录并不一样。 例如三星的目录为”cat/sys/class/net/eth0/address”,所以是否对所以机型都有效有待验证。(需要适配)

3.网上也有反映mac变更问题,是不是刷mac或者wifi故障导致,也不确定。

4.并不是所有的设备都有Wifi硬件,硬件不存在自然也就得不到这一信息。(这个还好)

5.需要 ACCESS_WIFI_STATE 权限。(这个权限还好,用户比较容易通过)

B.通过WIFI上网或WIFI AP探针SSID广播扫描WIFI AP均可以获取这个设备的MAC地址。

四、ANDROID_ID

在设备首次启动时,系统会随机生成一个64位的数字,并把这个数字以16进制字符串的形式保存下来,这个16进制的字符串就是ANDROID_ID,当设备被恢复出厂设置后该值会被重置。可以通过下面的方法获取:

import android.provider.Settings; String ANDROID_ID =Settings.System.getString(getContentResolver(),Settings.System.ANDROID_ID);

ANDROID_ID可以作为设备标识,但需要注意:
它在Android <=2.1 or Android>=2.3的版本是可靠、稳定的,但在2.2的版本并不是100%可靠的。
厂商定制系统的Bug:不同的设备可能会产生相同的ANDROID_ID:9774d56d682e549c。(摩托罗拉好像出现过这个问题)
厂商定制系统的Bug:有些设备返回的值为null。
设备差异:对于CDMA设备,ANDROID_ID和TelephonyManager.getDeviceId() 返回相同的值。
并且,如果某个Andorid手机被Root过的话,这个ID也可以被改变。

五、设备序列号(Serial Number, SN)

获取办法:

String serialNum = android.os.Build.SERIAL;

装有SIM卡的设备获取办法:getSystemService(Context.TELEPHONY_SERVIEC).getSimSerialNumber();

注意对CDMA设备,返回的是一个空值。

在Android 2.3可以通过android.os.Build.SERIAL获取,非手机设备可以通过该接口获取。

在少数的一些设备上,会返回垃圾数据。对于没有通话功能的设备,它可能会返回一个固定的值。

六、IDFA

2014年Android2.3基于Google Play推出了IDFA,功能同IOS的IDFA一样,允许用户重置或禁用该ID,由用户决定是否愿意被追踪。由此就出现了各种各种ID的问题。设置界面如下图所示:

但是在中国发行的国行手机由于某些原因,google地图、Play等基础App被阉割掉了,这样导致在中国国行手机中都获取不到该IDFA。(除非用户自行Root并安装google Play)

所以这也是市场中Android体系ID混乱的根本点所在。尤其突出的是google Adx在中国大量的Android流量长期无可用的ID标识的尴尬局面,这个问题google Adx今年应该有所调整。

七、OpenUDID

非Android官方提供的Api,由于Android体系ID较混乱,所以也有很多大厂在使用该ID。原代码地址如下:https://github.com/vieux/OpenUDID

用法如下:

* Addthis to your manifest:

<serviceandroid:name=”org.openudid.OpenUDID_service”>

<intent-filter>

<actionandroid:name=”org.openudid.GETUDID” />

</intent-filter>

</service>

* Call`void OpenUDID_manager.sync(Context yourContext);` to initialize the OpenUDID

* Call`boolean OpenUDID_manager.isInitialized();` to check if the initialization isover (it’s asynchronous)

* Call`String OpenUDID_manager.getOpenUDID();` to retrieve your OpenUDID

目前国内市场上Android主要以IMEI作为广告流量标识为主,国外市场主要以IDFA为主,但是随着Android6.0的运行时权限限制,Android体系中的ID将面临洗牌。

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

文字的表现力毕竟有限,若大家还比较迷糊的话,欢迎参加“1.7号的线下大课堂”专门增加了针对移动ID的专题,可面对面为您答疑解惑讲透这些问题。

2016-12-21
摘要:移动IOS设备体系ID您知道多少?本系列第一篇《移动设备ID烦恼知多少?》已将ID的各种烦恼问题说了那么多,下面我体系化地从IOS、Android两大体系来详解一下两大体系中的各种设备ID吧:

先说IOS吧:2013年IOS6是一个巨大的分水岭:

一、IMEI

在iOS5之后该方法就被废弃掉了,因此iOS5以后不能获取手机IMEI,但是也是可以通过私有API获取手机的IMEI号的,但是通过苹果私有API获取IMEI号,上架苹果商店会被拒掉的。

电信运营商因为通讯网络协议中都是传递用户手机的IMEI及SIM卡的IMSI,所以运营商是有这些用户的IMEI及IMSI的;

二、UDID

UDID的全称是UniqueDevice Identifier,顾名思义,它就是苹果IOS设备的唯一识别码,它由40个字符的字母和数字组成。在很多需要限制一台设备一个账号的应用中经常会用到。在iOS5中可以获取到设备的UDID,iOS7中已经完全的禁用了它。iOS7之前的使用了的app如果在iOS7上运行,它不会返回设备的UDID,而是会返回一串字符串,以FFFFFFFF开头,跟着identifierForVendor的十六进制值。

废弃版本:iOS6

获取代码:[[UIDevice currentDevice] uniqueIdentifier]

AppleAccount(非法私有方法):虽然苹果在iOS6中禁用了获取UDID的方式,但是只要你研究下就知道这个API只是私有化了,使用私有API还是可以获取设备的UDID。但是这个方法也面临着风险:比如API变更以及AppStore审核问题,但是在越狱设备上你还是可以尽情享用的。

类:AADeviceInfo(dump出头文件)

@classNSObject<OS_dispatch_semaphore>, APSConnection, NSData;

@interfaceAADeviceInfo : NSObject {

APSConnection*_apsConnection;

BOOL_tokenDone;

NSData*_token;

NSObject<OS_dispatch_semaphore>*_tokenSema;

}

+(id)userAgentHeader;

+(id)signatureWithDictionary:(id)arg1;

+(id)apnsToken;

+(id)serialNumber;

+(id)clientInfoHeader;

+(id)appleIDClientIdentifier;

+(id)productVersion;

+(id)osVersion;

+(id)udid;

+(id)infoDictionary;

-(id)wifiMacAddress;

-(id)regionCode;

-(id)deviceClass;

- (id)osName;

-(id)productType;

-(id)apnsToken;

-(id)serialNumber;

-(id)deviceInfoDictionary;

-(id)appleIDClientIdentifier;

-(id)productVersion;

-(id)osVersion;

-(id)udid;

-(id)init;

-(void).cxx_destruct;

-(id)buildVersion;

@end

获取代码:[AADeviceInfo udid]

使用方法:在项目中将真机上的AppleAccount.framework框架导出,引入Xcode工程中,利用runtime或者直接使用该类就行。(细节补充:导出AppleAccount.framework后,进入AppleAccount.framework的根目录,新建Headers文件夹,然后将dump出的头文件放在Headers目录,就可以像引用第三方framework一样在项目中使用)

三、无线网卡MAC地址

1、在App中编程获取使用:

IOS7以后不能通过获得MAC地址来标示手机唯一,App应用在iOS6及以下时,可以正确取道Mac地址,在iOS7上,会返回固定值。这样带来的问题是无法区分具体的iOS设备,有些产品就非常难搞了,目前没有找到可以区分不同iOS设备的方法。测试过mac地址,确实会返回固定值02:00:00:00:00:00。

MAC地址在网络上用来区分设备的唯一性,接入网络的设备都有一个MAC地址,他们肯定都是不同的,是唯一的。一部iPhone上可能有多个MAC地址,包括WIFI的、SIM的等,但是iTouch和iPad上就有一个WIFI的,因此只需获取WIFI的MAC地址就好了,也就是en0的地址。MAC地址就如同我们身份证上的身份证号码,具有全球唯一性。但在iOS7之后,如果请求Mac地址都会返回一个固定值。

废弃版本:iOS7.0+(当然App有一些特殊的方法,例如主动提示用户选择WIFI网络的方式可以获取MAC地址。)

获取代码:

- (NSString *)macAddress

{

int mib[6];

size_t len;

char *buf;

unsigned char *ptr;

struct if_msghdr *ifm;

struct sockaddr_dl *sdl;

mib[0] = CTL_NET;

mib[1] = AF_ROUTE;

mib[2] = 0;

mib[3] = AF_LINK;

mib[4] = NET_RT_IFLIST;

if ((mib[5] =if_nametoindex(”en0″)) == 0) {

printf(”Error: if_nametoindexerror/n”);

return NULL;

}

if (sysctl(mib, 6, NULL, &len, NULL, 0)< 0) {

printf(”Error: sysctl, take1/n”);

return NULL;

}

if ((buf = malloc(len)) == NULL) {

printf(”Could not allocate memory.error!/n”);

return NULL;

}

if (sysctl(mib, 6, buf, &len, NULL, 0)< 0) {

printf(”Error: sysctl, take2″);

return NULL;

}

ifm = (struct if_msghdr *)buf;

sdl = (struct sockaddr_dl *)(ifm + 1);

ptr = (unsigned char *)LLADDR(sdl);

NSString *outstring = [NSStringstringWithFormat:@"%02x:%02x:%02x:%02x:%02x:%02x", *ptr, *(ptr+1),*(ptr+2), *(ptr+3), *(ptr+4), *(ptr+5)];

NSLog(@”outString:%@”,outstring);

free(buf);

return [outstring uppercaseString];

}

2、WIFI上网成功后时WIFI AP可以获取这个设备的MAC地址;

3、WIFI AP探针SSID广播扫描已获取不到IOS8以上手机的MAC地址;

IOS8在同WIFI AP探针SSID广播扫描包通讯的时候,因为是非主动申请上网,所以IOS8都会随机生成一个MAC地址来回应WIFI AP探针。导致WIFI AP探针获取到假的MAC地址,以保护用户隐私。

当然有一些特别的做法:例如将AP伪装为用户常用的”SSID”,例如:“CMCC”等等,IOS会主动尝试连接,这个时候WIFI AP探针就获取到了用户真实的MAC地址。

四、IDFV

IDFV是App隔离的,某一App内部获取到给用户的IDFV是稳定不变的,但是不同App之间获取的IDFV是不同的,意味着App内部要追踪和分析用户及个性化可以直接使用IDFV。而要跨App来追踪这个用户的设备IDFV就无能为力了。

iOS 6.0系统新增用于替换uniqueIdentifier的接口。是给Vendor标识用户用的,每个设备在所属同一个Vender的应用里,都有相同的值。其中的Vender是指应用提供商,但准确点说,是通过BundleID的DNS反转的前两部分进行匹配,如果相同就是同一个Vender,例如对于com.somecompany.appone,com.somecompany.apptwo这两个BundleID来说,就属于同一个Vender,共享同一个idfv的值。和idfa不同的是,idfv的值是一定能取到的,所以非常适合于作为内部用户行为分析的主id,来标识用户,替代OpenUDID。如果用户将属于此Vender的所有App卸载,则idfv的值会被重置,即再重装此Vender的App,idfv的值和之前不同。

适用:iOS6.0+

例子:95955F33-BFBD-48BA-A630-866D2DAE482D

获取代码:[[[UIDevice currentDevice]identifierForVendor] UUIDString]

五、IDFA

广告标示符,适用于对外:例如广告推广,换量等跨应用的用户追踪等。

适用:iOS6.0+

例子:9C287922-EE26-4501-94B5-DDE6F83E1475

获取代码:[[[ASIdentifierManager sharedManager] advertisingIdentifier]UUIDString];

详细代码如下:

a.添加框架

AdSupport.framework

b.添加头文件

#import<AdSupport/ASIdentifierManager.h>

c.使用语句

NSString *identifierForAdvertising =[[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];

NSLog(@”identifierForAdvertising ==%@”,identifierForAdvertising)

广告标示符是由系统存储着的。不过即使这是由系统存储的,但是有几种情况下,会重新生成广告标示符。如果用户完全重置系统((设置程序 ->通用 -> 还原 ->还原位置与隐私),这个广告标示符会重新生成。

另外如果用户明确的还原广告(设置程序->通用 -> 关于本机 ->广告 ->还原广告标示符),那么广告标示符也会重新生成。


关于广告标示符的还原,有一点需要注意:如果程序在后台运行,此时用户“还原广告标示符”,然后再回到程序中,此时获取广告标示符并不会立即获得还原后的标示符。必须要终止程序,然后再重新启动程序,才能获得还原后的广告标示符。之所以会这样,因为ASIdentifierManager是一个单例。
作为媒体方的App开启IDFA注意:在App提交AppStore审核时,对于IDFA的用途请按下图勾选,且在AppStore的审核人员审核操作时能看到Ad,否则App审核将被拒(无Ad不可使用IDFA)。


作为广告主方App开启IDFA注意:在App提交AppStore审核时,对于IDFA的用途请按下图勾选,说明使用IDFA是为了作为广告主要跟踪广告效果的需要(若被拒,可按此理由作为广告主身份进行申诉。):

作为既具备媒体方及广告主方特性的App开启IDFA注意:在App提交AppStore审核时,对于IDFA的用途请按下图勾选,且在AppStore的审核人员审核操作时能看到Ad,否则App审核将被拒(无Ad不可使用IDFA)


若按上述操作后App审核仍被拒,可开启一个临时的Ad(无Ad不可使用IDFA),审核通过后关闭该Ad(在AppStore的审核人员审核操作时能看到Ad即可),且可发送一个带有Ad的截图进行申诉。

附被拒提示:

提交App审核时若未勾上“使用了IDFA”被拒的提示如下: Improper Advertising Identifier [IDFA] Usage. Your app contains theAdvertising Identifier [IDFA] API but you have not indicated its usage on thePrepare for Upload page in iTunes Connect.

提交App审核是若未勾上“Limit Ad Tracking setting in iOS”被拒的提示如下: Improper Advertising Identifier [IDFA] Usage. Your app contains theAdvertising Identifier [IDFA] API but your app is not respecting the Limit AdTracking setting in iOS.
最近大家恐慌的IOS10 关闭广告追踪后 IDFA为一串“0000……”不必惊慌,因为早在IOS6的时候就已经有这个功能了也没看到多大影响。一般IDFA是专门给“广告用的”,而Iphone手机只要在出厂的时候没有关闭“广告追踪”,很少有用户会主动去设置关闭。(据不完全统计也就10%左右的专业用户能找到那个藏的很深入的设置界面)。
同时IDFA由于是App获取后需要通过业务程序发送给服务器端的,所以电信运营商只有通过寻找业务数据包特征码的方式拆解业务数据包才能获取IDFA。所以不能100%拥有IDFA。

六、KeyChain

iOS整个系统有一个KeyChain,每个程序都可以往KeyChain中记录数据,而且只能读取到自己程序记录在KeyChain中的数据。而且就算我们程序删除掉,系统经过升级以后再安装回来,依旧可以获取到与之前一致的UDID(系统还原、刷机除外)。因此我们可以将UUID的字符串存储到KeyChain中,然后下次直接从KeyChain获取UUID字符串。(本示例中使用KeychainItemWrapper工具类)。

获取代码:

+(NSString *)UUID {

KeychainItemWrapper *keyChainWrapper =[[KeychainItemWrapper alloc] initWithIdentifier:@”MYAppID”accessGroup:@”com.test.app”];

NSString *UUID = [keyChainWrapper objectForKey:(__bridgeid)kSecValueData];

if (UUID == nil || UUID.length == 0) {

UUID = [[[UIDevice currentDevice]identifierForVendor] UUIDString];

[keyChainWrapper setObject:UUIDforKey:(__bridge id)kSecValueData];

}

return UUID;

}

七、OpenUDID:(IOS7+已无法使用)

非Apple官方提供的Api,原理是由第一个使用openudid的app生成,并存放到系统粘贴版(具体也不理解什么原理),之后安装的其他app去粘贴版取。但ios7发布后,OpenUDID不能用了. OpenUDID是用系统粘贴板作为中间存储供所有app调用. 新的系统把粘贴板的访问权限限制在了同一个开发者的范围内,既同一个开发者的多个app在同个设备上共享粘贴板。

目前市场上IOS主要以IDFA作为广告流量标识为主。
大家是不是已经彻底晕菜了?那我们休息一下,下篇再来看看“Android体系的各种ID”吧。

(转载请注明出处:微信订阅号:ad_automation)
文字的表现力毕竟有限,若大家还比较迷糊的话,欢迎参加“1.7号的线下大课堂专门增加了针对移动ID的专题,可面对面为您答疑解惑讲透这些问题。

2016-12-20

摘要:移动设备ID是精准广告的关键,关于她的烦恼您知道多少?

本来网上关于移动设备ID的文章有很多的,我是无需再整理一套系列来重复的。但是上周我发了篇《流量ID的携带率》的文章(由于该文章中的很多数据十分敏感,可能涉及同各合作伙伴间的保密协定,所以已删除了。)出来后,却有很多同学找我来咨询关于设备ID的很多问题。其中不乏4A公司TradingDesk资深媒介人、经验丰富的技术架构大拿、RTB圈内知名媒体的掌门人。

所以鉴于这样的情况,我有必要将我实操的经验中关于设备ID目前情况做个分享。

大家一致表示:“很有必要!我也糊涂。实战的产品经理才知道!”
首先:第一个要解答为什么大家这么关心移动设备ID的问题?

在上周发布的文章《移动广告要点知多少?》中也提到了,若我们需要在移动手机App上追踪用户:“主要以设备ID来标识一个人”;

1.追踪个体用户行为、及广告监测的需要:

“如果获取不到设备ID,无法监测频次等数据”;

不仅无法监测到用户浏览广告的频次数据,更加无法通过设备追踪这个用户,App运营及产品同学若需要定量追溯个体的连续行为来分析产品优化产品体验也少不了设备ID。
2.个性化推荐及广告:

广告业务需要通过移动设备ID来追踪用户个性化广告,进行个性化的广告投放(或者说精准广告、千人千面、在合适的场景对该用户推动适合的广告)。
3.联通数据孤岛,促进数据流动创造数据价值:

还有就是一个十分大的需求就是,我们都知道现在大量的用户数据由于其产生和采集的场景区隔性特点造成了大量的数据花园围墙。单独的数据孤岛能创造的价值是有限的,需要通过标准的设备ID体系打通。

二:为什么移动设备ID存在那么多折磨人的问题?

这个问题恐怕也是智能手机从幼年期走向成年期出现的“成长的烦恼”。

1.最开始的UDID (UniqueDevice Identifier):

最开始智能手机操作系统的设计者们对手机设计了可标识手机的UDID、网卡有固定的MAC地址,而这些ID都是同系统和设备绑定的。除非黑客普通用户是无法更改的。某种意义上来说就侵犯了用户隐私。不像浏览器中的cookie在《什么是CookieMapping》文中已详细讲解过,这里就不展开了。

2.IDFA(Identifier For Advertising)的出现:

所以在2013年IOS6以后版本的时候,IOS关闭了App代码中对UDID及网卡MAC地址的获取的API。取而代之的是IDFA及IDFV(Identifier For Vendor)。在2014年Android 2.3以后的版本模仿IOS也推出了IDFA。因为IOS及Android分别在系统中提供了用户可以关闭IDFA的操作界面。由用户决定是否愿意被追踪。由此就出现了各种各种ID的问题。

3.电信运营商通讯数据中常用IMEI(InternationalMobile Equipment Identity,移动设备国际识别码,又称为国际移动设备标识)、IMSI(International Mobile Subscriber Identification Number,区别移动用户的标志,储存在SIM卡中,可用于区别移动用户的有效信息):

很多人会有个误解是电信运营商能获取到所有的ID数据。其实不然。电信运营商在通讯数据中常用IMEI、IMSI。而其他的数据,都需要通过拆解数据业务包分析其中的数据来获取的。(当然前提是数据包中传递了UDID、IDFA等等ID).

4. WIFI场景下只能获取到MAC地址:

由于现在无线WIFI特别的普及,而无线WIFI AP(Access Point,无线访问节点)若不做特殊的拆解网络数据包内的内容,一般只能获取到MAC地址。尤其是用户在没有连接上WIFI通过WIFI上网的时候,我们经常听到有人说“AP探针”,那么这是个什么原理呢?原理其实很简单,一般为了无线WIFI AP便于让用户的手机上能便捷地使用到该AP的无线网络,所以会不断地将本AP的名字(即SSID)广播给到所有能接触到的手机设备。这样用户就可以在手机上的“无线网络列表”中看到该AP并选取就可以上网了。而这样的AP同手机直接广播交互的过程中就获取了手机的无线网卡的MAC地址。

所以上面这么几个复杂的情景一混杂,大家就该彻底的晕菜了。我还没把CRM系统中常见的手机号、会员ID等等。以及手机Web浏览器中的Cookie拿进来搅乎。以及还没把各个不同App媒体输出ID时是明文还是MD5加密,还是SHA1加密。加密前用的纯原文ID,还是去了分隔符,大写小写等等问题。

估计各位看官看到这里一定已经脑裂了。对的,这就是目前数字营销领域遇到的各种设备ID折磨人的问题。

面对上述的问题,我们知道必须要打通这些ID,我们才能依据不同场景下选定或获取人群的ID包进行定向广告投放或者打通不同场景下的行为进行人群画像等行为分析。

下图是监测规范中对于ID定义的指导参考:<MMA China wireless mobile Internetmarketing alliance Appembedded advertising monitoring API standardV.1.1.pdf>;但是实际广告流量的ID五花八门。

在后续的几篇文章中我们将详细讲解IOS体系的各种ID、Android体系的各种ID、以及ADX怎么发出这些ID的以及最近的一些变化。

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

2016-12-19

摘要:Android6.0推出了“运行时权限”,IMEI需用户授权才能获取,Android设备ID面临大洗牌。AndroidID、MAC地址将可能重回主导地位。

Android6.0带来了噩耗:

这个噩耗是已发布有一段时间的Android6.0(代号棉花糖)推出了“运行时权限”,简单说就是App若需要获取高密级的权限需要每次询问用户是否同意,如下图所示(左申请单权限、右同时申请多权限):

而不是像之前那样在App安装的时候需要的权限全打上了勾,用户也不在意,安装好之后用户也不能取消这些权限。如下图所示:

Android6.0系统还提供了一个用户可以管理应用权限的界面,通过这个界面用户可以把已经授予的权限再关闭,界面长得是这样的:

Android6.0版本之前App中的代码是可以获取IMEI号的,IMEI号是一串15位的号码,比如像这样359881030314356。

IMEI获取代码如下:

TelephonyManager TelephonyMgr =(TelephonyManager)getSystemService(TELEPHONY_SERVICE);

String szImei = TelephonyMgr.getDeviceId();

需要权限<uses-permissionandroid:name=”android.permission.READ_PHONE_STATE” />

通常用户会因为你向他们要了这个权限而给你一个差评,因为他们觉得你就是在窃取他们的隐私,很明显,你就是在收集一些数据。

Android6.0运行时权限限制:

其中“READ_PHONE_STATE”权限是用来获取deviceID,即IMEI号码。所以一般建议在完全支持运行时权限之前,将对应的值写入到App本地数据中,对于新安装的,可以采取其他策略减少对统计的影响。

我们大概统计了一下目前Android6.0大体市场占比及IMEI用户关闭获取权限的数据如下:

Android6.0在Android占比20%左右,其中6.0有35%左右的用户会禁止获取IMEI。也就是说目前Android流量中有7%没有主ID:IMEI

可以预见这种情况在未来的半年到一年还会越来越严重。

目前国内市场上Android主要以imei作为广告流量标识为主,国外市场主要以IDFA为主,但是随着Android6.0的运行时权限限制,Android体系中的ID将面临洗牌。

AndroidID、MAC地址将可能重回主导地位。

(IDFA由于googlePlay无法进中国估计一时半火儿活不了。)

尤其那些以IMEI号为主的媒体及Adx(Youtu、IQIYI、SOHU、Xtrader等等

)一定要注意了!赶紧升级吧,起码需要3个月App新版本覆盖率才能到位。

更多关于ID的体系化的内容欢迎大家持续关注这周的ID系列连载文章,谢谢!

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