分析用户行为，首先需要标识用户。选取合适的用户标识，对于提高用户行为分析的准确性有非常大的影响，尤其是对漏斗、留存、Session 等和用户相关的分析功能。

对于唯一标识一个用户，需要考虑两种场景：

• 用户登录之前如何标识？
• 用户登录之后如何标识？

下面，我们分别进行介绍。

（1）登录之前

对于登录之前的用户，我们可以努力去唯一标识 ta 当前正在使用的 iOS 设备。业界一般使用 iOS 设备的某个特定属性或者某几个特定属性组合的方式，来唯一标识一台 iOS 设备。此时的用户 ID，我们一般称之为设备 ID 或匿名 ID。对于究竟该如何去唯一标识一台 iOS 设备，目前业界也没有一个非常完美或普适的方案。同时，苹果为了维护整个生态系统的健康发展，也会极力阻止个人或者组织去唯一标识一台 iOS 设备。因此，对于如何唯一标识一台 iOS 设备，将会是一场持久战，更是一个多方博弈的过程。可能我们唯一能做的，就是在现有的条件及政策之下，尝试努力寻找一种最优的解决方案。
下面，我们介绍几个常见的可以考虑用来作为 iOS 设备 ID 的属性。

A.UDID

UDID 的英文全称是 Unique Device Identifier，是设备唯一标识符的缩写。从名称我们可以猜测到，UDID 是和设备相关的，而且只跟设备相关。它是一个由 40 位十六进制组成的序列。
在 iOS 5 之前，可以通过如下代码片段获取当前设备的 UDID：

NSString *udid = [[UIDevice currentDevice] uniqueIdentifier];

返回的 UDID 示例如下：

fc8c9322aeb3b4042c85fda3bc12953896da88f6

但从 iOS 5 开始，苹果为了保护用户隐私，就不再支持通过以上方式获取 UDID。

结论：
由于从 iOS 5 开始，苹果禁止 iOS 应用程序通过代码获取 UDID，因此 UDID 不适合作为 iOS 设备 ID。

B．UUID

UUID 的英文全称是 Universally Unique Identifier，是通用唯一标识符的缩写。它是一个由 32 位十六进制组成的序列，
使用小横线来连接，格式为：8-4-4-4-12（数字代表位数，加上 4 个横线，总共是 36 位），如下示例。
UUID 示例：

D8E4354E-C18A-44BB-BC75-548BD67C56E5

通过 UUID，能让你在任何一个时刻，在不借助任何服务器的情况下生成唯一标识符，也就是说，UUID 在某一特定的时空下是全球唯一的。
从 iOS 6 开始，iOS 应用程序可以通过 NSUUID 类来获取 UUID，如下代码片段。

NSString *uuid = [NSUUID UUID].UUIDString;

生成的 UUID，系统不会做持久化存储，因此每次调用的时候都会获得一个全新的 UUID。
如果需要兼容更老版本的 iOS 系统，也可以使用 CFUUID 类来获取 UUID。CFUUID 是 CoreFoundation 框架的一部分，因此 API 都是 C 语言风格，代码片段参考如下。

CFUUIDRef cfuuidRef = CFUUIDCreate(kCFAllocatorDefault);
NSString *uuid = (NSString*)CFBridgingRelease(CFUUIDCreateString(kCFAllocatorDefault, cfuuidRef));

提示：NSUUID 和 CFUUID 的功能完全一样，只不过 NSUUID 是 Objective-C 接口，而 CFUUID 是 C 语言风格的 API。

结论：
由于每次获取 UUID 时，返回的都是一个全新的 UUID，如果用户删除应用程序并再次安装时，将无法做到唯一标识iOS 设备。因此 UUID 也不适合作为 iOS 设备 ID。

C．MAC 地址

MAC 地址是用来标识互联网上的每一个站点，它是一个由 12 位十六进制组成的序列，如下示例：

C4:B3:01:BD:42:B1

凡是接入网络的设备都会有一个 MAC 地址，用来区分每个设备的唯一性。一个 iOS 设备（一般指iPhone手机）可能会有多个 MAC 地址，这是因为它可能会有多个设备接入网络，比如 Wi-Fi、SIM 卡等。一般情况下，我们只需要获取 Wi-Fi 的MAC 地址即可，即 en0 的地址。
但从 iOS 7 开始，苹果禁止 iOS 应用程序获取 MAC 地址。如果 iOS 应用程序继续获取 MAC 地址，系统将会返回一个固定的MAC 地址 02:00:00:00:00:00，这也是因为 MAC 地址和 UDID 一样，都属于隐私信息。

结论：
从 iOS 7 开始，苹果禁止 iOS 应用程序获取 MAC 地址，因此 MAC 地址也不适合作为 iOS 设备ID。

D．IDFA

IDFA 的英文全称是 Identifier For Advertising，是广告标识符的缩写，主要用于广告推广、换量等跨应用的设备追踪等。
它也是一个由 32 位十六进制组成的序列，格式与 UUID 一致。在同一个 iOS 设备上，同一时刻，所有的应用程序获取到的IDFA 都是相同的。
从 iOS 6 开始，我们可以利用 AdSupport.framework 库提供的方法来获取 IDFA，代码片段参考如下。

#import <AdSupport/AdSupport.h>
 NSString *idfa = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];

返回 IDFA 示例：

FB584D10-FFC4-40D8-A3AF-DDC77B60462B

但 IDFA 的值也并不是固定不变的。
目前，以下操作均会改变 IDFA 的值：

