前言

從0到1搭建一個產品，就應該從最基本的一個用戶賬號開始說起。雖然一個注冊登錄到整個賬號體系看起來很簡單，也是每個應用需要做的東西，然而對于一個產品經理而言，想要設計好并不容易。從不同的業務場景出發，不同的產品會產生一樣的業務需求。一個簡單的企業OA系統可能只需要簡單的后臺賬號權限即可，而往往To C的賬號設計具有很大的差異性，往往不同的。

如何從一個產品經理的角度去探索一個賬號體系的搭建？首先要抓住賬號體系的本質。

賬號就是一個個數據ID

不論產品屬于哪種類型的哪個行業，每個用戶在產品上注冊了一個賬號都是一個數據ID。我常常和朋友說，在現實生活中每個人都是有血有肉的，但是在互聯網上，每個人都只是一堆冰冷的數據而已。

如何把抖音點贊的行為、評論區里的留言、用戶現實的地理位置進行分析的前提是需要大數據，而落地則是需要能夠把數據串聯起來的賬號體系。而UID（User ID）就是那個關鍵且必不可少的一環，通過UID（User ID）可以將相關數據堆疊起來，通過數據模型挖掘用戶的喜惡。這也是為什么微信會推出微信開放平臺，讓基于微信的應用能夠打通用戶信息。

透過業務本質看字段可變性

一般情況下，一個產品的賬號體系包含的字段有：

UID

賬號

登錄號（郵箱、手機號、微信等第三方平臺openID）

賬號名

昵稱

UID

一般一個用戶在創建賬號的同時會生成一個UID，一般對用戶是不可見的，也是不可變的。當然也有一些產品會直接把UID當成賬號使用，但是并不建議這樣使用。

賬號

為什么用賬號而不用UID，一般后端會直接采用升序的方式創建UID，而這樣會讓競品估計出用戶數，于是采用賬號來避免。早期互聯網產品，一般是賬號等于登錄號，一般不可變或者限制變更次數。

早期，在UID生成的同時，也會同時生成一個賬號，比如早期的QQ就是這樣的做法。但是這樣做，就必然需要在系統層面保證號碼的唯一性，還有需要用戶記住賬號。基于這樣的業務，也導致QQ號碼是不能夠變更的。

再后來為了用戶之間更容易記住對方的信息的泛社交軟件，郵箱、新浪微博在創建的時候必須先設置賬號，驗證唯一性且不可更改。一般這個賬號比較容易記憶。

而如今，很多App應用都為了提高用戶體驗，直接采用手機加動態碼登錄的快方式來提高用戶的轉化率，在創建賬號之后隨機生成賬號僅僅作為賬號的標識。這樣的操作，讓用戶更容易記住登錄號。但是這樣的方式，也就使得我們在應用中登錄注冊的業務邏輯發生了比較大的變動，具體在后面的章節會講到。

賬號名

目前，事實上查了很久，大多數人說的賬號名，大多數起到的功能和賬號是相同的。比如京東的賬號名，微信的微信號都是起到標識用戶的作用，并沒有特別的含義。一般而言，這樣的編號是不可變的。比如京東賬號名即不可變。

登錄號

隨著各大平臺，新浪微博、支付寶、微信、QQ等第三方平臺都開放了openID為提供聯合登錄。

如今，登錄已經變得非常便捷，登錄的方式也變得多種多樣。基本上登錄號都是可以變更的。然而，也產生了一系列的問題，比如如何解決手機變更未及時解綁問題、如何手機動態碼登錄如何判定用戶是否為持賬號用戶等問題。后續，文章再專門針對該問題進行詳細解說。

昵稱

昵稱，這個設計一般需要看業務的需求。

強社交軟件，一般是在用戶的朋友圈子內，用戶之間互動一般頻繁，對于昵稱的變化事實上并不會有太大的反應。所以，一般在強社交軟件里面昵稱都是可以被修改的。比如微信、QQ的昵稱都是隨意改動的，并不需要具有唯一性。

而相比而言，泛社交軟件的業務一般基于，用戶關注、互動性相對而言比較小。如果用戶頻繁修改昵稱，可能會導致關注者的混亂，基于這些原因，泛社交應用一般需要限制用戶修改昵稱的次數并且需要昵稱具有唯一性，比如新浪微博。

即使是做電商的京東，在留言區也是類似于泛社交的應用，在用戶昵稱的唯一性上也是做了限制。

當然舉個反例，在作為知識付費的得到App，在業務場景上，我個人覺得更適合于運營起線上社區，然后醞釀出一群社區知識大咖來增加用戶的黏度。所以泛社交特性應該在得到App上更加注意。結果，當我在2018年7月24日測試的時候，發現得到并沒有對昵稱進行限制唯一性。也就意味著，另一個人完全可以復制另一個大V的賬號昵稱和頭像進行留言，后果可以想象。同樣，在抖音上也可以這樣做。抖音上假的大V就是一個結果。

后話

賬號體系的設計，對每個參數的限制會延伸到登錄注冊的整個邏輯線設計。需要產品經理們對產品的定位和業務認真的思考。從產品從0到1的時候做好規劃。

當然，也不是賬號體系設計的越復雜越好，開發和完美總是要二選一不是嗎？