全域用户关联

ClkLog 全域用户关联（IDM 3.0）

提示

全域用户关联（IDM 3.0）仅 ClkLog CDP 企业版3.0、信创版支持，ClkLog PRO 专业版、CDP 企业版3.0 以前的版本均不支持；

1. 方案概述与适用场景

简易用户关联只能处理"设备 ID + 登录 ID"两类身份。但实际业务中，用户标识远不止这两种：

用户可能全程不登录，只在小程序里授权了手机号；
同一个用户可能在公众号、小程序、App、企业微信里留下不同的 OpenID；
同一个人在不同业务线可能有不同的会员 ID；
用户可能更换手机号、解绑邮箱、换微信号。

这些场景用"设备 + 登录"无法打通。全域用户关联的思路是：

不再限制身份种类。只要业务系统能拿到、并且能写进同一条数据里，任何已注册的业务标识都可以参与关联；系统用一套统一的"用户编号"把这些标识串起来。

典型场景

场景	说明
单业务线多触点	App、Web、小程序、公众号、企业微信都要打通
跨业务线打通	各业务线的会员 ID 不同，需要配置为不同的业务身份类型，再通过同一手机号、UnionID 等建立关联
无登录场景	用户不注册不登录，只授权手机号或微信身份
身份会变化	换手机号、换微信、解绑邮箱

2. 基本概念

2.1 ClkLog 用户 ID

ClkLog 为每个用户分配一个内部编号，叫用户 ID（user_id）。所有行为数据和统计都按它归集。

由系统自动生成，业务侧不需要关心格式；
用户首次出现时分配，之后尽量保持不变；
一旦关联上登录 ID，用户 ID 会趋于稳定，不因再绑定其他 ID 而改变。

2.2 业务 ID

用户在业务中留下的、可以用来识别他的各种标识，统称为业务 ID，例如：

登录 ID、会员 ID；
手机号、邮箱；
微信 UnionID、公众号/小程序 OpenID；
AndroidId、IDFV、Cookie ID 等设备标识。

上报时，手机号、UnionID 等业务 ID 放在事件的 identities 节点里，每个 ID 都带明确的类型。使用 SDK 时，业务 ID 通过 bind() 写入 SDK 缓存，SDK 会自动在后续事件的 identities 中携带；服务端或自研上报则直接在事件 JSON 中填写。登录 ID 和设备 ID 分别由 distinct_id、anonymous_id 携带。例如：

{
  "distinct_id": "web_3f9a",
  "anonymous_id": "web_3f9a",
  "type": "track_id_bind",
  "event": "$BindID",
  "identities": {
    "$identity_mobile": "13911112222",
    "$identity_mp_unionid": "union_5b8a"
  }
}

2.3 业务 ID 的分类

分类	特点	典型 ID
设备 ID	不稳定、生命周期短	Cookie ID、AndroidId、IDFV
生态 ID	较稳定，但可能换绑	微信 UnionID、OpenID、企业微信外部联系人 ID
业务 ID	最稳定、生命周期最长	登录 ID、会员 ID、手机号、邮箱

分类的主要用途是帮助实施人员确定"哪些 ID 值得作为主要识别依据"，以及配置数量约束和优先级。

2.4 为什么要给 ID 标类型

同一条数据里可能同时有手机号、UnionID、设备 ID。只有每个 ID 都标明类型，系统才能判断：

这个 ID 属于哪一类；
一个用户能有几个这种 ID；
发生冲突时应该以谁为准。

因此，identities 里的 key 必须是已注册的身份类型，不能随意起名。

3. 核心能力

3.1 业务 ID 自由关联

要让系统把两个 ID 认定为同一个人，需要把它们放进同一条绑定事件（$BindID）；普通事件里的 identities 只用于查找已关联用户，不会新建绑定。

例如：

设备 ID + 手机号 → 打通设备与手机号；
UnionID + 公众号 OpenID → 打通微信生态内不同触点；
业务线 A 会员 ID + 业务线 B 会员 ID → 打通跨业务线账号（配置为两个不同的业务身份类型）。

