用户体系搭建之ID-Mapping
ID-Mapping简介
在推进用户画像和风险控制时,遇到的最大的问题是用户身份信息的混乱:
- 相同设备,不同账号间切换
- 相同用户,不同渠道下账号不相同,如微信小程序和APP
- 同个用户,在不同的设备商登录
- …
ID-Mapping是大数据分析中非常基本但又关键的环节,ID-Mapping通俗的说就是把几份不同来源的数据,通过各种技术手段识别为同一个对象或主题,例如同一台设备(直接),同一个用户(间接),同一家企业(间接)等等,可以形象地理解为用户画像的“拼图”过程。一个用户的行为信息、属性数据是分散在很多不同的数据来源的,因此从单个数据来看,都相当于“盲人摸象”,看到的只是这个用户一个片面的画像,而ID-Mapping能把碎片化的数据全部串联起来,消除数据孤岛,提供一个用户的完整信息视图,同时让某一个领域的数据在另一个领域绽放出巨大的价值。
ID-Mapping有非常多的用处,比如:
- 跨屏跟踪和跨设备跟踪,将一个用户的手机(App、小程序)、PC、平板等设备的上的行为信息串联到一起。
- 风险防控层面,通过模型识别可能存在用户、设备伪造问题。
ID-Mapping行业内方案
阿里巴巴OneID
在阿里巴巴内部用户的ID类型包含:phone、PC cookie、IMEI与IDFA、淘宝账户、支付宝账户、邮箱等。而对于每个BU来说,他们知道的只是这个客户的片面属性,在开展营销活动时,只是针对一个手机号或一个邮箱做营销,但背后不能识别出来一个自然人、一个公司。为打破数据孤岛,创造更大的数据价值,阿里使用OneData作为核心方法论。
OneData体系包含:
- OneModel:数据资产构建与管理
- OneID:实体打通和画像
- OneService:逻辑化服务
OneID 的做法是通过统一的实体识别和连接,打破数据孤岛,实现数据通融。简单来说,用户、设备等业务实体,在对应的业务数据中,会被映射为唯一识别(UID)上,其各个维度的数据通过这个 UID 进行关联。各个部门、业务、产品对业务实体的 UID 的定义和实现不一样,使得数据间无法直接关联,成为了数据孤岛。基于手机号、身份证、邮箱、设备 ID 等信息,结合业务规则、机器学习、图算法等算法,进行 ID-Mapping,将各种 UID 都映射到统一 ID 上。通过这个统一 ID,便可关联起各个数据孤岛的数据,实现数据通融,以确保业务分析、用户画像等数据应用的准确和全面。
网易ID-Mapping
网易产品线有网易云音乐、网易邮箱、网易新闻、网易严选等,不同应用上有不同的ID,如yanxuanid、oaid、musicid、phone、email、idfa、imei等。
要想标识唯一ID,网易采用的思路及方案为:结合各种账户、各种设备型号之间的关系对,以及设备使用规律等用户数据,采用规则规律、数据挖掘算法(连通图划分+社区发现)的方法,判别账户是否属于同一个人。
ID-Mapping过程中,常遇到的问题及对应方案如下:
- 用户有多个设备信息。解决方案:定义相关的阈值进行关联。社区发现当前应用于营销场景,暂未用于风控或用户运营场景,因为这种方式会把一些异常的账号关联在一起,且会存在仅登录使用过一次的设备信息。
- 设备过期,一般是2年半左右时间。解决方案:设定衰减系数,对单用户多设备加大衰减力度。
备注:通常一人多设备对应的场景有,借用朋友设备、设备脏数据、刷号等。
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的过程。
美团ID-Mapping
美团与大众点评进行了合并,那同一个用户在两个APP上有不同的身份标识,美团要怎样进行唯一标识呢?我们来看看美团和大众点评的账号体系。美团采用手机号、微信、微博、美团账号的登录方式;大众点评采用的手机号、微信、QQ、微博的登录方式;其交集为手机号、微信、微博。最终,对于注册用户账户体系,美团采用了手机号作为用户的唯一标识。
从上述案例可看出,ID-Mapping有三种常见方法:
- 基于账号体系企业中最常用的是基于账号体系来做ID的打通,用户注册时,给到用户一个uid,以uid来强关联所有注册用户的信息。
- 基于设备:那对于未注册用户可以通过终端设备ID精准识别,包含Android/iOS两类主流终端的识别。通过SDK将各种ID采集上报,后台利用的ID关系库和校准算法,实时生成/找回终端唯一ID并下发。
- 基于账号&设备:结合各种账户、各种设备型号之间的关系对,以及设备使用规律等用户数据,采用规则规律、数据挖掘算法的方法,输出关系稳定的ID关系对,并生成一个UID作为唯一识别该对象的标识码。
id-mapping实现方案
id-mapping技术手段1:按账号优先级
按账号优先级进行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”这种简单条件逻辑很难实现。
id-mapping技术手段2:借助图计算
采用图计算手段,来找到各种id标识之间的关联关系,从而识别出哪些id标识属于同一个人
图计算的核心思想:将数据表达成“点”,点和点之间可以通过某种业务含义建立“边”。然后,我们就可以从点、边上找出各种类型的数据关系:比如连通性,比如最短路径规划,id_mapping(id打通)的最后目标,就是形成一个id映射字典:
整体流程:
- 将当日数据中的所有用户标识字段,及标志字段之间的关联,生成点集合 、边集合
- 将上一日的ids->guid的映射关系,也生成点集合、边集合
- 将上面两类点集合、边集合合并到一起生成一个图
- 再对上述的图执行“最大连通子图”算法,得到一个连通子图结果
- 在从结果图中取到哪些id属于同一组,并生成一个唯一标识
- 将上面步骤生成的唯一标识去比对前日的ids->guid映射表(如果一个人已经存在guid,则沿用原来的guid)
具体实现方案可使用图计算或图数据库实现。
总结
One ID的核心价值是打通数据孤岛,把不同时期孤立建设的系统,用统一的ID串联起来。One ID功能就像是在修桥梁,把各个数据孤岛贯通之后,这些孤岛就连成一片。数据孤岛被打破之后,我们就能更全面、更完整的了解我们的用户、产品、商家,能够更加精准的评价他们的价值,进行进一步的价值发现,为精细化运营夯实数据基础。One ID的核心技术是ID-Mapping,其原理是将各系统的关键要素抽象成图计算用的“点”和“边”,用图计算算法很轻易的判定同一个“对象”,从而构建一个个无向连通图,生成ID映射字典。这个ID映射字典就是一座座通往各个数据孤岛的桥梁。我们通过这些桥梁,可以把相同“对象”在不同孤岛中的数据串联起来。
参考链接: