我接手过很多不同行业、不同类型的项目，但都有一个共同点：都涉及到账号体系。看似不难，但深究起来，却值得思考、值得品味。于是，写了这篇文章。这次，我会从内到外，从概念类别到设计方法，认真分析一下账号体系。

这篇文章比较长，下面是这篇文章的地图。（如下图，点击可查看大图）

1.账户体系的概念和价值

账户体系是用户在各个平台的通行证。

平台为用户提供可持续的服务，用户在平台上获得价值，这个中介就是账户体系。

阿京将其理解为连接用户和平台的枢纽。

注：本文中账号=账户，两个概念是一样的。

我们都知道一个产品最终的服务提供者是“人”，那么人拿什么来证明我是这个产品的服务对象呢？

你可以想象一下，我们去银行，银行叫我们去开一个“账户”，我们提供身份证，去办理一张银行卡，卡号是6367********6318，那么银行卡就是我们的账户。我们去屈臣氏，结账时被要求办卡，我们提供手机号，去办理一张会员卡，卡号是QCS3***3，那么会员卡就是我们的账户。

这两个例子中，身份证和手机号是我们在这个世界上的唯一标识，可以作为注册账号的凭证。我们提供自己的唯一个人识别码（如身份证、手机号等）后，不同平台会将其转换成平台用户的唯一识别码（如前文提到的银行卡号、会员卡号）。

那么，有了账号，我们就可以用“通行证”来获取平台上的服务。

账户体系的价值在于：

完善系统持续迭代能力，为未来产品扩展铺平道路；加强账户相关功能模块的可行性，保障系统稳定性；完善账户集成能力，为产品生态布局一站式账户通。

而且随着产品周期的推进，账号体系的长尾价值也会越来越明显。

2.账户体系需求分析

账号体系对于用户和平台的意义在于保证用户能够使用产品服务、保证产品提供个性化服务、保证满足企业的业务需求。

那么，账户体系的需求是什么？

用户的信息可以通过验证（如邮箱验证、手机验证码验证等）来保证用户的真实性。一个人有多部手机、多个邮箱、多个第三方账户，但都是同一个人所有，需要合并到同一个账户中，保证用户的唯一性。用户的手机可能会更换，可能会注册手机号，需要解除旧手机号的绑定，绑定新的手机号，保证用户账户的账户安全。用户在进行交易服务时，采取的安全措施是为了保证用户资金的安全。用户在使用第三方登录时，也是在构建自己的账户体系。…

按照需求强度来划分，账户体系可以分为强需求与弱需求。

账号体系是社交类、互动类产品中至关重要的，需求量非常大。账号体系是所有产品功能的基石。社交类产品大多需要互动，需要建立用户数据，因此需要建立和维护账号体系。在这个过程中，账号体系体现出核心价值，记录各类用户数据，将用户兴趣与账号挂钩，提供可持续的服务。

对于工具类产品来说，账号体系是一个比较弱的需求，没有账号体系也可以正常运营和使用，但有了账号体系，后续可以更精准的建立用户画像，前期可能不重要，但版本迭代多了就派上用场了。在这个过程中，账号体系体现出了延伸价值和商业价值，通过积累的用户数据提供个性化服务，更高效的满足用户需求，提升用户体验。

总体来说，账号体系是为了解决用户信息的唯一性、真实性、安全性等问题，对于所有产品来说，账号体系并不是必须的，可以根据产品类型在产品规划前期或者后期建立。

三、科目体系分类及历史渊源

账号体系的种类很多，互联网发展至今，可以概括为四种类型：自定义账号、邮箱账号、手机账号、第三方登录账号。

1. 自定义您的帐户

自定义账号是“账号+密码”的形式，通用账号是用户自己定义的，是比较古老的账号体系，在互联网疯狂发展的初期，各大平台都还没建立，智能手机也还没诞生，使用的平台都是PC，账号都是用户自己制定的。

至于坏处，相信有过体验的人都记得清清楚楚，经常会备一个小本子记录不同的账号密码，QQ一个，某个游戏平台一个，某个社交平台一个……如果设置不同，反而会增加用户的记忆负担。

在互联网发展初期比较适用，但现在平台这么多，“账号+密码”的方式已经逐渐开始被取代。

2. 电子邮件账户

