业务中台建设 - C端用户中心
业务场景
互联网公司，自主开发内部系统
多条业务线产品，涉及到toC/toB、交易/SaaS等领域
名词解释
用户
app的使用者，操作的主体对象。
对于面向C端的产品来说，“用户”比较明确，例如 你是淘宝的用户，用手机号注册使用，你就是淘宝的用户。
对于面向B端的产品来说，有员工有企业，企业下有多个员工，不同员工有不同的权限。“用户”指代的是B端产品的操作主体，指的是员工用户，用户根据其拥有的权限，代替企业进行行为操作。
登陆账号
用户要登陆app，而登陆的方式有很多，用户名/密码登陆、手机号短信验证码登陆、第三方授权登陆...
不同的登陆方式对应的是不同的账号，用户账号、手机号账号、微信授权账号等等
一个用户可以有1个或多个登陆账号，通过同一个用户的不同登陆账号登陆后，是以用户为主体进行操作。
客户
在现实世界中，客户是为产品或服务买单的人。
对于面向C端的产品来说，客户就是用户。
对于面向B端的产品来说，客户是企业。
线索
会员
账号
自然人
认证
划定边界
toC端的用户
用户注册、登录、认证三大功能
对于上述的业务场景，涉及到很多的实体，简化的业务流程可能是这样的：
很复杂，基于此可以得出一个模型图
本文重点考虑C端用户域的设计方案，原因是C端用户方面可复用度较高，核心是C端用户的身份识别、登陆账号以及实名认证后得到的自然人模型。
设计要点
生命周期
作为主要模型，C端用户要有自己的状态，有自己的生命周期
通过线索或者其他渠道获得的用户信息也会加入到系统中，原因是需要做统一的ID打通，未注册和已注册的用户使用同一个ID，其他业务系统只要关注一个对象即可。
这部分用户是没有主动注册的，因此需要通过状态特殊标识出来。
用户主动发起注册后，即为此状态
用户注册后，经过了实名认证，可信度很高。
用户可以选择主动注销
业务隔离
C用户用户要支持多条业务线，不同app。同一个手机号在不同的app中，是否同一条用户记录；业务表现上即是否互相影响，修改了手机号137xxxxxxxx在app A中的信息，在app B中信息是否会变更；在app A中注销了手机号137xxxxxxxx对应的用户，app B中是否会注销。
方案1: 统一用户
代表：阿里巴巴、美团
该方案需要在app的产品功能设计上，告知用户采用统一用户方案
方案2: 各app业务隔离
用户在不同的app上感知到的两个app没有关系。
具体选用哪个方案需要公司产品研发决策层达成一致意见，从上层统一规划。
注销用户
8.5 个人信息主体注销账户
对个人信息控制者的要求包括:
通过注册账户提供产品或服务的个人信息控制者，应向个人信息主体提供注销账户的方法，且方法简便易操作;
受理注销账户请求后，需要人工处理的，应在承诺时限内(不超过15个工作日)完成核查和处理;
注销过程如需进行身份核验，要求个人信息主体再次提供的个人信息类型不应多于注册、使用等服务环节收集的个人信息类型;
注销过程不应设置不合理的条件或提出额外要求增加个人信息主体义务，如注销单个账户视同注销多个产品或服务，要求个人信息主体填写精确的历史操作记录作为注销的必要条件等;
注 1:多个产品或服务之间存在必要业务关联关系的，例如，一旦注销某个产品或服务的账户，将会导致其他产品或服务的必要业务功能无法实现或者服务质量明显下降的，需向个人信息主体进行详细说明。
注 2:产品或服务没有独立的账户体系的，可采取对该产品或服务账号以外其他个人信息进行删除，并切断账户体系与产品或服务的关联等措施实现注销。
注销账户的过程需收集个人敏感信息核验身份时，应明确对收集个人敏感信息后的处理措施，如达成目的后立即删除或匿名化处理等;
个人信息主体注销账户后，应及时删除其个人信息或匿名化处理。因法律规规定需要留存个人信息的，不能再次将其用于日常业务活动中。
匿名化：通过对个人信息的技术处理，使得个人信息主体无法被识别或者关联，且处理后的信息不能被复原的过程。
注:个人信息经匿名化处理后所得的信息不属于个人信息。
整理出几个关键点
一般在系统建设中不会直接删除数据，尤其是这种底层的ID，被各个系统落库使用，删除后容易造成数据不一致。因此匿名化是更好的选择，需要对用户手机号、名称和认证信息等关键字段进行混淆处理，比如 通过MD5算法修改为不可逆的字符串。
注销用户的流程为：
用户身份识别
通过业务主键能唯一识别一个用户， 常见的业务主键有手机号、微信号、邮箱、用户名等，对于一个用户可以有多个业务主键。如下图为例
用户ID手机号微信号100113700000001wx00a100213700000002wx00b
对于第一个用户来说，通过手机号(13700000001) 或 微信号(wx00a) 找到的是同一个用户。
实际场景中为了降低用户使用产品的门槛，手机号不是必须的，用户只用微信登陆也是可以的；
用户现用手机号注册登录，然后使用微信注册登录，就会出现1001和1003两个用户，每个用户都关联了很多业务数据；
用户使用手机号登录，使用的是1001用户，然后期望绑定微信wx00a登录，此时系统发现wx00a已被使用。
用户ID手机号微信号100113700000001100213700000002wx00b1003wx00a
手机号修改
用户会有修改手机号的诉求，系统涉及之初就需要支持用户修改手机号，以用户ID做关联键，其他系统不冗余手机号，不然容易造成数据不一致。
修改手机号的业务流程如下：
手机号回收（二次放号）
A持有手机号手机号13700000001，在系统中注册成为用户(ID：u001)，该用户可能会将手机号13700000001注销，运营商在一段时间(例如 3个月)后会将手机号13700000001重新放给B使用，B用手机号13700000001登录后，发现系统中是A的信息，因为登录的是u001用户，会对B造成一定困扰，甚至可以使用u001的身份进行一些危险的操作，例如 资金账户方面的功能。
在系统设计时如何处理这个问题，有下面2个可选的方案
如果能拿到运营商的信息，或者通过第三方的渠道拿到类似的信息也是可以的。
长期未登录后，重新登录时，可以调用第三方接口查询是否是回收的手机号，可以注销原账户信息，这样用户即可以通过新手机号注册全新的用户。
2. 拿不到运营商信息如何处理？
手机号是系统识别用户的主要方式，在系统感知不到手机号已被回收的情况下，可以将选择权交给用户。
手机号长期未登录后，再次登录时，根据不同的安全级别，采用不同方式
高风险：可以对用户进行身份验证，人脸、指纹、安全问题等，通过后可以认为没有换号
低风险：主动提示用户当前账户是否本人，用户确认后可以选择重新注册新用户