Linkflow联否官网

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

用于标识唯一用户的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－