聊聊各类消费者触点平台上识别用户的ID(上)

原创作者:宋星
公众号来源:宋星的数字观

用于标识唯一用户的ID,是消费者深度运营中一类非常关键的数据。

由于在不同的消费者触点平台上,有不同的ID类型,它们的特性和获取方法各不相同,应用的前提也不一样,这给我们带来了很多挑战。

这系列文章,我将介绍各类消费者触点平台上的用户识别ID,以及它们各自背后的“来龙去脉”。

该系列文章将涉及的触点平台包括:

网站、app、微信生态(公众号、小程序、企业微信)、阿里生态(小程序)、字节跳动生态(小程序、蓝V?)。

本文(上集)的目录如下:
1、首先,不用提但最重要的ID
2、网站端标识唯一用户

  • Cookie
  • 第一方和第三方cookie怎么分辨
  • 谁可以利用Cookie?
  • Cookie正在受到挑战
  • Cookie被禁用?
  • Cookie之外的网站端ID

3、APP端标识唯一用户

  • APP端的设备ID必须分苹果手机和安卓手机
  • IDFA
  • 谁能获得IDFA
  • iOS14中获取IDFA的新规则
  • 苹果端是否可以利用IMEI号码?
  • IMEI
  • 安卓端用什么ID
  • Android_ID
  • MAC地址
  • OAID
  • 谁能获得安卓端的各种ID

4、彩蛋

1、首先,不用提但最重要的ID

当然是User ID。所有的平台都支持User ID。并且,各个平台越来越倾向于让用户提供手机号码作为User ID。这是最可靠的ID,唯一的缺点就是,必须要用户注册登录才能拿到ID。这个ID就不做更多介绍了,但我想强调,User ID事实上是目前诸多ID中,最为重要的,没有之一。

2、网站端标识唯一用户

Cookie

在网站端,标识唯一用户的ID是“大名鼎鼎”的cookie。这个英文原义为小甜饼的东西,作为网站的重要技术配置,历史悠久。

Cookie实际上就是浏览器生成的一个文本文件。它的逻辑是这样,每一个网站,都可以“告诉”浏览器,我要生成cookie,然后,浏览器会执行网站的要求,产生一个文本文件,并且存放在浏览器使用者的设备(比如电脑)的存储器(硬盘或者闪存盘)中。一个网站可以告诉浏览器很多次cookie生成的要求,浏览器也就会为它生成很多的cookie文件。

理论上一个网站可以生成的cookie的数量是无限的,但是大部分浏览器都做了数量的限定。不过,即使如此,一个网站生成几十上百个cookie,没有任何问题。所以,懂得查看cookie文件的朋友,找到cookie存放文件夹,会看到成千上万的cookie文本文件,就是这个原因。

除了网站要求浏览器生成cookie,网站上的第三方代码(就是说这个代码不是网站编写的,而是它把第三方的程序代码——通常是JavaScript放置在自己的网站里)也可以要求浏览器为它(第三方)生成cookie,这时这个cookie的所有者,可能不是网站,而是网站第三方代码的所有者,也就是这个第三方。

第一方和第三方cookie怎么分辨

那么,这种由第三方代码生成的cookie,是否就是我们所说的“第三方cookie”?答案是,无法确定。一般而言,网站自己要求浏览器生成的cookie,确实是第一方cookie。而第三方代码要求浏览器生成的cookie,可以是第三方cookie,也可以是第一方cookie,取决于这个第三方代码的具体要求。

换句话说,如果第三方代码要求浏览器生成的cookie,它的域名是这个网站,那么,它仍然是第一方cookie,而如果第三方要求浏览器生成的cookie的域名是这个第三方或者其他第三方,那么它生成的这个cookie就被称为第三方cookie。

比如,很多网站都置入了谷歌分析(Google Analytics)的监测代码,这个代码对网站而言,是第三方的,但它生成的cookie,域名却是网站的域名,因此,它生成的这个cookie仍然是第一方cookie。

