账户体系：一文助你看透账号体系与账户体系的区别

账户体系是任意一款互联网产品都必有的基础体系，而账户体系的产品设计文章却寥寥无几。本文小编将从互联保险产品的账户体系入手，来聊一聊如何基于复杂业务场景构建一套完整账户体系。 

一、账户体系、账号体系、用户体系的区别与联系

在分享如何构建账户体系之前，先聊一聊小编对「账户」「账号」「用户」三者之间关联和区别的理解。

• 账户可以定义是一个具有特定信息含义的内容集。比如一张身份证，一本银行存折，一份个人信用资料等。
• 账号则是一组特定符号组成的序列，且与账户有一一映射关系。比如身份证号，银行卡号，个人征信代码等。
• 用户则是通过这组特定字符序列与内容集产生关联的个体，同时也是账户内容所描述的特定个体。

在互联网产品中，用户体系往往是面向用户，更偏重于用户运营与增长。而账户体系则是面向业务，更偏重于产品结构与业务支撑。账号体系则是桥接在用户体系与账户体系之间，为用户体系提供价值体现的同时，又可为账户体系提供服务的支持。换言之，在偏重用户体验的产品中，账户体系的价值常常被忽略。而在偏重于业务效率与供需交易的产品中，账户体系的价值举足轻重。

案例：信用卡

这里小编通过「信用卡」这个大家生活中都会接触的产品来讲讲上述三者的区别和关联。

对于一张信用卡来讲，我们站在普通人的角度看，它的用户自然是使用它的人。它的账号自然是登录或支付的账号和密码。而它的账户可能就是它的消费记录，可用金额等。读到这里大家可能觉得这个例子非常的简单。

那么我们换一个思考的角度，站在产品经理的立场看，对于一个信用卡产品来讲，它的用户体系，账号体系，账户体系又分别是什么呢？

在小编看，信用卡的用户体系就是它的用户成长体系，可能是用户积分体系，会员等级体系等这些可以提升用户粘性，促进用户刷卡消费，提升业务量的产品运营模块。而这部分模块往往是直接面向用户的，我们可以在各种信用卡产品中轻易找到。

信用卡的账号体系就是信用卡的使用通道或者说产品触达用户的渠道。可以是线下直接刷卡消费，这时使用的账号就是卡号和支付密码。也可以线上产品端扫码消费，或者第三方支付通道调起，这时必然要通过产品端的登录账号和密码以及付款账号和密码等。这些不同的用途的账号和密码共同组建了一个复杂的账号体系。

账户体系就更加复杂了，包括普通用户可以看到的个人基本信息，个人认证信息，信贷账户，分期账户，分期账户，余额账户，借贷账户，消费记录，贷款记录，还款记录等。以及普通用户看不到的银行信用评级记录，逾期记录，卡片升级记录，异常消费记录等等。由此也可以看出账户体系更多是面向业务的，根据业务不同，账户体系的设计偏重也不同。

那么下面小编将通过互联网保险产品的账户体系搭建方法论来聊一聊如何设计一个可以应对复杂业务场景的账户体系。

二、搭建账户体系的第一步：用户是谁，具有什么样的特点？

在互联网保险行业中，由于其业务场景的多元化，可以分为持牌保险企业，保险经纪公司，理赔服务供应商，代理人展业供应商等多种产品形态。小编将通过复杂度适中的互保经纪公司的产品为例来进行分析。

用户关系定位：

首先将保险产品的需求侧用户分为以下四类：

1、个人用户：进行投保和被保险的个人。

2、个人客户：存在的被保险的个人。

3、企业用户：进行投保和被保险的企业。

4、企业客户：进行被保险的企业。

这里的用户和客户的区别在于：用户是与产品产生直接行为的个体，而客户是与产品产生间接行为的个体。间接行为就是该个体并未与本产品中产生直接交互行为，而是通过第三方代为完成的。比如企业为员工提供的补充医疗险，就是企业为员工集体购买的险种。当产品本身为被保险人提供保全或理赔服务时，则需要为该被保险人进行账户的创建和维护。客户与用户的具体关联逻辑将在第二步中进行讲解。