在互联网狂野的年代，为了解决“减轻用户记忆负担”的问题，各类邮箱盛行，QQ邮箱、网易邮箱、新浪邮箱等巨头纷纷抢占市场。邮箱当时已经成为用户的常用工具，记忆难度比随机获取一个账户名简单得多，于是便采用了“邮箱号+密码”的登录方式。

使用邮箱作为注册方式的好处是，就像一套自定义账号的系统，可以减少用户的记忆负担。缺点也很明显，邮箱认证流程比较冗长，需要打开邮箱接收邮件并确认，这个过程中很容易导致用户流失。

过去PC端是主流，而现在移动设备占据了绝大部分市场，大部分用户不会在手机上安装邮箱应用，因此在移动端接收邮箱验证信息难度加大，丢失率也会增加。

因此在目前移动设备占据市场主导地位的形势下，“邮箱+密码”的账户体系已经逐渐开始淡出人们的视线。

3.手机号码账户体系

据统计，截至2018年，智能手机的市场占有率已经达到98.6%，这意味着几乎每个人都拥有一部智能手机。

每个人可能没有社交账号（微信、QQ等），但一定有一个手机号码。

优点的话，用户可能很难记住账号，但手机号比较简单，安全。对于平台来说，通过手机号登录，可以搭建自己的账号体系，方便后续的精细化运营（活动通知、用户召回等）。由于手机号目前都是运营商实名注册的，可以减少垃圾营销账号的数量。

至于缺点，第一，“手机号+验证码”登录需要支付一定的短信费用，好在价格不高，但需要谨防黑客恶意攻击，这也涉及到账号体系的风控机制，后面会讲到；第二，在信号不好的地方，收不到验证码；第三，手机号可能会更换，需要考虑解绑逻辑和换号逻辑。

注意事项：手机号账户体系的便捷性在于可以将注册和登录流程合二为一，如果您还未注册，当您获取验证码登录时系统会自动为您注册，降低您的运营成本，提升便捷性。

但同时由于其便捷性，也有其局限性，用户可能会更换手机号，因此需要引导用户在用手机号注册后设置密码，降低风险。

4.第三方账户体系

随着各大超级App的诞生和成熟，“第三方登录”的概念也随之出现。

第三方账户体系是指用户通过授权将第三方的信息绑定到自己的账户体系中，当发现用户的第三方账户已经绑定到某平台时，可以直接登录对应账户，实现一键注册，一键登录。

在考虑使用第三方登录的时候，还需要考虑立即绑定和延时绑定两种情况。通常第三方授权之后，系统只能获取头像昵称等一些信息。如果考虑以后自己的账号信息，就需要让用户绑定相应的信息，这就涉及到立即绑定和延时绑定。

立即绑定虽然会让用户操作繁琐，而且容易造成丢失，但是可以保证用户的信息被获取。

延迟绑定虽然可以保证用户体验，但是在使用过程中填写信息时容易让用户产生拒绝。

至于采用哪种方式，就需要各位品友在实际的产品设计中做出选择了。

“鱼与熊掌不可兼得”

四、如何设计账户体系？ 1、账户体系的字段

要设计一个科目体系，首先需要了解科目体系包含哪些基本字段。

（1）用户账户（用户，包括自定义、邮箱、手机号）

用户账号是系统平台内的唯一标识，不同的账号体系类型，用户账号的展现形式不同，包括自定义账号、邮箱、手机号等。

通常出于隐私和安全原因，用户账户只有自己可见，其他人看不到。它是用户的个人通行证。

（2）用户密码（User）

用户密码是基于“账号+密码”体系的字段，通常由字母和数字组成，有些密码设置为包含符号。

这里的产品同事在设计的时候，需要考虑“字母+数字”和“字母+数字+符号”不同的情况。

（3）用户名（）

用户名（）是用户向外界展示的名字，可以是用户自定义的，也可以是系统先赋值设置，再提供修改的权限。如果使用第三方授权登录，一般会使用第三方昵称作为用户名，后期可以进行修改。

究竟是用户定义，还是系统指定，在下面的设计中会详细解释。

（4）用户唯一标识符（UID）

用户唯一标识（UID）是系统配置，通常由数字组成，对用户不可见。用户注册为系统账号后，自动生成，不可更改，与每个用户一一对应。

（5）开立账户（）

通过第三方网站URL验证用户身份，当用户第三方授权登录成功后，系统通过获取用户的open ID生成用户ID，同时读取用户在第三方网站的身份昵称和头像，昵称可以作为第一个账户名。