Cookie的作用,不仅仅只是存储一个用户的唯一标识ID这么单一,实际上存储用户的唯一标识ID是它的作用之一,但它还有很多其他的作用,例如存储用户的状态属性等,本文就不赘述了。而用户ID,则作为一个单一的字段,存储在某些cookie中。对于同一个网站而言,它或者第三方为它生成的诸多cookie,里面都可能带有标识用户的ID,而且这些ID,即使是对同一个人,也很可能完全不同。

例如,Google Analytics为网站生成的第一方cookie,就有它自己标识用户的ID字段格式,跟网站自己生成的cookie中标识用户的ID字段格式完全不同。

前面说了,cookie的历史很悠久,谁能利用cookie呢?

谁可以利用Cookie?

Cookie的使用原则是谁生成,谁使用。哪怕是第一方cookie,如果不是网站自己生成,而是由第三方生成的,那么,它的使用原则上也是给第三方自己用,而不是给网站用。当然,这个并不绝对,如果生成方愿意在技术上做一些设置,从而让其他方也能应用它们生成的cookie,这也是有可能的,不过这种情况并不常见。

谁生成谁使用原则最典型的例子,就是前面提到的谷歌分析。谷歌分析为网站建立了第一方cookie,但这个第一方cookie是谷歌分析自己用的,用于做用户行为的追踪和统计,而网站其实并不能直接利用。如果说,网站利用了谷歌分析生成的这个cookie,也是在谷歌分析的报告上实现的——网站运营者,通过谷歌分析的监测报告,了解到流量和用户的行为。

顺便说一句,无论是DMP,还是CDP,还是网站分析工具,还是其他的什么数据系统,如果要统计网站上的用户和行为,那么为这个网站生成cookie,尤其是生成第一方cookie,是最基础也是最普遍的方法。

Cookie正在受到挑战

最大的挑战来自于用户隐私。

很多人因为,cookie存储了唯一标识用户的ID(这被称为假名ID,所谓假名ID,就是并不是实名,但颗粒度能到个人级别的ID),还存储了用户的行为,所以透露了用户的隐私。这种理解是狭隘的,原因在于cookie其实几乎不存储或只存储极为有限的用户行为(毕竟cookie只是一个很小的文本文件),并且ID也是假名化的。

但第三方cookie确实容易让人产生隐私忧虑,因为它属于第三方,而不是某个具体的网站,因此一个第三方可以为多个网站生成同一个第三方cookie,只要这些网站都加了这个第三方的代码。比如,很多网站上的广告,添加了同一个监测公司的代码,而这个监测公司,为这些网站都建立了一个共同的cookie,用来标识同一个消费者。这时,这个消费者访问这些网站及他访问时间的信息,就可以被记录在cookie中。

这种情况下,虽然并没有透露用户在每个网站中具体干了什么,但第三方cookie,还是“泄露了”用户的网站访问的轨迹。

Cookie被禁用?

那么,cookie会被禁用吗?

Cookie是否被禁用,分为两个层面,一个是法律层面,一个是技术层面。

法律层面如果被禁用,那么就等于判了它死刑。不过,在中国,没有看到任何法律明确要求禁用cookie,这意味着在中国使用cookie现在是完全合法的。在欧洲,以严格著称的GDPR(欧盟的个人隐私保护的法律)也没有禁用cookie,而是要求对cookie这一类的所有假名信息都要明确告知消费者,并且征得消费者同意之后才能使用。

但在技术层面上,情况有所不同,主要是会对第一方cookie和第三方cookie区别以待。大部分的浏览器,都默认不禁止第一方cookie,但很多浏览器,包括Firefox,Safari,以及Google的Chrome都已经或者即将默认禁用第三方cookie。

第三方cookie被默认禁用影响大吗?简单而言,对于自己的网站的分析,以及对于CDP的应用,没有影响。但是对于网站端的广告的监测,以及跨网站的用户行为追踪,则有很大的影响。或者说,对企业的私域流量运营影响不大,对公域广告在网站的投放,以及第三方广告投放公司,有比较大的影响。

Cookie之外的网站端ID

基于cookie被浏览器和各种法律或多或少的“封堵”,我们不得不考虑是否有什么替代方法。

一种替代品是Flash cookie。Flash是Adobe公司的一个存储用户行为信息的技术解决方案,与浏览器cookie不同,flash cookie的信息并不存放在客户端,因此某种意义上,它很难被删除。

