账户体系

1. 账户体系概要

账户体系是用户跟产品的第一次亲密接触,也是后续所有交流的基础,影响深远。如果后期想要修改,很可能牵一发而动全身,需要仔细处理。

首先账户体系的目标是什么?我想有以下几点:1作为基础系统,在用户和平台之间搭建桥梁;2为运营做用户分析提供基础数据;3作为资金流动的单位之一,为后续平台资金流动打好基础。

从整个应用来说,不论toB还是toC的产品,账户体系都几乎跟所有子系统都相关,比如积分,卡券,等级,活动,订单,财务,权限等。这些外部关系暂且不谈,现在主要关注内部。下图是对账户体系内部的角色主题事件的分析。当然不同的应用下,账号都会有不同的主题和事件,我们只看看大概通用的主题。其中用户注册和运营的账户分析是比较关键两点。

账户系统

2. 注册

用户注册简化后大致有这些方案:账号+密码,手机号+密码,手机号+短信,单纯第三方账号。为什么说简化呢?比如有些应用,用第三方账号授权后还是让你输入手机号+密码,这种情况仍然归于手机号+密码方案。

2.1 账号+密码

2.1.1 优点

》不用担心换手机号。不依赖手机号,换号了重新绑定下就行。这点怎么说呢,确实有些人就因为这个原因,只选择买支持双卡双待的手机,或者被迫维持两支手机。

2.1.2 缺点

记忆成本。用户又要记住账号,又要记住密码。

找回密码比较麻烦。如果注册的时候没有引导用户填写手机号或邮箱,当用户忘记密码的时候,几乎没办法找回。

账号不允许重复。当你想用一个账号的时候,发现已经被别人用过了,对用户来说是很糟糕的体验。

2.1.3 适合场景

ToB端的业务。比如一些SaaS平台可能用邮箱作为账号,也有让你自己输入账号的。

必须要有单独账号作为唯一标识的业务。比如银行开户,一些政务平台等。

2.2 手机号+密码

目前绝大部分C端产品都以手机号作为用户标识了。

2.2.1 优点

方便快捷,人人都有手机号,还不怕重复

容易建立社群关系。如果能把通讯录拿到,瞬间就把用户关系建立了。

找回密码简单

登录不依赖短信。这点很重要,一来节约短信成本,二来避免用户不方便用手机的情况。

2.2.2 缺点

如果应用使用频率很低,用户要拿手机号注册还是有点麻烦,或者说抵触

2.2.3 适合场景

比较适合大部分C端产品上,并且产品使用频率不能太低。

2.3 手机号+短信

有些应用比较激进,直接手机号+短信验证码就登录了,似乎没有密码的概念了。

2.3.1 优点

非常容易得到用户

2.3.2 缺点

手机号或者手机不可用时,很不方便。手机总有没电的时候,手机号如果换了,都将是很尴尬的情况。

2.3.3 适合场景

有些应用只希望用户尽快完成业务(主要是交易),比如买电影票,让观众绑个手机号就行了,没必要再加密码。

2.4 单纯第三方账号

2.4.1 优点

极快。几乎感觉不到门槛,就成为了这个应用的用户。

不存在忘记密码这一说

2.4.2 缺点

用户数据受限。严重依赖第三方授权。当然让用户先进来,在以后的业务中完善资料也不失为一种套路。

2.4.3 适合场景

》适合一些工具型的应用。

》当非常渴望用户数量时。


当然,以上都是简化后的方案,在实际应用里通常都是选一个方案为主,辅之其他的信息,比如以账号+密码为方案,同时可以绑定手机号或微信,比如以手机号+密码为方案,同时可以绑定微信QQ新浪,比如以第三方账号为方案,同时可以绑定手机号等。但是,只要是以某个方案为主,同时能绑定其他信息,就不可避免地碰到账号合并的问题。


2.5 账号合并的问题

试想以下场景:

第一天,小明创建账号A,同时绑定了微信W。

第二天,小明又创建了账号B,这是他还想绑定微信W。你让不让他绑?

在这个场景下,不论我们说的账号A账号B,究竟是账号+密码,还是手机号+密码,还是第三方账号,都不影响。问题的核心始终都是让不让他绑。

2.5.1 不让绑:账号不允许合并。

大部分应用认为,不应该让小明绑微信W,可以提示说微信W已经被绑定过,或者说请先解除微信W之前的绑定,甚至直接问用户是否要解除微信W跟账号A的绑定,这三种情况都可以归为本质上不让绑。这背后的根本,是指微信W可以隶属于账号A,也可以隶属于账号B,但账号A和账号B代表两个用户,不允许将他们数据合并起来

2.5.2 让绑:账号允许合并。

小部分应用认为,可以让账号B直接绑定微信W,并且把原来的账号A数据带入到账号B。这样做当然也行,但是要非常谨慎地处理数据。这里把数据分成普通数据和敏感数据。普通数据是指很容易合并的,类似收藏,评论等。敏感数据,是需要反复考虑的,比如积分,等级,订单等。拿积分来说,如果每天签到可以加1分,那么两个账号合并时,其实是多拿了很多分的。再比如等级,究竟按等级高的合并还是按等级低的?

如果让我来选,会更倾向不允许账号合并。

2.6 账号体系设计

首先,任何事情的设计,都应该跟随业务,千万不要过度设计。下面是一个账号体系设计的例子。

其中,username可以由系统生成,可以是手机号,或者账户中的任何一种,此时的密码是放在账户里的。

3. 账户分析/用户分析

这里涉及到埋点,用户画像,数据分析等内容。

你可能感兴趣的:(账户体系)