案例：个人账户体系

当确定了用户是谁后，在搭建账户体系时就要为用户添加标签，创建账户规则及字段，以及不同类型的账户的下的属性字段有哪些。企业用户因涉及到供给侧，需求侧以及第三方服务角色，相对较为复杂，在此就不展开讨论了。此处小编以个人用户为例简单说明一下。

个人用户的账户信息大概可以分为以上七个信息模块。其中基本信息和身份认证信息这两个模块的用途是确定用户的真实性和唯一性。保险行业相对于其他行业，在进行投保核保时是需要进行个人身份的认证。因而保险产品更容易获取用户的真实信息，用于保险风控及用户运营。

这里可能有读者朋友会问：为什么将基本信息和身份认证信息归并在个人账户体系中，而不是放在用户体系或者账号体系中。这里小编解释一下自己的考虑。首先没有归并到用户体系的原因很简单，用户体系的作用是为了促进用户与产品的粘性，进而促进业务增长。而个人基本信息和身份认证信息的归并并不能起到这方面的作用。而在较为复杂或繁琐的产品中，可能会存在多账号的情况，此时如果将基本信息和认证信息放入账号体系中，可能会带来数据不同步或数据冗余的问题。

保险信息和所属企业的用途是确定个人是用户还是客户以及该个人与保单之间的关联关系。因为一个人可以关联多张保单。

• 如该个人在某一保单中是连带被保险人，那么该人对于该保单/该保险产品而言就是客户，因为Ta无法与产品发生直接交互行为，而是需要主保险人代为进行保全或理赔的行为交互。
• 如该个人在某一保单中是主被保险人，但该保单的理赔收单方式是以企业为单位收单理赔。那么该个人对于该保单/该保险产品而言仍是客户，因为TA没有与产品发生直接交互行为。
• 如该个人在某一保单中是主被保险人，且他可以直接在产品中提起保全或理赔的申请，那么该个人对于该保单/该保险产品是用户。

支付信息的用途是在用户与产品产生理赔行为时所需要处理的业务信息模块。这其中较为重要的是额度账户模块，将在第二步重点说明。而登录账号模块作为各种产品的基础支撑模块，将在第三步中重点讨论一下。运营信息模块属于用户体系部分，本文不做扩展。

三、搭建账户体系的第二步：业务是什么，具有什么样的区别？

如果第一步是确定账户的标准化属性，那么这一步则是确定账户的业务化属性。因为小编讨论的是保险产品的账户体系，那么该账户体系主要围绕的就是险种责任和险种额度。即交易业务的规则和金额。

投保方案中的每条险种责任对应的险种额度都是不同的，被保险人的理赔诉求与险种责任是一一对应的。

在互联网保险中，业务主要可以分为两个思考方向：

1、提供什么服务？比如投保，保全，理赔。

2、支持什么险种？比如健康险，财险，车险，寿险等。

这里我们就通过支持补充医疗险的保全和理赔的团体保单业务为例子来简单分析一下。

补充医疗保险是相对于基本医疗保险而言的，包括企业补充医疗保险、商业医疗保险、社会互助和社区医疗保险等多种形式，是基本医疗保险的有力补充，也是多层次医疗保障体系的重要组成部分。

从业务种类来进行保险账户体系的分析与构建：

保险的业务种类可以直接理解为保险的险种区分及具体理赔或保全规则。因为讨论的是补充医疗保险的保全和理赔业务，所以第一个属性就是账户业务类型，基本医疗保险或补充医疗保险。第二个重要的属性则是保险项目性质，这类企业的补充医疗保险项目会分为风险型和基金型。所谓风险型保险项目是以一个特定时间段为标准（大多是一年一期），到期续保后重置保险额度，不进行保额累加的操作。而基金型保险项目则可以在到期续保后进行险种额度的累加。因而需要在账户中区分保单性质是基金型还是风险型。还有一类重要的维度就是保险期间，也就是险种额度有效期。例如去年的理赔申请仅能使用去年的险种额度而不能使用今年的险种额度。当然还有很多其他的规则，比如共享额度，即多个险种共用一个额度。企业公共额度，即在某些特殊病中对个人补充医疗账户的额外的额度补充。

