神策分析用户关联说明文档

最后更新于：2018-09-27 16:16:57

1. 背景介绍

用户在完成注册或登录前，神策会为用户分配一个匿名 ID 来标识用户，将该匿名 ID 作为 distinct_id 来记录用户的事件数据。当用户完成注册或登录之后，通过调用神策接口尝试进行用户关联。在关联成功的情况下，匿名 ID 和该登录 ID 发生的所有行为都会被认为是同一个用户实体发生的，在进行事件、漏斗、留存等用户相关的分析时会算作是一个用户。

2. 使用说明

2.1 匿名 ID 生成规则

iOS 端：
默认情况下，神策 SDK 会优先使用 IDFV 作为匿名 ID，如果 IDFV 获取失败，则使用随机的 UUID，一般情况下都能够获取到 IDFV。使用 IDFV 或 UUID 作为匿名 ID，当用户卸载重装 App 时匿名 ID 会变。也可以通过配置使用 IDFA 作为匿名 ID，如果开启 IDFA ，神策 SDK 会在获取 IDFV 之前先尝试获取 IDFA 作为匿名 ID。使用 IDFA 能避免用户在重装 App 后匿名 ID发生变化的情况。
1.9.10 及之后的版本，iOS 端使用 Keychain 将匿名 ID 存储到本地，匿名 ID 无论使用 IDFV 还是 IDFA，卸载重装都不会改变。

Android 端：
1.10.5 之前版本，默认使用 UUID 作为匿名 ID，App 卸载重装 UUID 会变，为了保证匿名 ID 不变，可以通过配置使用 AndroidID 作为匿名 ID ；1.10.5 及之后的版本 SDK 默认会以 Android ID 作为匿名 ID，如果 Android ID 获取不到则获取随机的 UUID。

web 端：
默认情况下使用 cookie_id 作为匿名 ID。

小程序端：
默认情况下使用 UUID 作为匿名 ID，但是删除小程序，UUID 会变。为了保证匿名 ID 不变，建议通过获取 open_id 作为匿名 ID。
如果选择使用open_id作为匿名ID的话，请注意【操作暂存】，由于获取 openid 是一个异步的操作，但是冷启动事件等会先发生，这时候这个冷启动事件的 distinct_id 就不对了。所以我们会把先发生的操作，暂存起来，等获取到 openid 等后调用 sa.init() 后才会发送数据。 open_id 的获取和操作暂存的方法请参考下述文档。
https://www.sensorsdata.cn/manual/mp_sdk.html#21-操作暂存和-sainit-表示准备完成

2.2 用户关联具体步骤

客户端通过 login 方法进行用户关联，在 SDK 初始化完成之后，神策 SDK 会自动生成一个匿名 ID 作为用户标识，在用户注册、登录、初始化 SDK（App 端）等任何可以拿到用户登录 ID 时都需要通过调用 login 方法完成用户关联。
服务端接入包括使用 Java / Python 等 SDK，以及直接使用 BatchImporter / LogAgent 等工具进行导入等情况，通常在用户注册或登录时调用 trackSignup 方法传入 登录 ID 和匿名 ID （获取方式见备注一）实现用户关联。
特别的，服务端无法区分传入的 ID 到底是匿名 ID 还是登录 ID，在通过 track 添加事件或者通过 profile 设置用户属性时，需要根据实际情况传入 isLoginId 属性来标识触发事件或属性时对应的用户是否是登录 ID，如果不设置可能会导致用户关联异常。具体步骤可参考各端 SDK 文档和数据导入的数据格式要求。

备注一：
JavaScript SDK 获取 Cookie 中的 distinct_id ，可以通过 sensors.store.getDistinctId() 方法获取。
安卓 SDK：通过 getAnonymousId 方法 获取神策分析 SDK 分配的 匿名 ID，String AnonymousId=SensorsDataAPI.sharedInstance().getAnonymousId();
iOS SDK：通过 anonymousId 方法可获取神策分析 iOS SDK 分配的 匿名 ID，获取当前用户的匿名id NSString *anonymousId = [[SensorsAnalyticsSDK sharedInstance] anonymousId];（swift 代码示例：let anonymousId:String = SensorsAnalyticsSDK.sharedInstance().anonymousId()）。