从技术层面上来说也分为静默授权和用户授权，有兴趣的朋友可以了解一下。

上图为账户体系的信息框架（来自互联网）

2.账户体系核心流程

账户体系包含四个核心流程，分别是注册流程、登录流程、找回密码流程、风控流程。其中注册流程与登录流程可以合二为一。

（1）注册+登录流程

要设计一个登录和注册流程，我们首先需要对该流程进行简单而详细的分析。

账号注册登录流程遵循三个原则：①安全性②普遍性③便捷性。

简单来说，在登录注册过程中，安全性是第一前提，其次在保证通用性的前提下追求便捷性。：那么按照KANO模型，安全性是一个基本需求，通用性是一个预期需求，便捷性是一个激动人心的需求。

如上所述，注册登录的组合有多种，包括账号+密码、邮箱+密码、手机号+验证码、手机号+密码+验证码、第三方登录、第三方登录+手机号绑定、第三方登录+密码、第三方登录+密码+手机号绑定……

绑定方式有很多种，不用刻意去记住。按照主流的绑定方式，绑定的信息越多（手机号、微信等），对平台的风险越低，对用户的安全性越高，但也会增加用户的运营成本。如何设计，要看平台的现状和定位，不同的产品设计方式不一样，不能一概而论。

从安全性上来说，绑定方式越多越安全；从便捷性上来说，可以通过简单的注册登录（比如市面上的“闪测”登录）来设定初始门槛，后期再补充信息即可。

这里有一点需要注意，注意《用户协议》的设计。

用户协议是限制用户滥用非法手段干扰系统运行的一种手段，是注册过程中不可缺少的一部分，但也是最容易被忽视的部分。

设计的方式有以下几种，仅供参考：

（2）密码找回流程

找回密码的常用方式有以下几种：手机号、邮箱、银行卡、手动申诉。

①手机号验证

若密码遗失，可使用“原手机+验证码”方式重设，但可能存在运营商第二次放行该号码的情况，因此需要在系统设计时规划多个“信任手机”或“信任设备”。

② 检索电子邮件

通过邮箱找回的方式是过去PC端的经典方式，PC时代是邮箱的时代，QQ、网易等主流邮箱已经占领了整个市场，自然通过邮箱找回是最便捷的，但随着移动时代的到来，通过邮箱找回的方式逐渐被废弃，如果账户体系中没有基于邮箱的账户方式，一般很少会要求用户在系统中绑定邮箱。

移动时代，找回邮箱比较麻烦，用处也不大，但是可以作为找回手机号码的辅助手段。

③验证银行卡

若系统涉及银行卡绑定，可将银行卡作为个人唯一标识，通过“银行卡+预留手机号+验证码”的验证方式核实个人信息，确定是否为个人，并找回密码。

④人工服务

当所有验证方式均失效时，找回密码的唯一途径是通过人工服务，用户需要先上传身份证等个人信息，客服会在一定工作日内处理，这会消耗相应的客服资源且反馈时间较长。

（3）风险控制流程

风控流程的本质就是保证用户身份的合法性和正确性，防止一些不法分子进行恶意的攻击和注册，影响原有系统的安全。

账号是用户登录系统的“通行证”，其重要性不言而喻。保护账号安全也至关重要。在注册登录过程中，黑客恶意注册，会导致平台资源浪费；账号信息泄露，会导致用户信息受损；无论对于平台还是对于用户来说，都是巨大的损失。

对于风控措施，我们可以从恶意注册账号、IP、盗窃等角度进行思考。

阿京列举了以下账户体系的风险控制措施，供参考。

关于恶意注册账号，浪费平台资源：

窃取账号，影响账号安全：

3.账户体系页面展示

页面只展示部分逻辑，目前登录、注册页面的展现形式不同，可根据系统的定位进行规划设计。

5. 账户体系的合并与整合

在每个大系统中，都有多个系统、多个账号相互交织，这就产生了账号合并、关联问题。

在同一个系统中，问题是合并问题：

不同系统中的问题是如何将它们连接起来：

1. 账户体系合并

账户合并是指在一个系统内，将一个用户的多个账户合并为一个账户。

账号分为同类型和不同类型两种，同类型是指注册类型相同，比如同一个人用两个手机号注册两个账号；不同类型是指注册类型不同，比如有手机号注册，有微信注册，有邮箱注册，但主人都是同一个人。

