干货分享！最全 “用户账号” 设计分享

编辑导语：用户账号要如何设计？账号的构架是什么？本篇文章中，作者列出了用户账号构架的详解，分析了用户账号建设的几个阶段，推荐想要学习如何构建用户账号的群体阅读。

一、背景

用户账号（指的C端账号，分享也是基于此）其实是一个不那么新奇的功能，一直在随着互联网的变迁而变化；用户账号是一个比较底层比较核心的模块，在企业不断扩张以及业务不断增加的情况下， 怎么做好一个 “体验好”，“安全性强”，“易对接” 的账号中台其实是不容易的 ，接下来就给大家分享一些实战中的一些总结！

二、账号的架构

经过一些实战中的积累，总结了一个账号产品的架构分享给大家，接下来分按照不同的模块进行详细的说明：（文章中任何的图片不得在本人没有授权的情况下，随意转载）

三、用户账号架构详解

1. 账号的功能模块

（1）登录/注册方式说明

目前大多数的登录逻辑里面是包含了注册的，也就是说用户登录如果没有注册就默认帮助用户注册并登录成功，这样体验会更好，如下流程：

第一步，用户名+密码 注册：

注册方式：用户自己输入符合平台规则的用户名+密码即可注册。

优缺点：目前大部分的平台已经不使用这种方式了，因为这种安全性不高且与用户的关联性不大。

适用场景：有些场景用户没有手机号或第三方的账号就只能用这种形式了，例如：如果你的产品用户是小学生，没有手机也没有手机号只能使用这种注册方式了。

第二步，手机号+短信验证码 注册：

注册方式：用户自己输入手机号，平台将发送验证码给到用户，用户填写正确的验证码后即注册成功。

优点：适用面广，用户接受程度高，注册较简单，安全性高，可触达用户。

缺点：短信容易收不到（可以通过手机号+语音验证码解决），填写短信验证码的时候有一些麻烦（Android系统可以通过获取短信内容自动填充来优化体验）。

适用场景：APP，H5，web，小程序，电脑客户端都适用。

是否需要第三方服务：需要短信服务商。

第三步，手机号+语音验证码 注册：

注册方式：用户输入自己的手机号，平台将给到用户打语音电话并告诉用户验证码，用户填写正确的验证码后即注册成功。

优点：用户可以在收不到短信验证码的时候，可以通过语音验证码来收。

缺点：第三方语音验证码服务比较贵，成本比较高。

适用场景：在收不到短信验证码的场景下可以使用（一定要控制在用户第一次点击短信验证码，且没有输入验证码的情况下，再展示语音验证码，来控制成本）。

是否需要第三方服务：需要，语音验证码服务商。

第四步，第三方账号（微信，QQ，支付宝） 注册：

注册方式：用户授权平台可以获取用户的 userID，头像，昵称等信息即注册成功。

优点：用户注册登录简单，用户接受度广。

缺点：没有触达的方式不方便后期的运营，容易出现同一个用户存在多个账号，因为有可能用户选择用不同的第三方账号分别去登陆。

适用场景：纯工具类，或者社区类的产品可以使用这种注册方式，以及产品业务比较早期的阶段，为了让用户尽快体验到产品的核心价值。

是否需要第三方服务：第三方授权用户信息的接口。

第五步，第三方账号+手机号 注册：

注册方式：用户向平台授权个人信息后，还需要填写手机号+验证码才能注册。

优点：用户接受度广，有了用户的手机号不存在多账号，后期的运营可以触达到用户。

缺点：首次注册时，需要授权还需要填写手机号。

适用场景：适用大多数的业务场景，有一些产品早期会将绑定手机号的操作放在用户进行某项核心操作前例如下单前，发布作品前等。

是否需要第三方服务：第三方授权用户信息的接口，短信验证码服务。

第六步，手机号一键登录 注册：

注册方式：用户向平台授权本机的手机号，授权同意后即注册成功。

优点：用户注册登录简单，用户接受度广。

缺点：有少数场景用户选择非本机号，所以要结合用户手动输入手机号一起使用。

适用场景：适用大多数的业务场景。

是否需要第三方服务：运营商获取本机手机号SDK

第七步，邮箱+验证码（手机号+验证+密码），注册：

注册方式：用户输入邮箱+验证+密码即可注册成功

优点：国外比较常见的注册方式，国内用户使用场景比较少

缺点：注册比较繁琐。

适用场景：做海外市场比较常见

是否需要第三方服务：第三方邮件服务

有一些其他的密码登录的方式，适用于手机不在身边或没有手机的用户使用：

• 手机号+密码 登录
• 邮箱+密码 登录
• 用户名+密码 登录

（2）修改密码

第一步，手机号+验证码+新密码：
修改方式：当用户验证码注册时填写的手机号或者用户账号绑定的手机号，即可修改为新的密码

