在简易用户关联方案中，所有的用户 ID 会被分为两类，一类是设备 ID（匿名 ID），一类是登录 ID。
在实际业务中，很多触点的用户标识，会介于上述二者之间，比如微信生态的 OpenID 和 UnionID。
为了彻底解决用户关联的问题，我们采用了新的标识用户方案，该方案与过往最大的区别在于所有的 ID 都有了明确的含义。
请注意，项目部署后，默认是使用简易用户关联的一对一关联方案，若需要更换到全域用户关联方案，可联系神策值班同学。
用户关联方案可升级方式：简易用户关联一对一关联方案 > 简易用户关联多对一关联方案 > 全域用户关联，只允许从前到后单向升级（可从一对一直接升级到全域用户关联），不支持反向升级。
项目重置后，默认会回退到简易用户关联一对一关联方案，若需要更换到全域用户关联方案，可联系神策值班同学。
典型场景
概述
使用场景
单业务线中存在多个触点
业务触点包含 App、Web、微信小程序、微信公众号、企业微信等多触点，需要尽快打通用户在不同触点的数据。
跨业务线数据打通
多业务线用户没有打通（例如一个手机号登录不同业务线，获取到的用户登录标识不一样），现需要做跨业务线用户打通。
基本概念
神策 ID
神策分析使用神策 ID（即 events 表里的 user_id 和 users 表里的 id）来对每个产品的用户进行唯一的标识，而神策 ID 是基于业务 ID 按照一定规则生成的。
业务 ID
概述
一个用户在不同的触点、不同的业务阶段，都可以获取到不同 ID 来标识用户行为，例如设备 ID、邮箱地址、微信的 OpenID 和 UnionID，用户登录标识等，这些我们统称为业务 ID。这些业务 ID 的区别主要是生命周期和精度的不同。
分类
业务 ID 可以大致分为设备 ID、特定生态的 ID、业务相关的标识三类；
分类
描述
代表
设备 ID
这类 ID 指的是神策客户端 SDK 在首次初始化后，默认生成的设备 ID，例如 Web 端的 UUID (因为存在 cookie 中也称 cookie_id)，iOS 端的 IDFV。
这类业务 ID 的特征是不稳定、生命周期也比较短。
例如 Web 端的 Cookies 有可能被清空（比如各种安全卫士），iOS 端的 IDFV 在 App 卸载重新安装后会发生变化等。
AndroidId、IDFV、cookie_id 等
特定生态的 ID
这类 ID 指的是特定生态中标识用户的 ID，例如微信生态的 OpenID、UnionID，企业微信生态的外部联系人 ID。
这类业务 ID 相比于设备 ID，稳定性会大大提高，生命周期也相对较长，但是仍然会存在变化的可能。
例如 App 注册登录后，绑定了微信号，后续可能因为各种原因，解绑之前的微信号，重新绑定一个新的微信号。
OpenID、UnionID 等
业务相关的标识
这类 ID 主要是实际业务系统中的用户 ID，通常是业务数据库里中用户表的主键。
相比于特定生态的 ID，这类 ID 主要是由业务系统生成，稳定性更高，生命周期更长。
用户登录 ID 等
语义明确
相比于过去只有匿名 ID 和登录 ID，在该方案中，所有的业务 ID 在事件上报以及神策系统中，都会标识明确的类型。
数据上报中，每条数据会有 identities 结构，里面会有明确类型的业务 ID：
{
"distinct_id":"123",
"login_id":"123",
"anonymous_id":"xxxxxxxx",
"identities":{
"identity_a_user_id":"123",
"$identity_mp_unionid":"aZxxxxxxxx",
"$identity_mobile":"131xxxxxxxx",
"$identity_android_id":"xxxxxxxx"
}
……
}
神策系统中，
关于 ID，神策系统内会预置常用的 ID，具体可以参考 预置 id key 清单
其中，$identity_login_id 是系统内优先级最高的 ID，每个用户有且只有一个该 ID（对应数量配置始终为 1），无法更改。
关于 $identity_login_id 对应业务中的哪一个 ID？
需要业务侧确定是否有一种 ID 能够唯一标识所有用户，如果有则使用 $identity_login_id 来承接，如果没有则可以不使用该 $identity_login_id。
没有 $identity_login_id，会有什么影响？
对于业务上没有影响，其他有数据的 ID 会按照给定的规则正常关联。
使用 $identity_login_id 的好处是什么？
当一个用户关联上 $identity_login_id 之后，其 user_id 会变得稳定，不会因为关联其他 ID 而发生变化。
使用 $identity_login_id 上报的事件数据，由于其 user_id 的稳定，不会触发事件回溯，在一定程度上可以减少回溯带来的事件变化。
$identity_login_id 是否有什么额外的限制？
有，$identity_login_id 作为系统内优先级最高且唯一的 ID，是无法解绑的。
能力介绍
业务 ID 自由关联
得益于每个业务 ID 都有明确的类型，我们可以支持任意业务 ID 之间的自由关联，当然前提是需要将这些业务 ID 在同一条数据中上报上来。
例如，可以直接将用户的设备 ID 和对应的 OpenID 进行关联，也可以将用户微信生态的 UnionID 和 OpenID 进行关联，同样可以将一个用户不同业务线的登录 ID 进行关联。
支持业务 ID 解绑
过去，一个登录 ID 和一个匿名 ID 一旦关联，就不可改变。
但是实际业务会有很多需要更换 ID 的场景，例如最常见的手机号更换，银行卡解绑。
该方案可以实现已关联业务 ID 的解绑，只需要调用对应 SDK 的相关接口或者构建对应的解绑事件，即完成用户已关联业务 ID 的解绑。
解绑事件示例如下：
{
"identities":{
"$identity_mobile":"131xxxxxxxx"
},
"type":"track_id_unbind",
"event":"$UnbindID",
"project":"xxx",
……
}
关联原则
一个 ID 在同一时刻内，有且只有一个神策 ID。例如，同一个手机号，不可能同时是用户 A 和用户 B 的，同一个设备 ID 亦是如此；
完全孤立的 ID 是无法进行打通的；如果需要明确 A_ID=A1、B_ID=B1 是一个用户，那么必须有一条数据里同时有 A_ID=A1、B_ID=B1，这样知晓两个 ID 之间的关系，从而实现打通。
关键概念
用户业务 ID 的含义明确了，也会带来一个变化，就是业务 ID 的类型变多了。
（神策系统内会预置一些业务 ID，覆盖诸如微信公众号、微信小程序、企业微信、App 等主要场景；如果仍然不满足业务需求，则可以通过神策系统内「数据融合」>「用户表」>「配置用户关联」来新增。）
如果一条数据中上报了很多类型的业务 ID，这些业务 ID 能否成功关联，还需要看另外两个概念：数量和优先级。
关联约束
关联约束是业务 ID 级别的配置，其含义是一个用户可以拥有单个还是多个此类型的业务 ID；
比如手机号，一个人只能有一个，那么手机号的数量配置就是单值；
比如 AndroidId，一个人可能会更换手机、或者同时使用多个手机，那么 AndroidId 的数量配置就是多值；
当上报数据违反关联约束时，则新上报的业务 ID 会关联失败，无法写入用户表对应的业务 ID 中。
优先级
当上报数据的业务 ID 无法成功关联时，就需要使用业务 ID 优先级，来判断事件的归属用户。
假设，客户有两个 ID，一个是 A_ID，一个是设备 ID，ID 配置如下表格：
优先级
业务 ID
关联约束
备注
1
A_ID
单值
A 业务线登录 ID
2
设备 ID
多值
普通设备 ID
用户的操作如下：
当用户在小米手机上（AndroidID=小米 1）登录 A_ID=A1，小米 1 和 A1 成功关联；
当用户在该小米手机上，切换登录另一个账号 A_ID=A2，小米 1 和 A2 无法成功关联，如果 A1、A2、小米 1 关联为一个用户，则违反了 A_ID 数量为 1 的限制。
那么切换账号后，用户行为应该归属谁呢？
由于 A_ID 的优先级高于设备 ID，所以切换账号后的行为应该归属于 A2 对应的用户。
关联上限
关联约束为多值的用户标识可以设置关联上限，即：单个用户可以关联该标识的最大数量。
该数值只能输入大于 1 且小于 500 的整数。
超限策略
标识当单个用户关联对应标识超过关联上限时的处理策略。
滚动解绑：（默认策略）删除最早的标识，新的标识继续关联。
数据拦截：整条数据拦截，已关联的标识不会发生改变。
适用场景
该方案主要适用于 ID 来源复杂多样，ID 关系复杂的场景，举例如下：
业务触点多：需要打通微信生态、H5、App、电商平台、内部 CRM 等全渠道的数据，
拉通相互独立的多业务线的用户数据：例如同一手机号登录不同的业务线，获取到的业务线登录 ID 不一致，现在需要将不同业务线的同一个用户拉通；
实施方法
梳理各个触点的需要用于标识用户的业务 ID；
确定各个业务 ID 的数量以及优先级；
埋点侧将对应的业务 ID 都进行采集和上报。
案例
业务 ID 配置信息（以下配置仅表示示例，实际配置会有所差别）
优先级
业务 ID
数量
1
login_id
1
2
mobile
1
3
UnionID
1
4
A_OpenID
1
5
B_OpenID
1
6
C_OpenID
1
7
AndroidId
N
events 表
序列
event（事件）
AndroidId（安卓设备 ID）
login_id（业务线登录 ID）
mobile（手机号）
A_OpenID（订阅号 OpenID）
B_OpenID（服务号 OpenID）
C_OpenID（小程序 OpenID）
UnionID（微信 UnionID）
user_id（神策 ID）
1
用户下载安装使用 App
AndroidId_x
1
2
用户注册登录 App
AndroidId_x
login_id_1
1
3
用户绑定了手机号
AndroidId_x
login_id_1
131xxxxxxxx
1
4
用户在订阅号 A 产生交互
A1
U1
2
5
用户在服务号 B 产生交互
B1
U1
2
6
用户访问小程序 C 并授权手机号
131xxxxxxxx
C1
U1
2 > 1
7
用户在 App 上解绑了原先的手机号
131xxxxxxxx
1
8
用户在 App 上绑定新手机号
login_id_1
156xxxxxxxx
1
users 表
id（神策 ID）
AndroidId（安卓设备 ID）
login_id（业务线登录 ID）
mobile（手机号）
A_OpenID（订阅号 OpenID）
B_OpenID（服务号 OpenID）
C_OpenID（小程序 OpenID）
UnionID（微信 UnionID）
1
AndroidId_x
login_id_1
131xxxxxxxx 156xxxxxxxx
A1
B1
C1
U1
2
A1
B1
U1
详细步骤说明如下：
用户下载安装 App，获取到 AndroidId=AndroidId_x，分配对应的神策 ID 为 1，同时将神策 ID 1、AndroidId_x 写入 users 表对应的字段中；
用户注册登录 App，获取到 login_id=login_id_1，AndroidId_x 和 login_id_1 关联成功，并将 login_id_1 写入 users 表对应的字段中；
用户绑定了手机号，获取到 mobile=131xxxxxxxx，AndroidId_x、login_id_1、131xxxxxxxx 关联成功，同样将 131xxxxxxxx 写入 users 表对应的字段中；
用户在订阅号 A 有交互，获取到对应的订阅号 A_OpenID=A1 和 UnionID=U1，A1、U1 都是全新的业务 ID，所以新分配神策 ID 为 2，同时将神策 ID 2、A1、U1 写入 users 表对应的字段中；
用户在服务号 B 有交互，获取到对应的 B_OpenID=B1 和 UnionID=U1，B1 和 U1 关联成功，并将 B1 写入 users 表对应的字段中；
用户访问小程序 C 并授权手机号，可以同时获取到 mobile=131xxxxxxxx 和 UnionID=U1，由于 mobile=131xxxxxxxx 与神策 ID 1 的手机号相同，且关联不违反原则，所以神策 ID 2 会合并到神策 ID 1 上，同时 users 表中删除神策 ID 2；
用户在 App 上解绑了原先的手机号 mobile=131xxxxxxxx，解绑成功，131xxxxxxxx 会从 users 表中神策 ID 1 的 mobile 字段中删除；
用户在 App 上绑定新手机号 mobile=156xxxxxxxx，绑定成功，156xxxxxxxx 会写入 users 表中神策 ID 1 的 mobile 字段中；
后续修复：
由于用户访问小程序 C 并授权手机号，触发了神策 ID 1 和神策 ID 2 的合并，之后 users 表会将神策 ID 2 进行删除；
事件表中原先的神策 ID 2，也会被一并修复成神策 ID 1；
至此，用户在 App 端和微信生态的行为，全部拉通了。
局限性
不支持表达不同用户之间关系
全域用户关联可以完成单个用户在不同业务线、不同触点的用户标识打通，但无法表达不同类型用户之间的关系。
例如学生和老师的关系，一个老师可以对应多个学生，一个学生也可以对应多个老师。