表	作用（通俗理解）
用户表	记录每个用户的最新信息（编号、登录 ID、设备 ID、用户属性）
匿名用户表	按设备查用户：这台设备现在属于谁
登录用户表	按账号查用户：这个账号现在是哪个用户

三张表配合，才能同时支持"按设备找用户"和"按账号找用户"。

3. 关联规则

3.1 一句话概括

一个账号可以拥有多台设备；一台设备在同一时间只属于一个账号。

这是 ClkLog 简易关联的实际行为，也就是常说的"多对一"模式。

3.2 典型情况

场景	系统如何处理
用户第一次匿名访问	以设备 ID 建立用户，用户 ID 就是设备 ID
设备上第一次登录账号 A（该设备未绑定其他账号）	设备用户升级为账号 A 的用户，用户 ID 不变；账号 A 与这台设备绑定
账号 A 在另一台设备登录	直接使用账号 A 原来的用户 ID；新设备加入账号 A 名下
同一台设备换账号 B 登录	账号 B 建立自己的用户；设备改归账号 B；账号 A 的数据不受影响
退出登录后继续访问	按设备记录，可能形成独立的匿名记录；重新登录后回到对应账号的用户
用户清除缓存或换设备	产生新的设备 ID，视为新设备；登录后仍会回到原账号用户

3.3 用户 ID 是怎么确定的

纯匿名：用户 ID 直接使用设备 ID；
登录后：用户 ID 使用"登录 ID_设备 ID"的组合，或者沿用该设备/账号第一次登录时已经存在的用户 ID。

对使用者来说只需要记住一点：用户 ID 一旦建立就会尽量沿用，不会因为再次登录而改变。

4. 数据上报要求

4.1 需要调用的 SDK 动作

用户动作	SDK 调用	产生的事件
打开页面/使用功能	`track`	普通行为事件
登录成功	`login(登录 ID)`	`$SignUp` 登录事件
退出登录	`logout`	不产生事件，但后续事件不再携带登录 ID
设置用户属性	`profile_set` 等	用户属性事件

4.2 必填字段

每条事件必须同时具备：

anonymous_id（设备 ID）；
distinct_id（当前标识：匿名时等于设备 ID，登录后等于登录 ID）。

缺少任意一个，事件会在数据处理阶段被丢弃。

4.3 登录事件示例

{
  "distinct_id": "user_123",
  "login_id": "user_123",
  "anonymous_id": "cookie_id_xxx",
  "type": "track_signup",
  "event": "$SignUp"
}

登录后的普通事件示例：

{
  "distinct_id": "user_123",
  "login_id": "user_123",
  "anonymous_id": "cookie_id_xxx",
  "type": "track",
  "event": "SubmitOrder"
}

4.4 接入建议

登录成功后立即调用 login()，不要等到下一次页面打开；
退出登录调用 logout()，让后续行为回到设备维度；
不要在登录态手工修改 anonymous_id；
如果业务有服务端注册/登录接口，建议同时在服务端补发登录事件，降低客户端丢数据的概率；
同一页面不要切换不同的数据接收地址，否则设备 ID 和用户 ID 容易错乱。

5. 数据如何存储与统计

5.1 处理过程

SDK 上报事件
   ↓
接收服务校验并写入消息队列
   ↓
处理服务识别：这是哪台设备、哪个账号
   ↓
确定用户 ID，写入用户关系表
   ↓
行为事件带着用户 ID 写入分析库

系统会缓存近期的"设备 → 用户"和"账号 → 用户"关系，减少重复查询；缓存只用于加速，失效后由用户表兜底恢复。

5.2 报表口径

所有 UV、漏斗、留存、Session 统计都按用户 ID 计算；
匿名用户和登录用户是同一个用户时，登录后的行为会继续记在原用户下；
明细表（log_analysis）保存 distinct_id，项目事件表只保存用户 ID；两者都不单独保存登录 ID，因此报表无法直接按登录 ID 筛选事件。

6. 完整案例

假设用户小张：

