用户注册先到先得模式是不是该换了 用户注册或许不该先抢先得

　　用户注册先到先得模式是不是该换了 用户注册或许不该先抢先得。注册过用户名的人应该都有过这种经历，自己想注册的名字总是被抢了。纽约一家创意机构的产品总监Adam Ghahramani提出了他的修改建议。

　　Twitter、YouTube、Pinterest、Instagram等一大堆数字平台的共同特点是什么？对待用户名的态度就像婴儿对待尿片一样，而不是宝贵的、有利可图的资源。因为采用的是陈旧的先到先得模式，导致大部分的后来者都拿不到心仪的名字，不得不在自己想起的名字前后加上一堆没用意义的文字或符号（比如“boogie2988”、“Rclbeauty101”、“realDonaldTrump”）。

　　先到先得起源于域名注册。因为刚开始的时候申请域名还是一件很麻烦的事情，所以知道怎么申请以及为什么要申请的人理应拿到自己心仪的短域名。不过随着注册域名这件事变得越来越简单以及需求的增长，先到先得的缺陷也语愈发明显，但是想亡羊补牢为时已晚。更糟糕的是在惯性思维的驱动下，早期技术公司的身份系统也采用了域名的这种模式，而后来的公司想都没想也遵循了这种传统。导致现在几乎所有的web服务都严重错配了名字这个关键资产。

　　先到先得错在哪里？

　　先到先得的基本假设是来得早的比来得晚的用户更有价值。这种假设不仅是错的，而且是倒行逆施之举！

　　刚开始在极度渴望拥有首批会员的心情下，你会把最好的用户名以极低的价格提供出去。但要记住的是那时候你的产品还没有成熟，你的用户引导流程还没有经过测试，你的服务还缺少内容和功能。换句话说，你早期的留存率是很糟糕的，所以你的那些好名字有可能是鲜花插在了牛粪上。尽管早期采用者对于你的口碑影响很重要，但这些人来大都只是尝鲜而不是受到名字吸引的，而且可能都抱着玩玩一夜情就走开的心态。

　　放弃先到先得并不容易，占坑的人会恨你，骗子会抛弃你，发垃圾广告的会背叛你，是吧？但其实这是好事。

　　替代方案

　　但怎样用户名系统应该怎么做呢？我先来抛砖引玉一下：

　　· 步骤1：让成员用电子邮件登录，这样来降低用户名的重要性

　　· 步骤2：先从给成员分配三个词组成的用户名开始，比方说我的Pinterest账号可以是这样的：pinterest.com/adam-is-nimble

　　· 步骤3：让成员自己想办法争取把名字缩短成2个词甚至1个词。比方说账号存续时间超过6个月或者pin了5000条之后我可以把自己的名字缩短成pinterest.com/nimble。当然，输入“adam-is-nimble”的链接应该自动会自动重定向。

　　通过这样，你最好的用户将可以拥有最好的名字，而绝大部分只是想玩玩就走或者注册进来只是想发垃圾信息的人在他们制造任何伤害前可能就会放弃了。当然，光这样还是不够的：

　　· 推动参与。LinkedIn会推动成员写文章。如果多写文章可以让我有机会拿到更好的名字的话我会一天写十几篇。

　　· 把服务“游戏化”。这样获得更好用户名的过程会变得很有趣！而有趣可以让你的产品粘性更强。

　　· 改善留存率。如果大家都努力升级自己的名字的话，他们也许就不会轻易离开了，因为那样的损失会很大。

　　· 引起嫉妒和好奇。谁看到另一个成员的名字很短都会很好奇。发生了什么？我的名字怎样才能一样短？

　　此外，执法也会容易很多，因为每天分发的短名字少了很多，监控起来自然也容易得多。那些申请可能会构成侵权的名字的人也会多掂量一下，因为如果遇到麻烦的话自己多年的努力可能就会付诸东流了。

　　在我抛砖引玉之后，果然大家就此话题在Hacker News上面展开了热烈的讨论，我的收获很大，下面我把其中一些很有价值的讨论问答整理出来，供大家参考。

　　把旧用户名回收怎么样？

　　有时候你注册账号纯粹只是为了发个言然后可以去下载附件之后就一去不复返。设计一个算法把落满灰尘的账号回收回来行不行呢？[!--empirenews.page--]

　　实际上去年Tumblr就是这么干的。它给所有活动闲置的账号发了封邮件，给对方两个选择：要么登录，要么去死。如果成员回来报到一下，Tumblr就原谅他们。如果成员无视警告，Tumblr就会让别人占用掉这个名字。你还可以索回自己的数据，只是需要重新注册一个新的名字来托管原来的数据。

　　我不建议Tumblr的这种做法，因为回收的名字并不能给到合适的人手上。假设有一个潜在价值很高的成员叫做“zoebarnes1986”，她本来是取一个更好的名字的，但她能够怎么做呢？每天来回检查10几次看看“zoe”或者“zoebarnes”开头的名字有没有吗？这种机会更有可能被刚注册的新人拿到。而Tumblr也不可能把过期的名字公布出去，因为这会让那些账号成为黑客的目标。

　　而且删除用户名还会带来很多麻烦。旧的书签、、误报、身份困惑以及搜索流量丢失这些仅仅是其中的部分挑战。

　　如果你想让旧名字回收利用，不妨采取GitHub的做法。GitHub不会像个疯子一样发放名字，而是允许它的成员申请闲置的名字。客服人员会审查申请，跟成员进行沟通，如果账号的确是闲置的话，就让申请者使用那个名字。你最有价值的成员一定会喜欢自己被当成人来看待的。

　　暴雪公司的身份系统如何？

　　魔兽争霸的东家暴雪娱乐的门户Battle.net采用了一套独特的系统。其机制是这样的。

　　任何人都可以注册任何名字。上面叫Jane的人可以有4000个。

　　关键是每一个Jane都会分配一个四位数字。所以URL看起来会像下面这样：

　　…/profile/Jane-1829/

　　…/profile/Jane-2313/

　　…/profile/Jane-4215/

　　…/profile/Jane-2919/

　　4位数可以有1万种排列。如果有超过1万人都想起名Jane也没关系，暴雪在后面加多一个数字就行了，问题不大。

　　暴雪的系统非常公平。URL也挺不错，因为只需一个词加上4位数要好过15位的数字ID。

　　这套系统对暴雪来说是OK的，因为没人会把自己的游戏ID放到名片或者电视广告上。

　　我喜欢这套系统，因为它有效解决了上亿用户的命名问题。每个人都能得到一个普通的URL，让大家可以通过其他手段突出自己。如果你不指望卡戴珊之类的人加入你的服务的话，可以用这种机制。

　　另外说一下，暴雪的机制非常公平，但还不是绝对公平。因为随机数字可能会带来意想不到的后果。比方说拿到“4444”的人可能会非常恼火，而拿到“8888”的也许会欣喜若狂。

　　SoundCloud的怎样？

　　SoundCloud的用户名系统解决了注册过程当中的一个痛点。虽然它还是先到先得的机制，但花了些心思。

　　设想你正在煎蛋一边想着要加入SoundCloud的一个竞争对手。你点击了注册页面，输入用户，然后点“走你！”

　　你请求的用户已被使用。请再试一次。

　　（⊙o⊙）…你开始第二次尝试。

　　你请求的用户已被使用。请再试一次。

　　你看了看，煎锅上面已经升腾起太多的烟了。你退出了网站继续做你的早餐。

　　第二天你决定加入SoundCloud。这次你煎的是培根。

　　你输入邮件地址和密码。

　　“呃？注册就完成了吗？可是我的用户名呢？”你问道。

　　啊哈！你意识到自己被随机分配了一个！这个名字起得不好，不过你可以在以后再改。现在，你要弄培根了。

　　这套系统让注册过程很流畅，并且让不可靠的成员拿不到好名字，因为那些人基本上也懒得折腾默认的设置。我唯一要发的小牢骚是SoundCloud让升级太容易了，有此特权的人应该要付出血和泪的代价才对！

　　我试过把我的iPhone游戏的Facebook用户名改过来……结果是这样的！

　　看吧，最糟糕的“恭喜！你的用户名可以用”提示出现了。机场的安全标志看起来都没有那么不吉利。

　　这让我想起一位被抢劫过多次的熟食店老板。店内到处挂着“不许入店打劫！”的纸板，墙上还斜靠着一杆来复枪。坏人不会被这些玩意儿吓到，但是客户却会感到不舒服的。[!--empirenews.page--]

　　得用聪明的设计来修复你的用户名系统，而不是带威胁性的废话和感叹号。

　　另一个想法：URL区

　　一位要求匿名的读者提出了URL区的想法。

　　任何人都可以注册任何名字，但是注册的办法不是像暴雪的Jane-2381那种做法，而是分配一个字典友好的URL区。档案链接看起来应该是这样的：

　　www.myservice.com/saturn/Jane

　　www.myservice.com/mars/Jane

　　www.myservice.com/jupiter/Jane

　　你可以利用这些URL区来区分用户类型。比方说公司可以到这儿：

　　www.myservice.com/business/IBM

　　www.myservice.com/business/Microsoft

　　客户支持代理可以是这样：

　　www.myservice.com/staff/Adam

　　www.myservice.com/staff/Nimble

　　有朝一日最好的用户可能可以拿到根权限：

　　www.myservice.com/Mo

　　总结

　　最后我们概括一下上面讨论的要点。

　　· 注册时不要用户域，像SoundCloud那样

　　· 先给用户分配一个无趣的ID数字，还是像SoundCloud那样

　　· 在到达移动里程碑之后，让大家可以升级自己的ID数字为用户名，可以用URL区的方式或者像暴雪那样后缀加4位数字

　　· 在到达更大的里程碑之后，让大家升级到更厉害的账号名（没有数字或者不分区）

　　· 像GitHub那样建立一套基于申请的回收系统以便不浪费

　　· 可能可以给商家单独建一个注册层，视服务性质而定

　　上述做法值得一试！