客户身份
身份就好比我们的身份证，一旦信息出错，将有可能导致各渠道数据匹配出错，甚至完全混乱，所以在接入各渠道数据之前，请务必先梳理清楚各渠道身份情况、身份优先级及合并逻辑。
1.概述#
DM Hub支持接入全渠道数据，如微信粉丝数据、页面表单数据、线下活动数据、天猫订单数据、网页浏览数据，以及第三方系统对接数据。当各渠道的数据汇入DM Hub时，我们会通过身份id去匹配数据，保证数据准确落在对应的客户身上，如手机号码、邮箱、微信openid，微信unionid都可以作为一种身份类型来唯一识别一个客户。
记录客户身份主要有以下两个作用：
通过跨渠道身份（如手机号、邮箱）可以将多个渠道的客户信息整合到一起，实现跨渠道客户数据打通；
外部系统通过渠道身份信息就可以对特定的客户进行CRUD（增查改删）操作（而不用记录DM Hub系统内部的客户id）。
2.客户特殊属性和身份的区别#
在DM Hub中，手机号码和邮箱既可以作为客户属性，也可以作为客户身份，那么它们之间有什么区别呢？
数据获取方式不同： 手机号码和邮箱属性可以通过表单，数据对接，导入，手动修改等方式获得；手机号码和邮箱身份暂时仅支持调用接口创建；
读写特性： 手机号码和邮箱属性支持修改，但身份暂不支持修改；
唯一性： 不同客户可能拥有相同的手机号或邮箱属性，但是不会拥有相同的手机号或邮箱身份；
用途不同： 手机号码和邮箱属性主要用于对客户进行触达，如发送短信（邮件）；客户身份主要用于客户匹配和识别。
caution
在导入客户数据时，如果文件中包含“手机号码”和“邮箱”，匹配时是先通过身份去匹配数据，当没有对应的身份时，才会使用手机号码或邮箱属性去匹配
3.系统中创建客户身份的场景#
绑定微信服务号：授权后自动导入微信粉丝，自动添加粉丝的微信身份openid（如果有申请微信开放平台且绑定公众号，则还有unionid）；
关注公众号：openid（如果有申请微信开放平台且绑定公众号，则还有unionid）
微信环境提交微页面表单：openid
访问微页面时进行了微信授权：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的两者的 |
| 在用商品 | 保留客户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) | 如果根据提供的多个客户身份找到多个客户，且多个客户不存在身份唯一性冲突，则根据“目标客户策略”找到目标客户，先将其他客户合并到目标客户，再对目标客户进行字段更新。 |
高优先级身份优先 (不合并)
高优先级身份优先 (合并)
最先找到的客户优先（不合并）
最先找到的客户优先（合并）
