标识用户——全域用户关联

在简易用户关联方案中，所有的用户 ID 会被分为两类，一类是设备 ID（匿名 ID），一类是登录 ID。

在实际业务中，很多触点的用户标识，会介于上述二者之间，比如微信生态的 OpenID 和 UnionID。

为了彻底解决用户关联的问题，我们采用了新的标识用户方案，该方案与过往最大的区别在于所有的 ID 都有了明确的含义。

请注意，项目部署后，默认是使用简易用户关联的一对一关联方案，若需要更换到全域用户关联方案，可联系神策值班同学。

用户关联方案可升级方式：简易用户关联一对一关联方案→简易用户关联多对一关联方案→全域用户关联，只允许从前到后单向升级（可从一对一直接升级到全域用户关联），不支持反向升级。

项目重置后，默认会回退到简易用户关联一对一关联方案，若需要更换到全域用户关联方案，可联系神策值班同学。

典型场景

基本概念

神策 ID

神策分析使用神策 ID (即 events 表里的 user_id 和 users 表里的 id )来对每个产品的用户进行唯一的标识，而神策 ID 是基于业务 ID 按照一定规则生成的。

业务 ID

概述

一个用户在不同的触点、不同的业务阶段，都可以获取到不同 ID 来标识用户行为，例如设备 ID、邮箱地址、微信的 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 配置如下表格：

用户的操作如下：

1. 当用户在小米手机上（AndroidID=小米 1）登录 A_ID=A1，小米 1 和 A1 成功关联；
2. 当用户在该小米手机上，切换登录另一个账号 A_ID=A2，小米 1 和 A2 无法成功关联，如果 A1、A2、小米 1 关联为一个用户，则违反了 A_ID 数量为 1 的限制。

那么切换账号后，用户行为应该归属谁呢？

由于 A_ID 的优先级高于设备 ID，所以切换账号后的行为应该归属于 A2 对应的用户。

关联上限

关联约束为多值的用户标识可以设置关联上限，即：单个用户可以关联该标识的最大数量。

该数值只能输入大于 1 且小于 500 的整数。

超限策略

标识当单个用户关联对应标识超过关联上限时的处理策略。

滚动解绑：（默认策略）删除最早的标识，新的标识继续关联。

数据拦截：整条数据拦截，已关联的标识不会发生改变。

适用场景

该方案主要适用于 ID 来源复杂多样，ID 关系复杂的场景，举例如下：

• 业务触点多：需要打通微信生态、H5、App、电商平台、内部 CRM 等全渠道的数据，
• 拉通相互独立的多业务线的用户数据：例如同一手机号登录不同的业务线，获取到的业务线登录 ID 不一致，现在需要将不同业务线的同一个用户拉通；

实施方法

1. 梳理各个触点的需要用于标识用户的业务 ID；
2. 确定各个业务 ID 的数量以及优先级；
3. 埋点侧将对应的业务 ID 都进行采集和上报。

案例

业务 ID 配置信息（以下配置仅表示示例，实际配置会有所差别）

events 表

users 表

详细步骤说明如下：

1. 用户下载安装 App，获取到 AndroidId=AndroidId_x，分配对应的神策 ID 为 1，同时将神策 ID 1、AndroidId_x 写入 users 表对应的字段中；
2. 用户注册登录 App，获取到 login_id=login_id_1，AndroidId_x 和 login_id_1 关联成功，并将 login_id_1 写入 users 表对应的字段中；
3. 用户绑定了手机号，获取到 mobile=131xxxxxxxx，AndroidId_x、login_id_1、131xxxxxxxx关联成功，同样将 131xxxxxxxx 写入 users 表对应的字段中；
4. 用户在订阅号 A 有交互，获取到对应的订阅号 A_OpenID=A1 和 UnionID=U1，A1、U1 都是全新的业务 ID，所以新分配神策 ID 为 2，同时将策 ID 2、A1、U1 写入 users 表对应的字段中；
5. 用户在服务号 B 有交互，获取到对应的 B_OpenID=B1 和 UnionID=U1，B1 和 U1 关联成功，并将 B1 写入 users 表对应的字段中；
6. 用户访问小程序 C 并授权手机号，可以同时获取到 mobile=131xxxxxxxx 和 UnionID=U1，由于 mobile=131xxxxxxxx 与神策 ID 1 的手机号相同，且关联不违反原则，所以神策 ID 2 会合并到神策 ID 1 上，同时 users 表中删除神策 ID 2；
7. 用户在 App 上解绑了原先的手机号 mobile=131xxxxxxx，解绑成功，131xxxxxxxx  会从 users 表中神策 ID 1 的 mobile 字段中删除；
8. 用户在 App 上绑定新手机号 mobile=156xxxxxxxx，绑定成功，156xxxxxxxx 会写入 users 表中神策 ID 1 的 mobile 字段中；

后续修复：

1. 由于用户访问小程序 C 并授权手机号，触发了神策 ID 1 和神策 ID 2 的合并，之后 users 表会将神策 ID 2 进行删除；
2. 事件表中原先的神策 ID 2 ，也会被一并修复成神策 ID 1；

至此，用户在 App 端和微信生态的行为，全部拉通了。

局限性

不支持表达不同用户之间关系

全域用户关联可以完成单个用户在不同业务线、不同触点的用户标识打通，无法表达不同类型用户之间的关系。

例如学生和老师的关系，一个老师可以对应多个学生，一个学生也可以对应多个老师。