3.2 支持解绑

已关联的业务 ID 可以解除绑定，例如用户更换手机号、解绑邮箱。

解绑只影响之后的识别，不会改写历史行为数据。

登录 ID 是例外：它是最高优先级、且用于保持用户编号稳定的身份，不允许解绑。

3.3 关联原则

一个业务 ID 在同一时刻只能属于一个用户。 同一个手机号不可能同时是用户 A 和用户 B 的。
孤立的 ID 无法打通。 如果要把 A_ID 和 B_ID 认定为同一个人，必须有一条数据同时携带这两个 ID。
单值约束优先于连通性。 如果强行把两个用户合并，会导致某个"只能有一个值"的身份出现两个不同值，则系统拒绝合并，行为按优先级归属。

3.4 用户 ID 的稳定性

用户关联上登录 ID 后，后续再绑定手机号、UnionID 等，用户 ID 不变；
发生用户合并时，系统优先保留"拥有登录 ID"的那一方，尽量减少用户 ID 变化；
正常处理情况下，用户 ID 变化只发生在合并场景，且合并前的历史数据会在后续任务中逐步归并。

4. 关键配置概念

4.1 关联约束（单值 / 多值）

每种身份类型都要有约束（项目内配置，或从 default 继承）：一个用户能有几个这种 ID？

约束	含义	例子
单值（SINGLE）	一个用户只能有一个	手机号、邮箱、登录 ID、UnionID
多值（MULTI）	一个用户可以有很多个	设备 ID、OpenID

当上报的数据违反约束时，该 ID 绑定失败，但事件本身仍会按优先级归属到某个用户。

4.2 关联上限

多值类型可以设置上限，即一个用户最多关联多少个该类型 ID。

例如设备 ID 上限 500、OpenID 上限 5。超过上限时按"超限策略"处理。

4.3 超限策略

页面选项	行为
滚动解绑(ROLLING_UNBIND)	删除最早关联的那个 ID，新的 ID 继续关联
拒绝绑定(BLOCK)	该次绑定被拒绝，已关联的 ID 保持不变；这是系统默认策略

4.4 优先级

当一个用户同时有多个 ID，而这些 ID 分别指向不同用户时，系统需要决定"这条行为算谁的"。规则是按优先级从高到低匹配：

登录 ID 优先级最高；
其次是各业务/生态 ID，由项目自行配置顺序；
设备 ID 优先级最低。

示例：

优先级	身份类型	约束
1	登录 ID	单值
2	手机号	单值
3	微信 UnionID	单值
4	公众号/小程序 OpenID	多值
5	设备 ID	多值

用户先用账号 A 登录，再换账号 B 登录同一台设备：

设备已经和账号 A 关联过；
账号 B 无法再把该设备"抢"过来（设备只属于一个登录）；
因为登录 ID 优先级最高，切换账号后的行为归属账号 B；
账号 A 和账号 B 不会被合并。

5. 关联规则与处理流程

用户调用 login 后，系统会：

查找登录 ID 是否已有对应用户；
如果登录 ID 是新的：
- 设备尚未关联其他账号 → 设备用户升级为该账号用户；
- 设备已关联其他账号 → 新账号建立自己的用户，设备不跟着走；
如果登录 ID 已存在 → 直接使用该账号的用户；若设备当前属于另一个可合并的用户，则尝试合并（见 5.3）。

注意：全域关联在登录时不会把设备改绑到新账号。设备已属于其他账号时，未登录行为仍归原账号；新账号登录后的行为归新账号。这与简易关联的设备跟随规则不同。

5.2 绑定（$BindID）

用户调用 bind，或业务系统上报带有 identities 的绑定事件时，系统会：

先确定当前用户（按登录 ID → 业务 ID → 设备 ID 的优先级）；
逐个处理 identities 中的业务 ID：
- 这个 ID 还没被任何用户使用 → 直接绑定到当前用户；
- 这个 ID 已属于当前用户 → 刷新绑定；
- 这个 ID 已属于另一个用户 → 尝试合并两个用户；
- 如果绑定会违反单值约束 → 绑定失败，行为仍归当前用户。

