帐号体系：后端信息结构设计

编辑导语：帐号是用户的身份标识，产品在设计过程中，便需要针对帐号体系的搭建进行考量。不过帐号体系也有类别区分，在不同类型的产品中，帐号体系的后端结构设计又该如何实现呢？本篇文章里，作者便对帐号体系的后端信息结构设计做了总结，一起来看一下。

上一篇文章，我们介绍了帐号的价值，以及不同类型的产品对帐号的需求差异。这篇文章，我们详细介绍一下帐号体系的后端结构设计，即为了实现帐号体系的全部功能，帐号体系的后端应该如何设计。

一、帐号体系的分类

从帐号应用的范围维度，可以把帐号分为“仅为自研应用提供服务”的帐号体系，和“开放给第三方开发商使用”的帐号体系。

第1种帐号体系，仅在开发者自己研发的应用中使用，帐号数据不会被第三方应用获取和使用。

而第2种帐号体系，不仅在自研的应用中使用，还可以通过开放平台提供给第三方应用使用，是大平台、国民级开发商的舞台，本文暂不涉及。

仅为自研应用提供服务的帐号体系，按自研应用数量，又可以分为两种：

1. 单应用的帐号体系：只在开发者研发的单个应用上使用的帐号体系。大部分开发者、业务单一的开发者都属于这一类。如脉脉、即刻、keep等。
2. 矩阵应用的帐号体系：同一个开发者研发的若干个应用，使用同一套帐号体系。部分业务多样、或推出了多个关联应用的开发者，属于这一类。如美团旗下，多个矩阵应用使用同一套帐号体系，如美团外卖、大众点评、美团优选、美团买菜、猫眼电影。

对于单应用的帐号体系，用户修改帐号信息时，只对单一应用有效。而对于矩阵应用的帐号体系，用户修改帐号信息，将同时影响使用了该帐号体系的全部矩阵应用。

例如，用户修改即刻App中的绑定手机号，只会对该用户使用即刻App有影响。

若用户美团App中修改手机号号码，会有如下提示：

接下来，我们就这两种帐号体系的信息结构做详细分析。

二、单应用的帐号体系

单应用帐号体系只为单个应用服务，其信息结构相对简单，主要包括4部分：UserID、第三方帐号、密码、设备号、其他业务字段，如下图：

1. UserID

UserID是用户在应用中的唯一身份标识，通常也称为用户ID。系统或其他用户都可以通过UserID，准确找到该用户。UserID会在用户在注册帐号时，系统根据规则自动生成。

• 用户注册QQ帐号时，系统会按一定的规则从未被使用的号池中给用户分配一个QQ号。
• 用户注册小红书时，会按规则生成一串纯数字的小红书号。

UserID必须至少满足两个要求：唯一、不可修改。

只有UserID是唯一的，才能通过它准确定位一个用户，而不是多个用户，或错误地定位用户。

不可修改是因为UserID通常会被引用到很多个功能中，若可以随意修改，会带来极大的刷数据成本，甚至会引发系统数据混乱。

在即刻App中，动态、评论、关注、点赞、分享、收藏等功能都需要引用用户身份标识号，以记录相关数据的操作人。

如果修改了某个用户的身份识别号，那么该用户所有的动态、评论、关注、点赞、分享、收藏数据中的身份识别号都需要修改，否则就会导致数据操作人找不到，引发数据混乱。

2. 第三方帐号

随着第三方帐号（如微信号、QQ号、手机号）的大规模普及，直接使用第三方帐号，替代UserID登录系统成为主流的设计方式。

UserID有两个很明显的缺陷，导致被第三方帐号替代。一是UserID是一个不需要用户关注的信息，因为用户几乎没有直接使用UserID的场景。二是记住各个应用的UserID成本很高，因为每一个应用生成的UserID都不一样。

如果用户日常使用50个应用，那他必须记住50个完全不一样的编号，那将会是一个灾难。

而像微信号、QQ号、手机号这类第三方帐号，几乎每一个人都拥有一个，也都能唯一标识用户身份。

如果将第三方帐号跟UserID一一关联，并使用它们来登录应用，将给用户带来极大的便利。

3. 密码

登录应用时，除了输入帐号并不能确定当前用户是该帐号的所有人，还必须要通过某种方式来验证用户身份，以确保帐号不被盗用。

目前大部分应用都通过让用户输入与UserID一一对应，且只能被帐号所有人知道的密码，来完成身份验证。

为了确保密码不被恶意破解，还需要对密码的复杂度做要求。如至少8个字符、必须包括大小写字母和数字。

