关于用户登录注册的一些实践

虽然关于用户登录注册几乎是每个系统的标配,也是大多数教程里的经典样例。但实际工作中,我们还是时不时会被“用户”搞的焦头烂额。比如防止机器注册、oauth接入以及带来的用户账号合并问题、用户身份验证或身份标识、用户相关的表应该如何设计以应对未来各种扩展和可能性等等。

这里记录一些之前的设计和开发的经验。

用户是否一定要注册并登录

我个人非常反感打开一个网站或者App以后,还没搞清楚是做什么的时候就强制要求注册的。这种做法绝对是“好奇心杀手”,至少一半的人被这个动作挡在了外面,实在是不值得。我之前参与的项目,只要是可以最终能够获得用户的联系方式的,那么一定不需要用户注册以后才能使用功能。比较常见的情况是标准的电商网站,浏览和查看是不需要用户注册的,但是结算时就需要了,在我看来虽然比一上来就注册好一点,但还是有点“伤” – 用户都已经下决心购买了啊!用户结算时一般都会做两件事:填写联系方式、支付。这些都不需要用户ID这个东西,能联系到用户就已经很成功了,一定要用户填个注册表单吗?当然不排除是万恶的KPI。

不过不注册产生的一个问题是用户“返回”和订单跟踪时会需要额外的流程来,比如需要用户提供订单号来找回订单,甚至可能需要人工介入。

身份标识

即如何标识一个用户,常见的标识有:昵称、邮箱、手机号、OAuth授权ID。更多的标识建议没有特殊必要就不要收集了,一来涉及到个人隐私,二来这种数据需要更高安全要求的存储(前提是你没打算用来干坏事)。在bot还不是那么泛滥的年代,常常是一个昵称就可以了,但现在连邮箱都不行了,几乎都是手机号码起步。很多时候,一个手机号就对应一个用户,虽然现实并不是这样,但至少是比较靠谱。会产生多账号问题 – 因为有些人换号了或者有多个手机号,如果用户有合并账号asset(也就是账号的“资产”,比如余额、积分、优惠券等等)的需求,目前看貌似真不好搞,判断两个账号同一个人并不容易也会存在风险。

比较常见的还是基于手机号标识用户后,在进行手机号的更换绑定的流程,这样就成了“一个用户一个手机号”,也算是解决了问题。至于账号相关asset合并问题,就要视具体情况来定了。

多账号问题

举个极端的例子,当系统支持手机号、邮箱注册,同时支持Oauth登录时,如果没有任何限制,一个用户可能会用手机号、邮箱、各个Oauth各注册一个用户。这种情况带来的问题是用户会搞不清楚自己的订单在哪个用户里,相信我,有这种“糊涂”的用户。之前的一个经验是“关联”,比如,除了上述的标识以外,我们通常还会生成一个唯一的标识记到cookie里,同时useragent信息也可以部分的标识,geo信息,ip归属地,甚至再“玄”一点的用户行为模式。通过这些标识也可以进行账号是否属于同一用户的判断,此时再提供给用户合并账号的流程。

OAuth

OAuth现在也是标配了,大多数的OAuth的接入都不困难,所以接入的技术细节就略过了。之前的经验是用户和用户OAuth是一对多的。用户正常注册后,然后绑定各OAuth,这样之后通过OAuth登录就可以确定用户,这是最简单的情况。如果用户是先通过微博的OAuth登录,之后又正常注册的,也就是上面说的多账号问题了,除了上面的“关联”方法,另一种解决办法是针对这种用户鼓励再进行手机号或邮箱的注册。

经常见到,用OAuth登录跳转回来以后,马上要求用户进行手机号或邮箱注册的流程,虽然可以最快的完成绑定。但却失去了Oauth登录的便捷性,有点被“坑”的感觉 – 本来觉得注册麻烦,以后授权一下就可以搞定,结果授权完还是一样要注册。

用户表结构

也没什么花头,User表记录用户的基本信息,UserProfile记录用户的个人资料,UserAddress记录用户的地址,UserOauth记录用户的登录授权信息,UserCredit用户积分信息,UserXXX,总之就是尽量让User表纯粹,通过增加实体表来扩展。比较简单,就不细说了。

验证码(captcha)