5.3 冲突与用户合并

当两个 ID 分别属于两个用户，而它们又出现在同一条数据里时，系统尝试把两个用户合并。

可以合并的条件：

两个用户没有各自不同的登录 ID；
两个用户没有各自不同的同类单值 ID（例如两个不同的手机号）。

合并时：

优先保留拥有登录 ID 的用户；
把另一个用户的业务 ID、设备、登录关系迁移过来；
记录一条合并关系，便于追溯；
被合并用户的用户属性暂不做自动合并。

不能合并时：

不合并；
该次绑定失败；
事件仍按优先级归属到当前用户。

5.4 解绑（$UnbindID）

解绑时，系统会先识别当前用户，再把指定的业务 ID 标记为"已解绑"。

需要满足：

该 ID 当前确实属于这个用户；
该 ID 不是登录 ID。

解绑后：

后续再用这个 ID 上报，不会再命中原来的用户；
历史行为数据不会改变；
如果解绑后又重新绑定，可以恢复关联。

5.5 普通事件归属

普通 track 事件按以下顺序确定用户：

有登录 ID → 用登录 ID 找用户；
没有登录 ID → 依次用 identities 中的业务 ID 找用户（按优先级）；
都没有命中 → 用设备 ID 找用户；
仍然没有 → 视为新用户，分配新的用户 ID。

因此，只要事件携带了已经关联的手机号、UnionID 或登录 ID，即使设备是新的，也能归到老用户。

5.6 合并后的历史数据处理

合并发生时，历史行为数据不会立刻改写。系统会：

先记录"旧用户 → 新用户"的合并关系；
在每日凌晨的归并任务中，把合并之前的历史行为逐步改记到新用户下；
归并完成后，删除这条合并关系。

因此在合并完成前，报表可能把同一个人按新旧两个用户分别统计（例如 UV 偏高）。 这是当前的已知限制，不是数据丢失。

6. 配置与开启

6.1 项目开关

在系统管理 → 全域用户关联 → 用户关联配置中，为项目开启全域用户关联：

先确认当前部署为 ClkLog CDP 企业版3.0（其他产品版本不支持 3.0）；
IDM 版本选择 3.0；
打开"允许绑定"（关闭时 $BindID 会按普通事件处理，不执行身份绑定）；
按需打开"允许解绑"。

未开启的项目继续使用简易用户关联（2.0）。

6.2 身份类型

系统预置了 6 种身份类型：

身份类型	含义	建议约束
登录 ID	业务账号	单值，不可解绑
匿名 ID	设备标识	多值
手机号	用户手机号	单值
邮箱	用户邮箱	单值
微信 UnionID	微信开放平台唯一标识	单值
微信 OpenID	公众号/小程序标识	多值

如果业务还有其它 ID（例如企微外部联系人 ID、自定义会员 ID），需要先在"身份类型标识"页面注册，然后才能配置约束。

6.3 约束与优先级

在"用户关联配置"中为每种身份类型设置：

单值/多值；
关联上限（多值类型）；
超限策略；
优先级；
是否允许绑定。

重要：新项目默认没有可继承的身份约束；每个项目需要单独配置，未配置约束的身份类型无法绑定。

6.4 运行参数

系统管理中还提供少量运行参数，例如配置刷新间隔、单次历史归并的处理条数、归并任务执行时间。一般保持默认即可。

7. 实施方法

7.1 第一步：梳理触点和 ID

列出用户会出现的所有触点，以及每个触点能拿到的 ID：

触点	可获取的 ID
App	设备 ID、登录 ID、手机号
Web	Cookie ID、登录 ID
小程序	OpenID、UnionID、手机号
公众号	OpenID、UnionID
企业微信	外部联系人 ID

7.2 第二步：确定约束和优先级

对每个 ID 回答两个问题：

