當我們需要一個安全的賬戶體系
登陸註冊存在於每個產品中，賬戶的存在是使用者進行訪問、使用、滿足使用者需求的入口。那一個安全的賬戶體系在現在的產品設計中有那些不同的展現方式？
最近我的工作中，在搭建賬戶體系的過程中，我發現一個安全的賬戶體系是需要業務、公司資源、產品階段的交集後的產物。
常見的賬戶設計方式
登陸與註冊，由兩個不同的流程組成，但其核心的是賬戶的設計方式，不同的賬戶設計方式導致在註冊和登陸的不同。雖然設計方式不同，但其不同的方式組成的單元是相同的。
那麼構建一個賬戶的常用單元，或者我們需要考慮的單元由那些？這裡我以腦圖的方式遍歷出來
【賬戶基本單位】
賬戶的組成在產品搭建的時候就會是整個產品的框架，毫不誇張的說賬戶體系的擴充套件性將是一個好的產品關鍵。除了基本的賬戶、密碼、手機號，一個好的賬戶設計會需要結合演算法、產品中的功能模組、產品服務綜合來表達使用者的所有資訊。但是我們往往在工作中，很難面面俱到考慮。因為業務的側重點不同，以後的功能擴充套件情況也無法預知。
那既然這樣，如何把一個好的賬戶體系搭建好？
從最簡單的賬戶基本要素出發
手機號賬戶
只有手機號的賬戶存在弱點和優點是什麼？
優點：
註冊流程短
產品設計落地快
驗證安全
賬戶真實
缺點：
更換手機號後賬戶可能丟失
賬戶安全低
產品關聯性弱
流量接入弱
社交關係建立弱
建議落地場景
產品0-1初期
使用者基數少
產品內容搭建期
產品業務對於賬戶要求低（例如：金融行業賬戶的要求就會比較高）
手機號+密碼
手機號加密碼是一種賬戶註冊最基本的產品設計，考慮移動端產品的發展，如果產品是基於移動端發展起來，那麼手機號註冊會是一種最快速方式。但是當我們例如web端產品在移動端產品中建立新的賬戶體系，那麼郵箱的註冊方式將會繼續保持。
賬戶的擴充套件問題，是賬戶中又需要最為注重考慮的。尤其是是支援新的賬戶擴充套件，或極少碰見的將老賬戶砍掉。我們針對賬戶的“可長可短”，是需要做好一個長期規劃。
那麼手機號+密碼的優點和缺點是什麼呢？
優點：
賬戶可以更換
可以幫助申訴或找回
不用依賴於手機
驗證碼無法接收，照常可以登陸
減少成本
缺點：
引流效果弱
賬戶資訊少
密碼可能需要設定不同強度才可透過
手機號+密碼+基本資訊
這種方式是我們現在存在比較上的賬戶設計，尤其是在現在移動端產品上，很可能移動端產品最為常見的就是剛剛的第二種。那麼在web端產品中，哪個時候使用者建立賬戶，產品經理巴不得希望得到使用者更多的資訊，方便自己去做更好的營銷，但不得不說這種方式可以讓我們更好的理解新使用者。
但這種方式的優點和缺點又如何？
優點：
使用者資訊全
方便產品業務或社交關係推薦
使用者歸屬感強
利於申訴
成本低
缺點
：
流程長
使用者體驗感低
使用者牴觸心裡強
可能產生多餘的資訊
使用者名稱+密碼
這種方式可以說是目前基本看不到了，因為使用者名稱+密碼的方式需要使用者又要記住賬戶，又要記住密碼。並且在申訴的流程中，讓使用者選擇記憶賬戶名稱也是一種不可“預期”的結果。
忘了賬戶，申訴怎麼進行？
優點：
可不用擔心更換手機
告知使用者其賬戶與手機號不是一個概念
使用者對賬戶的信任感強
缺點：
賬戶可能重複
賬戶丟失
第三方關聯弱
使用者聯絡弱
手機號+第三方+密碼
這種方式在第三方產品之外也是非常常見，尤其是流量瓜分的時代，作為一個從0-1的產品特別喜歡能夠將使用者從bat引入到自身的產品中，減少註冊門檻就可以讓使用者體驗其產品無非是最快的一個方式。由此這種方式成了當前主流的一種方式
優點
：
流量引入快
賬戶申訴方便
賬戶不怕更換
安全性高
使用者體驗好
使用者資訊度高
缺點：
使用者可能有多個賬戶
一旦更換第三方，無法找回賬戶
使用者第三方隱私可能會有被呼叫
無法對使用者提供更多有利的價值服務
賬戶的搭建一定要全域性
很多產品同學在做0-1的產品時候就希望產品快速上線，賬戶怎麼簡單怎麼來。但是一旦到後面的申訴、產品業務需要賬戶支援的時候，賬戶卻沒辦法支援。所以我強烈建議如果你正在考慮賬戶搭建，不管再難，根據公司當前業務的發展方向建立起來完全的賬戶體系。
可以分優先順序做先後，但是不能沒有。否則以後就只會等著服務端同學拼命的改著來著客服的需求，說“ xx客戶找不到密碼了”，瘋狂的直接改code 。
