账户体系

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. 账户分析/用户分析

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,386评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,142评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,704评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,702评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,716评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,573评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,314评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,230评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,680评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,873评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,991评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,706评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,329评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,910评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,038评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,158评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,941评论 2 355

推荐阅读更多精彩内容