不过,及基本上Flash快要被各个浏览器抛弃,甚至Adobe自己也已经宣布要放弃对Flash的更新和支持。所以,Flash cookie也会很快成为历史。

HTML5技术的发展,为cookie“变身“创造了新的可能。HTML5利用JavaScript的两种存储方法来实现类似于cookie的效果,一种是local storage(类似于永久cookie),另外一种是session storage(类似于暂时cookie)。这两种存储方式的优势之一,是比标准cookie更大的存储空间。

另一种替代方式是各种被称为“画布指纹(Canvas Fingerprint)”的方案。事实上这不是一种标准化的方案,而是把各种各样互联网客户端特征“凑在一起”,识别同一个用户。画布指纹的思想由两种特征构成,其一,浏览器相关的软件特征的尽可能的搜集,例如浏览器版本号、语言、窗口分辨率等等;其二,对互联网客户端的硬件信息的尽可能的搜集(例如网络适配器的MAC地址,操作系统的编号等,不过这一类信息获取非常困难)。将这些信息结合在一起,对于识别一个具体的用户是非常准确的。可惜,这个方法的问题是,相对于cookie,更存在隐私方面的有忧虑。

你可以认为这些替代cookie的方法都是旁门左道,cookie仍然是目前网站端用户唯一性标识所不可或缺的。

3、APP端标识唯一用户

网站端标识用户用cookie,app端则主要用device ID,即设备ID。

设备ID其实是一类ID的统称,甚至部分ID跟硬件无关,单也被算作是设备ID,这一点跟cookie很不一样。Cookie很单纯,而设备ID则很庞杂。

APP端的设备ID必须分苹果手机和安卓手机

设备ID,在苹果端,很简单,基本能用的就是两种,一种是IDFA,一种是IDFV。IDFA = ID for Advertisers,IDFV = ID for Vendors。所以IDFA是给广告主用的苹果移动设备的ID,而IDFV是给app开发者用的苹果移动设备的ID。之前苹果端也用UDID(Unique Device ID),已经被废止。

在数字营销的场景下,苹果手机主要应用的ID是IDFA。

而在安卓设备上,设备ID就五花八门了,包括移动设备的国际识别码(IMEI),或是其他各种各样的ID。安卓设备并没有IDFA,但国内近期鼓捣出一个类似于IDFA的OAID。这些我们后面再挨个介绍。

IDFA

IDFA虽然被认为是一种设备ID,但是它根本就和设备无关。准确说来,它是苹果iOS操作系统提供(编出来)的ID,由于iOS是操作系统,因此这个ID也就是一个软件的ID罢了。

正因如此,它跟硬件设备的ID有明显的区别。

IDFA允许用户将它禁用。用户也可以还原广告标识符,这就意味着重新生成一个新的标识符,而旧的那个就直接消失了。这里的广告标识符,就是指IDFA。

就算用户不主动禁用或者还原IDFA,当iOS系统升级,IDFA也会随之被更新。

因此,IDFA实际上并不像硬件ID那样,跟机器永远绑定,也就不可能永远能够追踪到同一个用户。

谁能获得IDFA

任何一个app都可以向苹果官方申请获取IDFA的权限,但使用IDFA的场合只限于如下下种情形:

(1)在这个app内投放广告;

(2)为了标明(追踪)此app安装来自先前投放的特定的广告;

(3)为了标明(追踪)此app中发生的操作来自先前投放的广告。

除了app之外,app中的与广告投放和监测相关的第三方SDK也能够获取iOS的IDFA。

网页中埋入的监测JavaScript代码是否可以获得IDFA?答案是否定的。网页,在任何情况下都不能直接获得IDFA。但,考虑到网页肯定是在浏览器或者某些具有浏览器的app(比如微信或今日头条)中打开的,因此,如果浏览器或者app愿意,它们可以将自己获取到的IDFA传递给网页。不过,这种情况在技术上能实现,在实际应用中,很罕见。

毕竟,很难想象谷歌的Chrome或者微信,给某个网页传递IDFA。

