IDMapping是采用关联规则和融合算法将来源于不同渠道的同一用户进行识别打通的功能模块，是VeCDP数据的基础底座。
比如用户的数据池中包含来自微信公众号、企业微信、抖音商城、自有多个App的订单或行为数据，每个渠道获取的用户数据标识不统一（如微信有UnionID、External_UserID，自有APP有DeviceID、EmailID、WebID及业务UseID等），常规情况下由于用户主键不统一导致数据无法串联分析，而IDMapping正是解决此类问题，使各个渠道的数据真正打通，形成更完整的数据档案和数据画像，实现更精准的洞察分析和营销应用。
2.1 主体
又称对象、个体、实体，即需要进行IDMapping的目标对象，如人、车、店等，通常具备以下属性：
- 具有主动的行为日志数据/经营日志，即会主动产生数据的对象，如人/门店/线索/车
- 具有完整的生命周期变化，即不是一成不变的且会随着某种过程成长变化的对象，如商品品牌/品类
常见主体说明：
主体分类 | 解释说明 |
|---|---|
人（用户） | 判断条件：
组合定义：
场景说明：如某金融机构有不同app的用户，考虑客户侧对用户的管理手段去定义主体
|
车 | 随着汽车智能化转型，车等同于手机代表一个终端用户，且车的数据来源相对单一且固定（Vin码），一般无需进行ID打通，仅需配置VinID即可。 |
门店 | 门店在经营管理过程中，其有完整的经营数据档案，如门店营收、经营状态等，也有可被触达的营销触点，如店主的手机、门店的app或终点经营工具（如收银台），门店的身份相对固定，一般仅需配置ShopID。 |
商品品类 | 商品作为主体时，建议以SKC商品品类为商品主体的最小粒度，因为品类在经营管理过程中具有库存、营收、销量等经营数据，使用上会同人-货-场形成多主体联动的应用，在供货推荐、定向营销等经营策略上形成数据联动。 |
2.2 OneID
又称BaseID、基准ID，是IDMapping融合的最终产物，表示围绕某个主体融合打通的唯一用户标识，通常也会定义成自然人。
如购买DataFinder或DataTester产品，OneID = SSID，底层复用一套统一的IDM服务 （2022年6月份之前单独购买Finder的用户除外）
说明
注意：
OneID（系统内名称为 Baseid）是通过IDMapping产生的唯一身份标识，VeCDP数据档案、标签体系均是以Baseid作为主键构建的数据模型，如在分群、营销推送、洞察分析需要分析其他ID类型，系统会根据ID-OneID的映射关系转化成对应ID，转换后的ID数量可能会大于OneID数量（多ID对应一个OneID）
OneID是表示唯一标识，通过不同ID查询OneID只能查询到一个结果，不会存在一个ID对应多个OneID！（最基准的原则，即一个人不可能有两个身份证）
2.3 ID类型
又称用户标识，是不同渠道上报的用户标记数据，比如设备ID、EmailID
常见不同渠道的ID类型：
ID类型（渠道标识） | ID 标识Code | ID类型名称 | ID类型描述 | 来源类型 | 推荐优先级 |
|---|---|---|---|---|---|
UID | UID | 用户ID | 业务侧实际注册产生的用户ID | 业务ID | 1 |
VIN_ID | VINID | 车辆ID | 业务侧车标识的唯一标识ID，常用Vin码 | ||
Shop_ID | SHOPID | 商家ID | 业务侧商家主体对应的唯一标识 | ||
Item_ID | ITEMID | 商品ID | 业务侧商品主体对应的唯一标识 | ||
Phone | PHONE | 手机号 | 手机号，明文展示的手机号 | 手机号认证 | 2 |
Phone_SHA256 | PHONE(SHA256) | 手机号（SHA256加密） | 手机号，使用SHA256加密算法加密 | ||
Phone_MD5 | PHONE(MD5) | 手机号（MD5加密） | 手机号，使用MD5加密算法加密 | ||
IDFA | IDFA | IDFA广告主标识符 | 广告主标识符（Identifier for advertisers，IDFA）即每台 iOS 设备独有的字母和数字组合，移动广告网络可以用它来跟踪用户并投放定向广告 | 设备标识 | 3 |
IDFA_MD5 | IDFA(MD5) | IDFA广告主标识符（MD5加密） | 广告主标识符（Identifier for advertisers，IDFA），采用MD5加密，即每台 iOS 设备独有的字母和数字组合，移动广告网络可以用它来跟踪用户并投放定向广告 | ||
IMEI | IMEI | IMEI手机序列号 | IMEI（International Mobile Equipment Identity）即国际移动设备身份码，也是通常所说的手机序列号、手机“串号”，是一个全球唯一的标识一个特定的移动电话设备的号码 | ||
IMEI_MD5 | IMEI(MD5) | IMEI手机序列号（MD5加密） | IMEI（International Mobile Equipment Identity），采用MD5加密，即国际移动设备身份码，也是通常所说的手机序列号、手机“串号”，是一个全球唯一的标识一个特定的移动电话设备的号码 | ||
OAID | OAID | OAID匿名设备号 | 匿名设备标识符（Open Anonymous Device Identifier，OAID）是由移动安全联盟、中国信息通信研究院及终端生产企业共同研究制定了联盟标准《移动智能终端补充设备标识体系规范》中的一种 Android 平台的设备标识 | ||
OAID_MD5 | OAID(MD5) | OAID匿名设备号（MD5加密） | 匿名设备标识符（Open Anonymous Device Identifier，OAID），采用MD5加密，是由移动安全联盟、中国信息通信研究院及终端生产企业共同研究制定了联盟标准《移动智能终端补充设备标识体系规范》中的一种 Android 平台的设备标识 | ||
DeviceID | DEVICEID | 设备ID | 客户侧通过设备标识计算出来的设备指纹 | ||
ByteId | BYTEID | 字节BYTEID | 字节BYTEID | 抖音生态 | 4 |
DY_UnionID | DY_UNIONID | 抖音应用身份UnionID | Openid是抖音用户在不同类型的产品的身份ID，是抖音号、抖店、小程序等用户在当前应用的唯一标识。 | ||
DY_MpID_OpenID | DY_MPID_OPENID | 抖音mpid + OpenID组合ID | MpID：媒体平台ID，如头条（54）、西瓜（117）、爱优腾等 | ||
DY_MpID_OpenID_MD5 | DY_MPID_OPENID(MD5) | 抖音mpid + OpenID组合ID（MD5加密） | MpID：媒体平台ID，如头条（54）、西瓜（117）、爱优腾等 | ||
DouDian_AppID_OpenID | DOUDIAN_APPID_OPENID | 抖音AppID+OpenID组合ID | Openid抖音用户唯一标识 | ||
WX_UnionID | WX_UNIONID | 微信公众号用户UnionID | 同一用户，对同一个微信开放平台帐号下的不同应用，UnionID是相同的UnionID是用户在微信开放平台上的唯一标识，包括小程序、公众号等，同一个用户的UnionID都是一样的。 | 微信公众号 | 5 |
WX_AppID_OpenID | WX_APPID_OPENID | 微信公众号用户AppID_OpenID组合ID | OpenID是用户在小程序中的唯一标识 即每个微信号对应每个公众号只有唯一的OpenID | ||
WX_External_UserID | WX_EXTERNAL_USERID | 微信应用用户ID | unionid + openid = 代开发应用external_userid，即服务商用户ID | 企业微信 | 5 |
WX_GROUP_CHAT_ID | WX_GROUP_CHATID | 企业微信群ID | 企业微信群ID | ||
PrivateID | PRIVATEID | 自定义ID | 在存量ID无法满足的情况，自定义的一个ID类型 | 自定义ID | 6 |
如购买DataFinder产品，DataFinder内会包含一些特有ID类型：
说明
- DataFinder上报用户ID（user_unique_id）及自定义ID时，请勿将不同类型的ID数据上报至统一ID类型中，如手机号和用户ID同时上报到用户ID（user_unique_id）
- DataFinder 存在单口径和多口径的功能，表示客户上报的ID类型数，如仅上报用户ID（user_unique_id）为单口径，如额外上报了自定义ID为多口径
ID类型（渠道标识） | ID 标识Code | ID类型名称 | ID类型描述 |
|---|---|---|---|
PrivateID | finder_uid | 用户ID（user_unique_id） | 业务用户ID, 客户进行设置，场景的有账号、手机号、email等 |
PrivateID | finder_did | 设备ID（device_id） | 移动端设备ID，又称为匿名ID，一个设备在不同的app中对应的设备id相同，为安全考虑，对外暴露的是bytedance device id，实际上可以理解为通过appid作为key对device id进行加密生成的一个设备id。 |
PrivateID | finder_webid | Web ID（web_id） | web端设备ID，又称为匿名ID |
PrivateID | finder_anonid | 匿名ID（anonymous_id） | 客户侧自定义设备ID，又称为匿名ID，可以由客户系统后端生成或历史已有的设备ID |
自定义ID | PRIVATEID | -- | 使用上同用户ID，用户上报的自定义ID，如手机号等 |
2.4 ID优先级及参考关系
- 优先级：不同渠道存在多个ID类型，在OneID生成过程中需要定义ID参与生成的先后顺序
- 参考关系：ID融合打通的关键是能够在**ID之间能建立一条连线**，存在连线的ID可以定义成一个OneID，此时这个联系就是参考关系，通常参考关系同优先级组合使用，共同定义OneID的生成顺序和融合规则。
比如用户主体拥有 设备DeviceID、手机号ID，基于不同优先级和参考关系的场景示例：
场景 | 示例图 | 设备DeviceID | 手机号ID | OneID | 说明 |
|---|---|---|---|---|---|
| 1 | BaseID1 | 无参考关系，DeviceID和手机号ID表示没有任何映射关系，此时每个DeviceID和每个手机号ID均代表一个用户，参照示例共5个用户 | ||
2 | BaseID2 | ||||
AA | BaseID3 | ||||
BB | BaseID4 | ||||
CC | BaseID5 | ||||
| 1 | AA | BaseID1 | 低优先级的AA/BB手机号均参考高优先级的 1 设备DeviceID，此时这两个手机号代表一个人 | |
1 | BB | BaseID1 | |||
2 | CC | BaseID2 | |||
| 1 | AA | BaseID1 | 数据表现上低优先级的AA 手机号映射了两个1/2设备DeviceID，但是实际OneID生成过程中 高优先级的1、2先生成OneID （BaseID1/BaseID2），低优先级去参考复用OneID时，只能复用其中一个，因此A手机号只能归属于 BaseID1/BaseID2的其中一个，具体归属哪个可以定义OneID生成和参考策略 | |
2 | BaseID2 |
2.5 OneID生成策略&参考策略（选配）
OneID生成策略：强制一对一 （默认关闭，即默认无需强制一对一）
- 说明：某种渠道的ID不管如何融合，都要求每个ID实际就对应一个人，不存在多个ID合并为一个人的场景，即通过OneID反查该ID时绝对只可定义到具体一个ID值
- 举例：如手机号设置了强制一对一，一个人有两个手机号，设置前可能根据参考相同的设备ID绑定到相同的OneID上，设置后每个手机号会对应一个OneID
- 场景建议：
- 场景1：所有低优先级的ID都参考到最高优先级的ID，此时可以保留默认设置-关闭
- 场景2：最高优先级的ID参考到低优先级的ID，此时最高优先级的ID设置强制一对一
- 场景3：如会员ID-手机号 = 1：N，优先级 会员ID > 手机号，客户要求一个会员只可以对应一个手机号，此时可以设置会员D和手机号强制一对一，手机号参考会员ID时设置参考策略。
OneID生成策略：离线参考实时（ 默认开启，即默认实时优先）
- **说明：**当ID数据来源有离线数据和实时数据时，离线侧会保留全部的参考关系，存在数据更精准但时效差的特点，实时数据则更多依赖实时上报数据里面是否包含丰富的数据关系，如果没有包含的话可能不会进行太多融合，而第二天离线数据又补齐了实时缺失的关系，此时离线和实时产生的OneID可能不同，因此需要决定到底希望OneID更准还是希望数据能够更好串联。
- 离线ID数据：ID 参考关系和全量数据比较全面准确；但时效性差，通常为 T-1
- 实时ID数据：ID 参考关系依赖实时数据上报，绝大部分情况不包含全量数据；时效性好，通常为 T-0
- 作用：
- 当同一个ID在离线侧和实时侧计算的Baseid发生冲突时，通过【离线参考实时】配置确定业务ID映射到离线侧或者实时侧的Baseid
举例：离线同实时融合场景一般用于新用户场景
比如，客户存在线上和线下两种渠道获客，线上用户用手机号登记了APP，但是同时线下营销进行了实名登记，获得了用户手机号和身份证号，身份证号优先级高于手机号，多个渠道可能同时登记多次，存在一个身份证号绑定多个手机号。
低优先级的ID是先参考高优先级的ID，还是先执行复用已有的OneID
时间 | 身份证号 | 手机号 | OneID | 说明 |
|---|---|---|---|---|
T天实时 | 123 | BaseID1 | ||
T天实时 | 234 | BaseID2 | ||
T日离线 | AA | BaseID0 | ||
T+1天离线 | AA | 123 | BaseID0 | 当手机号关闭【离线参考实时】时，手机号 123、234 均通过身份证 AA 绑定到 BaseID0。 |
T+1天离线 | AA | 234 | BaseID0 | |
T+1天离线 | AA | 123 | BaseID1 | 当手机号开启【离线参考实时】时，手机号 123、234 均根据实时侧数据分别绑定BaseID1、BaseID2。 |
T+1天离线 | 234 | BaseID2 |
- **场景建议：**建议Finder上报ID配置实时优先，非Finder 上报ID配置离线优先。
- 假设有 Finder_uid、uid 且优先级顺序为 Finder_uid > uid：
埋点上报的id类型 | 是否实时上报 ID 关系（通过 Idbind 接口） | 推荐开启离线参考实时的 ID | 推荐关闭离线参考实时的 ID | 能满足 | 不能满足 |
|---|---|---|---|---|---|
Finder_uid | Finder_uid | uid | Finder_uid在新客场景下，T日实时侧 和 T+1 日的实时侧、离线测的 baseid一致，行为串联 | ||
uid | 上报 Finder_uid 与 uid 的关联关系 | Finder_uid、uid | uid在新客场景下，T日实时侧 和 T+1 日的实时侧、离线测的 baseid一致，行为串联 | 新客场景下，由于埋点上报 Finder_uid 与 uid 的实时侧关联关系，这两者的离线侧关联关系不生效。最终两者生成的 baseid 可能与离线测关系不一致 | |
uid | Finder_uid | uid在新客场景下，T日实时侧 和 T+1 日的实时侧、离线测的 baseid一致，行为串联 | 新客场景下，由于 uid 在实时侧已经生成过 baseid，所以离线测 Finder 与 uid 的参考关系不生效，导致离线测及时有参考关系，计算后两者生成的 baseid 不一致 | ||
Finder_uid/uid多口径上报 | Finder_uid、uid | Finder_uid、uid 分别在离线侧和实时侧、T 日和 T+1日的 baseid一致 | Finder_uid、uid离线侧的参考关系不生效，即两者生成的 baseid 不一致 | ||
上报 Finder_uid 与 uid 的关联关系 | Finder_uid、uid | Finder_uid、uid离线侧和实时侧在 T 日和 T+1日的 baseid一致 |
OneID生成策略：OneID是否可变（ 默认开启，即默认允许变化）
- **说明：**考虑ID数据的稳定，不希望ID对应的OneID发生改变，此时可以关闭OneID可以变化的开关
- 关闭后，好处：ID对应的OneID不再因为参考关系、优先级等配置改变，数据稳定
- 关闭后，坏处：如果后续发生ID存在融合关系，此时不会再做ID打通，长期对OneID融合的覆盖准确有影响
- 场景：
- 最高优先级、非最高但未配置参考关系的ID可以关闭OneID变化
- 离线参考关系和ID的生成基本同时建立，后续基本不存在变化，可以关闭OneID变化
- 举例：如行为数据匿名登陆转实名注册且匿名存在较为丰富的行为操作，具备挖掘的价值，希望将匿名和实名的数据串联起来，此时可以对匿名的设备ID设置关闭OneID变化，保证匿名前后的行为串联。（此类场景如果匿名转实名的周期相对较短3天内，也可以通过「OneID修正功能」进行回刷串联）
- 注意：
- 强制一对一和关闭OneID变化 不要同时执行，同时配置时可能存在
OneID参考策略
- 作用：ID间相互参考时，如存在参考ID是一对多的关系，为了参考最合理的ID对应的OneID，则需要指定策略字段和策略逻辑，如不配置则采用系统默认策略随机选择一个作为参考的ID。
- **举例：**如「设备ID」参考「手机ID」时，数据上存在一个设备ID对应多个手机ID，此时可设置 最新 使用时间 的手机ID作为参考的手机ID，此时使用时间为策略字段，最新为策略逻辑
- 注意：参考策略常规仅在两个ID存在多对多、多对一且需严格转化为一对一参考时进行设置。
ID间换解绑操作
- **作用：**OneID生成过程中，首先看有没有参考到的ID，其次看ID本身有无已生成的OneID，如果两个ID前一天存在参考关系复用了相同的OneID，到第二天关系解除，高优先级的ID可以继续复用原有的OneID，低优先级虽然不再参考高优先级的OneID，但会复用历史已生成的OneID，此时两个ID对应的OneID还是相同的，在某些场景下不太符合预期，需要在第二步关系断掉时优先主动生成OneID而非复用历史已有的OneID。
- 举例：假设存在会员ID绑定手机号，支持换绑手机号的操作，此时被换绑的手机号不应该跟原始会员关联。
- ID类型及优先级：会员ID > 手机号，手机号根据绑定关系参考会员ID
会员ID | 手机号 | 未开启换绑 | 开启换绑 | |
|---|---|---|---|---|
T-1天 | 1 | A | baseid1 | baseid1 |
T天 | -- | A | baseid1 | baseid2 |
1 | B | baseid1 | baseid1 |
跨主体转换关系
说明
注意：主体转换关系和参考关系是两个完全不同的概念
主体转换关系是服务于**多个主体间进行主体转换使用的，如人-车购买关系
参考关系是服务于一个主体多个ID**进行OneID生成的，如手机号参考设备号
- 作用：主体转换关系是表示两个主体相互转换时使用的关系数据，其具有具体的业务含义，数据表现上至少会存储两列，一列是主体1的ID，一列是主体2的ID，两者同时出现在一行时表示其业务映射关系，具体会在跨主体圈选、跨主体洞察分析、跨主体查询服务等场景选择应用。
- **场景：**以人和车两个主体为例，人和车具备偏好关系、购买关系、维保关系等多重业务关系，每个关系都代表一个主体转换关系，如希望根据人的标签和车的标签共同圈选目标用户时，此时严格依赖关系数据作为关联查询条件