一个用户能有几个？（单值/多值）
它有多可靠？（决定优先级）

一般原则：

登录 ID 最高；
手机号、邮箱、UnionID 等业务/生态 ID 次之；
设备 ID 最低。

7.3 第三步：埋点上报

每条事件都必须带 anonymous_id 和 distinct_id，否则事件会被丢弃；
用户登录时调用 login；
用户授权手机号、绑定微信、关联业务账号时，调用 bind()，把业务 ID 绑定到当前用户；SDK 会自动把当前已知的所有 ID 放进 identities；
用户解绑时调用 unbind()，只指定被解绑的 ID；

例如（Web JS）：拿到手机号后调用 sensors.bind("$identity_mobile", "13911112222")；之后调用 sensors.track(...) 会自动携带该 ID，不需要在每条事件里手工拼 identities。

7.4 第四步：验证

重点验证：

新设备绑定已知手机号，是否能归到老用户；
同一账号多设备登录，是否是一个用户；
换手机号后解绑旧号、绑定新号，是否正常；
两个不同用户各有不同手机号时，是否不会被错误合并；
合并发生后，次日的历史归并是否正常。

8. 完整案例

假设在线教育用户小林，先后接触官网、小程序和企业微信。为便于看清变化，用固定代号表示各个 ID：

代号	含义
DEV-WEB	小林官网浏览器的设备 ID
DEV-MP	小林小程序的设备 ID
DEV-PC	另一台电脑的设备 ID
PHONE-A	手机号 13911112222
OPENID-A	小程序 OpenID
UNION-A	微信 UnionID
MEMBER-A	会员 ID
WECOM-A / WECOM-B	更换前后的企业微信外部联系人 ID

业务已注册两个自定义身份类型：会员 ID（ $identity_member_id）和企业微信外部联系人 ID（$ identity_ewc_external_id），并按“手机号 > UnionID > 会员 ID > 小程序 OpenID > 企微联系人 > 设备 ID”配置优先级（登录 ID 仍最高，本例未登录）。

步骤	行为	本次出现的 ID	归属变化
1	新浏览器访问官网，匿名浏览	DEV-WEB	新用户 1001；DEV-WEB → 1001
2	官网预约试听，填写手机号（未注册）	DEV-WEB、PHONE-A	PHONE-A → 1001
3	首次打开小程序（另一台设备）	DEV-MP	新用户 1002；DEV-MP → 1002
4	小程序授权微信登录	OPENID-A、UNION-A	OPENID-A、UNION-A → 1002
5	添加企业微信顾问	UNION-A、WECOM-A	UNION-A 命中 1002；WECOM-A → 1002
6	小程序报名并开通会员	PHONE-A、UNION-A、MEMBER-A	PHONE-A 属 1001，UNION-A 属 1002；无单值冲突，1002 合并到 1001；MEMBER-A → 1001
7	换一台电脑打开会员中心，普通事件携带会员 ID	DEV-PC、MEMBER-A	MEMBER-A 命中 1001；DEV-PC 不建立绑定
8	在小程序更换企业微信顾问	解绑 WECOM-A，绑定 WECOM-B	WECOM-A 失效；WECOM-B → 1001

最终 ID 归属

ID	最终归属	变化说明
DEV-WEB	用户 1001	第 1 步建立
PHONE-A	用户 1001	第 2 步绑定
DEV-MP	用户 1001	原属 1002，第 6 步随合并迁移
OPENID-A	用户 1001	原属 1002，第 6 步随合并迁移
UNION-A	用户 1001	原属 1002，第 6 步随合并迁移
WECOM-A	已解绑	原属 1002，随合并到 1001 后在第 8 步解绑
WECOM-B	用户 1001	第 8 步重新绑定
MEMBER-A	用户 1001	第 6 步绑定
DEV-PC	未绑定	第 7 步仅单条事件按 MEMBER-A 命中 1001

第 6 步之后：

