在OneData 体系中,OneID 指统一数据萃取,是一套解决数据孤岛问题的思想和方法。
数据孤岛是企业发展到一定阶段后普遍遇到的问题。各个部门、业务、产品,各自定义和存储其数据,使得这些数据间难以关联,变成孤岛一般的存在。
OneID的做法是通过统一的实体识别和连接,打破数据孤岛,实现数据通融。简单来说,用户、设备等业务实体,在对应的业务数据中,会被映射为唯一识别(UID)上,其各个维度的数据通过这个UID进行关联。
各个部门、业务、产品对业务实体的UID的定义和实现不一样,使得数据间无法直接关联,成为了数据孤岛。
基于手机号、身份证、邮箱、设备ID等信息,结合业务规则、机器学习、图算法等算法,进行 ID-Mapping,将各种 UID 都映射到统一ID上。通过这个统一ID,便可关联起各个数据孤岛的数据,实现数据通融,以确保业务分析、用户画像等数据应用的准确和全面。
在推进用户画像和风险控制时,遇到的最大的问题是用户身份信息的混乱:
假如没有网络身份证,那么每个商家(App)只能基于自己的账号体系标识用户,并记录用户的行为。而有了统一的网络身份证之后,各个商家之间的数据就可以打通了,天猫不仅知道用户A在淘宝系的购物数据,也能了解到该用户在社交网络的行为,以及旅游的喜好,等等。
在现实的数据中,由于,用户可能使用各种各样的设备,有着各种各样的前端入口,甚至同一个用户拥有多个设备以及使用多种前端入口,就会导致,日志数据中对同一个人,不同时间段所收集到的日志数据中,可能取到的标识个数、种类各不相同;
存在的问题
设备 ID
需要注意的是,设备 ID 并不一定是设备的唯一标识。例如 Web 端的 Cookies 有可能被清空(例如各种安全卫士),而 iOS 端的 IDFV( Identifier For Vendor)在不同厂商的 App 间是不同的,而且重新安装IDFV会被重置。
比如用户可能使用各种各样的设备,其次是不同设备有不同的操作系统,设置是软件本身的版本也会影响我们对用户的标识,
手机、平板电脑、PC
安卓手机、ios手机、winphone手机
安卓系统有各种版本 ( 5.0 6.0 7.0 8.0 9.0 )
ios系统也有各种版本(3.x 4.x 5.x 6.x 7.x … 12.x )
登录 ID,用户名,手机号
登录 ID 通常是业务数据库里的主键或其它唯一标识。所以 登录 ID,相对来说更精确更持久。但是,用户在使用时不一定注册或者登录,而这个时候是没有_登录 ID_ 的。
**基于账号:**体系企业中最常用的是基于账号体系来做ID的打通,用户注册时,给到用户一个uid,以uid来强关联所有注册用户的信息。
基于设备:那对于未注册用户可以通过终端设备ID精准识别,包含Android/iOS两类主流终端的识别。通过SDK将各种ID采集上报,后台利用的ID关系库和校准算法,实时生成/找回终端唯一ID并下发。
**基于账号&设备:**结合各种账户、各种设备型号之间的关系对,以及设备使用规律等用户数据,采用规则规律、数据挖掘算法的方法,输出关系稳定的ID关系对,并生成一个UID作为唯一识别该对象的标识码。
方案一:仅使用设备 ID,不管用户是谁,只要设备未变,设备ID 就不变,即使多人使用同一个设备,也会被识别为同一个用户。
方案二:关联设备 ID 和登录 ID(一对一),
当用户换手机后,登录账号之后的行为与换手机之前的行为贯通了,但是在新设备上首次登录之前的行为仍没法贯通,仍被识别为新的用户的行为。
当用户把旧手机送给朋友之后,由于旧手机已被关联到自己的登录 ID 了,无法再与朋友的登录 ID 关联。后续使用这台旧手机的用户们,若不登录就操作,则都会被识别为同一个用户。
方案三:关联设备 ID 和登录 ID(多对一)
当用户把旧手机送给朋友之后,由于旧手机已被关联到自己的登录 ID 了,无法再与朋友的登录 ID 关联。后续使用这台旧手机的用户们,若不登录就操作,则都会被识别为同一个用户)。
而事实上,旧手机上后续的匿名登录很难识别到底是谁,可能归为匿名登录之前最近一次登录的用户会更合理一些。
其实,三种方案没有对与错,我们应该结合自己的业务场景以及埋点复杂度来选择合适的方案。
百度用的是图数据库的方式解决的。
图计算的逻辑就是把数据抽象成“点”和“边”,然后用图计算天然的“连接”特效,实现数据的自动识别和打通。
怎么实现ID串联
你看,其实我们要做的,就是把这几个数据做一个打通,类似于这样:
你看这个图,既没有方向,也可能不能形成“环”状。这就是一个无向连通图。这么着一连,这些信息就能对上了。
ID Mapping 有几个场景:1、多端数据的识别;2、多源数据的打通。这两种情况的处理方式基本是一样的。
先举一个例子:老王在商城PC端浏览商品,在手机端下单,后台自动生成订单,交给ERP进行后续的订单、物流处理。后来老王有点不耐烦,给供应链金融客服打电话咨询。那么老王的数据如下:
(注:大多数情况下网页端和手机端的 UUID 是一样的,这只是一个例子,理解大意就行)
所以呢, ID Mapping 的过程基本是以下几步:
整体流程:
就这样,孤立的系统数据就算是从 ID 层面打通了,我们基于这个字典我们就能做更多事情了,比如更全面的画一个用户画像。
数据我们也能存好,怎么放都行,最好是扔ES等查询速度快的数据库里,对外提供 One ID 的查询服务。
以上就是ID-Mapping的核心技术了。在实际落地的时候,你还会遇到各种各样的问题,比如遇到多对多的情况怎么办?之前缺少要素匹配不上,但是后来用户增加了信息,又匹配上了咋办?
结果数据存成什么样比较好用?放在那里比较好?要不要建一个DV模型方便找数据?那是工程建设中需要考虑的问题。这就得完全靠实践出真知了。
虽然上面的示例讲起来非常简单,但真实的用户数据存在于车企多个平台,且数据形式和数据信息也存在差异,真正操作起来还会存在很多“模棱两可”、“拿不准”的情况,因此,在利用ID Mapping串联用户信息的时候,需要设定规则。
规则的范围包含:①针对新增用户数据、②针对同一用户在不同渠道数据整合规则、③用户数据整合过程中涉及的细节、颗粒度补充规则等。
① 比如新增用户规则:如何判断不同组数据是否为同一用户数据?假如我们设定身份证号相同,即判断为同一人(E6a592f68g035T3),身份证号不同,赋予新的OneID(E6a592f68g035T4);
② 同一用户若在不同渠道/平台间都存在数据,且数据相悖,那么我们应该取信哪个?如:VIN码为LFV123XXXXXX的车辆,在发票系统中留的车主姓名为王俊凯,而在售后系统中留的车主姓名为黄晓明。那么这辆车的车主到底叫什么名字?这时候我们应该对渠道来源置信度做规则设定。如根据了解,发票系统是每个用户在购车时需出示身份证件登记录入的,而售后去返厂维修保养的时候,却只需要送修人口头说一声即记录,因此我们判定:发票> 售后。在做OneID用户信息整合的时候,应该取这辆车的车主姓名王俊凯。
③ 用户数据整合过程中涉及的细节、颗粒度问题:虽然我们知道发票系统置信度较高,但实际探查发现,发票系统中有些用户信息的填充率很低(比如:婚姻状态、学历、邮箱等),这种情况下,就要“变通行事”,采用多主键或取其他渠道信息填充率高且准确率也高的数据,补充完善车主信息。
One ID的核心价值是打通数据孤岛,把不同时期孤立建设的系统,用统一的ID串联起来。One ID功能就像是在修桥梁,把各个数据孤岛贯通之后,这些孤岛就连成一片。
数据孤岛被打破之后,我们就能更全面、更完整的了解我们的用户、产品、商家,能够更加精准的评价他们的价值,进行进一步的价值发现,为精细化运营夯实数据基础。
One ID的核心技术是ID-Mapping,其原理是将各系统的关键要素抽象成图计算用的“点”和“边”,用图计算算法很轻易的判定同一个“对象”,从而构建一个个无向连通图,生成ID映射字典。
这个ID映射字典就是一座座通往各个数据孤岛的桥梁。我们通过这些桥梁,可以把相同“对象”在不同孤岛中的数据串联起来。这样,我们就掌控了全局,而非局部。
参考链接: