客户身份
身份就好比我们的身份证，一旦信息出错，将有可能导致各渠道数据匹配出错，甚至完全混乱，所以在接入各渠道数据之前，请务必先梳理清楚各渠道身份情况、身份优先级及合并逻辑。
1.概述
DM Hub 支持接入全渠道数据，如微信粉丝数据、页面表单数据、线下活动数据、天猫订单数据、网页浏览数据，以及第三方系统对接数据。当各渠道的数据汇入 DM Hub 时，我们会通过身份 id 去匹配数据，保证数据准确落在对应的客户身上，如手机号码、邮箱、微信 openid，微信 unionid 都可以作为一种身份类型来唯一识别一个客户。
记录客户身份主要有以下两个作用：
通过跨渠道身份（如手机号、邮箱）可以将多个渠道的客户信息整合到一起，实现跨渠道客户数据打通；
外部系统通过渠道身份信息就可以对特定的客户进行 CRUD（增查改删）操作（而不用记录 DM Hub 系统内部的客户 id）。
2.客户特殊属性和身份的区别
在 DM Hub 中，手机号码和邮箱既可以作为客户属性，也可以作为客户身份，那么它们之间有什么区别呢？
数据获取方式不同： 手机号码和邮箱属性可以通过表单，调用接口，导入，手动修改等方式获得；手机号码和邮箱身份支持通过导入文件和调用接口创建；
读写特性： 手机号码和邮箱属性支持修改，但身份暂不支持修改；
唯一性： 不同客户可能拥有相同的手机号或邮箱属性，但是不会拥有相同的手机号或邮箱身份；
用途不同： 手机号码和邮箱属性主要用于对客户进行触达，如发送短信（邮件）；客户身份主要用于客户匹配和识别。
在导入客户数据时，如果文件中包含“手机号码”和“邮箱”，匹配时是先通过身份去匹配数据，当没有对应的身份时，才会使用手机号码或邮箱属性去匹配
3.系统中创建客户身份的场景
绑定微信服务号：授权后自动导入微信粉丝，自动添加粉丝的微信身份 openid（如果有申请微信开放平台且绑定公众号，则还有 unionid）；
关注公众号：openid（如果有申请微信开放平台且绑定公众号，则还有 unionid）
微信环境提交微页面表单：openid（如果有申请微信开放平台且绑定公众号，则还有 unionid）
访问微页面时进行了微信授权：openid（如果有申请微信开放平台且绑定公众号，则还有 unionid）
淘宝：导入天猫订单时会自动将淘宝会员名作为淘宝身份
创建会员：成为会员后，对应的客户将自动生成一个会员身份；微信环境通过提交 DM Hub 创建的会员注册页表单创建的会员，对应的客户除了有会员身份还会有 openid 和手机号。
4.身份设置
4.1 功能位置
设置中心-基础数据-客户身份
4.2 身份唯一性
支持自定义设置身份值是否为唯一
4.2.1 身份值不唯一的场景示例：
比如一家企业有 3 个微信公众号，并且将这 3 个公众号粉丝全部接入到 DM Hub，客户 A 同时关注了 3 个公众号，如果设置了微信 openid 身份唯一，则粉丝 A 会在 DM Hub 中分别根据 openid1、openid2、openid3 创建 3 个客户。但是通常从用户画像完整性的角度，我们更希望将粉丝 A 在 3 个公众号中的所有行为集中到一个客户，此时就必须将微信 openid 身份设置为不唯一（也就是身份唯一这里不勾选），然后通过微信 unionid 来实现身份匹配（参考什么是 unionid 及 unionid 的作用）。
4.2.2 身份值唯一的场景示例：
首先会员 id 肯定是唯一的，因此在 DM Hub 中会员 id 这个身份类型默认就是唯一的，且无法更改。因为一个客户最多只能对应创建一个会员，不允许出现一对多的情况。再比如淘宝 id，也应该是唯一的。
4.3 身份优先级
- 身份优先级可以直接在【设置中心-身份】进行设置，也可以在接口中预设其处理逻辑；
- 外部系统传入事件或者订单时对应的客户可能会有多个身份，根据身份优先级依次匹配；
- 当添加或合并客户身份产生冲突时，可以利用优先级来解决这个冲突。
4.4 系统已有身份的默认设置
| 身份名称 | 优先级 | 身份类型 | 默认身份唯一 | 可自定义唯一性 | 可自定义优先级 |
|---|---|---|---|---|---|
| 会员 | 0 | membershipId | 是 | X | X |
| 手机号码 | 1 | mobile | 否 | √ | √ |
| 微信 openid | 2 | 否 | √ | √ | |
| 微信 unionid | 3 | wechat-unionid | 否 | √ | √ |
| 小程序 | 4 | applet-wechat | 否 | √ | √ |
| 淘宝 | 5 | taobao-account | 否 | √ | √ |
| 支付宝 | 6 | alipay-account | 否 | √ | √ |
| 支付宝生活号 | 7 | alipay | 否 | √ | √ |
| 企业微信 | 8 | wechatcorp | 否 | √ | √ |
| 邮箱 | 9 | 否 | √ | √ | |
| dmhub | 10 | dmhub | 否 | √ | √ |
| 有赞 ID | 11 | cp_extyouzan_identity_userId | 否 | X | X |
| 企业微信 | 12 | cp_employee_tools_identity_corp | 否 | X | X |
| MD5 加密身份 | 13 | commonMd5 | 否 | X | √ |
| 天猫加密身份 | 14 | tmallMd5 | 否 | X | √ |
| 京东加密身份 | 15 | jdMd5 | 否 | X | √ |
4.5 什么是加密身份
由于数据隐私和安全问题，有些渠道只能提供加密的手机号码（如天猫、京东会员）身份，同时也会提供加密方法，为了支持全渠道客户数据匹配识别，系统会对其他渠道获取的明文“手机号码”身份也进行对应方式加密，根据密文就能匹配识别。(目前仅手机号码身份支持加密)
4.6 加密身份的处理逻辑
- 每种加密类型的加密结果会记录为一个新的系统身份（这些身份是非唯一的且不可修改）；
- 设置好“手机号码”的加密方式以及用于存储加密信息的身份后，之后进入系统的明文手机号码身份，都会根据加密算法自动生成对应的加密身份，且直接根据加密身份自动识别匹配客户；
- 修改加密 key 后，不会自动更新历史的加密身份，需要删除原有加密数据，并重新计算新的加密结果。
4.7 加密规则
| 加密类型 | 加密规则 | 备注 |
|---|---|---|
| MD5 加密 | MD5 加密 | |
| 天猫 MD5 加密 | MD5(MD5("tmall"+$content+$key));加密后的字符串为 32 位小写。tmall 为固定字符 串，key 为手机号加密密钥(会员中心开发者后台、测试平台可见)、content 为需要加密的 内容(这里是 moblie) | 品牌多个门店，加密的 key 不同 |
| 京东 MD5 加密 | 加密规则为拼接字符串两次 MD5 加密（大写）：加密手机号=MD5(MD5(品牌秘钥+会员体系 id+用户手机号+品牌秘钥)) | 品牌多个门店，品牌秘钥相同 |
提供 Open API 来查看手机号码身份的各类加密身份值
5.客户合并
首先要明确两个概念，合并和更新。
合并： 客户合并是指系统中已经存在两个客户 A 和 B，由于他们存在某些关键信息（如手机号、邮箱）一致或者相似，可以将他们合并为一个客户（前提是这两个客户身份没有冲突，否则合并失败）。
更新： API 传过来的数据匹配到系统中的某个客户，将数据更新到系统中已有的客户上。
5.1 系统自动合并场景：
相同 Unionid 的客户合并
场景： 每一个粉丝在每一个公众号中都有对应的一个 openid 身份，如果您有多个微信公众号，并且均授权绑定到 DM Hub 中，关注这两个公众号时就会根据 oepnid 分别创建客户。例:您有 A、B 两个公众号，粉丝小 D 关注了 A，然后又关注了 B，这样系统中就会出现昵称均为小 D，但是身份分别是 openidA、openidB 两个客户。但是如果这两个公众号在授权 DM Hub 之后在微信开放平台进行了绑定，则除了 openid 身份以外，还有一个 unionid 身份，并且在 A、B 两个公众号中的 unionid 相同。对于绑定后新关注进来的客户，会自动获取 uninonid 和 openid 两个身份，关注第二个公众号的时候就会 unionid 进行匹配更新。但是在绑定开放平台之前创建的粉丝，会自动获取 unionid 并且进行合并吗？注意，这里历史粉丝是不会自动更新 unionid 的，必须将绑定的公众号解绑，重新授权导入粉丝。如解绑后，先授权 A 公众号，再授权 B 公众号，则原来身份是 openidB 的客户 B 就会因为和客户 A 有一样的 unionid 而进行合并。
合并说明： 将按照标准的合并规则合并，合并方向为客户 B 合并到客户 A
提交微页面表单后合并客户
场景： 系统已经存在一个手机号为 189XXX 的客户 A，没有 openid 身份，然后客户 B 关注公众号（在系统中将新建一个有 openid 身份的客户 B），接着客户 B 又提交了微页面表单，该表单有手机号码字段且手机号有验证码要求（这是合并的必要条件），其中手机号填写的也是 189XXX，提交后客户 A 合并到了 B。
合并说明： 客户 id 将保留有 openid 身份的客户；如果 A 和 B 存在身份冲突（身份冲突指的是两个客户有相同渠道的相同身份类型，openid 除外，比如客户 A 和客户 B 的会员 ID 不同）将不合并；若没有身份冲突则会进行合并，且是先合并再根据填写的表单内容来更新客户信息；（注：鉴于创建和合并客户需要时间，为了保证自动流的触发条件或事件判断能正常执行，提交表单事件将延迟几秒钟发送出去）。
5.2 客户合并的处理逻辑
以下说明中均以客户 A 合并到客户 B 的顺序为例
5.2.1 客户合并后的客户 ID 处理逻辑：
合并后将保留客户 B 的客户 id，可以理解为客户 A 被删除了，客户 B 被更新了。客户 A 的客户 id 在系统中不存在了，主要影响是：
- 权益码的发放记录，抽奖活动的抽奖记录都是关联的客户 id（不影响事件），合并后并不会更新为新 id；
- 外部系统对接中可能使用了客户 A 客户 id，出现查询不到该客户等情况。
5.2.2 客户相关信息的合并逻辑：
| 客户信息 | 合并规则 |
|---|---|
| 群组 | 保留客户 A 和客户 B 两者的（智能群组会在之后重算并判定客户是否仍属于该群组） |
| 标签 | 保留客户 A 和客户 B 两者的（智能和模型标签会在之后重算并判定客户是否仍拥有该标签） |
| 身份 | 保留客户 A 和客户 B 两者的（如果两个客户都有系统的会员身份，不允许合并） |
| 订单 | 保留客户 A 和客户 B 的两者的 |
| 客户指标 | 保留客户 B 的 |
| 任务 | 保留客户 A 和客户 B 的两者的 |
| 事件 | 保留客户 A 和客户 B 的两者的 |
合并后客户属性的值默认以客户 B 为准，仅当其属性值为空时，才取客户 A 的属性值。但是部分属性有例外，如下表所示：
| 客户属性 | 合并规则 |
|---|---|
| 省份、城市、区县 | 仅当客户 B 的这三个属性值都为空时，才会取客户 A 的属性值 |
| 创建时间、创建方式、创建自 | 统一取创建时间更早的客户的属性值 |
| 来源相关的字段、营销活动 | 统一取创建时间更早的客户的属性值 |
| 客户阶段 | 取阶段更高的客户的属性值 |
| 是否会员 | A 和 B 中如果存在某个客户的“是否会员”（ID：isMember）为是，那合并后该属性保持为“是” |
5.2.3 客户合并对自定流程的影响
合并发生时若客户 A 正在某个自动流中且在进行中：
- 情况 1：该自动流进行中的客户没有客户 B，则将由客户 B 取代客户 A，继续走完自动流
- 情况 2：该自动流进行中的客户已有客户 B，则不处理（即客户 A 被删除了）
5.3 客户合并的处理方式
5.3.1 系统中手工操作
上文中已介绍系统通过客户身份能对客户数据进行自动匹配，但是还是存在一些特殊场景，考虑到数据合并可能导致部分数据丢失，系统无法准确进行自动合并，这个时候可能需要用户人工操作合并客户。合并客户有两个入口，一是【设置中心】-【数据操作】-【合并客户】
两个功能入口的指向一样，DM Hub 支持合并手机号或邮箱属性相同的客户，选择合适的合并方式。
选择后，系统将开始扫描客户，给出合并意见，如下图所示：
邮箱冲突： 邮箱冲突指的是两个客户虽然有相同的手机号属性，但邮箱不一致。邮箱是联系客户的关键信息，如果冲突需要客户谨慎选择保留哪个邮箱
身份冲突： 身份冲突指的是两个客户拥有相同手机号属性，且拥有相同的身份类型，且这种身份类型的身份 id 不一致。
基于此，DM Hub 给出如下的合并意见：
推荐合并： 组内客户不存在邮箱或身份冲突。
谨慎合并： 组内客户存在邮箱冲突或部分客户存在身份冲突。组内存在邮箱冲突，那么合并时需要选择合并后保留哪个邮箱，组内部分客户身份冲突，那么无身份冲突的客户还是可以选择合并。
无法合并：组内所有客户彼此身份冲突。
我们选择“推荐合并”来进行合并操作，其中每一块都是待合并的一组客户，通过左侧的 checkbox 可以选择要合并的客户，您也可以直接点选合并后希望保留的客户属性，选中的属性在右边会显示一个绿色的"√"。
右上方有两个勾选框：
显示客户身份：勾选后将在表中右侧显示客户身份
显示相同的属性值：勾选后，这一组客户中，值相同的客户属性也会显示。
批量合并
针对扫描后“推荐合并”的所有分组，系统支持一键批量合并，点击右上角按钮便可以进行批量合并。
注意：多个客户合并时，客户 id 优先保留有会员身份的，再是有微信身份的，再是其他身份的客户。
5.3.2 API 进行客户合并
参考文档：客户合并
6.API-多身份创建客户
6.1 多身份创建客户 API 使用说明
参考文档：多身份创建客户
6.2 多身份创建客户的处理策略
使用 API 多身份创建客户时可以附带多个客户身份信息，根据策略的不同，DM Hub 会进行客户创建、更新或合并。具体步骤如下：
- 根据提供的客户身份，DM Hub 首先使用“目标客户策略”寻找目标客户
- 找到目标客户后，DM Hub 会根据“客户合并策略”决定是否对多个客户进行合并；
- 如果身份不冲突，DM Hub 将未关联客户的身份关联到目标客户；
- DM Hub 将 API 提供的客户字段更新到目标客户。
客户创建中的策略表
| 策略分类 | 策略名称 | 策略行为 |
|---|---|---|
| 身份唯一性策略 | 系统身份唯一性策略 | 在 DM Hub 设置中心进行设置；外部应用插件的身份，插件可以设置身份的唯一性 |
| 身份优先级策略(identityPriorityStrategy) | 系统身份优先级 (system)默认策略(v2) | 使用系统配置的身份优先级 |
| 自定义身份优先级 (custom)默认策略(v1) | 以 API 提供的身份的顺序为优先级 | |
| 目标客户策略(targetCustomerStrategy) | 高优先级身份优先(identityFirst) | 按身份优先级的顺序查找客户:如果用最高优先级身份能找到客户，则该客户为目标客户,否则，接着用次高优先级身份查找客户，如果找到客户：1. 将比当前身份优先级高的身份添加到客户上会有冲突，则接着用下一个优先级身份查找；2. 将比当前身份优先级高的身份添加到客户上没有冲突，则该客户作为目标客户，并将比当前身份优先级低的身份添加到目标客户（若有冲突，则添加失败）如果最后匹配到的客户都会带来身份冲突，则以最高优先级身份创建一个新客户，并将新客户为目标客户，接着添加其他身份。 |
| 最先找到的客户优先(customerFirst)默认策略(v1, v2) | 按身份优先级的顺序查找客户，第一个找到的客户为目标客户（不检查高优先级身份冲突问题）如果找不到匹配的客户，则以最高优先级身份创建一个新客户，并将新客户为目标客户添加其他身份。 | |
| 客户合并策略(autoMerge) | 不合并客户(false)默认策略(v1, v2) | 如果根据提供的多个客户身份找到多个客户，则根据“目标客户策略”找到目标客户，并对目标客户进行字段更新。不对客户进行合并。 |
| 合并客户(true) | 如果根据提供的多个客户身份找到多个客户，且多个客户不存在身份唯一性冲突，则根据“目标客户策略”找到目标客户，先将其他客户合并到目标客户，再对目标客户进行字段更新。 |
高优先级身份优先 (不合并)
高优先级身份优先 (合并)
最先找到的客户优先（不合并）
最先找到的客户优先（合并）