• 通过设置 → 通用 → 还原 → 抹掉所有内容和设置，
• 通过 iTunes 还原设备
• 通过设置 → 隐私 → 广告 → 限制广告追踪，

一 旦 用 户 限 制 了 广 告 追 踪，我 们 获 取 到 的 IDFA 将 是 一 个 固 定 的 IDFA，即 一 连 串 的 零：
00000000-0000-0000-0000-000000000000。
因此，在获取 IDFA 之前，我们可以利用 AdSupport.framework 库提供的接口来判断用户是否限制了广告追踪。

BOOL isLimitAdTracking = [[ASIdentifierManager sharedManager] isAdvertisingTrackingEnabled];

一旦用户还原了广告标识符，系统将会生成一个全新的 IDFA。

结论：
虽然 IDFA 有一些限制条件，但对于这些操作，只会在特定的情况下才会出现，或者只有专业人士才有可能做这些操作。同时，IDFA 也能解决应用程序卸载重装唯一标识设备的问题。因此，IDFA 目前来说比较适合作为iOS 设备ID。

E. IDFV

IDFV 英文全称是 Identifier For Vendor，是应用开发商标识符的缩写，是给 Vendor 标识用户使用的，主要适用于分析用户在应用内的行为等。它也是一个由 32 位十六进
制组成的序列，格式也与 UUID 一致。每个 iOS 设备在所属同一个 Vendor 的应用里，获取到的IDFV 是相同的。Vendor 是通过反转后的 BundleID 的前两部分进行匹配的，如果相同就属于同一个 Vendor。比如，对 于 com.apple.example1 和 com.apple.example2 这两个 BundleID 来说，它们就属于同一个 Vendor，将共享同一个 IDFV。和 IDFA 相比， IDFV 不会出现获取不到的
场景。但 IDFV 也有一个很大的缺点：如果用户将属于此 Vendor的所有应用程序都卸载，则 IDFV 的值将会被系统重置。即使后面重装此 Vendor 的应用程序，获取到的也将是一个全新的 IDFV。另外，以下操作也会重置 IDFV：

• 通过设置 → 通用 → 还原 → 抹掉所有内容和设置
• 通过 iTunes 还原设备
• 卸载设备上某个开发者账号下的所有应用程序

在 iOS 应用程序内，可以通过 UIDevice 类来获取 IDFV，
可参考如下代码片段。

NSString *idfv = [[[UIDevice currentDevice] identifierForVendor] UUIDString];

返回的 IDFV 示例如下：

18B4587A-0A6F-44A0-AD3C-3BB1C490C177

结论：
和 IDFA 相比，特别是在解决应用程序卸载重装的问题上，IDFV 不太适合作为 iOS 设备 ID。

F. IMEI

IMEI 的英文全称是 International Mobile Equipment Identity， 是国际移动设备身份码的缩写，它是由 15 位纯数字组成的串，并且是全球唯一的。任何一部手机，在其生产并组装完成之后，都会被写入一个全球唯一的 IMEI。我们可以通过设置 → 通用 → 关于本机查看本机 IMEI。

结论：
从 iOS 2 开 始，苹 果 提 供 了 相 应 的 API 来 获 取IMEI。但后来为了保护用户隐私，从 iOS 5 开始，苹果就不再允许应用程序获取 IMEI。因此，IMEI 也不适合作为iOS 设备 ID 。

G．最佳实践

上面介绍的属性，它们各有优缺点，都不是非常完美的方案。
它们总的来说有以下两个问题：

• 无法保证唯一性
• 会受到各种相关政策的限制

关于设备 ID，到底有没有一种完美的方案呢？目前确实没有！我们只能在现有的条件和限制之下，寻找一种相对比较完美的方案。结合实际情况来看，对于常规数据分析中的设备 ID，可按照如下优先级顺序获取，基本上能满足我们的业务需求。

IDFA → IDFV → UUID

对于设备 ID，不管是使用 IDFA 还是 IDFV，用户限制广告追踪或应用程序卸载重装，都有可能导致发生变化。那我们是否还有更好的方案呢？

是有的，那就是 Keychain。

什么是 Keychain ？

Keychain 是 OS X 和 iOS 都提供的一种安全存储敏感信息的工具。比如，我们可以在 Keychain 中存储用户名、密码等信息。Keychain 的安全机制是从系统层面保证了存
储的这些敏感信息不会被非法读取或者窃取。

Keychain 的特点：

• 保 存 在 Keychain 中 的 数 据，即 使 应 用 程 序 被 卸 载 了，数据仍然存在；重新安装应用程序，可以从 Keychain 中读取到这些数据
• Keychain 中的数据可以通过 Group 的方式实现应用程序之间共享，只要应用程序具有相同的 TeamID 即可
• 保存在 Keychain 中的数据都是经过加密的，因此非常安全

关于 Keychain 的详细用法，我们在此处不再详细描述，详细说明可以参照苹果官方文档 Keychain services

（2）登录之后

对登录之后的用户进行标识，相对来说比较简单。因为用户一旦在你的产品中进行了注册或登录，那 ta 在你的用户系统里肯定就是唯一的了。此时的用户 ID 我们一般称之为登录 ID。登录 ID 通常是业务数据库里的主键或其它唯一标识。因此，登录 ID 相对来说会更精确、更稳定，同时，也具有唯一性。
我们可以提供一个 - login: 方法，当应用程序拿到用户的登录 ID 之后，通过调用 - login: 方法把登录 ID 传给 SDK，在此之后触发的事件，即可使用登录 ID 来标识用户。