随着第三方帐号和手机号的普及，逐渐发展出了更多验证身份的方式：

1. 手机号+短信验证码：用户输入了系统临时生成的短信验证码，即表明当前登录用户是帐号所有人；
2. 手机号一键登录：通过移动运营商的身份校验接口，验证用户身份；
3. 第三方帐号授权登录：通过已登录的第三方应用的接口，验证用户身份。

这些验证身份的方式，不需要用户记密码，也不需要担心密码忘记，操作上更便捷、更快速，也更安全，逐渐替代帐号+密码的身份验证方式，成为产品设计的主流方案。

4. 设备号

设备号是用来标识用户使用应用的硬件编号。如web端用cookie作为设备号，iOS用UUID、IDFV、IDFA，Android用UUID、Android ID。

在帐号信息中，记录用户使用的设备号，可以用来标记用户常用设备，确保用户帐号安全。当用户在一个新设备上登录应用时，系统能及时发现，并触发安全校验。

还有部分应用对用户的可用设备做了限制，如印象笔记的免费用户，只能在两个设备上同时使用。此时，也需要记录用户的设备号。

5. 其他业务信息

除了以上几个系统需要的信息，还有一些业务层面需要用到的信息，如用户昵称、头像。通常在需要显示用户信息的地方出现，如用户详情页、评论列表、会话列表等。不仅彰显了用户的个性，还为用户识别、查找其他用户提供了便利。

不同的产品需求不同，帐号体系中的业务信息，要根据业务的需要来定义。

三、矩阵应用的帐号体系

同一个公司开发的多个应用，称之为矩阵应用。

1. 共用帐号体系的原因

相对于使用独立的帐号体系，矩阵应用共用一套帐号体系，无论是对企业还是到用户，都是一个更好的选择。

对企业来说，能大幅度减少企业的开发和维护成本。矩阵应用中的每一个应用，大多由多个团队独立开发。如果每个应用都单独开发和维护一套帐号体系，有多少个应用就要重复开发多少次，成本随着应用数线性增加。

而多个应用共用一套帐号体系，企业只需要开发一次，当有新应用时，只需要简单接入，成本大幅度降低。

同时，共用一套帐号体系，还能强化品牌认知，带来更高的商业价值。 帐号体系独立开发，会导致使用多个应用的同一个用户在不同的应用中，有完全不一样的帐号，用户也会默认为，这是多个不同的企业开发的产品。这对于企业建立完整的用户画像非常不利，企业获得的用户数据不足，对用户的理解就不够完整，能转化的商业价值也就更少。

若共用一套帐号体系，用户会认为这是同一家企业的产品，对企业的品牌认知就好得到强化。同时，多个应用中产生的用户数据，能关联到同一个帐号下，企业获取的用户数据更丰富，对用户的理解更深入，通过个性化推荐和精细化运营，自然能带来更大的商业价值。

对用户来说，共用一套帐号体系能获得更便捷的服务。帐号体系独立，用户必须分别注册帐号、使用不同的帐号登录应用，同样的帐号资料需要设置多遍。而共用帐号体系，用户只需要注册一个帐号，就能登录全部矩阵应用，且用户数据还能自动同步。很明显，用户操作更便捷。

2. 矩阵应用帐号体系的信息结构

矩阵应用帐号体系需要在单应用帐号体系的基础上，增加应用层面的身份标识（AppUserID），以明确用户是哪些应用的使用者。其信息结构如下：

之所以要增加应用层的身份标识，主要有2个价值。

1）记录用户在每一个应用中的行为信息，并利用这些信息做特定的运营动作。

运营人员设计了一个面向该应用新用户的促销活动，若以UserID生成时间为准，就会导致大量最近几天才开始使用该应用的新用户被排除在活动范围之外。

通过AppUserID生成时间，即可准确筛选出该应用的新用户。

2）统计矩阵应用在平台用户中的渗透率，为应用精准导流。根据各应用的AppUserID数量和平台UserID数量，即可计算出各个应用在平台用户中的渗透率。若某个应用需要其他应用导流，以增加其用户量，可在其他应用中向该用户精准推荐该应用。

四、总结

按使用范围，可以将帐号体系分为单应用帐号体系和矩阵应用帐号体系。单应用帐号体系的信息结构主要包括UserID、第三方帐号、密码和头像昵称等业务信息，而矩阵帐号体系则在单应用帐号体系的基础上，增加AppUserID。在设计帐号体系时，信息结构是最重要的部分。

#专栏作家#

誓博，微信公众号：产品慎思录。人人都是产品经理专栏作家。5年产品经验，电商售后平台后端产品负责人。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议