验证码用来防止机器人进行表单提交,比较经典是12306的验证码。对这件事我是有点“悲观”的,因为永远都是道高一尺,魔高一丈。现在很多时候都是用了手机或者邮箱的动态验证码,或者类似微信换设备登录时选择好友头像,还有非常原始但有效的“注册预留问题”。相对来说类似微信这种根据账号的asset(微信的好友就是微信账号的asset)来进行验证,但这个又是和你的业务相关的,比如如果是滴滴打车,可能会让你选择你曾经在哪些城市使用过滴滴。

单纯的captcha真的没有卵用,看看满大街的注册机就行了,当可以cover成本的时候,甚至都可以人肉来做,搞captcha有啥用呢?

创业之贼

磕磕碰碰,在九零后纷纷崛起的时代,我这个八零后老人也开始创业了。
想起写这个题目已经有一段时间了,在开始创业以后,很多思考方式和做事方法和以前不同,所以也就越发留心那些“做事”的人是怎么做事的,那些“说”的人是怎么说的。
现在形形色色的创业者(包括想要创业的人)是何其多,但90%(或者更高)还没有实质的成效。作为一个技术工作者,我有幸接触了很多想要创业和处于创业初期(包括我)的人。那些想要创业还没有创业的人,无非两种执行力强的和执行力弱的;而那些已经创业的创业者其实也无外乎那两种。而且所占比例可以说没什么区别,一方面是现今创业门槛过低,而另一方面也是很多人并不具备识别doer的能力。于是乎,很多时候创业就成了赌博和包办婚姻的结合体。
而我想要说的,恰恰就是创业团队里的talker问题,我称这种人为“创业之贼”。

最初的核心的创业团队,通常是“知根知底”并且是互相认可对方在各自专业领域的能力的。但是我们知道,通常两个人是很难“起事”的,这时候就需要通过各种人脉圈去找一些可以弥补某些短板的合伙人加入。而这种时候就很可能引入所谓的talker,并且创业者遇到这种情况非常普遍。一种心理原因是“饥不择食”,有总比没有强;还有一种可能是某个创始人比较看重,直接做了决定。

如果这个人能胜任,并且能够被其他人认可还好。但如果这个人只会说不会做就头疼了,事情到他那里就停了,做事情来有头无尾,时不时需要别人擦屁股,各种idea满天飞但永远都是别人来实施,不分析原因不持续学习(这个最可怕)。恭喜你!你遇到了所谓的“创业之贼”。

怎么解决“创业之贼”这个问题呢?很多doer并不是很有经验去处理这种问题,毕竟大家更多的精力是往目标去冲,但“贼”的问题在于,你越是忽略他,他可能越让你烦心,最后可能让整个团队都会受到影响。创业团队天天都是各种要解决的问题,难不成是去搞“宫斗”?

学霸中的学渣

隐藏在学霸中的学渣,也就是俗称“凤尾”的人。他们见识过什么是学霸、并了解成为学霸需要如何努力。同时,他能够体会学渣的心理活动是怎样的。

为什么你会激怒开发人员?

有机会深度接触产品经理和开发工程师这两类人,有时候也会在二者之间不停地的角色切换。这种不上不下的感觉有时候让人颇感难受。为什么?因为一边需要考虑定义产品边界以尽快上线迭代、不得不进行妥协,而另一边作为开发人员却时时事事想要做到最大的扩展和可能性,而不得不拖延进度。

但二者有一点是需要有共识的,那就是细节的重视。

好吧,有点跑题了。

之所以突发奇想想到这个题目,也许是内心的另一半有积郁已久的怒气吧。常见的比如改需求、催进度、不去了解技术这些就不说了。说三个我比较有体会的。

1. 不正确的命名

这个放到第一个可能让很多人意外了。在中国,程序员可能算是整体英文能力最高的群体。当我作为一个产品经理设计完一个产品,并准备“亲手”去实现它的时候,我发现我经常需要用到英汉/英英词典去给产品、模块、子系统、甚至状态正确的命名。比如“积分”,到底应该是point、credit,当程序员在思考”积分“的本质的时候,如果产品过来来一句,“别纠结了!就叫‘jifen’吧!”,你知道程序员心里是怎么想的吗?你知道程序员每次在IDE中看到jifen这个词的时候是怎么想的吗?你知道程序员会不得不创建诸如“JifenAccount”,“JifenLog”这些奇葩的名词吗?你能想到code review时候,其他程序员对你英文能力的“冷嘲热讽”吗?

2. “引经据典”