官网、小程序、企业微信的行为都归到用户 1001；
用户 1002 不再作为独立用户参与关联，其身份、设备、登录关系迁移到 1001；用户表中的历史记录和用户属性不会自动删除或合并；
用户 1002 合并前的历史行为，会在后续归并任务中改记到 1001。

第 7 步说明：

普通事件携带已绑定的会员 ID，可以让该条事件命中老用户；
但普通事件不会建立设备映射，DEV-PC 本身仍不是 1001 的已知设备。若要让这台电脑后续不带 ID 的事件也归 1001，需要在该设备上执行一次 bind 或 login。

单值冲突示例

如果另一个用户 1003 已有手机号 13844445555，却试图把 MEMBER-A 绑定到 1003：

MEMBER-A 已属于 1001，系统会尝试合并 1003 与 1001；
两人各自已有不同手机号（单值冲突），合并被拒绝；
MEMBER-A 绑定失败，1003 的行为仍归 1003，1001 不受影响。

9. 使用限制与注意事项

需要建立关联的那两个 ID（如设备 ID 与手机号）必须同时出现在同一条绑定事件中，系统才能建立关系。 分散在不同事件里的 ID 无法自动打通。
身份类型必须先注册、再配置约束。 未注册，或未配置无法，无法绑定。
每个项目都要单独配置。 新项目默认没有可继承的约束；需配置项目的身份约束后才会生效。
登录 ID 不能解绑。 它用于保持用户编号稳定。
解绑不改历史。 解绑只影响之后的识别。
合并需要时间归并历史数据。 归并完成前，报表可能把同一人按两个用户统计。
合并不会自动合并用户属性。
管理端的"人工合并"目前只记录合并审计，不会真正迁移数据。 需要实际合并时，应通过真实的绑定事件触发。
从 2.0 切换到 3.0（仅 ClkLog CDP 企业版3.0 支持）不会迁移已有用户关系和历史数据。 切换后新旧用户 ID 可能并存，建议在项目初期确定方案。
同一用户被多实例并发处理时，系统按最终一致处理。 极少数情况下可能出现短暂不一致，通常随缓存过期和后续事件修正恢复，必要时需人工核查。

10. 常见问题

Q1：用户没有登录，只授权了手机号，能识别吗？

可以。把手机号作为身份类型绑定到当前设备用户，之后这个手机号在其它设备或触点出现时，都能命中同一个用户。

Q2：两个用户的手机号不同，但 UnionID 相同，会合并吗？

不会。手机号是单值，两个用户各自已有不同手机号时，合并会导致同一个用户出现两个手机号，系统会拒绝合并；这次 UnionID 绑定失败，行为仍按优先级归属。如果其中一个用户还没有手机号，则可以合并。

Q3：两个用户各有不同的手机号，但设备相同，会合并吗？

不会。手机号是单值，合并会让同一个用户出现两个手机号，系统会拒绝合并；行为按优先级归属（通常是后登录的账号）。

Q4：绑定失败会影响事件入库吗？

不会。绑定失败只表示这个 ID 没关联上，事件仍会按优先级归到某个用户并正常入库。

Q5：解绑手机号后，之前的订单还能查到吗？

能。历史行为不会改变，只是后续用这个手机号上报时不再命中原用户。

Q6：合并后为什么报表里的 UV 变多了？

合并关系先记录、历史数据后归并；归并完成前，同一个人可能按新旧两个用户分别计数。这是当前的已知限制。

Q7：如何确认配置生效？

在管理端保存配置后会立即热生效；也可以用测试事件验证绑定、解绑、合并是否符合预期。

Q8：设备 ID 需要作为身份类型配置吗？

系统已预置匿名 ID 为设备类型，一般不需要额外配置。设备类 ID 由匿名用户表管理，不参与业务身份绑定，只用于兜底识别。如果业务还要使用 AndroidId、IDFV 等其它设备标识，需要先把它们注册为设备类型，否则绑定会被拒绝（未注册或未配置约束的类型无法绑定）。

技术指南

核心功能

用户关联

指标项说明

全域用户关联