用户识别规则

本章节主要介绍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. 访客ID（#distinct_id）

访客ID是用户在未登录状态下的标识，如果您使用客户端SDK接入，则用户安装应用时，SDK会自动给该用户配置一个#distinct_id，即该用户的访客ID。如果您需要配置访客ID，请在上传事件前调用identify进行设置。访客ID将会被SDK保存，无需多次进行配置。注意不要在上传事件之后再次调用identify更改访客ID，否则将会造成用户无法匹配以及重复用户的问题。

在没有调用login传入账号ID之前，该用户的数据只会带有#distinct_id，而不会有#account_id，该条数据将根据#distinct_id与用户ID进行关联。

2. 账号ID（#account_id）

当用户登录或注册成功时，可以调用login设置账号ID，此时数据将会带有#account_id和#distinct_id。SDK将会保存账号ID，如果多次调用login配置账号ID，则会取最后一次的传入值作为账号ID。您可以调用logout清除账号ID，清除后的数据将只有#distinct_id。如果传入的数据带有#account_id，后台会优先根据#account_id关联用户ID。

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。此时可能发生三种情况：

1. 访客ID没有与用户ID进行绑定，可认为是登录用户首次发送事件。且在访客状态下没有产生事件，此时会新建一个用户ID，并与账号ID和访客ID进行绑定。
2. 访客ID与用户ID进行过绑定，但之前没有绑定过账号ID。即访客用户转变为登录用户，此时账号ID将会与该访客ID以及相应的用户ID进行绑定，不会产生新的用户ID。
3. 访客ID与用户ID进行过绑定，且已绑定过账号ID。这种情况可能发生于某个新用户在一台已经被登录用户使用过的设备上注册了自己的账号，此时账号ID将无法绑定访客ID，将会新建一个用户ID与账号ID进行绑定，访客ID不做处理。

需要注意的是，账号ID与用户ID的绑定判断，只会发生在后台收到一条含有新账号ID的数据时，即账号ID的绑定判断只会进行一次，因此第三种情况将会造成该账号ID永久性地无法绑定任何访客ID。

三、案列分析

为了帮助您更好地理解TA的用户标识方案，本节将会以案列的形式，具体展示识别规则的运作机制。案列将呈现后台收到数据后配置用户ID的操作，您需要关注的是每一步中#user_id的值以及关联的原理。

1. 只有访客ID的情况

当只有访客ID的情况时，将只会以#distinct_id生成用户ID

在上述场景中，后台收到了三个新的访客ID，因此新建了三次用户ID，而第四步中访客ID"A"存在对应的用户ID"1"，因此没有新建用户ID，视作之前已创建过的用户，其用户ID为"1"。

2. 访客ID已绑定用户ID，但未绑定账号ID

当访客ID有对应的用户ID，但没有绑定账号ID时，传入账号ID将会绑定账号ID与访客ID

在上述场景中，后台收到新的访客ID，并因此新建用户ID。之后收到了新的账号ID，此时访客ID没有与账号ID绑定，因此新的账号ID与访客ID进行了绑定。

3. 访客ID已绑定用户ID，且已绑定账号ID

当访客ID有对应的用户ID，且已绑定账号ID时，新的账号ID将无法绑定访客ID，且之后也无法绑定

在上述场景中，可以看到访客ID"A"已经与账号ID"甲"进行了绑定，此时新账号ID"乙"将无法绑定访客ID"A"，只能与新建的用户ID"2"进行绑定；当第三步账号ID"乙"与访客ID"B"同时传入时，由于账号ID"乙"已经绑定了用户ID，此时不会进行的绑定判断；所以在第四步时，传入的访客ID"B"会被判断为新的访客ID而绑定了新的用户ID，之后新账号ID"丙"与未绑定账号ID的"B"进行了绑定。下面列出此时的User表的结构以帮助您理解本条规则：

四、复杂场景的分析

最后呈现的是复杂场景下的用户识别，为了便于理解，我们会将关键步骤的User表结构呈现出来，您可以对照该步骤的讲解来进行理解：

上述复杂场景，我们将逐步进行分析：
（1）传入新访客ID"A"，与新建用户ID"1"进行绑定

（2）新账号ID"甲"，访客ID"A"没有绑定账号ID，因此"甲"、"A"、"1"进行绑定。

（3）新账号ID"乙"，访客ID"A"已经绑定了账号ID"甲"，因此与新建用户ID"2"进行绑定，此时没有与访客ID绑定，User表如下：

（4）此时新访客ID"B"实际上没有与任何ID绑定，视作新访客ID，与新建用户ID"3"进行绑定

（5）账号ID"乙"，已绑定用户ID"2"，不再进行绑定，此时User表如下：

（6）新账号ID"丙"，访客ID"B"没有绑定账号ID，因此"丙"、"B"、"3"进行绑定，User表如下

（7）账号ID"丙"，已绑定用户ID"3"和访客ID"B"，此时不对访客ID"C"进行操作

（8）账号ID"乙"，已绑定用户ID"2"，此时不对访客ID"C"进行操作

（9）新账号ID"丁"与新访客ID"C"和新建的用户ID"4"进行绑定，User表如下：

（10）最后访客ID"C"已与用户ID"4"进行了绑定

最后的User表结构为：