“Facebook就是这么做的,微信就是这么做的”,这种话多半出自一只菜鸟产品经理 – 因为你只知道需求,却不知道边界、约束。你有没有制定合理的版本计划并和程序员商量过?你有没有正确地评估你可用的开发资源和时间?

3. 缺乏学习能力

这一点其实任何人都应该避免,别抱着一知半解去和别人讨论。多去了解“目标”周边的情况 – 这就是学习能力。缺乏学习能力其实不可怕,可怕的是没有意愿或没有动力去学。这种就建议转行了,应该去做自己喜欢的事情。

4. 重复

DRY(Don’t repeat yourself),重复的问题就像是“重复”代码一样可恶。

为什么有那么多的“半拉子”App

无论是App Store还是各大应用市场,只要搜索一个主题,总会有一大堆相似的App跳出来,然而其中90%都是没法用的。根本原因是:所有人,无论什么背景或经历都觉得应该搭上移动互联网时代的大潮,似乎做个App就万事大吉,等着收钱了。可是对于一个不了解互联网和网络技术的人来说,他完全低估了做一件互联网产品的难度,以为简简单单找个外包团队,花几万块钱就ok了。可是对外包团队来说,他们不会告诉你,产品需要运营,需要持续的优化和技术投入。做好,收钱,完事!如果都告诉你,可能会吓到你,项目不做了,怎么收钱?我并不是对外包这个行业有偏见,只是这是外包存在的根本。也有很多优秀的外包团队。

具体的来说,造成90%的App都是“失败”的不外乎这几个原因:

1. 拍脑袋

很多时候,老大的一个idea,或者是看到某个心仪的App之后,一拍脑袋,说:“我就做一个这个App,你先给我抄一个。”或者“我也要做一个,然后再把微博、微信、社交、大数据这些东西都加进去。“ 一般碰到这种人,我绝对会把他拍回去,或者关系还不错的话,我会尝试让他明白后面的事情有多少,合理的投入是多少(通常要在他原本以为的基础上乘以5或10)。

2. 谈情怀

不得不说,有很多谈情怀的互联网产品是很不错的。但通常都是解决某个具体的问题,或者是工具类的App。否则一旦开始谈情怀,就会清高到觉得运营的工作low到不应该做,殊不知,很多产品运营的工作是非常dirty的。太清高的结果就是太多的有所不为,或者想都不想。

3. 搞”神器“

产品如果没有清晰的目标,就会搞很多功能。一会儿是社交,一会儿要通讯、一会儿要LBS、反正能加的都要有。似乎做个微博+微信的东西就可以超越微博和微信了。(怎么感觉我在黑支付宝啊!),最终的结果是开发团队疲于奔命,做出来的东西没人用。

4. 没规划

只要不是工具类的App,都需要有长远的规划,我的经验是至少1年验证。1年的验证如果只是一个平台,并且持续优化的话,没有50万、100万根本没得玩(开发成本而已,都不说运营成本)。你说你自己做的,你自己做也要算成本的吧!什么?外包给你报价5万,好吧!又一个”半拉子“App要上线了。是的,如果是做一个商店或者新闻阅读这种相对标准的App,可能是可以做出来。但还是要考虑获取用户的成本吧。

上述这些都是我的一些经验,难免片面。对于想要做一件产品的人来说,最主要的是思考”我要解决一个什么问题“,别贪多。很多时候,一个App的失败不是因为缺乏方法,而是缺少方向。

比特时代的思考方式变化

人类社会的发展,从粒子的角度来看是从原子(农业时代、工业时代、商业时代),到目前的比特(信息时代),未来也许应该是光子(时间时代)。

各个阶段的价值表现形式(或者说货币、等价物)也不同,在原子阶段,是贵金属(其实货币是个非常通用、基础的概念);而信息时代则是比特。比如,过去我们说一个人的价值是说某个人可以产生多少产品(农业),或者说某个人可以组织并生产多少产品(工业时代),而商业时代作为“交界”,恰恰说明了人类进入信息时代的前提。因之,某种程度来说,商人也是拥有或者善于利用某种信息而已。商业时代其实也不尽然是指纯粹我们所说的商业行为,更多像是“交换”行为 – 用产品去进行交换产品,或者用产品去交换信息。从这个角度来说,我们看到的所谓“权钱交易”只不过是一种不合法(或者说有碍他人权益的)的商业行为而已。

