互联网的账号自带备忘机制;
通常在系统研发的过程中,需要不断适配各种业务场景,扩展服务的领域和能力,一般会将构建的产品矩阵划分出多条业务线,以便更好地管理;
由于各个业务线的数据入口和管理策略的不同,这样从不同路径下沉淀的数据,可能因为系统边界问题从而被孤立;如果用户数据被分裂,会因为数据不全面给分析决策带来误导;
比较经典的场景,用户从应用端完成注册之后,通常不会过多提供自身信息,由于业务需要不断丰富用户画像,所以用户数据通常会被调度到独立的管理系统中,通过不同的触点反馈进行信息扩展,比如采集埋点数据,线下接触,营销电话等;
这种情况从操作上是有明显感知的场景,显然用户在应用库中的数据和在管理库是存在很大差异的,在真实的情况中用户可能在不同的应用和场景中会产生重复,必然会导致用户数据难以统一维护;
用户的行为数据在当下的互联网产品中,是极其具有分析价值的,不同的应用端不管是否处于登录状态,在产品中产生的数据都是有记录的手段,进而在数据层面分析识别;
这些编号最大的特点就是具有唯一性,可以标识用户在不同终端不同状态的操作信息,而当这些数据沉淀到系统时,会根据端口和操作类型进行存储,不同的终端下其数据唯一标识也不相同;
从数据分析的角度上来看,显然不希望用户的行为信息被分裂并且各自孤立,这样对多终端多状态下的用户行为数据进行全域关联,是行之有效的方式,其基本原理涉及到ID的映射技术;
基于上述的业务情况,在产品矩阵中提供用户身份的全局统一标识至关重要,用户实体在不同业务线所产生的行为数据,通过唯一序列号进行识别,这样进行用户分析时看到的画像比较全面;
在当下的互联网产品中,基于手机号创建应用账号的模式已经是常见功能,手机号注册之后,再通过手机号去关联相应的终端ID,从而使各种孤立的数据被链接起来;
其实现的原理并不复杂,首先需要提供一套映射库,当新的手机号被系统识别采集时,在映射库中新建一条数据,手机号和对应的唯一ID,此后其他路径的数据,如果手机号相同则绑定在该ID下面;
在ID映射机制下,虽然各个业务线数据相对孤立,数据之间不会产生直接影响,但是实际上已经被唯一ID串联起来,这样将ID关联的数据进行综合分析,准确性会提高很多;
不管从任何路径或渠道下采集的数据,如果存在手机号的维度,或者手机号相关联的序列号标识,判断该手机号是否存在全局映射ID,没有则在映射库中创建对应关系,如果有则直接绑定即可;
在执行数据的全局调度和分析时,则通过映射库的标准关系,基于ID标识将全部业务线的数据进行查询和统筹分析,从而生成相对全面的数据档案,以及标准的分析逻辑;下面给出一个参考性的结构设计:
这里存在数据关联的逻辑,ID标识与手机号都是唯一的且一对一,但是手机号与终端的序列号可能存在一对多,甚至是多对多;账号与应用中产生的行为数据,虽然追求准确性,但是精确度不会过度要求;
这种情况下就需要执行相应的业务策略,比如同一个手机号可能登录过不同手机中的相同应用,手机中的应用也可能被多个账号登录过,此时则需要基于策略做关联上的取舍,可能是账号登录时长,或者登录前后的时段,无法一概而论;
以手机号作为账号主体为例,开放的应用并不会明显区别注册和登录,以此简化操作避免阻断掉用户,在通过手机号登录时,如果是未注册的用户直接进行信息初始化即可;
注册登录集成在一起的复用接口比较复杂,但是以最短的路径让用户快速使用产品,通过行为数据采集分析,从而可以精准识别用户需求,进行正确的引导和营销,发挥出数据的真正价值;
这里给出一份账号管理的结构设计参考,通常情况下用户的主表维度会围绕可登录的账号来设计,而涉及到信息采集的数据会写入用户档案表,由于不同业务场景对信息依赖不同,所以在用户注册之后会引导各种数据采集的页面;
用户身份识别和账号作为系统非常基础的核心能力,在设计的时候既要有用户体验,同时要重视数据的安全性;作为核心能力在前期设计的时候就需要一定的前瞻性,做好可能性的规划和结构预留,避免后续的迭代跨度过大。
编程文档:
https://gitee.com/cicadasmile/butte-java-note
应用仓库:
https://gitee.com/cicadasmile/butte-flyer-parent