时间	行为	设备/账号	系统记录
第 1 天	新手机安装 App，浏览商品	设备 X	建立用户 U1，用户 ID = X
第 1 天	注册并登录账号 A	设备 X、账号 A	用户仍为 U1，账号 A 绑定到 U1
第 2 天	用同一账号 A 在平板登录	设备 Y、账号 A	仍为用户 U1，设备 Y 加入 U1
第 3 天	在平板上退出账号 A，继续浏览	设备 Y	按设备 Y 记录
第 3 天	在平板上登录账号 A	设备 Y、账号 A	回到用户 U1
第 5 天	把手机送给朋友，朋友登录账号 B	设备 X、账号 B	账号 B 建立新用户 U2；设备 X 改归 U2
第 5 天	朋友用账号 B 继续使用	设备 X、账号 B	记为用户 U2

可以看到：

账号 A 在手机和平板上的登录后行为，能够归到同一个用户 U1；
账号 B 不会和账号 A 混在一起；
但账号 A 在平板"登录之前"的匿名浏览，仍留在独立记录中，不会自动并入 U1。这是本方案的固有限制。

7. 适用场景与局限

7.1 适合的场景

有明确的注册/登录体系；
主要诉求是打通"同一账号在不同设备上的登录后行为"；
不希望维护手机号、邮箱、微信 ID 等复杂身份关系；
数据量和身份类型相对简单。

7.2 局限

局限	说明
不支持业务 ID 关联	手机号、邮箱、UnionID、OpenID 等不参与关联
不能解绑	设备与账号一旦建立关系，系统不提供解绑能力
登录前行为不回溯	新设备上"先浏览、后登录"的那段行为不会自动并入账号用户
设备只能属于一个账号	一台设备被新账号登录后，旧账号在该设备上的匿名行为不会再归旧账号
换设备会拆数据	换设备后、登录前的行为会被识别为新用户
同一设备多人使用	后登录的账号会接管设备，前一个账号的匿名行为无法区分

8. 常见问题

Q1：用户登录后，之前的匿名行为会自动算到账号上吗？

在同一台设备上首次登录时，设备用户会直接升级为账号用户，登录前后的行为是同一个用户。但如果用户是在新设备上先浏览、后登录，登录前的那段行为不会自动并入账号用户。

Q2：同一个账号在多台设备登录，会算作一个用户吗？

会。账号第一次建立用户后，后续设备登录都会复用该用户 ID。

Q3：一台设备换了账号，之前账号的数据会丢吗？

不会丢，也不会被改写。旧账号的数据仍在旧用户下；设备从换账号时刻起归新账号。

Q4：退出登录后，用户算谁？

系统按设备识别。重新登录后回到对应账号的用户。登录期间的账号归属不会因为退出登录而被删除。

Q5：清除浏览器缓存会怎样？

设备 ID 会变化，系统视为新设备。用户重新登录后仍会回到原账号用户；但清除缓存到重新登录之间的行为会被识别为新的匿名用户。

Q6：为什么有的事件没有进报表？

优先检查是否同时上报了 anonymous_id 和 distinct_id。缺少任意一个，事件会被丢弃。

Q7：这个方案能改成全域用户关联吗？

不能直接切换。全域用户关联（IDM 3.0）仅 ClkLog CDP 企业版3.0 支持，ClkLog PRO 专业版、CDP 企业版3.0之前的版本均不支持。可联系ClLog客服升级到 ClkLog CDP 企业版3.0 ，升级后，可在项目管理中把 IDM 版本切换为 3.0，并完成身份类型和约束配置；切换不会自动迁移已有的用户关系和历史数据，新旧用户 ID 可能并存。

9. 产品版本说明

简易用户关联对应 IDM 2.0，ClkLog PRO 专业版、PRO 专业版3.0、CDP 企业版、CDP 企业版3.0 均支持；
新建项目默认使用简易用户关联 2.0；
全域用户关联（IDM 3.0）仅 ClkLog CDP 企业版3.0 支持，其他产品版本不支持；如需使用，请联系 ClkLog 客服升级为 ClkLog CDP 企业版3.0。

Docker安装

技术指南

源码安装

集成说明

核心功能

用户关联

指标项说明

ClkLog 简易用户关联（IDM 2.0）

1. 方案概述与适用场景

2. 基本概念

2.1 ClkLog 用户 ID

2.2 设备 ID（匿名 ID）

2.3 登录 ID

2.4 三张用户表