根据上述描述，我可以将额度账户切分为四层结构，即项目层，保单层，责任层，额度层。额度有效期则是从保单层到责任层再到额度层皆有关联。

从业务流程来进行保险账户体系的分析与构建：

保险的业务流程在这里可以理解为理赔流程和保全流程，当被保险人申请理赔服务后，在完成的收单，录单，理算及复核后，会相应的扣除被保险人的对应的险种额度。这其中就会涉及到账户额度的变动。根据业务流程不同，会延伸出额度加费流程，额度冻结流程，账务清结算流程等。因此在额度层就需要记录该账户的总额度，可用额度，冻结额度，剩余可用额度，初始额度，累计使用额度，累计加费额度。因而就能得到如下图所示的额度账户的结构样例。

搭建账户体系的第三步：账号有哪些，会遇到什么问题？

读到这里，可能会有读者有疑惑，开篇时小编不是将账号体系和账户体系分开来了吗，为什么账户体系中要考虑账号呢？因为账户体系是一个内容集，我们需要一把钥匙去打开这个内容集，而账号就是触达账户体系的钥匙。但是这把钥匙如何设计也是需要考量的。

有些读者可能在设计账户体系或者初期构建一个C端产品时，会优先搭建账号体系，再根据业务发展逐步的完善账户体系和用户体系。这种产品设计思路在某些流量为王，偏重用户体验的C端产品中是一种还不错的产品设计思路。但是在一些具有复杂业务场景的行业或产品中可能并不是一个好的设计思路，比如互联网金融，互联网保险或者偏重供需交易业务的互联网+传统行业。为什么这样讲呢？且看小编一一为你解答。

1、互联网产品的账号类型和适应场景：

首先我们先来看看产品账号共有哪些类型，每一种类型的前世今生是怎么样的。

（1）.自定义账号类型：

自定义账号起源于PC时代，用户可以根据喜好设定一组字符为账号，没有特定的组合格式。其缺点除了显而易见的因无特定生成规则而不容易记忆外，还无法关联到某一可以认证号主身份的识别信息，丢失后不易直接找回。

（2）.邮箱账号类型：

与自定义账号一样起源于PC时代，在自定义账号兴起之后，为了解决其易忘，难维护，难找回的问题。同时使用邮箱也逐步进入中国网民生活中。各大厂开始纷纷使用邮箱作为PC端最常见的登录账号形态。其优点较自定义账号除了降低了维护成本，提高了用户找回账号的便捷性外。也为对流失用户的召回和激活，账号安全性，产品业务推广的提升都起到的至关重要的作用。

（3）.手机号码账号类型：

当移动时代的到来后，由于中国大多数网民的手机号普及度远高于邮箱普及度，且国内网民的并未养成如国外网民一样的邮件使用习惯。手机号码作为账号载体受到了绝大多数移动产品的认可。其较邮箱有更高效便民的登录方式，仅需通过验证码即可登录，不需在消耗脑力成本记录密码。尤其当三大运营商对全网手机号实现身份认证后，其对账号安全性的提高是邮箱账号所无法比拟的。现在更有本机手机号一键登录的功能，更极大提高用户体验。

（4）.三方授权账号类型：

随着几大国民现象级的APP产品出现，其为抢占各垂直赛道和树立用户心智，衍生出第三方授权登录的概念。仅需要移动产品开启第三方登录接口，用户注册/登录时授权第三方，即可通过第三方账号登录产品。其优点使用户可以跳过较为繁琐的手机号注册登录流程，一键式完成注册/登录，并可将基本信息直接带入产品中。其缺点也十分明显，用户是方便了，但是作为产品本身，无法获得用户真实有效的身份信息。无法对用户进行安全验证，用户召回激活，用户常规运营等行为。

