# 用户识别规则
本章节主要介绍 TA 采用的用户识别规则，阐明如何区分两个用户以及关联同一用户在登录状态以及非登录状态下的行为。
摘要：
1. 一个用户会有三个ID进行识别
分别是：
访客ID #distinct_id 用户在未登录状态下的ID
账号ID #account_id 用户的登录ID
TA用户ID #user_id TA后台用以标识用户的唯一ID
2. 识别一个用户最为关键的ID是 用户ID
每一条数据中的 用户ID 都是根据 账号ID 与 访客ID 生成的
会优先根据 账号ID 进行生成，如果 账号ID 不存在则根据 访客ID 进行生成
3. 当TA后台接收到包含新的 账号ID 的数据时，将会与当前数据的 访客ID 进行绑定
如果访客ID存在且没有被其他账号ID绑定，则绑定成功，两ID标识的数据将使用同一用户ID
如果访客ID不存在或已被其他账号ID绑定，则绑定失败，且不会再进行绑定，未绑定的ID为NULL
4. 用户ID、账号ID 与 访客ID 三者一一对应，不存在一绑多的情况
用户既可能在不同的设备上使用您的产品，也会在未登录状态下进行使用，使得准确地用户标识变得相当复杂。TA 选择了一种较为准确且便于理解的方案。本文档将会详细介绍用户识别的规则，并提供案例帮助您快速理解。
# 一、识别规则
TA 平台主要使用三个 ID 来进行用户的识别，分别是访客 ID（#distinct_id）、账号 ID（#account_id）以及 TA 用户 ID（#user_id）。本节将会介绍这三个 ID 的生成规则：
# 1.1 访客 ID（#distinct_id）
访客 ID 是用户在未登录状态下的标识，如果您使用客户端 SDK 接入，则用户安装应用时，SDK 会自动给该用户配置一个#distinct_id，即该用户的访客 ID。如果您需要配置访客 ID，请在上传事件前调用identify进行设置。访客 ID 将会被 SDK 保存，无需多次进行配置。注意不要在上传事件之后再次调用identify更改访客 ID，否则将会造成用户无法匹配以及重复用户的问题。
在没有调用login传入账号 ID 之前，该用户的数据只会带有#distinct_id，而不会有#account_id，该条数据将根据#distinct_id与用户 ID 进行关联。
# 1.2 账号 ID（#account_id）
当用户登录或注册成功时，可以调用login设置账号 ID，此时数据将会带有#account_id和#distinct_id。SDK 将会保存账号 ID，如果多次调用login配置账号 ID，则会取最后一次的传入值作为账号 ID。您可以调用logout清除账号 ID，清除后的数据将只有#distinct_id。如果传入的数据带有#account_id，后台会优先根据#account_id关联用户 ID。
# 1.3 TA 用户 ID（#user_id）
用户 ID 是识别用户的唯一标识。当 TA 收到传入数据之后，会根据账号 ID 与访客 ID 寻找与之关联的用户 ID，插入每条 Event 中作为主键，或在 User 表中寻找对应主键的 profile 设置用户属性，当账号 ID 存在时优先根据账号 ID 寻找关联的用户 ID，当账号 ID 不存在时根据访客 ID 寻找关联的用户 ID。
当账号 ID 没有找到关联的用户 ID，或在账号 ID 不存在且访客 ID 没有找到关联的用户 ID 时，则会新建用户 ID 并与账号 ID 或访客 ID（无账号 ID 时）进行绑定。用户 ID、账号 ID 与访客 ID 三者互相一一对应。当账号 ID 未找到关联的用户 ID 时，TA 会根据下列规则进行访客 ID 与账号 ID 的绑定。
# 二、访客 ID 与账号 ID 的绑定
当 TA 收到一条来自新的访客用户的数据时，将会根据访客 ID 生成一个用户 ID 并与之绑定。而收到一条来自新的登录用户的数据时，可能访客 ID 已经与用户 ID 进行了绑定，此时需要对访客 ID 是否已绑定用户 ID 进行判断，以此判断是否能够绑定访客 ID 与账号 ID。此时可能发生三种情况：
- 访客 ID 没有与用户 ID 进行绑定，可认为是登录用户首次发送事件。且在访客状态下没有产生事件，此时会新建一个用户 ID，并与账号 ID 和访客 ID 进行绑定。
- 访客 ID 与用户 ID 进行过绑定，但之前没有绑定过账号 ID。即访客用户转变为登录用户，此时账号 ID 将会与该访客 ID 以及相应的用户 ID 进行绑定，不会产生新的用户 ID。
- 访客 ID 与用户 ID 进行过绑定，且已绑定过账号 ID。这种情况可能发生于某个新用户在一台已经被登录用户使用过的设备上注册了自己的账号，此时账号 ID 将无法绑定访客 ID，将会新建一个用户 ID 与账号 ID 进行绑定，访客 ID 不做处理。
需要注意的是，账号 ID 与用户 ID 的绑定判断，只会发生在后台收到一条含有新账号 ID 的数据时，即账号 ID 的绑定判断只会进行一次，因此第三种情况将会造成该账号 ID 永久性地无法绑定任何访客 ID。
# 三、案列分析
为了帮助您更好地理解 TA 的用户标识方案，本节将会以案列的形式，具体展示识别规则的运作机制。案列将呈现后台收到数据后配置用户 ID 的操作，您需要关注的是每一步中#user_id的值以及关联的原理。
# 3.1 只有访客 ID 的情况
当只有访客 ID 的情况时，将只会以#distinct_id生成用户 ID
| #account_id | #distinct_id | #user_id |
|---|---|---|
| null | A | 1 |
| null | B | 2 |
| null | C | 3 |
| null | A | 1 |
在上述场景中，后台收到了三个新的访客 ID，因此新建了三次用户 ID，而第四步中访客 ID"A"存在对应的用户 ID"1"，因此没有新建用户 ID，视作之前已创建过的用户，其用户 ID 为"1"。
# 3.2 访客 ID 已绑定用户 ID，但未绑定账号 ID
当访客 ID 有对应的用户 ID，但没有绑定账号 ID 时，传入账号 ID 将会绑定账号 ID 与访客 ID
| #account_id | #distinct_id | #user_id |
|---|---|---|
| null | A | 1 |
| 甲 | A | 1 |
在上述场景中，后台收到新的访客 ID，并因此新建用户 ID。之后收到了新的账号 ID，此时访客 ID 没有与账号 ID 绑定，因此新的账号 ID 与访客 ID 进行了绑定。
# 3.3 访客 ID 已绑定用户 ID，且已绑定账号 ID
当访客 ID 有对应的用户 ID，且已绑定账号 ID 时，新的账号 ID 将无法绑定该访客 ID，该账号 ID 后续可与其他访客 ID 尝试进行绑定
| #account_id | #distinct_id | #user_id |
|---|---|---|
| 甲 | A | 1 |
| 乙 | A | 2 |
| 乙 | B | 2 |
| null | B | 2 |
| null | A | 1 |
| 丙 | B | 3 |
在上述场景中，可以看到访客 ID "A" 已经与账号 ID "甲" 进行了绑定，此时新账号 ID"乙"将无法绑定访客 ID "A" ，只能与新建的用户 ID "2" 进行绑定；第三步账号 ID "乙" 与访客 ID "B" 同时传入时，访客 ID "B" 没有绑定过账号 ID，因此两者绑定；所以第四步时，传入的访客 ID "B" 归因于用户 ID "2" 上，之后新账号 ID "丙" 与访客 ID "B" 同时传入，同样不发生绑定，视为新用户，以下是最终的绑定关系：
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | B |
| 3 | 丙 | null |
# 四、复杂场景的分析
最后呈现的是复杂场景下的用户识别，为了便于理解，我们会将关键步骤的 User 表结构呈现出来，您可以对照该步骤的讲解来进行理解：
| 步骤 | #account_id | #distinct_id | #user_id |
|---|---|---|---|
| 1 | null | A | 1 |
| 2 | 甲 | A | 1 |
| 3 | 乙 | A | 2 |
| 4 | null | B | 3 |
| 5 | 乙 | B | 2 |
| 6 | 丙 | B | 3 |
| 7 | 丙 | C | 3 |
| 8 | 乙 | C | 2 |
| 9 | 丁 | C | 4 |
| 10 | null | C | 2 |
上述复杂场景，我们将逐步进行分析：
（1）传入新访客 ID"A"，与新建用户 ID"1"进行绑定
（2）新账号 ID"甲"，访客 ID"A"没有绑定账号 ID，因此"甲"、"A"、"1"进行绑定。
（3）新账号 ID"乙"，访客 ID"A"已经绑定了账号 ID"甲"，因此与新建用户 ID"2"进行绑定，此时没有与访客 ID 绑定，User 表如下：
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | null |
（4）此时新访客 ID"B"实际上没有与任何 ID 绑定，视作新访客 ID，与新建用户 ID"3"进行绑定
（5）账号 ID "乙" 与 访客 ID "B" 已归属于两个用户，因此不发生绑定，此时 User 表如下：
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | null |
| 3 | null | B |
（6）新账号 ID"丙"，访客 ID"B" 没有绑定账号 ID，因此"丙"、"B"、"3"进行绑定，User 表如下
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | null |
| 3 | 丙 | B |
（7）账号 ID"丙"，已绑定用户 ID"3"和访客 ID"B"，此时不对访客 ID"C"进行操作
（8）账号 ID"乙" 与 访客 ID "C" 同时传入，访客 ID "C"没有与其他账号 ID 绑定，因此两者进行绑定，User 表如下
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | C |
| 3 | 丙 | B |
（9）新账号 ID"丁"为新用户，访客 ID "C" 已归属于用户 ID"2"，因此不进行绑定，User 表如下：
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | C |
| 3 | 丙 | B |
| 4 | 丁 | null |
（10）最后访客 ID"C"已与用户 ID"2"进行了绑定
最后的 User 表结构为：
| #user_id | #account_id | #distinct_id |
|---|---|---|
| 1 | 甲 | A |
| 2 | 乙 | C |
| 3 | 丙 | B |
| 4 | 丁 | null |