iOS14中获取IDFA的新规则

在iOS14中,获取IDFA将有新的规则。在此前的iOS版本中,app及app中的SDK对IDFA的获取,不需要征得app用户的同意。

而在iOS14中,则必须提前提示用户,并且必须得到用户的明示点击同意,才能获得IDFA。

这将进一步降低IDFA的适用面,并导致iOS广告投放对受众的追踪能力的进一步下降。

苹果端是否可以利用IMEI号码?

无论是app,还是app中的SDK,都无法获取iOS设备的IMEI号,除非这个设备被越狱了。因为苹果iOS操作系统只开放了IDFA让广告行业利用。

IMEI号是硬件设备的固有编号,是典型的假名信息(关于什么是假名信息,欢迎大家参加我的大课堂了解)。苹果,乃至于几乎今天所有的手机制造商,都已经或即将在手机中禁止app获取该硬件ID。

但并不意味着所有人都不可能获取苹果手机的IMEI号。

有一类特殊的机构,他们可以获取苹果手机的IMEI号。这就是通信运营商。因为手机入网,必须要报自己的IMEI号等信息,所以,通信运营商能够拿到每个移动通信设备的IMEI号。

IMEI

既然谈到了IMEI,我们有必要介绍它。

IMEI是安卓手机主要依赖的硬件设备ID。它确实是与硬件设备捆绑的,除非用专门的设备重写硬件设备的ROM,否则一个设备的IMEI号不可能发生改变。

苹果手机很早就禁用了IMEI,但安卓端则迟迟没有禁用它。

IMEI是国际移动设备识别码(International Mobile Equipment Identity)的缩写,即通常所说的手机序列号、手机“串号”,用于在移动电话网络中识别每一部独立的手机等移动通信设备,相当于移动电话的身份证。

因为一个电话卡(SIM卡)一次只能放在一个手机上,因此,手机上的IMEI号,实际上在一段时间之内是跟电话号码唯一绑定的。

哪怕双卡双待的手机,也有两个IMEI号,跟两个手机号码对应。

IMEI号一般而言,是和手机一对一唯一的。但是,由于部分水货甚至走私手机,以及一些“山寨”手机的存在,有可能存在IMEI号中的字段全部是“0”,或者盗用其他手机IMEI号的情况,导致IMEI号和手机设备不能一一对应。这种情况目前在减少。

另外一种IMEI号的误差来自于作弊,即用软件模拟手机,并生成假的IMEI号。这一情况在灰产和黑产生意中,极为常见。

手机号码和IMEI号的对应信息,运营商必然拥有。行业中有很多能够提供IMEI号和手机号码互换服务的供应商,其数据源归根结底,来自于运营商。

但是,随着个人信息保护法律的逐步完善,IMEI存在的隐私风险受到关注。普遍的观点是,考虑到它存续的时间长,不可更换,并且有可能被转换为电话号码,因此需要受到更严格监管。

IMEI号是否会被国家法律层面上禁用,至少在我写这篇文章的时候,仍然没有经全国人大审议后发布的成文法律对此进行确认。但从实际情况看,大量的广告投放的数据应用,以及投放中的效果监测,都仍然依赖于IMEI号。

不过,随着Android Q(新的安卓操作系统)的发布,安卓阵营的手机厂商也开始逐步禁止app获取IMEI。可以预测,未来IMEI将在移动设备中,不再能够作为数字营销和广告推广的用户识别ID。

安卓端用什么ID

安卓端曾经用的ID很多,五花八门。因为安卓的系统开放性很强,而且还能被随意的“root”(就是把操作系统的管理员权限都获取下来,然后就可以对操作系统“为所欲为”),所以,安卓上面运行的各种app、SDK等,都能拿到安卓上的各种ID。

也正因此,安卓端的安全性一直为人所诟病。直到最近才有所改善,我们后面再讲。

安卓端最主要使用的ID包括:IMEI、AndroidID、MAC地址、OAID。

IMEI前面已经讲过。安卓端的IMEI号,曾经(现在很多手机仍然是)能够被app或者app内的一些SDK随意拿到

Android_ID

