oneid构建
仅凭userid并不能准确地标识所有的用户,再加上埋点框架的固有缺陷,无法做到统一用户身份识别,故需要构建oneid体系,对同一用户赋予相同的oneid。这也是在构建数仓之时的第一步,由于自身数据埋点框架的特点,我们并不能像第三方sdk一样一开始就对同一个用户做到oneid标识,目前阶段需要在已有埋点日志的基础上通过一定的逻辑构建出oneid。
构建oneid通常有两种方式,第一种是通过生成的uuid和userid进行关联的方式,按照一定的业务规则,有一个uuid对应一个userid的关联方式,也有多个uuid关联一个userid的方式,在关联之后通过一定规则生成oneid,该种方式简单易于理解,通常通过sql就可以很方面的构造出oneid。第二种是通过图计算来进行oneid的构建,主要思想是通过多个用户标识之间的关联关系来合并唯一用户,该方法会比第一种更加精确。
一、如何构建oneid
有我认为比较好的一套方案,是在app架构设计之初就考虑到统一用户身份标识的情况,将每个设备生成的uuid作为userid,但是这种方案依然存在缺陷,第一是无法解决同一设备注册多个账号的情况,第二是拿字符串作为userid,在注册用户数特别大的时候数据库的查找效率低于数字型的查找。
由于各公司情况的不同,这里仅考虑在不涉及外部数据源的前提下,通过清洗日志表数据构建oneid,参考神策中的标识用户逻辑标识用户,考虑方案三关联设备 ID 和登录 ID(多对一)的情况,通过拉链表实现设备 ID 和登录 ID 的动态关联。
二、oneid表格格式
设备id | 登录id | oneid | start_time | start_logintime | end_logintime | platform |
---|---|---|---|---|---|---|
获取日志表中16位uuid | uuid对应的userid | 有userid时使用userid,没有时使用uuid,统一使用oneid进行关联。 | uuid首次出现时间 | uuid对应userid登录时间 | uuid对应userid最后登录时间 | uuid对应的platform,排除多终端的影响 |
oneid生成逻辑:取第一次出现的uuid哈希值作为oneid
userid绑定设备id在userid第一次访问的时候
三、构建逻辑
(一)获取uuid和userid的映射关系
使用uuid作为主键,映射最后生成的oneid,同一uuid会对应多个userid,按照以下逻辑进行关联
归为匿名登录之前最近一次登录的用户。
四、数据缺项补正
数据缺项补正
反向补正,即根据新日志对稍早收集的日志中的个别数据项做回补或修订(例如,在用户登录后,对登录前页面日志做身份信息的回补)。
注:日志数据都需要做数据的反向补正,为了统一用户的行为链路
图计算注意事项
去掉弱关联,保留强关联
t和t-1之间的关联问题
选取id特征:
userid,imei,mac,androidid,uuid,imsi