從0到1的團隊搭建-tft每日頭條

不論産品屬于哪種類型的哪個行業，每個用戶在産品上注冊了一個賬号都是一個數據ID。那要如何從一個産品經理的角度，去探索一個賬号體系的搭建？

從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的時候做好規劃。

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

本文由 @UShow Jack 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議
,