谈谈三个层次的ID mapping
今天跟大家谈一个话题,就是ID mapping。
谈之前,先抛一个问题出来,什么是ID。在这里我们今天要谈的范畴中,给ID下一个定义,ID就是代表一个用户实体的一串儿序列号。在这个定义下,我们就发现手机号是一个用户ID,身份证号是一个用户ID,邮箱是一个用户ID,微信号也是一个用户ID。只不过这些ID的生命周期不同,精度也不同。
比如,身份证号一个人一生一般只有一个且终生不变,而手机号,邮箱号,微信号则存在停用和转赠的可能,可见如果使用手机号来代表一个人则可能存在一定的误差,而这就引出了第二个概念,mapping。
介绍mapping之前我们来看这样一个现实的案例。
A公司为了满足用户在不同场景下的需求开发了多条产品线,其中包含,小程序,APP和网站。同时,在线下通过多种渠道接触用户挖掘用户需求,获得的信息回流到了企业的CRM系统中,最终我们发现A企业从多个触点获取到大量的用户行为信息,但存在一个问题,由于各个系统相对孤立,同一个用户在不同的系统中被使用独立ID进行标识,在进行数据分析和决策时,每个用户的画像是片面的,只有孤立域中的画像。
用户的行为是断裂的,因为同一个用户在不同系统间操作时被采用了不同的ID进行标识。同时企业总体的用户统计数也是不准确的。mapping的提出正是为了解决这个案例中提到的问题。 ID Mapping是将用户关联,使得物理世界中一个真实的用户在互联网世界中也采用一个统一的ID进行关联。
关于ID mapping的实现,我们可以分成两大步骤,第一步是ID的标识,第二步则是ID的关联。
一、ID标识
如何标识一个用户又可以分成两种场景,第一是用户匿名状态下,第二是用户登录状态下。在用户登录状态下一般使用业务ID来对用户进行标识,如身份证号、userID、手机号等等。而在用户匿名状态下,则需要通过设备ID来对用户进行标识,根据用户使用的设备和系统的差异,标识的方式也不相同,一般来说可分为以下4类。
1.网页,网页一般使用cookie ID作为匿名ID来使用,cookie ID的生成规则是基于时间戳、随机数、屏幕的宽高和UA操作系统版本号进行生成的。cookie ID是64位字符串,使用cookie ID的风险在于一旦cookie 被清除或者用户更换了浏览器,那么cookie ID也会改变。
2.Android系统,Android设备获取设备唯一ID的方案有多种,如获取IMEI,WIFI或蓝牙的MAC地址都可以。考虑到易获得性,可以使用Android ID作为设备ID。Android ID 的位数为16位,Android ID会因为APP签名不同和设备账号不同而生成不同的值。需要注意的是Android 8.0 以下 Android ID不会改变,Android 8.0以上用户通过OTA方式升级app Android ID不会变,但如果卸载之后重新安装 Android ID会发生改变。
3.iOS系统,iOS系统一般采用IDFA或IDFV作为设备ID。IDFA和IDFV分别是iOS生态为广告主和开发商设计的两套ID规范。分别可供有广告的APP和同应用开发厂商进行使用,前者同一个设备下不同APP共享,后者同一个开发商下不同的APP共享。需要注意的是,用户是可以通过设置刷新来不断更新IDFA的。当然,苹果这么做也是为了方便用户清除个人的历史痕迹,包含自己的隐私。而在苹果的新规出台后,APP在获取IDFA的值时也需要用户完成手动确认后才可以。
4.微信小程序,微信小程序可以使用OPEN ID作为用户的匿名ID。
二、ID mapping
第二步是关联,根据用户关联解决的不同问题,可以将用户关联分为3个层次,分别是一对一关联,一对多关联和全域关联。
1.一对一关联解决的是用户登录前后的关联问题,其核心思路是将设备的匿名ID和用户的登录ID进行关联,同时每个设备ID和登录ID只进行一次成功关联,也就是说当设备甲已经和用户A关联后,若用户B在设备甲上登录并使用,设备甲不会再和用户B进行关联。同样的,用户A登录设备乙时也不会再进行关联。
2.一对多关联解决的是用户登录多个设备的关联问题,在一对一的关联方案下,虽然可以将用户登录前后的行为打通。但实际上,一个用户可能在网页,手机,平板等多个终端使用同一个产品。为了将用户使用多设备,多终端的数据打通,一对多的关联方案应运而生。
一对多的关联方案核心是一个用户登录ID可以和多个设备的匿名ID相关联。也就是说当用户分别在设备甲、乙、丙上登录用户账号后,系统会将设备甲、乙、丙和用户A关联成为同一个独立的用户实体。从而使得多个终端的行为数据得以打通。在关联时同样要注意的是,若设备乙已经和用户B关联过,那么用户A再登录设备乙时不会再进行关联。即一个用户可能关联多个设备,但一个设备不会关联多个用户。
3.前两种关联方式解决的是同一业务系统下的用户关联问题。但实际上,一家企业可能在不同时期不同环境下存在多条产品线和业务系统。
这些系统中用户使用不同ID进行登录,这就引出了用户关联的第三个层次,全域关联。全域关联的核心是打通不同业务系统中的数据,在关联逻辑上使用到了图论中的连通图概念,可以简单理解,A和B产生了关联,B和C产生了关联,则A、B、C之间两两进行了关联,这种关联方式与前两种关联方式最大的不同是,前两种方式以登录ID作为唯一枢纽ID,其他ID围绕登录ID进行关联,而全域关联将每个ID都作为联通的枢纽,最大程度上关联所有业务系统中的ID。
下图是一个形象的例子。
在上图中分别通过Unionid,loginid,Phone将属于不同系统的各类语义ID进行了关联。值得注意的是,除了以上关联外还需要根据业务特性定义唯一的业务ID,定义唯一业务ID的目的是将关联的各类用户ID关联到一个用户实体上,而在前两种关联方式上因为场景较为简单默认使用了登录id作为业务id进行使用了。
三、需要注意
进行IDmapping的方案设计时,可以根据自身的业务情况选择合适的ID mapping方案,除此之外还有一些特别需要注意的问题。
1.对历史事件的影响,ID mapping成功后势必会导致一些用户的合并从而使得事件分析的情况出现一定的差异,比如原来由于未关联而存在的用户A1和用户A2关联成同一个用户A,这时需要对历史的事件和用户属性进行合并,实时合并在大量查询时会影响效率,T+1的方式合并时则会对当日查询精度产生一定影响,选择哪种方案可视业务需求而定。
2.对用户属性的合并影响,在合并用户属性时可以根据业务需要选择多种逻辑覆盖,如以较早的时间戳为准先到先得,或以较晚的时间戳为准后来居上,再或者对不同id设定优先级,优先级较高的id覆盖优先级较低的id携带的属性都是可以选择的合并逻辑。
四、总结
总结一下,ID mapping的意义在于将互联网中的用户映射成为一个真实的用户实体,从而帮助企业完善用户画像和进行用户行为路径的分析。进行ID mapping时,分为ID 标识和ID关联两个步骤,每个步骤根据业务场景的差异各有多种方案可以选择。
关联完成并非结束,关联用户的目的是为了获得更为准确的数据帮助企业进行决策,因此对于历史事件和用户属性的合并逻辑同样不能忽视。
本文作者 @Beam 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!