（5）.特定账号类型：

最后这一种可能在普通产品中并不常见，但是在某些B端产品或与个人敏感信息相关的产品中颇为常见，比如银行类产品的账号为身份证号，银行卡号。或者社保产品，某些教学平台，OA系统等办公软件。该类账号大多并非主动注册创建的，而是通过被动邀请或主动激活已存在的账号产生。其场景皆是对产品及账号信息的保密性和安全性要求较高。

2、同一产品的账号合并与账户打通：

当我们了解了几种账号类型后，可能遇到过在一个复杂业务产品的账号体系可能包含以上多个甚至全部的类型。这种情况的出现可能是产品的历史遗留问题造成的或者其本身业务形态决定的。而作为产品经理此时要思考的问题是：是否应该合并这些账号数据？这就涉及到了一个非常关键的字段：用户唯一标识。

• 用户唯一标识（UID）：用户在产品中完成账号注册后，自动生成一组特定规则字符组，作为用户账号在产品中的唯一识别标识，不可修改，不可重复，不对用户开放。

合并账号数据其实就是在同一个业务体系或系统下，将同一个用户的不同账号进行数据合并。而账号的合并的本质区别就在于：是否将同一用户的不同账号的UID进行合并，保持用户在系统中的唯一性。

这里需要产品人衡量与思考的点在于：

• 不合并或合并，对于业务价值的影响是什么？对于用户价值的影响是什么？

（1）.多账号合并：

场景：用户A在同一产品的同一业务系统中有两个相互独立的登录账号，类型相同。

分析思路：这种场景较为常见，比如一个人拥有多个微信号码，QQ号，微博号等。大多数社交类产品是不处理这种一人多账号的情况。那么什么业务场景中会对这类同一用户多账号进行处理合并呢，小编在保险产品中就遇到过这类情况。其处理原因是因为互保产品中，用户作为被保险人会进行实名认证，当被实名认证后，如存在多账号的情况，将较难对其进行保全及理赔的服务维护。多账号的情况会造成保单信息不同步或保险数据冗余。换言之，当在同一产品的同一业务中，同一用户存在多个账号的情况时，如对该业务数据造成较大影响时，需要对账号数据进行合并处理。此时多账号的合并处理又分为两种：

1）、当需要被合并的账号类型相同，如类型都是手机号码时，其常见的处理手段为选择其中一个手机号码为账号名，其他手机号码注销，并将其对应的账户数据合并同步。

2）、当需要被合并的账号类型不同，如类型一个是手机号码，一个是邮箱号码时，其常见的处理手段为选择其中一个类型为账号主体，其他类型保存，可作为展现数据，也可作为副账号。并将其对应的账户数据合并同步。

在工作中，除了同一产品中同一用户的多账号是否合并的问题，我们还可能遇见同一产品同一账号的多账户是否打通的问题。

（2）.多账户打通：

场景：用户A在同一产品的不同业务系统中共用一个登录账号，但业务的账户数据是相互独立，不关联同步。

分析思路：这种场景也较为常见，比如同一个微信可以在王者荣耀的iOS端和Android端各创建一个账户，登录账号通用，但对应的账户数据相互独立。那么什么业务场景中会对这类同一用户同一账号在多业务系统的账户数据进行打通处理呢。

这种情况在具有供需交易类业务场景的产品中是较为场景的，比如保险产品，或者二手交易类产品，交易代理人产品。普通C端用户即可是需求方也可以是供给方，俗称小B用户。此时是否要将同一用户在买方业务系统的数据与卖方业务系统的数据打通，在于其相互是否有业务交集或连带的价值体现。

所谓打通账户数据就是将同一个用户同一账号的在不同业务系统的账户数据进行部分关联和同步。 在具有复杂业务场景的产品中，我们想清以上可能会遇的问题及对应解决方案后再进行账号体系的设计会更加的清晰和高效。

-END-