第二步，邮箱+验证码+新密码：
修改方式：当用户验证码注册时填写的邮箱或者用户账号绑定的邮箱，即可修改为新的密码

第三步，旧密码+新密码：
修改方式：当用户填写的旧密码与用户设置的密码一致时，即可修改为新的密码

（3）个人中心
个人中心本质：就是用户身份信息的管理，以及一个小型的用户画像，既可以为业务提供通用的用户数据，也可以为用户画像的基础数据。

个人中心数据来源：一部分让用户自行填写，例如用户注册完成后让用户选择或者填写一些数据；另一部部分是对用户登录数据或者操作数据的一些收集。

• 用户名 ：用户自己手动设置；
• 密码 ：用户自己手动设置；
• 用户昵称： 系统帮助自动生成，然后只允许用户修改一次且不能重复；
• 用户ID ：一般是纯数字，作为用户身份的标识。（这里面稍不注意会有很多安全性的问题，一会儿在账号安全重点说）；
• 性别 ：用户手动选；
• 签名： 用户自己输入；
• 手机号的绑定与解绑；
• 邮箱的绑定与解绑；
• 第三方账号的绑定与解绑；
• 头像 ：系统帮助自动生成，然后只允许用户修改；
• 国籍： 注册时选，或者用户手动添加；
• 职业： 注册时选，或者用户手动添加；
• 常用地址： 定位获取，或者用户手动输入（比方说用户如果在下单中有填写最好帮用户存下来，方便其他的模块使用）；
• 用户出生日期：用户自己填写；
• 用户登录日志： 帮助用户记录；
• 历史设备： 帮助用户记录；

（4）账号的注销

第一步 ，对于注销这个功能是不得不提供的一个功能，目前很多应用市场上架前对应用进行审核时如果发现这个应用没有注销的功能，可能会不让上架。

第二步 ，用户提交注销前一定要对用户的身份进行校验，第一个防止非本人操作，第二个系统层面会更加安全。

第三步 ，用户提交注销后一定要预留一个用户反悔的时间，一般是半个月或者一个月，因为注销用户对企业本身来说是一种损失，我们也需要尽力服务好用户减少这种流失。

2. 提供对外接入的方式

（1）提供对外接入方式时95%以上提供统一页面（页面需要做的灵活已配置），因为方便管理并且可以大大的增加效率；如果提供过多的API出去后期想优化一些有关页面的需求时，一方面：推动沟通的成本非非常高，另一方面：不是所有的团队都有那么多资源可以及时配合你去做技术修改的；例如：公司周年庆需要改登录页的风格以及画面，如果提供的统一的页面，只需要你自己修改通知到其他团队就行，如果你提供的是API那就麻烦了所有的应用全部都要跟着改动。

（2）剩下的5%提供API，总有一些业务的场景你是很难覆盖全的，这部分可以通过API来提供；总之一能用统一页面的就不要使用API 。

3. 账号的管理后台

账号管理后台，是为了方便做账号配置，数据监控，异常处理等综合的管理平台：

（1）应用管理模块 ： 对接入应用进行管理，记录应用的基础信息，并提供需给应用做单独配置的功能，例如：接入统一账号的应用名称，应用的唯一标识ID，应用的说明，应用所属部门，应用对应的负责人等等，这些信息是发现有谁在使用账号以及后续账号出现需要功能迭代沟通时的基础数据非常重要，包括需要单独给应用做特殊的配置也需要放在这里。

（2）用户管理模块 ：对注册用户进行管理，记录脱敏后一些基础信息，并提供一些给用户标记或辅助操作的功能；例如：有时候公司的运营自己注册了用户，但是很多操作的数据都是为了做测试的数据，这部分如果数据量过大的话 一定需要跟真实用户作区分，标记为内部用户；还有一些恶意用户需要标记为黑名单用户杜绝这类用户再次登录。

（3）账号配置模块 ：用于账号整体配置的模块。例如：提供统一页面的配置，配置页面颜色的风格，页面控件，页面的logo等；还包括短信验证码，语音验证码，图形验证码的配置等。

（4）账号日志模块 ：记录所有对账号服务进行增，删，改，查相关操作日志的模块，不管是 用户，后台运营人员，还是接口调用方；目的为了监控，追踪，溯源。

（5）数据分析模块 ：统计账号提供的功能使用数据情况。例如：用户填写数据导整个注册完成的成功率以及所花费的时间。

（6）接口管理模块 ：提供接口开关，接口调用量统计，核心接口失败警告灯服务。

（7）协议管理模块 ：提供协议的上传以及协议签约记录的模块。重点说明：目前工信部对互联网个人的隐私管理的非常严格，所以用户服务的条款与隐私协议是账号必须模块。如果对这块不是很了解的可以看我之前的文章。