此时用户发起合并，将自己拥有的账户合并为同一个账户。

处理方法是：保留其中一个主账户，将数据累积到主账户，清除其他账户的数据。

2.开放账户体系

账户互联互通是指不同系统内的账户数据实现互联互通。其中，“互联互通”分为单向互联互通和双向互联互通。

这里面的核心就是数据流，对于一个用户来说，本地数据在多个系统之间流动（单向或者双向），但是数据总量是不变的。

6.账户体系设计的几个关键点

（标出重点，这个会进行测试）

1. 建立适合自己产品的账号体系

账号体系的选择基于四个维度：①终端类型②产品类型③用户类型④产品发展。

（1）端子类型

目前有PC和移动端两种终端，以前PC时代最流行的是邮箱，打开邮箱就可以收到验证信息，现在移动时代，这样的操作就有些繁琐了。

（2）产品类型

不同类型的产品由于性质不同，应设计不同的账户体系。

设计的核心是将账户体系设计得尽可能贴近产品主流业务所使用的信息。

比如打车平台、外卖平台都要知道用户的手机号码，因此可以直接使用手机号登录的方式来设计账户体系。

（3）用户类型

不同的用户类型也需要不同的账户系统。

我们以三类用户为例：学生、年轻人、老年人。

（4）产品开发

当产品处于发展初期，需要快速占领市场，时间紧任务重，可以直接采用接入第三方登录的方式。当发展到一定规模的时候，就需要搭建一套自己的账号体系了。

2.根据产品类型设置是否强制登录

（1）先浏览，再登录

对于内容信息类产品，出于用户体验的考虑，一般不强制登录，引导用户先浏览后登录。延迟登录的一个重要原因是为了留住用户。根据漏斗模型，用户操作的步骤越多，流失的用户就越多。降低浏览门槛可以吸引用户浏览内容，当需要账户信息时（例如进行购买），可以引导用户注册登录。

那么这样设计的缺点是：①注册条目较多，系统维护成本较高；②用户信息需要在多个环节进行设计。

（2）浏览前请先登录

对于社交产品来说，一般都是采用先登录再浏览的方式，原因是对于社交来说，账号是唯一主体，后续的操作都需要通过账号进行，无法跳过注册登录的流程。

但有些内容产品就是这样设计的，很容易造成用户流失。

（3）无需注册或登录

如果是工具类产品，账户体系是弱需求，是可选项。如果资源有限，可以不通过账户体系直接使用产品，也不需要注册登录。当然，正如上文所说，对于工具类产品来说，账户体系的意义在于后续的拓展价值和商业价值。

3.考虑账号体系的安全机制（二次放号的情况）

如上文所说我们目前主流的账号体系注册方式主要有：①手机号账号体系②第三方账号体系。

但以手机号为核心的账户体系，会引发不同的问题。

当手机号码更换、停用后，旧号码将会丢失，运营商可能会回收并重新发放废弃的号码。

比如，有“厦门吴彦祖”之称的阿静，之前用旧电话号码注册过健身平台，有一天他换了手机号，于是旧号码就被注销了，运营商在一段时间（约四个月）后又将其重新投放到市场上。

那么这时候就会有人利用这个旧手机号访问健身平台，篡改阿静的账户信息。

那么，如何避免这个问题呢？

本质是通过身份认证来保证操作者是用户本人。

（1）好友协助验证

这种方式在社交产品中比较常见，比如QQ、微信等，线下联系好友，好友在账号上确认操作，经过多位好友验证后，才算通过。

其安全性较高，但操作复杂麻烦，多用于社交产品。

（2）历史信息核查

用户通过回忆历史操作信息和个人信息，并正确回答相应问题即可通过验证。例如：“最近购物的商品是什么？”“你以前用过什么密码？”“回忆最近的好友？”“回忆最近用过的头像”等。

但随着平台数量的增多，数据的不断更新，历史信息核查方式的准确率在逐渐降低，用户越来越难以记住自己设定的某些信息，体验远没有想象的那么好。

（3）用户身份验证

如果用户在系统中留下自己的信息，这些信息是唯一且安全的，那么这些信息可以用于自我验证，比如人脸识别、身份证、银行卡、社保卡等。

（4）通过其他已添加的“信任手机号码/设备”验证

