从到做产品搭建账号体系

　　不论产品属于哪种类型的哪个行业，每个用户在产品上注册了一个账号都是一个数据ID。那要如何从一个产品经理的角度，去探索一个账号体系的搭建？
　　从0到1搭建一个产品，就应该从最基本的一个用户账号开始说起。虽然一个注册登录到整个账号体系看起来很简单，也是每个应用需要做的东西，然而对于一个产品经理而言，想要设计好并不容易。
　　从不同的业务场景出发，不同的产品会产生一样的业务需求。一个简单的企业OA系统可能只需要简单的后台账号权限即可，而往往ToC的账号设计具有很大的差异性，往往不同的。
　　如何从一个产品经理的角度，去探索一个账号体系的搭建？
　　首先要抓住账号体系的本质。
　　一、账号就是一个个数据ID
　　不论产品属于哪种类型的哪个行业，每个用户在产品上注册了一个账号都是一个数据ID。我常常和朋友说，在现实生活中每个人都是有血有肉的，但是在互联网上，每个人都只是一堆冰冷的数据而已。
　　如何把抖音点赞的行为、评论区里的留言、用户现实的地理位置，进行分析的前提是需要大数据，而落地则是需要能够把数据串联起来的账号体系，而UID（UserID）就是那个关键且必不可少的一环。
　　通过UID（UserID）可以将相关数据堆叠起来，通过数据模型挖掘用户的喜恶。这也是为什么微信会推出微信开放平台，让基于微信的应用能够打通用户信息。
　　二、透过业务本质看字段可变性
　　一般情况下，一个产品的账号体系包含的字段有：
　　UID；
　　账号；
　　登录号（邮箱、手机号、微信等第三方平台openID）；
　　账号名；
　　昵称。
　　UID
　　一般一个用户在创建账号的同时会生成一个UID，一般对用户是不可见的，也是不可变的。当然也有一些产品会直接把UID当成账号使用，但是并不建议这样使用。
　　账号
　　为什么用账号而不用UID，一般后端会直接采用升序的方式创建UID，而这样会让竞品估计出用户数，于是采用账号来避免。早期互联网产品，一般是账号等于登录号，一般不可变或者限制变更次数。
　　早期，在UID生成的同时，也会同时生成一个账号，比如：早期的QQ就是这样的做法。但是这样做，就必然需要在系统层面保证号码的唯一性，还有需要用户记住账号。基于这样的业务，也导致QQ号码是不能够变更的。
　　再后来为了用户之间更容易记住对方的信息的泛社交软件，邮箱、新浪微博在创建的时候必须先设置账号，验证唯一性且不可更改。一般这个账号比较容易记忆。
　　而如今，很多App应用都为了提高用户体验，直接采用手机加动态码登录的快方式来提高用户的转化率，在创建账号之后随机生成账号仅仅作为账号的标识。这样的操作，让用户更容易记住登录号。
　　但是这样的方式，也就使得我们在应用中登录注册的业务逻辑发生了比较大的变动，具体在后面的章节会讲到。
　　账号名
　　目前，事实上查了很久，大多数人说的账号名，大多数起到的功能和账号是相同的。比如：京东的账号名，微信的微信号都是起到标识用户的作用，并没有特别的含义。一般而言，这样的编号是不可变的，比如京东账号名即不可变。
　　三、登录号
　　随着各大平台，新浪微博、支付宝、微信、QQ等第三方平台都开放了openID为提供联合登录。
　　如今，登录已经变得非常便捷，登录的方式也变得多种多样，基本上登录号都是可以变更的。然而，也产生了一系列的问题，比如：如何解决手机变更未及时解绑问题，如何手机动态码登录如何判定用户是否为持账号用户等问题。后续，文章再专门针对该问题进行详细解说。
　　四、昵称
　　昵称，这个设计一般需要看业务的需求。
　　强社交软件，一般是在用户的朋友圈子内，用户之间互动一般频繁，对于昵称的变化事实上并不会有太大的反应。所以，一般在强社交软件里面昵称都是可以被修改的。比如：微信、QQ的昵称都是随意改动的，并不需要具有唯一性。
　　而相比而言，泛社交软件的业务一般基于，用户关注、互动性相对而言比较小。如果用户频繁修改昵称，可能会导致关注者的混乱，基于这些原因，泛社交应用一般需要限制用户修改昵称的次数并且需要昵称具有唯一性，比如：新浪微博。
　　即使是做电商的京东，在留言区也是类似于泛社交的应用，在用户昵称的唯一性上也是做了限制。
　　当然举个反例，在作为知识付费的得到App，在业务场景上，我个人觉得更适合于运营起线上社区，然后酝酿出一群社区知识大咖来增加用户的黏度，所以泛社交特性应该在得到App上更加注意。
　　结果，当我在2018年7月24日测试的时候，发现得到并没有对昵称进行限制唯一性。也就意味着，另一个人完全可以复制另一个大V的账号昵称和头像进行留言，后果可以想象。
　　同样，在抖音上也可以这样做，抖音上假的大V就是一个结果。
　　五、后话
　　账号体系的设计，对每个参数的限制会延伸到登录注册的整个逻辑线设计，需要产品经理们对产品的定位和业务认真的思考，从产品从0到1的时候做好规划。
　　当然，也不是账号体系设计的越复杂越好，开发和完美总是要二选一不是吗？