术→技巧, 研发

用户系统设计:三户模型&三层身份模型

钱魏Way · · 6,704 次浏览

三户模型

三户模型最早是在增强型电信运营图(Enhanced Telecom Operations Map,eTOM)中提出,在电信行业中得到广泛使用。 三户指客户(Customer)、用户(User)和账户(Account)。eTOM 引入是电信行业营销模型转向“以客户为中心”的理念而产生的成果。围绕客户建立用户和账户。这三个是相互关联的实体,这种关联只是一个归属和映射的关系,而三个实体本身是相互独立的,分别是体现完全不同的几个域的信息,客户是体现了社会域的信息,用户体现了业务域的信息,账户体现的是资金域的信息。

  • 客户(customer):是指客户(自然人、公司、集团公司)的基本资料信息。例如自然人的姓名、手机号、身份证、邮箱地址等等;公司的五证一照、行业、联系人、网站地址、通讯地址等等。如无特指,一般客户指个人客户。
  • 用户(user):指客户在系统的登录账号信息,包括账号、密码、人员权限、角色等等。对应的,法人客户在系统中注册后,被称之为商户。
  • 账户(account):指客户在系统的虚拟账户,主要与交易记账相关。

以电信业务为例:

  • 客户:人
  • 用户:电信产品的实例表现
  • 账户:付费的账号

假设张三是中国典电信的一个客户,张三办理了一个手机SIM卡和一个宽带业务。其中手机SIM卡和宽带业务分别作为一个用户存在(电信产品实例)。下面还有一个账户的概念,账户是用户进行付费的。一般情况,一个用户只有一个账户,以上例为例,张三有一个账户,为手机号和宽带付费。当然,有的人可能存在多个账户,例如手机号是一个账户,宽带是是一个账户。

总结一下,一个客户(张三)可以有多个用户(一个手机号和一个宽带业务),但一个用户只能归属于一个客户。一个客户可以用多个账户,但一个账户也只能归属于一个客户。账户和用户的关系比较复杂,一般情况,一个账户可以给多个用户付费,但也允许,一个用户的不同费用由多个账户付费,所以账户和用户之间是多对多的关系。

客户

客户是一个社会化的概念,一个自然人或一个法人就称之为一个客户,法人客户既可以是一个企业,也可以是与这个企业、集团相关的自然人客户,可以称之为一个集团客户组。

客户可分为个人客户,企业客户。一个客户可以包含多个用户,客户通过唯一的客户标识来确定。客户描述一个客户的自然属性,客户可以和用户一一对应,也可以和用户一对多。即使不使用业务,也可能存在客户,因为客户是自然存在的。客户信息包含客户名,地址,邮政编码,性别,年龄,职业,证件号码等等信息,是自然存在的信息。

个人客户

在互联网系统中,一般是用户先注册,先有用户,然后补充客户身份信息。也就是客户身份信息是在运行过程中逐步完善的。在电信体系或银行体系,客户的主键通常是证件号(如身份证),将所有相同的证件视为同一客户。在互联网行业通常是将手机号识别为主键(注意:手机号有注销、更换等问题),这里面就有一个关键业务,既然相同证件的证件号或手机号会识别成一个客户,当相同的证件号或手机号进入系统时,系统是如何处理的?当然是合成一个了,这个过程叫做客户归并,即:将客户合成同一个客户号的过程,我们称为归并。归并是有风险的,所以需要一些鉴权手段来处理。

在互联网应用中,一个系统中的生命周期如下:

正常的互联网站点一般只有正常和禁入2种状态,银行业可能还会包含冻结和止付状态(以司法协查为例,某个客户被协查以致账户冻结,需要冻结该客户下所有资金账户,这些账户都被止付)。

注意在这个流程中没有销户的状态。 这是为了支持历史业务的处理,客户一般不做销户。 此外这个流程和支付账户的流程比较类似,这是为了方便在客户层面做账户控制。

存在问题,用户手机号更换带来的身份识别不能解决。

企业客户

企业客户相对个人客户来说比较复杂点,但三户模型仍然适用。企业客户是一个组织,其账户必然是组织授权内部人员去操作。但是这个操作人,同个人客户一样,只是系统的使用者,即用户。企业的资金比较大,并且有严格的业务流程,所以在系统使用上,一般是多个用户操作一个或多个资金账户。这种关系本身来说,也是一种授权关系,企业授权相应的用户来操作特定的资金账户,只不过为了管理方便,可以引入角色管理机制来实现。对于支付公司来说,企业客户通常都是发展商户过程中产生的。企业客户的识别同个人客户识别也是一样的,通过企业证件来统一识别。相同的企业证件号归并到同一个企业客户下面。建立企业客户的好处在于:

  • 有些企业本身只开通了企业服务业务,而不开通商户服务
  • 一个企业可以开通多个商户,企业客户是这些多个商户的统计口径

