目录
此内容是否有帮助?

# 用户识别规则

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

摘要

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

# 一、用户识别 ID 的类型

TA 平台主要使用有三个用户识别 ID,分别是「访客 ID(#distinct_id)」、「账号 ID(#account_id)」以及「TA 用户 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 TA 用户 ID(#user_id)

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

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

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

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

# 二、更新 ID 的关系表

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

  • 如果数据只包含「账号 ID」,或者只包含「访客 ID」,且该 ID 是第一次收到。此时系统会新建一个「TA 用户 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」关联于一个新的「TA 用户 ID」
    • 「访客 ID」没有和其他「账号 ID」进行绑定,则「访客 ID」将与「账号 ID」进行绑定

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

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

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

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

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

# 四、案例分析

为了帮助您更好地理解 TA 的用户标识方案,本节将会以案例的形式,具体展示识别规则的运作机制。案例将呈现后台收到数据后配置「用户 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