互联网账号体系
一、账号的价值
账号的定义
用户与系统建立的一种联系，是实现从现实映射到虚拟系统中的唯一标识
账号的价值
1.用户角度
记录自身的各类数据，并且作为活动交流的身份标识
2.企业角度
搜集用户信息，建立用户体系级画像，实现用户精细化运营推广， 为企业带来更多的价值
二、账号体系架构
三、账号基本要素构成
用户身份（UID）：用户注册后，系统会建立一个内部标识，自动按序为用户分配一个数字编号，即UID。该标识在该系统中具有唯一性，不可更改，对外不可见，是注册用户的身份标识，用户所有的数据资产都会绑定到这个内部标识上，类似现实生活中的身份证号码。
用户名（Username）：由用户自定义或系统随机分配，系统分配一般由英文字母、数字或者2者组合而成。在系统中具有唯一性，一般设置一次后不可更改，如：阿里云的账号。
用户昵称（Nickname）：用户自定义的个性花名称，可自由设置和改动，一般为公开信息，对他人可见。常见的各类个人信息的名称，即是用户昵称。
用户账号（User Account）：是一个集合概念，是用户的外部标识，包括用户名、手机号、邮箱，并与UID进行唯一性映射。例如：在注册时可以采用填写手机号，或者邮箱等不同形式的方式。
账号密码（password）：一串理论上只有身份标识所有者记得的字符串，目前是教育最充分的一种身份识别的方式。
第三方账号：即OpenId，就是将三方的帐号绑定到产品自身的帐号上，当查询到用户第三方的帐号已经绑定了平台的某个user_id时，直接登录对应的帐号，实现一键注册与一键登录。常见的有微信、微博、QQ等第三方常用社交账号登录。
四、账号组合方式及差异
五、账号主要设计流程（注册登录、找回密码、风控流程）
1. 注册及登录流程
（1）遵循的原则
-
注册方式具有普遍的适应性。
-
注册流程尽量简单快捷，减低用户的损耗。
-
保证注册方式的安全性。
（2）设计的思路
-
账号体系是重要的一环，但是并不是所有的产品都是必要的，其重要程度根据产品的业务性质决定，例如社交类为强体系，工具类为弱体系。
-
是先注册才可以使用（石墨文档）还是先使用到核心业务需再要求注册（淘宝），部分产品是明确先有账号后才能使用，主要由产品的核心业务决定的。当两者都支持的情况。
比较如下：
注册前置（先注册再使用）
优点：统一注册入口，逻辑处理简单，用户信息完整收集。
缺点：用户体验差，容易造成用户流失。
注册后置（先使用再注册）
优点：对用户友好，用户体验较好；
缺点：注册验证入口多，系统维护成本较大；前期需进行整体规划；用户信息需要分多环节收集。
注册方式的确定
主要考虑：
用户来源：主要针对于第三方登录的，例如：产品的用户与微博的用户交集大，选用第三方登录时，应选择微博。
业务模式：主要是风险控制与流量的平衡，对风险控制要求低的产品，注册流程简短。
平台渠道：不同的渠道方式，用户对注册登录流程的接受程度存在着区别，如：小程序、h5流程力争简单，app和网站，可根据业务需要，把握平衡点。
2. 找回密码
找回密码流程，常见的几种找回密码的方式：
手机验证：方便快捷，但是存在手机号码更换，二次放号的问题，所以不能只有一种单纯的手机号验证。
邮箱：以前是主要的找回密码的流程，现在逐渐被手机验证代替，但是它仍有自身的重要价值，与手机验证相辅助，提供多元方式。
人工审核：针对用户出现极其特殊情况而增设的人工渠道，一般是用户量大的平台会专门设计人工审核的流程。
具体可体验支付宝的找回密码流程：
3. 风控流程
账号风控的根本目标就是确保用户身份的合法真实性。杜绝不法分子的盗取，防止恶意攻击，归结为以下几种：
-
禁止非正常的、大量的“验证账号是否存在”的操作请求，防止不法份子通过不停的输入大量账号，去获取该账号是否存在的数据。
-
确保用户访问的真实性，进行手机号验证或手机扫码登录。
-
注册时增加邮件验证码功能或者通过邮件进行激活确认。
-
进行短信次数限制，保护短信通道不被恶意者大量刷短信，造成堵塞。
-
通过IP对请求上限做出限制，防止恶意用户大量发起注册请求，攻击服务器。
-
异常操作，非本人IP/手机进行通知提醒。
六、外延--账号同行证
目前存在的现象主要是很多公司的产品拥有各自独立的账号体系，各自为政，互不相通，形成信息孤岛。
1. 带来不利影响包括以下几点
（1）从用户的角度
同一公司的产品，用户需要注册多个账号，给用户带来使用上的不便，不易形成品牌意识。
（2）从企业的角度
账号的独立，造成账号管理难度加大和重复开发，不利于产品之间互相导流和推广，用户数据共享。为解决以上问题，需要将账号系统打通，即账号通行证。
通行证（passport）是指：
产品账号统一处理，所有应用系统都直接依赖与同一套身份认证系统，一个账号可以登录同一旗下的多个产品。百度、网易等大型公司已实现通行证。
2. 针对各个产品账号独立的情况下，通行证如何搭建
第一步，将各子系统的用户公共信息迁移到一张表，该表不包含任何业务的信息，只存在用户的核心数据，如：用户id、用户手机、用户密码、用户昵称。
第二步，差异化处理，针对不同的子系统可能有各自的特色属性情况下，比如：a系统用户属性有职称，b系统用户属性有兴趣标签，各个子系统需自己维护一个用户角色表。
第三步，统一登录认证，采用邮箱/手机账号方式，作为统一的注册方式，引导用户注册通行证。同时，确保原有的子系统账号仍可以登录。
账号体系在产品从0到1搭建时，应预估公司的后期的发展方向，决定是否有必要采用通行证的形式，避免后期花费大量时间去打通账号体系。