1.业务背景通常在系统研发过程中，需要不断适应各种业务场景，拓展服务领域和能力。通常，构建的产品矩阵会被划分为多个业务线，以便更好地管理；业务线的数据录入和管理策略不同，不同路径下沉积的数据可能因系统边界问题而相互隔离；如果用户数据被拆分，会因为数据不全面而误导分析决策；比较经典的场景：用户在应用端完成注册后，通常不会提供太多关于自己的信息。由于业务需要，用户画像不断丰富，用户数据通常会被调度到独立的管理系统中，通过不同的接触点进行信息扩展，例如收集嵌入式数据、线下联系人、营销电话等；这种情况是操作上有明显感知的场景。很明显，应用库中的用户数据和管理库中的用户数据是有很大区别的。在真实情况下，用户可能在不同的应用和场景中存在重复，这必然导致用户数据难以统一维护；2、唯一标识用户的行为数据，在当前的互联网产品中极具分析价值。无论是否处于登录状态，产品中产生的数据都是一种记录手段，然后在数据层面进行分析识别；这些号码最大的特点就是具有唯一性，可以识别用户在不同终端、不同状态下的操作信息。这些数据在存入系统时，会根据端口和操作类型进行存储，数据在不同终端下的唯一标识不同；从数据分析的角度来看，显然我们不希望用户的行为信息被拆分和孤立，因此多终端、多状态下的用户行为数据全局关联是一种有效的方式，其基本原理涉及ID映射技术；3.Idmapping基于上述业务情况，提供产品矩阵中用户身份的全局视图统一标识非常重要。不同业务线的用户实体产生的行为数据，通过唯一的序列号标识，让用户分析时看到的画像更全面；在目前的互联网产品中，基于手机号码创建应用账号模式已经是一种常见的功能。手机号注册后，通过手机号关联对应的终端ID，将各种孤立的数据联系起来；其实现原理并不复杂。首先，需要提供一套映射库。当系统识别并采集到一个新的手机号时，在映射库中新建一条数据，手机号和对应的唯一ID，然后是其他路径的数据，如果手机号是一样，会绑定在ID下；4、数据关联在ID映射机制下，虽然各个业务线的数据相对孤立，对数据没有直接影响，但实际上已经通过唯一的ID串联起来了。这样一来，ID关联数据的综合分析准确率就会大大提高；无论从任何路径或渠道下收集的数据，是否有手机号码维度，或手机号关联的序列号标识决定了手机号是否具有全局映射标识。如果没有，则在映射库中建立对应关系。如果有，可以直接绑定；在对数据进行全局调度和分析时，通过映射库的标准关系，基于ID标识，对所有业务线的数据进行查询和分析，生成一个比较全面的数据文件和标准的分析逻辑；下面给出一个参考结构设计：这里有一个数据关联从逻辑上讲，ID和手机号是唯一的，一一对应的，但是手机号和终端的序列号可能是一一对应的许多，甚至是多对多；账户和应用中产生的行为数据，虽然追求准确性，但不会过分要求准确性；在这种情况下，需要实施相应的业务策略。例如，同一个手机号可能在不同的手机上登录了同一个应用，手机中的应用也可能被多个账号登录。需要根据策略做取舍，可能是账号登录的时长，也可能是登录前后的时间，不能一概而论；5.注册登录以手机号为主账号为例。开放应用并没有明确区分注册和登录。这简化了操作以避免阻塞用户。通过手机号登录时，如果是未注册用户，直接初始化信息即可；用户在登录表单中输入手机号码并获取验证码；在登录服务中，生成并保持验证码的时效性；验证码需要通过对接的第三方短信平台推送到用户手机；登录表单填写验证码，然后提交登录信息进行验证；登录验证成功后，若用户未注册，则初始化账号系统；账号系统校验维护后，异步关联ID；最后需要返回一个Token身份令牌给客户端作为账户标识；与注册登录一体化的复用接口较为复杂，但最短路径让用户快速使用产品，通过行为数据的收集和分析，可以准确识别用户需求，进行正确的引导和营销，给予充分发挥数据的真正价值；这里给一个账号管理的结构设计参考，通常用户的主表维度会围绕可以登录的账号来设计，信息收集相关的数据会写入用户画像表。由于不同业务场景对信息的依赖程度不同，用户注册后会引导各种数据采集页面；用户身份识别和账号作为系统非常基础的核心能力，在设计时不仅要有用户体验，还要注意数据安全；作为核心能力，在早期设计时需要具有前瞻性，做好规划和架构的可能性。保留以避免后续迭代跨度太大。6.参考源码编程文档：https://gitee.com/cicadasmile/butte-java-note应用仓库：https://gitee.com/cicadasmile/butte传单父母