用户

用户是在产品基础上产生的实体。如果说一个客户使用了多个产品,那么一个客户就会对应好几个用户(即产品)。

个体用户

用户与资金账户之间我们可以抽象出一种授权关系,凡是授权用户,都可以操作资金账户,当然,这种授权包括客户自己的用户。用户的建立比较简单,一般自助注册后就可以生成用户实体了。

用户的生命周期如下:

如果用户想要销户,收到销户申请后,不能直接销户,客户是通过用户来进行资金账户的管理与操作的,所以,此时有个确认过程,要求各业务系统确认此用户下的所有账户是否可以销户,如果没有问题,先销资金账户,当用户下的所有资金账户都销户完毕,再销用户,用户销户完成后,会释放出此用户占用的资源,如注册手机号。

在互联网环境比较多的场景是用户更新手机号,用户更新手机号的时候涉及到的两个手机号都需要验证。需要注意的是, 更新手机号需要涉及到更新客户ID。

用户除了生命周期状态外,还有一个管理状态,比如锁定,从现实模型中来说,这个是不应该放在用户层面的而是放在账户层面上的,但互联网模式下,一个用户有多个资金账户,为了用户体验,把这些放在了用户层面上了,就如同支付密码放在用户层面上一样。

商户

商户是企业客户的一个业务影子,或是看成资金账户分组的一个手段。商户是客户一个外围业务,如果把它看成用户平级层面也是可以的,即:此商户所有业务产生的资金进入到一个分类资金账户里。不论怎么说,一个企业不论开多少个商户,每个商户又开通多少个资金账户,都改变不了资金账户的归属关系,它是现实客户这个实体的。

账户

账户的概念起源于金融业,只是一个客户存放资金的实体,目的是为选择的产品付费。一个客户可以拥有一个账户也可以拥有多个账户,账户上的资金可以为客户本人的用户付费,也可以为其他客户的用户付费,这种付费关系需要一个付费规则进行关联。

既然账户关系到付费规则,必然会引出账单的概念。一般来首先要生成用户账单,账单应该归属于用户。

账单分为两级,客户账单和用户账单:

  • 客户账单是根据用户账单按照规则进行简单的算术加和得到的。
  • 用户账单可以进一步细分为账单项,账单项是为客户打印账单提供清晰明了的消费明细。

账单应当归属于用户,为客户提供的账单应当以产品为单元来生成账单,一般的消费习惯都是以产品为单元来付费;但同时也应该生成客户账单,如果一个客户选择了运营商的多个产品,那么客户如果需要一个所有产品的账单,运营商应当提供,同时集团客户需要一个集团所有客户的消费明细,也需要有一个集团客户账单。

用户和账户的映射关系,主要就是销账规则。销账流程中处理模型应当也是按照用户的账单来销账,而不是按照客户账单,客户的账单应当只是用户账单的简单算术运算的得到的账单,只提供打印。

客户和账户应当有一个归属的对应规则,该规则应当是一种归属关系,个人账户应该归属于个人客户,集团账户应当归属于集团客户。但这只是一种归属关系,而没有付费关系,账户可以跨客户为几个用户付费,也可以为单个用户账单的某个账目付费。

产品在市场提供时难免会遇到,产品的某项子功能的交叉优惠,这种交叉优惠,应当打包成为一个产品。在具体的系统模型中的体现就是增加一个用户,并赋予一定的资费,同时指定一个账户来为其销账,就统一了整个模型。

账户的生命周期:

账户建模

在支付系统中,账户的建模,主要是从如下几个方面来考虑:

  • 交易的需求,比如检查账户是否被锁定、余额是否足够、是否有效等。
  • 记账的需求,按照公司会计需求记录账户上的所有行为,包括支出、充值、转账等。
  • 对账的需求,包括和支付渠道、商户、个人的对账需求,核对交易和账户余额是否正确。
  • 风控的需求,如反洗钱、反欺诈等,都需要依赖于账户体系来提供核心数据。
  • 信用的需求,对用户、资产、商户等主体进行信用评估时,也需要依赖账户体系来提供的核心数据。

