目录
此内容是否有帮助?

# 用户识别规则

用户既可能在不同的设备上使用您的产品，也会在未登录状态下进行使用，使得准确地用户标识变得相当复杂。TE 选择了一种较为准确且便于理解的方案。本文档将会详细介绍用户识别的规则，并提供案例帮助您快速理解。

摘要

  1. 一个用户会有三个ID进行识别，分别是：
  • TE用户ID（#user_id）：TE系统的用户唯一ID
  • 账号ID（#account_id）：用户的登录ID
  • 访客ID（#distinct_id）：用户在未登录状态下的ID
  1. 识别一个用户最为关键的是「TE用户ID」，TE 系统接收到的每一条数据，都会根据该条数据的「账号ID」与「访客ID」关联相应的「TE用户ID」。如果一条数据同时包含「账号ID」与「访客ID」，优先根据「账号ID」关联「TE用户ID」。如果「账号ID」不存在，则根据「访客ID」关联「TE用户ID」
  2. 当TE后台接收的数据中包含新的「账号ID」或者「访客ID」时：
  • 如果数据中存在「访客ID」，且「访客ID」已经关联了「TE 用户 ID」，但没有绑定「账号ID」，则该「账号ID」与「访客ID」进行绑定，共用一个「TE用户ID」
  • 如果「访客ID」不存在或已被其他账号ID绑定，则不进行绑定，「账号ID」将关联一个新的「TE用户ID」
  1. 当TE后台接收到包含新的「访客ID」的数据时：
  • 如果当前数据存在「账号ID」，则与该「账号ID」进行绑定，两个 ID 关联同一个「TE用户ID」
  • 如果当前数据不存在「账号ID」，则不进行绑定，该「访客ID」将关联一个新的「TE用户ID」
  1. 「TE用户ID」与「账号ID」一一对应，「账号ID」与「访客ID」可以一绑多，但一个「访客ID」只能绑定一个「账号ID」。

# 一、用户识别 ID 的类型

TE 平台主要使用有三个用户识别 ID，分别是「访客 ID（#distinct_id）」、「账号 ID（#account_id）」以及「TE 用户 ID（#user_id）」，本节将简单介绍这三个 ID 的含义：

# 1.1 访客 ID（#distinct_id）

访客 ID 是用户在未登录状态下的标识，用来识别用户在登录前或者游戏外的数据，比如说注册前数据、广告数据等。

如果您使用客户端 SDK 接入，则SDK 会自动给该用户配置一个唯一的访客 ID。如果您需要定制用户的访客 ID，请在 SDK 初始化后，立刻调用identify进行设置。

WARNING

请避免在上传事件后再次调用identify更改访客 ID，该操作可能导致用户无法匹配或者重复用户等严重数据问题。

# 1.2 账号 ID（#account_id）

账号 ID 是用户在登录状态下的标识，用来标识用户在登录后的数据。游戏大多采用「账号、角色」两个维度来标识用户，一般情况下，我们建议使用较小的粒度，也就是「角色 ID」作为账号 ID，没有角色维度时采用「账号登录 ID」作为账号 ID。

如果您使用客户端 SDK 接入，可以在用户进行注册、登录时，或者创建角色、进入服务器时，调用login设置账号 ID。SDK 将会保存账号 ID，之后的每条数据中都会带有账号 ID。如果再次调用login配置账号 ID，则将会以新传入值作为账号 ID。您还可以调用logout清除账号 ID，清除后的数据将不带有账号 ID。

# 1.3 TE 用户 ID（#user_id）

「TE 用户 ID」是 TE 系统内部用来识别用户的唯一标识 ID。任何一条正确数据在入库时，系统都会根据「账号 ID」与「访客 ID」生成该条数据的「TE 用户 ID」，以此明确该条数据属于哪一个用户。

「TE 用户 ID」在分析中承担着非常重要的作用。事件数据、用户属性以及用户分群标签等数据表需要通过「TE 用户 ID」进行关联。在分析模型中计算的用户去重数，实质上就是「TE 用户 ID」的去重数。

可以认为，用户识别规则就是每一条数据生成「TE 用户 ID」的规则。生成「TE 用户 ID」的逻辑可分为两步：

  1. 更新用户 ID 的关系表：当数据存在新的「账号 ID」或者「访客 ID」时，TE 系统会更新内部的用户 ID 的关系表
  2. 数据关联「TE 用户 ID」：根据数据中的「账号 ID」或「访客 ID」查找关系表中对应的「用户 ID」，为每一条数据关联「TE 用户 ID」

