不管从任何路径或渠道下采集的数据，如果存在手机号的维度，或者手机号相关联的序列号标识，判断该手机号是否存在全局映射ID，没有则在映射库中创建对应关系，如果有则直接绑定即可；

在执行数据的全局调度和分析时，则通过映射库的标准关系，基于ID标识将全部业务线的数据进行查询和统筹分析，从而生成相对全面的数据档案，以及标准的分析逻辑；下面给出一个参考性的结构设计：

这里存在数据关联的逻辑，ID标识与手机号都是唯一的且一对一，但是手机号与终端的序列号可能存在一对多，甚至是多对多；账号与应用中产生的行为数据，虽然追求准确性，但是精确度不会过度要求；

这种情况下就需要执行相应的业务策略，比如同一个手机号可能登录过不同手机中的相同应用，手机中的应用也可能被多个账号登录过，此时则需要基于策略做关联上的取舍，可能是账号登录时长，或者登录前后的时段，无法一概而论；

以手机号作为账号主体为例，开放的应用并不会明显区别注册和登录，以此简化操作避免阻断掉用户，在通过手机号登录时，如果是未注册的用户直接进行信息初始化即可；

• 用户在登录表单中，输入手机号并获取验证码；
• 在登录服务中，生成并维护验证码的时效；
• 验证码需要借助对接的第三方短信平台推送到用户手机中；
• 登录表单填充验证码之后提交登录信息进行验证；
• 当登录验证成功之后，如果用户未注册则初始化账号体系；
• 账号体系校验和维护之后，通过异步方式关联ID标识；
• 最后需要给用户端返回Token身份令牌，作为账号识别；

注册登录集成在一起的复用接口比较复杂，但是以最短的路径让用户快速使用产品，通过行为数据采集分析，从而可以精准识别用户需求，进行正确的引导和营销，发挥出数据的真正价值；

这里给出一份账号管理的结构设计参考，通常情况下用户的主表维度会围绕可登录的账号来设计，而涉及到信息采集的数据会写入用户档案表，由于不同业务场景对信息依赖不同，所以在用户注册之后会引导各种数据采集的页面；

用户身份识别和账号作为系统非常基础的核心能力，在设计的时候既要有用户体验，同时要重视数据的安全性；作为核心能力在前期设计的时候就需要一定的前瞻性，做好可能性的规划和结构预留，避免后续的迭代跨度过大。

END