以这个角度来看,我们目前的信息时代和原子时代的一个最大的区别其实是“所有权”的问题,所谓“世界是平的”,即信息的所有权被极大的放开,原有商业时代的信息壁垒在被不断打破,催生了新的经济行为和经济形式,而经济领域的变化又会影响到大众心理和大众价值观。鉴于此,我们应该如何调整自己的行为模式以符合这新的时代呢?这里粗浅思考一下。

1. 不要试图增加公共的信息壁垒,信息获取是公平的

2. 建立个人的信息壁垒

3. 尽可能获取最多的信息

这两条其实完全可以映射到原子时代的:

1. 不要损害他人的利益(不要试图强行获取其他人的金钱)

2. 保护自己的利益(建立自己的金钱壁垒)

3. 个人利益最大化(在前两者的前提下,获取更多的金钱)

这里不涉及道德问题,控制欲望这件事不是这里讨论的。所以,这里也没有鼓励人去“向钱看”。

所以很多时候,我们需要让别人对你的了解处于一个合理的区间里,同时尽量获取多的信息。

NPS悖论

NPS(Net Promoter Score),译作“净推荐值” ,是一种计量某个客户将会向其他人推荐某个企业或服务可能性的指数。不知什么时候被引入互联网产品界,被各种产品经理视为神物。wikipedia

之前也曾经做过NPS的收集工作,也曾经非常迷恋NPS。但最近一段时间的思考发现,似乎很难获得一个非常有效或者参考比较高的NPS。

为什么?主要是“收集”。我们知道NPS是一个非常泛(general)的指标,因此绝大多数的NPS获取方法都是在各种问卷调查的最后一项来一句:“请告诉我们您向他人推荐XXX的倾向是:1.2…..10”,非常常见,有时候还会在一些线下的实体店里遇到类似的问题。

首先的问题是:填表悖论。这个不知有没有专门的定义,我只是拍脑袋想起来这个词。什么意思呢?其实很容易理解,那些愿意回答你的产品的调查的人首先就已经有较高的推荐意愿了。试想,如果我都不喜欢或者厌恶你的产品,我还愿意花时间告诉你反馈吗?尤其是同类产品的获取相对容易的时候。也许这也是NPS的计算方法非常“苛刻”的一部分原因,去抵消掉填表悖论的影响。

另一个问题,其实是接着上一个问题。一个极度理性的人是不会浪费一丁点时间在一件没有后续结果的事情上的(除非被逼无奈,如果你的产品能让一个理性的人没有别的选择,相信我,你不需要NPS,你只需要数钱即可)。从这个角度来说,你的调查最终只会遇到两类人:

1. 感性的人

2. 对产品抱有强烈喜爱的人

后者不用说了,他们的回答一定会提升NPS,至少不会拉低,而前者呢?就非常难说了。感性的人的结果是非常主观的,饱含各种偏见,几乎是一种随机结果。你真的确定要用主观感觉来衡量你的产品好坏吗?除非这种感觉数据足够多,并且一定要在用户一使用完马上来做(以减少其他因素影响主观印象),也许才能获得有参考意义的数据。可获取这个数据我还是觉得很悲观的。

说成这样,难道就要抛弃NPS吗?当然不,只是我们需要特别警惕NPS的收集,同时要知道NPS的参考价值有多少。不要盲目,否则就是“迷信”了。

关于“起名字”的一些启发

最近听了好几个很有意境的产品名字,从中似乎悟到一些门道。记录一下。

第一步:基础

比如一个成语或者一句常用语。通常是褒义的,当然也可以用贬义词 — 含有自嘲的意味。比如:精益求精,刻舟求剑,采菊东篱下。如果是短语的话,最好是主谓、动宾或者动补,也就是有“动作”,这样的名字才会有画面感或者意境。

第二步:提炼

如果“基础词句”有点长的话,就把信息量不高的字或词去掉。

比如“采菊东篱下”似乎没什么可以去掉的

第三步:偏移

暂时没想到合适的描述词,就用偏移吧。所谓偏移是指,将分开的词语进行替换,替换的方向可以是近义、反义或者随机替换。偏移可以进行多重。

比如“采菊东篱下”的“采菊”“东”“篱下”或者(“东篱” “下”),随意替换一下:采菊=>撷(近义), 东=>南(反义),篱下=>XXX(替换为和产品相关的字词)

第四步:优化

根据目标产品在进行裁剪和替换即可。