01 | ID-Mapping 简介
在推进用户画像和风险控制时，遇到的最大的问题是用户身份信息的混乱：
- 相同设备，不同账号间切换
- 相同用户，不同渠道下账号不相同，如微信小程序和APP
- 同个用户，在不同的设备商登录
- …
ID-Mapping是大数据分析中非常基本但又关键的环节，ID-Mapping通俗的说就是把几份不同来源的数据，通过各种技术手段识别为同一个对象或主题，例如同一台设备（直接），同一个用户（间接），同一家企业（间接）等等，可以形象地理解为用户画像的“拼图”过程。
一个用户的行为信息、属性数据是分散在很多不同的数据来源的，因此从单个数据来看，都相当于“盲人摸象”，看到的只是这个用户一个片面的画像，而ID-Mapping能把碎片化的数据全部串联起来，消除数据孤岛，提供一个用户的完整信息视图，同时让某一个领域的数据在另一个领域绽放出巨大的价值。
ID-Mapping有非常多的用处，比如：
- 跨屏跟踪和跨设备跟踪，将一个用户的手机（App、小程序）、PC、平板等设备的上的行为信息串联到一起。
- 风险防控层面，通过模型识别可能存在用户、设备伪造问题。
02 | ID-Mapping行业内方案
1、阿里巴巴OneID
在阿里巴巴内部用户的ID类型包含：phone、PC cookie、IMEI与IDFA、淘宝账户、支付宝账户、邮箱等。而对于每个BU来说，他们知道的只是这个客户的片面属性，在开展营销活动时，只是针对一个手机号或一个邮箱做营销，但背后不能识别出来一个自然人、一个公司。为打破数据孤岛，创造更大的数据价值，阿里使用OneData作为核心方法论。
OneData体系包含：
- OneModel：数据资产构建与管理
- OneID：实体打通和画像
- OneService：逻辑化服务
OneID 的做法是通过统一的实体识别和连接，打破数据孤岛，实现数据通融。简单来说，用户、设备等业务实体，在对应的业务数据中，会被映射为唯一识别（UID）上，其各个维度的数据通过这个 UID 进行关联。各个部门、业务、产品对业务实体的 UID 的定义和实现不一样，使得数据间无法直接关联，成为了数据孤岛。基于手机号、身份证、邮箱、设备 ID 等信息，结合业务规则、机器学习、图算法等算法，进行 ID-Mapping，将各种 UID 都映射到统一 ID 上。通过这个统一 ID，便可关联起各个数据孤岛的数据，实现数据通融，以确保业务分析、用户画像等数据应用的准确和全面。
2、网易ID-Mapping
网易产品线有网易云音乐、网易邮箱、网易新闻、网易严选等，不同应用上有不同的ID，如yanxuanid、oaid、musicid、phone、email、idfa、imei等。
要想标识唯一ID，网易采用的思路及方案为：结合各种账户、各种设备型号之间的关系对，以及设备使用规律等用户数据，采用规则规律、数据挖掘算法（连通图划分+社区发现）的方法，判别账户是否属于同一个人。
ID-Mapping过程中，常遇到的问题及对应方案如下：
- 用户有多个设备信息。解决方案：定义相关的阈值进行关联。社区发现当前应用于营销场景，暂未用于风控或用户运营场景，因为这种方式会把一些异常的账号关联在一起，且会存在仅登录使用过一次的设备信息。
- 设备过期，一般是2年半左右时间。解决方案：设定衰减系数，对单用户多设备加大衰减力度。
备注：通常一人多设备对应的场景有，借用朋友设备、设备脏数据、刷号等。
3、58同城 ID-Mapping
58业务场景丰富，其产品线包含58同城、赶集、安居客、中华英才网、转转、58到家等。在这种多用户、多业务线、多子公司的情况下，用户数据种类繁杂，构建画像的数据来自于日志、简历库、帖子库、用户信息库、商家库、认证信息库等数据源，其中仅日志就涉及到58、赶集、安居客等各个子产品的PC/M/APP日志。如何将众多数据源串联起来是构建用户画像面临的第一个问题，如下是58构建的ID-Mapping模型图。
从图中可以看出，不同业务线所拥有的ID标识不一：
- 58同城：wuser、wbdid、wimei
- 58赶集：guser、gbdid、gapud、gimei
- 安居客：kimei
其中可以通过telep、bidua、appua、imei、idfa关联起来，由此建立不同ID之间的关联映射关系，就是ID-Mapping的过程。
4、美团ID-Mapping
美团与大众点评进行了合并，那同一个用户在两个APP上有不同的身份标识，美团要怎样进行唯一标识呢？我们来看看美团和大众点评的账号体系。美团采用手机号、微信、微博、美团账号的登录方式；大众点评采用的手机号、微信、QQ、微博的登录方式；其交集为手机号、微信、微博。最终，对于注册用户账户体系，美团采用了手机号作为用户的唯一标识。
从上述案例可看出，ID-Mapping有三种常见方法：
- 基于账号体系企业中最常用的是基于账号体系来做ID的打通，用户注册时，给到用户一个uid，以uid来强关联所有注册用户的信息。
- 基于设备：那对于未注册用户可以通过终端设备ID精准识别，包含Android/iOS两类主流终端的识别。通过SDK将各种ID采集上报，后台利用的ID关系库和校准算法，实时生成/找回终端唯一ID并下发。
- 基于账号&设备：结合各种账户、各种设备型号之间的关系对，以及设备使用规律等用户数据，采用规则规律、数据挖掘算法的方法，输出关系稳定的ID关系对，并生成一个UID作为唯一识别该对象的标识码。
03 | id-mapping实现方案
1、id-mapping：按账号优先级
按账号优先级进行id-mapping是最简单的方案，将数据库中的手机号/uid/deviceid等按优先级取一个标识，作为这条数据的用户唯一标识。但这个方案存在严重的漏洞。
在现实的日志数据中，由于，用户可能使用各种各样的设备，有着各种各样的前端入口，甚至同一个用户拥有多个设备以及使用多种前端入口，就会导致，日志数据中对同一个人，不同时间段所收集到的日志数据中，可能取到的标识个数、种类各不相同。
比如，用户可能使用各种各样的设备和渠道：
- 手机、平板电脑
- 安卓手机、ios手机
- 有PC、APP和小程序
产生问题：用户设备的标识，没办法轻易定制一个规则来取某个作为唯一标识：
- cookieid：PC站存在用户cookies中的ID，会被清理电脑时重生成
- unionid：微信提供的唯一身份认证
- mac：手机网卡物理地址， 若干早期版本的ios，winphone，android可取到
- imei(入网许可证序号)：安卓系统可取到，若干早期版本的ios，winphone可取到，运营商可取到
- imsi(手机SIM卡序号)：安卓系统可取到，若干早期版本的ios，winphone可取到，运营商可取到
- androidid ：安卓系统id
- openuuid(app自己生成的序号) ：卸载重装app就会变更
- idfa（广告跟踪码）：用户可重置
- deviceid(app日志采集埋点开发人员自己定义一种逻辑id，可能取自 android,imei,openudid等)：逻辑上的id
从而导致：有些场景有某些数据，有些场景没有，从而没有办法行程整合的一份数据。要从这些纷繁复杂的各类id中，分辨出哪些id属于同一个受众（设备），用普通的“where x=y”这种简单条件逻辑很难实现。
2、id-mapping：借助图计算
采用图计算手段，来找到各种id标识之间的关联关系，从而识别出哪些id标识属于同一个人
图计算的核心思想：将数据表达成“点”，点和点之间可以通过某种业务含义建立“边”。然后，我们就可以从点、边上找出各种类型的数据关系：比如连通性，比如最短路径规划，id_mapping(id打通)的最后目标，就是形成一个id映射字典：
整体流程：
- 将当日数据中的所有用户标识字段，及标志字段之间的关联，生成点集合 、边集合
- 将上一日的ids->guid的映射关系，也生成点集合、边集合
- 将上面两类点集合、边集合合并到一起生成一个图
- 再对上述的图执行“最大连通子图”算法，得到一个连通子图结果
- 在从结果图中取到哪些id属于同一组，并生成一个唯一标识
- 将上面步骤生成的唯一标识去比对前日的ids->guid映射表（如果一个人已经存在guid，则沿用原来的guid）
具体实现方案可使用图计算或图数据库实现。
04 | 总结
One ID的核心价值是打通数据孤岛，把不同时期孤立建设的系统，用统一的ID串联起来。One ID功能就像是在修桥梁，把各个数据孤岛贯通之后，这些孤岛就连成一片。数据孤岛被打破之后，我们就能更全面、更完整的了解我们的用户、产品、商家，能够更加精准的评价他们的价值，进行进一步的价值发现，为精细化运营夯实数据基础。
One ID的核心技术是ID-Mapping，其原理是将各系统的关键要素抽象成图计算用的“点”和“边”，用图计算算法很轻易的判定同一个“对象”，从而构建一个个无向连通图，生成ID映射字典。这个ID映射字典就是一座座通往各个数据孤岛的桥梁。我们通过这些桥梁，可以把相同“对象”在不同孤岛中的数据串联起来。