AndroidID或Android_ID,是用户安卓手机上操作系统提供的ID。在设备首次启动时,系统会随机生成一个64位的数字,并把这个数字以16进制字符串的形式保存下来,这个16进制的字符串就是Android_ID。这个ID与IDFA似乎有些类似,都是操作系统的ID,但其实区别很大。除非手机用户重刷ROM(类似于格式化后重装操作系统),否则Android_ID不能被用户禁用、重写。这意味着这个ID跟硬件ID其实没有太大区别,也是一种典型的假名信息。

没错,它跟IMEI号的待遇一样,Android Q操作系统已经对它进行了屏蔽。

MAC地址

MAC地址是一种特别典型的硬件ID,也就是说,它是被写死在硬件上的,就像刻在铭牌上的汽车的发动机号。

MAC地址的硬件是网卡。所有网络设备要上网,其实都需要有一个网卡(过去是真的一个粗大的卡,现在已经只是一个小小的芯片了)。而所有的网卡,都有一个自己的寻址地址,用6段二位16进制数表示,例如00-50-BA-CE-D6-F9。如果一台计算机有两张网卡,就会有两个MAC地址。

这东西也是无法被普通用户重写擦除的,所以,同样是敏感的假名信息,同样需要被屏蔽,以免被滥用于追踪消费者。

目前没有成文法对它进行明确说明是否可用。但在这一两年的实际应用中,一般都认为这是一种隐私信息,需要加以保护。

OAID

随着Android Q的发布,Android_ID、MAC、IMEI这些被禁用,安卓端需要有一个既能不侵犯隐私,又能对消费者进行追踪的ID。

苹果的IDFA给了安卓阵营的厂商很大启发。于是,在2018年(或者更早的时间),中国信息通信研究院发起了一个移动安全联盟(MSA),主要成员包括华为、ViVO、小米等手机厂商。MSA作为开发者,开发了OAID,用于安卓端的用户追踪,以取代前面说的这些假名ID。

OAID跟IDFA很类似,用户可以禁用、更新,并且操作系统升级之后,OAID也自动会被更新。因此,它不能算是一个一直与硬件绑定的假名ID,而更类似于一个匿名ID。

例如,在华为的开发者文档中,有介绍OAID,如下:

  • 用户可在系统”设置>隐私>广告与隐私”或”设置>安全与隐私>更多安全设置>匿名设备标识”界面中,重置”广告标识符”和启用”限制个性化广告”,以保护用户个人数据的隐私安全。
  • 用户重置”广告标识符”后,会生成一个新的OAID,开发者(app和SDK等)将只能获取到这个新的OAID。

所以,它的英文名字,也起名叫“匿名”。OAID的英文是Open Anonymous  ID,即开放性的匿名ID。

谁能获得安卓端的各种ID

跟苹果iOS端类似,app、app中的SDK(经过app授权),以及运营商可以获得安卓端的ID。

不过,运营商情形比较特殊。运营商并不能直接获得OAID或者IDFA这样的匿名ID,运营商只能获得IMEI号为主的硬件标识。

运营商如果要获得OAID或者IDFA,也需要通过它们自己的app——如果用户安装了它们的app的话。

4、彩蛋

最后,给大家一个彩蛋。哈哈,上面那么多文字,浓缩成下面的表就好了。

原创作者:宋星
公众号来源:宋星的数字观


Warning: count(): Parameter must be an array or an object that implements Countable in /home/wwwroot/lf-2020.becomingjenny.net/wp-content/plugins/wechat-social-login/templates/share/share-bar.php on line 7

-END-

你想了解的CDP知识都在这
你想了解的CDP知识都在这
微信营销专辑:个性化菜单、智能标签、深度分析,助您开启微信精细化运营之旅
微信营销专辑:个性化菜单、智能标签、深度分析,助您开启微信精细化运营之旅

内容订阅

关于我们

扫码关注 LinkFlow 微信公众号

关注 LinkFlow 微信公众号

获取营销干货和最新活动咨讯

在线咨询 欢迎联系 400热线 4006969886 联系邮箱 marketing@linkflowtech.com 微信咨询 获取介绍资料、咨询、演示、请添加咨询微信。 申请试用 免费申请