4. 基础数据模块

账号中台是一个核心偏底层的服务，作为产品经理一定要清楚的，你的模块中有哪些比较核心的数据，以及这些数据都是用做什么，这样你在设计的产品或处理复杂异常场景的时候你会得心应手。

（1）账号的状态：正常，冻结，注销。

（2）用户基础信息
设备信息：（设备名称，设备型号，设备ID），
地址信息：（常登录地址，公司/家的位置），
用户信息：（姓名，年龄，邮箱，手机号，性别，职业，学历，昵称，证件号），
第三方账号信息：（昵称，头像，第三方ID，姓名）。

（3）应用信息（使用账号的应用信息）
应用名称，创建时间，应用描述，应用类型（APP/web/h5/小程序），应用所属部门ID（departmentID），产品ID（productID），应用类型ID（applicationID）

（4）接口的场景：注册，登录，修改密码，绑定手机号等。

其实底层数据都是给以后能的规划打基础，特别是作为几十个或上百个业务使用的账号中台，底层数据非常的重要。

接下来重点说一些基础数据都是有什么作用的：

第一步，设备信息：

• 可以为用户提供用户历史登录设备，以及非常用设备登录等安全提醒的功能。
• 可以限制同一个账号同时登录设备数量的限制，如果所在的业务有会员等业务这个功能是非常需要的。

第二步，应用信息，接口场景：

有这四层的数据，账号平台可以清楚的知道 用户是从哪个应用端注册进来的；有这四层的数据，账号后续想根据不同的业务，产品，应用做个性化的配置，才有标记为。（层级的划分，根据公司的组织架构来，如果创业型公司建议，前期对增加一些层级备用，防止公司做大后，需要额外的增加）

这些底层数据很重要，一定要把账号整体的规划想全，然后第一个版本就要吧底层的数据做好；这样后面做起来就轻松很多，如果前期不把基础打牢固，后面再想去收集这些数据会异常艰难。

所以其实真正做产品的高手，不是遇到需求时才解决；而是先把可能预见到的需求早就想了一遍，然后在第一个版本就把基础打好。

5. 底层能力：这边指的是账号服务，需要的一些第三方的能力

（1）图形验证码
使用场景：主要是通过手机号接受验证码的场景，在手机号接受短信前，先通过图形验证码防止被恶意的刷数据。
注意事项：不要每次都弹验证码，一定要给一定的数量限制，例如同一个手机号一天在平台获取短信验证码的次数超过5次就需要进行图形验证码的校验。

（2）短信验证码
使用场景：使用手机号进行注册或登录场景

（3）语音验证码
使用场景：使用手机号进行注册或登录，但是用户收不到短信的场景
注意事项：控制用户使用语音验证码的场景，例如同一个页面用户联系点击了两次获取短信验证码，但是没有填写或者填写不正确的场景，展示语音验证码的入口。

（4）邮箱验证码
使用场景：使用邮箱进行注册或登录的场景

（5）文本鉴别
使用场景：对用户输入的文本进行安全性，合规性，鉴黄等的鉴别；例如用户在输入用户名，用户签名等等
注意事项：一定需要搭配一个 文本黑白名单的功能一起使用，因为有很多的文本第三方公司是存在误杀或者遗漏的场景，而且他们短时间又不能快速的解决。

（6）一键登录
使用场景：APP用户使用本机手机号进行注册的场景
注意事项：搭配手动输入手机号+验证码的场景一起使用，因为有些用户不想使用本机作为注册的手机号。

（7）图片鉴别
使用场景：对用户上传的图片进行安全性，合规性，鉴黄等的鉴别，例如用户上传头像

在引入第三方能力时有一些经验可以分享：

引入第三方的服务商时，一定要从 服务可用性，业务场景覆盖度，产品的体验，客服的相应速度，技术支持的力度，价格，接入的复杂度，数据的安全性等多个维度综合评估。

相同能力的第三方服务商一定要一到两个兜底的服务商。例如：图形验证码当一个服务商的当天失败的次数超过一定次数，系统自动切换到下一个备用的服务商，进而保证系统的稳定性。

6. 账号安全

（1）安全设计规范

由公司安全产品经理，提供的一些设计中常见的安全规避方案。例如：用户的手机号，姓名，密码等在数据库需要加密保存，展示在页面时需要脱敏处理等等。（产品平时遇到安全性的问题是，自己也要多加总结）

（2）安全风控功能

弱密码稽查： 密码在之前没有做格式的限定，导致用户设置的密码过于简单，在用户登录成功后提示用户修改密码的复杂度 或 定期通过密码库的查询，发现有密码安全性低的情况通知到用户去修改。

手机号/邮箱的绑定与解绑通知： 用户进行核心资产的解绑时，需要通过短信或邮件通知到用户。