# 二、更新 ID 的关系表

TE 系统内部，存在一个独立于事件表、用户表的用户 ID 的关系表，该表记录了「TE 用户 ID」与「账号 ID」、「访客 ID」的关联关系。当系统收到的数据中包含新的「账号 ID」或「访客 ID」时，这张关系表将被更新。

  • 如果数据只包含「账号 ID」，或者只包含「访客 ID」，且该 ID 是第一次收到。此时系统会新建一个「TE 用户 ID」，并与传入的 ID 进行关联。

如果数据中同时包含「账号 ID」和「访客 ID」，则还会有 ID 绑定机制。ID 绑定指的是「账号 ID」和「访客 ID」进行绑定，共同关联在同一个「TE 用户 ID」上，相当于绑定了一个用户在登录前以及登录后的数据。

  • 「账号 ID」和「访客 ID」都是第一次收到，此时两个 ID 会进行绑定，并与一个新的「TE 用户 ID」进行关联
  • 如果「账号 ID」存在于关联表，而「访客 ID」是新增 ID，则「访客 ID」将与「账号 ID」进行绑定，一个「账号 ID」可以绑定多个「访客 ID」。
  • 如果「访客 ID」存在于关联表，而「账号 ID」是新增 ID，会包含两种情况：
    • 「访客 ID」已经与其他「账号 ID」进行绑定，则「访客 ID」不与「账号 ID」绑定，「账号 ID」关联于一个新的「TE 用户 ID」
    • 「访客 ID」没有和其他「账号 ID」进行绑定，则「访客 ID」将与「账号 ID」进行绑定

如果数据中的「账号 ID」或「访客 ID」都在关系表中存在，则关系表不进行调整。

# 三、数据关联「TE 用户 ID」

接下来就是数据关联「TE 用户 ID」的环节，仍然分为两个规则：

  • 如果数据中只有「账号 ID」或「访客 ID」，则直接获取该 ID 关联的「TE 用户 ID」
  • 如果数据中同时包含「账号 ID」和「访客 ID」，则获取「账号 ID」关联的「TE 用户 ID」

简单来说，「账号 ID」在关联用户ID的判断上优先级更高。有「账号 ID」时，取「账号 ID」的关联 ID；没有「账号 ID」时，取「访客 ID」的关联 ID。

# 四、案例分析

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

# 4.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"。

# 4.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」进行了绑定。

# 4.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" 同时传入，同样不发生绑定，「账号 ID」"丙" 关联新的「用户 ID」"3"，以下是 ID 关联表最终的状态：

#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
 丁
 D
 4
10
 null
 C
 3

上述复杂场景，我们将逐步进行分析：

（1）传入新「访客 ID」"A"，与新建「用户 ID」"1"进行绑定

（2）新增「账号 ID」"甲"，「访客 ID」"A"没有绑定账号 ID，因此"甲"、"A"进行绑定，关联「用户 ID」"1"。

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

#user_id #account_id #distinct_id
1
 甲
 A
2
 乙
 null

（4）此时新增「访客 ID」"B"，新建「用户 ID」"3"与其关联

（5）「账号 ID」"乙" 与「访客 ID」"B" 都存在于 ID 关联表，因此不发生绑定，此时 ID 关联表如下：

#user_id #account_id #distinct_id
1
 甲
 A
2
 乙
 null
3
 null
 B

（6）新增「账号 ID」"丙"，「访客 ID」"B" 没有绑定「账号 ID」，因此"丙"、"B"进行绑定，与「用户 ID」"3"进行关联，此时 ID 关联表如下：

#user_id #account_id #distinct_id
1
 甲
 A
2
 乙
 null
3
 丙
 B

（7）新增「访客 ID」"C"，与「账号 ID」"丙"进行绑定，此时 ID 关联表如下：

#user_id #account_id #distinct_id
1
 甲
 A
2
 乙
 null
3
 丙
 B, C

（8）「账号 ID」"乙" 与「访客 ID」"C" 都存在于 ID 关联表，此时 ID 关联表不发生变化

（9）新增「账号 ID」"丁"与「访客 ID」"D"，两者进行绑定，并关联与新的「用户 ID」"4"

（10）最后，数据中只有「访客 ID」"C"，返回其关联的「用户 ID」"3"

最后的 ID 关联表结构为：

#user_id #account_id #distinct_id
1
 甲
 A
2
 乙
 null
3
 丙
 B, C
4
 丁
 D

← 数据规则 →