部分平台会在系统中添加多个“信任手机号”功能，通过添加多个手机号，当主手机号丢失时，可以通过剩余的手机号发短信验证用户身份。

您还可以添加多个“受信任的设备”来验证登录，之后受信任的设备可以将陌生的设备踢出离线。

（5）安全问题认证/邮箱认证

通过密保问题和邮箱验证是互联网早期PC时代的常用方式，通过“账号+密码”的账户体系，增加了设置密保问题的安全措施，保障用户账户安全。

这种方式最大的问题就是安全问题的记忆，很多人经常会忘记，比如苹果账号还是用安全问题的，如果不刻意去记的话，我想大多数人都会很容易忘记。

（6）客户服务投诉等。

在尝试了所有提交信息和验证的步骤后，如果还是不行，那么唯一能拿回账号的方法就是向客服申诉。申诉方式是要求用户填写一份表格来证明账号信息，并提交给客服，这样客服就可以人工确定账号的主人。

但这种方式很可能占用客服资源，而且费时费力，所以不是一个好主意。

4. 一些可以提升用户体验的设计

（1）通过带空格的手机号注册

当您注册或者绑定手机号时需要输入手机号时，会自动给您留一个空格，采用3-4-4方法，您可以在输入过程中随时轻松校准输入的内容和位数。

当用户需要输入银行卡信息时，同样按照4-4-4-4-3的方式设计。

（2）准确的错误提示

在账户表单输入框中，如果信息输入有误，必须向用户反馈精准的错误提示。

例如用户输入账号和密码后，若信息错误，则有两种处理方式： ① 信息错误 ② 账号不存在/密码错误。

显然，第二种方式比第一种要好得多。用户可以清楚地知道自己的错误并进行改正，减少了多次尝试的时间。

同时，根据特斯勒定律“前端越简单，背后的逻辑一定越复杂”，用户得到的错误提示越准确，投入的开发资源和时间就越多。如果产品前期着急开发上线，可以牺牲一些交互和用户体验，把优先级放到后面，等稳定后再做修改。

（3）输入数字时，数字键盘自动激活

输入密码时，若密码要求纯数字，则会自动调出数字键盘并强制不可转换，防止用户误输入错误信息，增加用户不必要的操作。

（4）有前提条件的按钮可以灰显，输入信息后恢复为可点击状态

若信息不符合系统要求，按钮将会变灰，以减少不必要的点击。

例如登录时需要输入账号和密码，如果用户只输入账号或者密码，按钮会保持灰色，当账号和密码都输入完毕并且符合要求（例如6~16位数字）时，按钮才恢复为可点击状态。

（5）密码提供显示/隐藏按钮

当输入高度安全的信息时，为用户提供显示/隐藏按钮。

例如，当用户正在输入密码时，如果旁边有人，则密码输入步骤的私密性就会降低。提供显示/隐藏按钮，让用户选择是否显示正在输入的信息。

（6）必填项和非必填项提示

当用户注册账号并首次登录时，有些系统会要求用户输入一些信息，用于早期的用户推荐。这些信息以表格形式标明必填项和非必填项，例如可以用星号来区分。将操作的可控性在用户输入信息时预先放置。

最后的想法

账户体系可大可小，一个看似很小的功能点，却能延伸出很多细微的学问。

关键在于产品的尺寸，是否值得如此深入的设计。

对于初始产品，帐户系统只能用于注册和登录，并且用户的数量很少，因此无需考虑在主要业务和完整的情况下考虑风险控制和安全机制，毕竟要改善帐户系统还不算太晚。

据推测，如果PM没有足够的洞察力并完全模拟了业务方案，则他或她可能无法完全构建一个良好的帐户系统（不仅在构建方面，而且在各种风险控制措施和安全机制方面）。

当开始写这篇文章时，从第一个单词到现在的时间远远超过了估计的时间。

当我考虑它时，我想：“有很多帐户系统，总结它们并不难。”

当我第一次开始写作时，我想：“没关系，我有什么感觉。”

写作中途，我想：“为什么看起来有些困难？”

当我要结束写作时，我想：“哦，我的上帝，这太难了。

（只是在开玩笑）

我最初计划用3,000个单词来解释它，但现在已经成长为10,000个字。

“永远不要低估任何看似很小的功能点。”

作者：一个热爱产品的普通人，产品经理。