ID-Mapping简介
-
相同设备,不同账号间切换
-
相同用户,不同渠道下账号不相同,如微信小程序和APP
-
同个用户,在不同的设备商登录
-
…
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)
具体实现方案可使用图计算或图数据库实现。
总结
原文始发于微信公众号(数据思考笔记):用户体系搭建之ID-Mapping
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论