3. 关键字段介绍

神策进行用户行为分析，从产品角度看，只用到了两张表，事件表（Events）和用户表（Users）。在用户关联中，会涉及事件表和用户表这两张表。

3.1 事件表（Events）

user_id 是神策内部给用户分配的唯一标识，是用于计算触发用户数、漏斗、留存等的最终依据，和用户表中的 id 是对应的，同一个用户实体 user_id = id。

distinct_id 是用户触发事件数据时的用户标识，可以是匿名 ID（例如 iOS 的 IDFA/IDFV，Web 的 Cookie 等），也可以是登录 ID。同一用户的事件数据也是如此，用户在匿名状态下触发的事件是以匿名 ID 来记录，而登录状态下是以登录 ID 来记录的。但成功地完成了用户关联的一个用户实体的 user_id 必然是一致的。即可以在事件表中查询到，同一个 user_id 的 distinct_id 是不同的。

3.2 用户表（Users）

id 同事件表中的 user_id 一样，是神策内部给用户分配的唯一标识，对于同一个用户实体，user_id = id。需要注意的是，并不是有一个 user_id 就会有一个用户表中的 id 与之对应。例如通常场景下的用户未登录帐号进行的匿名操作，或者未设置用户属性等情况下，数据库中只有用户的事件数据而没有用户数据，所以这时查询触发用户数的依据是 user_id 而不是 id。

first_id 为用户的匿名 ID，与事件表登录前行为的 distinct_id 相关联。需要特别注意的是，如果某个用户 first_id 的值等于 second_id，说明该用户没有成功关联到匿名 ID，登录 ID 和自身进行关联。

second_id 为用户的登录 ID，与事件表登录后行为的 distinct_id 相关联。

4. 常见关联场景

Events 表：

Users 表：

假定有新设备 ID X、Y，新登录 ID A、B、C，均无任何操作记录，以下步骤按时间顺序发生：

1、当某用户使用新设备 X 以匿名状态触发任意行为事件时，此时事件表中 distinct_id 为设备 ID X，user_id 为根据一定规则以 X 哈希出的 U1，此时用户表中暂无该用户数据。

2、该用户登录或登录 A，调用 login 接口之后，会记录一个 $SignUp 事件尝试进行用户关联，成功关联之后，设备 ID X 产生的事件数据和登录 ID A 产生的事件数据会被认为是同一个用户 U1 的行为。

3、登录用户 A 触发任意行为事件时，此时 distinct_id 为 A，user_id 为 U1。

4、某用户在设备 X 上登录或登录 ID B，调用 login 接口，触发 $SignUp 事件尝试进行用户关联。由于 X 已经同登录 ID A 进行过关联，登录 ID B 会同自身进行关联，并以 B 哈希出 user_id 为 U2，此时 distinct_id 为 B。

5、登录用户 B 的行为，都会以 U2 来标识。

6、此时又有新的设备 Y，某用户以匿名状态在设备 Y 上触发任意行为事件。distinct_id 为 Y，user_id 为 U3，用户表中无新增数据。

7、登录 ID B 在设备 Y 上登录，调用 login 接口，触发 $SignUp 事件尝试进行用户关联，但由于登录 ID B 已经同自身进行过关联，B 同 Y 将关联失败，用户表中无新增数据。

8、在第 7 步 B 登录之后触发的任意行为事件，将以 U2 记录。

9、某用户在设备 Y 上登录或登录 C，调用 login 接口，触发 $SignUp 事件尝试进行用户关联，C 和 Y 会成功关联。

神策系统中，是以 user_id 来标识一个用户实体。即在以上表格中，只有三个用户，U1、U2、U3。X 同 A 关联被当作用户 U1，B 同自身关联被当作用户 U2，Y 同 C 关联被当作用户 U3。