这五个需求,按照其设计的优先级,也是从支付、记账、对账、风控来进行。支付系统根据其发展所处的阶段,逐步将新增需求纳入设计中。

根据业务需要,可以设置多种账户,如支付账户、预付卡账户、代扣账户、零钱账户、结算账户等。一般来说电商系统中涉及的账户类型有:

  • 虚拟币账号:用户和使用虚拟币的商户都需要建立虚拟币账户。
  • 代扣账号: 用来支持订阅类型的定期代扣;
  • 零钱账号:即电商的内部账号,用户、商户、清算单位需要建立零钱账户
  • 第三方支付账号:用户在第三方支付机构建立的账户。
  • 银行卡账号:用户的银行卡信息,每个卡对应一个账户。
  • 结算账号:用来支持和第三方支付公司、银行进行结算用。 第三方支付需要为每个商户号建立结算账号;银行需要为借记卡、贷记卡分别建立结算账号(有必要吗?银行卡直连时使用)。
  • 代扣代缴账户:用来支持代扣税款业务。

注意,有些第三方信息是不能保存的,如信用卡的CV号等。

三层身份模型

从使用层面,三户模型更加适合交易类网站,三层身份模型可能更加适合社交性质的网站。三层身份模型将用户分层三个层次,分别为:账户标识符,登录标识符和公开标识符。翻译成大白话可以是:账户ID、登陆账号、昵称。

账户标识符(DB Key)

从软件工程的角度,需要在数据库中存在一个用户标识(key)来记录每个用户的记录。这个用户标识可能会被用在Cookies或者URL中,这个账户标识符必须是永久的、唯一的。通常是由系统自动生成的一个ID,这个ID不受用户的控制,从用户角度这个标识符应该是不不可见或至少是惰性的,这个标识符不应该与一些公共名称,比如手机号或邮箱。

登录标识符(会话认证)

在创建与账户标识符关联的有效会话(Session)时,登陆标识符时必须要的,他们用来从服务中获取授权。通常由唯一的账号/密码对表示(这里的账号可以是邮箱或手机号,也可以是用户选择的用户名)。注意,账户/密码并不是一定需要存在的,笔筒通过oAuth形式的授权登陆(类似微信登陆、微博登陆等)。

将登陆标识符与账户标识符分开,可以使得用户更加容易的改变登陆方式。由于账户标识符不需要更改,因此可以避免更换登陆方式或登陆账号带来的数据迁移问题。最重要的是,可以提供多个不同登陆标识符附加到单个账户上,从而可以允许服务聚合从多个身份供应商收集的信息。(如授权获得微信或微博的个人信息)

公开标识符(社会标识)

与账户标识符和登陆标识符不同,公开标识符标识用户希望如何被服务商的其他用户感知。在线用户的公共标识符通常是复合对象:照片,昵称,可能还有年龄,性别和位置。它为任何观众提供了足够的信息,可以快速解读个人背景。公共标识符通常链接到详细的用户配置文件,其中可以进一步识别身份。公开标识符在某些情况下需要唯一(比如类似微博的@功能),有时是不需要唯一的(如微信的昵称)。

参考链接:

2 Replies to “用户系统设计:三户模型&三层身份模型”

  1. 这篇文章写的太棒了,每个概念都讲的很清楚,正巧最近公司里遇到销售那边所谓的“客户”与产品上“用户”的概念差,之前我们一直是把这两者划等号的,也就是说我们基本是这么认定的“客户买了我们的xxx产品”、“帮忙查询一下aaa客户在我们xxx产品上的数据”等等。。但有的时候实际操作起来发现会有阻抗,不对等。。因为会有一些特殊情况如“一个客户买了我们多个产品”,这种方式我们只是简单的做成类似一对多的关系而已。。前几天去了趟电信办理一些业务,正巧也发现电信账单的账单类型上分为“账户”和“用户”,所以一直在思考这些问题。。。除了三户模型问题之外,还有关于账单相关的模型问题,不知道博主有没有时间研究一下呢,我发现阿里云账单系统还是挺复杂的,账单页面分为“统计项”和“统计周期”两类,“统计项”下有计费项、实例、产品、账号、财务单元这5个,“统计周期”下有账期、按天、明细这3个。。有些懵了。哈哈

  2. 概念描述的很是清晰;
    所有的概念都融入在日常的工作中,读完这个有一种豁然开朗的状态

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注