异地登录提醒： 当发现用户的账号在非常用地登录时需要通知到用户或者增加验证码步骤。

非常用设备登录提醒： 当发现用户的账号在非常用设备登录时需要通知到用户或者增加验证码步骤。

设备登录数限制： 同一个账号在相同的设备上只能登录一个等等

输错次数锁定： 同一个用户登录时密码连续输出5次，把账号冻结一天等。

用户注销提醒： 用户发起注销操作时，一定需要通过短信或者邮箱通知到具体用户。

运营商二次放号： 解决之前的手机号停机后，被运营商再次放号给到其他人使用的场景。

（3）常见的安全风控问题

提示手机号已注册问题：

例子：某官网，在用户注册时，只要用户输入手机号已经注册，在输入框失去焦点时就提示用户该手机号已注册；导致竞品拿不同的手机号去试，凡是已经有注册的用户就一个个给用户打电话推销自己的产品；导致了公司花费了巨额费用引入的用户，被竞品亲而一举的盗取，损失惨重。

解决方案：a, 登录注册一体化，不要分开；b，像这种非要提示的，建议验证身份后再提示，会损失一些用户体验。

用户ID自增问题：

例子：某官网，在用户注册时，将用户的ID展示出来了，而且用户ID的生成方式为自增；被竞品抓到漏洞，导致竞品很轻易的知道公司新增用户数，不停的使用ID自增的方式暴力破解通过用户ID获取用户信息的接口，造成用户数据的泄露。

解决方案：用户ID随机分配 以及 内部接口使用的ID与外面用户展示的ID分开。

密码被暴力破解的问题：

例子：某官网，在用户注册时，没有做用户名 以及 密码复杂度的校验，导致用户大量的输入 123456 这种类似的密码。竞品通过暴力破解随意登录网站并对用户造成困扰。

解决方案：使用密码注册时，一定要有复杂度校验，不管是前端页面还是后端接口。

登录设备不限制问题：

例子：某付费视频网站，在用户登录是没有限制登录设备数量，导致不法份子购买一个账号后，以低价大量的将此账号卖给其他的用户，导致了公司收入大量受损。

以上几个例子一方面说明，账号本身十分的重要，一不小心就容易出问题。我们在设计的时候一定要有安全意识跟思维，这种安全意识跟思维只有慢慢的积累或者学习才能形成。

四、用户账号建设的几个阶段

用户账号并不是说一定要按照我提供的这种方式来设计，如果说业务单一简单就完全不必想我这样规划，我这方案比较适合中大型的互联网公司。

企业的不同阶段，其实对用户账号的需求也是不太一样的，企业的发展上我们大致可以分为：前期试错，扩大规模，精细化运营寻找第二曲线；每个阶段账号的侧重点是不同的，我们需要结合业务，进行一步步的迭代。

1. 前期试错阶段(红色部分)

（1）提供账号的登录注册，修改密码，主要等基础的功能。

（2）搭好账号的基础数据，为账号以后的功能拓展打好基础。

（3）提供统一的注册登录页面，方便不同业务进行试错对接。

2. 扩大规模阶段(绿色部分)

（1）提供账号的管理后台，增账号 对接，运营过程中的效率 与 异常监控。

（2）接入第三方的能力提升账号的合规性与安全性。

（3）规划账号安全的整体方案，提升账号的安全性。

3. 精细化运营，寻找第二曲线（蓝色部分）

（1）提供账号多样的接入方式。

（2）提供海外账号等多种类型的账号。

五、总结

用户账号是一个非常底层的模块，只要面向用户业务应用都需要用到；如何做到用户体验好，安全性高，易接入的账号是比较复杂的。

• 在设计账号的过程中，有非常多需要注意的点，接下来给大家做一个注意事项的汇总：
• 用户账号中心其实相当于一个小中台或微服务，中台最主要就是抽象共性，将逻辑标准化；账号其实也一样，当你在做规划的时候一定要想全，暂时不需要的一些功能通过配置先关掉，或预留技术方案方便下次升级的时候成本小。
• 账号的底层数据非常重要，在做第一个版本的时候就需要预留字段或上报。
• 用户账号在提供对外对接的方式时，一定要尽可能的提供统一页面的接入，这样对于以后的迭代以及统一的管理更加的高效。
• 用户账号的 安全与合规非常的重要，一定要在设计与规划的过程中多总结，一次安全事故对于公司来说就是非常大的损失，对于产品的靠谱能力是严重减分的。

近期持续的输出一些对大家有价值的一些文章，希望文章对大家以后产品的设计有一点点帮助，如果大家对于细节有想了解的，欢迎留言，我将一一作答。

接下来会分享 订单，支付，财务，推送，CRM等模块的分享，欢迎多多关注！

 

本文由@陈宏伟 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议