經常有新人剛進公司，看注冊登錄頁面不爽，改！改的不止是UI/UX，而是信息架構。雖然這塊功能模塊頁面不多，但沒考慮清楚把整個賬戶體系搞混了，造成不可回轉的大坑，運營馬上提著刀殺過來。

賬戶體系基本常識

賬戶是所有機構/平臺必須具備的基礎配置。不專指互聯網領域，例如你在屈臣氏辦了會員，提供手機號就能積累積分，積分達到多少報手機就能享受優惠，說明你在屈臣氏開了戶，手機號是開戶賬號，存在于屈臣氏的用戶數據中。簡單來說，賬戶是開戶的憑證，包含賬號名和密碼，意味著你成為他們的用戶，同時你也具備某方面的通行資格。

用戶賬號（User Account）：用戶注冊完成生成的通行證賬號，在系統中的屬性是唯一的，僅對用戶個人可見，他人不可見。

賬號名生成途徑：

• 系統自動配置，例如QQ號
• 用戶注冊時填寫的昵稱/手機號為首次賬號名。由于屬性關系，如需更改，建議加上次數限制，而且具有覆蓋性
• 用戶注冊之后自行設置，例如微信號，必須做同名判斷

用戶身份（user ID）：系統自行配置,一般是一串數字，根據用戶注冊時間排列，該ID不對用戶可見，為后臺管理用戶的唯一標識，不可更改。

開放賬戶（open ID）:?借助第三方網站url驗證用戶身份，當用戶第三方授權登錄成功，系統通過獲取用戶的open ID生成user ID,同時也讀取用戶在第三方網站的身份昵稱以及頭像，該昵稱可作為首次的賬號名。

open ID的獲取分為靜默和用戶授權。

例子：

投票活動，不需用戶授權登錄或關注公眾號，但需做投票次數限制，一個ID只能投一次等，如何限制呢？靜默獲取用戶open ID作為身份識別再行限制，弊端是只能在QQ，微信等第三方才能獲取。如用戶跑到瀏覽器投票？賦予用戶唯一碼，除非清理緩存，否則也可跟蹤。為何不限制IP？假如局域網內的IP是固定的，將導致你投了票，全公司都不能幫你投。

如何構建賬戶體系

注冊登錄設計進化流分析

早期注冊頁面繁瑣，需收集用戶的年齡性別等，則在用戶注冊時要求填寫，操作冗長，后期弱化為只需填寫賬號名/昵稱+密碼。而對手機號收集需求沒有那么強硬，個人資料頁綁定即可。

如后期需用戶綁定手機或郵箱，則新增引導活動/功能/優惠等，成本極高，周期較長。使用賬號名/昵稱+密碼登錄在場景中，容易遺忘，導致用戶使用周期短，除非是高黏度產品。

再者，用戶昵稱如賦予可登錄功能，輸入時必須做同名判斷，否則導致登錄賬戶無法識別，一般不建議！

隨著手機/郵箱收集需求的強化，手機/郵箱+密碼+昵稱注冊方式逐為趨勢。并不是競品或者趨勢如何，產品就怎么做，這個方式也有漏洞。例如電商，有新人領取優惠，不需驗證的注冊方式，遇到薅羊毛團伙就危險；但對于資訊類產品，互聯網的上半場，要的就是這些用戶數據，不需驗證，方便刷量。

注冊項能否去除密碼設置？手機+驗證碼+密碼（或不用密碼）+昵稱（或不用昵稱）注冊方式為目前普遍做法，細心留意，難以找到輸入賬號名注冊的產品，并且郵箱注冊也逐漸淘汰。

上圖為“在行”“美團”“華爾街見聞”的注冊頁面，均有密碼項。

手機號+驗證碼登錄，確實對于用戶較為方便。如去除密碼，只留下手機+驗證碼，當用戶手機丟失或更換，不在身邊時，則登錄不了。

微信在用戶退出時做了密碼設置提醒。密碼設置最好的時間段是在注冊時，如后期再做提醒，除非是高黏度產品，否則執行概率有點懸。如需增加密碼設置或者必須使用密碼登錄，則不能缺少注冊環節。

注冊環節能否省略？

上圖為“UC頭條”“唱吧”“魔力盒”的登錄頁面。

不需注冊，直接登錄，必須具備的條件如下：

• 有一項具備唯一屬性的信息作為識別用戶的身份憑證
• 該信息能夠被用戶長期記憶并且方便使用
• 注冊才能生成的信息項不作為唯一的登錄條件，例如密碼

而“UC頭條”“唱吧”“魔力盒”識別用戶身份的憑證是手機號/第三方的open ID。

手機號+驗證碼登錄的優點

例子：

報名活動，用戶填寫信息有手機號，沒有驗證碼，產品詢問該報名用戶需不需要加入賬戶系統，如需要，賬戶系統則加入這批數據，手機號作為登錄賬號。需要注意，僅是作為協辦方的商務活動，用戶不知其平臺，某天在平臺注冊時提示“該手機號已是賬號”等文案，必然一臉蒙圈，所以除非是充數據，否則不建議加入。

技術做法：將這批用戶鎖定，雖然存在于我們的賬戶系統，但注冊時沒有判斷限制。當用戶量大到一定程度，并且賬戶體系需調整，就尷尬了，刪也不是，不刪又不好處理。

產品做法：增加手機+驗證碼登錄入口。登錄成功，新用戶自行創建賬號，舊用戶直接登錄即可。

為什么市面很多產品依然保留“賬號/郵箱+密碼”的登錄方式？

產品早期已聚集很多用戶，并且注冊使用賬號/郵箱，然而該產品沒有綁定手機號的強硬需求，所以只能保留該登錄項。后期可根據綁定用戶占有比等數據判斷，再行決定是否去除賬號/郵箱+密碼登錄方式，切勿一刀切！

注冊登錄設計安全做法

上圖為喜馬拉雅FM的注冊登錄界面。

登錄項有賬號密碼/手機免密/第三方賬號，既方便新用戶也照顧老用戶以及丟失手機只能使用密碼登錄的用戶。

注冊項有手機+驗證碼+設置密碼，至于昵稱要不要？社交產品中昵稱是對外展示的馬甲，注冊時沒有填寫，則默認手機號為首次的昵稱，或者系統為新用戶統一配置默認昵稱+編號區分。

運營問過我為什么注冊成功后昵稱是手機號，好奇怪，我說可以去資料頁更改的，她還是覺得很奇怪，然而可能有些人又覺得注冊時候不要用戶填寫那么多信息。至于要或不要，建議產品下決定前多考慮，有條件做個A/B測試，沒條件可以選一項先行，埋點根據數據分析，再做決定。

例如先收回去，根據用戶后期更改昵稱頻率以及注冊成功至更改昵稱的時長等，判斷用戶對更改昵稱的需求迫切度，達到某一峰值，則放在注冊時填寫。

放出來之后追蹤用戶在設置昵稱頁面的跳出率高不高，如果很高，但又不想影響用戶注冊轉化率，可增加跳過按鈕填。用戶設置密碼成功點擊下一步操作按鈕時，賬號已經生成了。

設置昵稱功能之所以啰嗦那么久，是因為產品工作溝通中，矛盾點往往是小分歧~

手機注冊流程設計

輸入手機號完成，下一步操作是獲取驗證碼，點擊獲取時觸發判斷。切勿在最后提交注冊時判斷，否則既讓用戶做無用功，又產生無意義的信息費用。又啰嗦了，因為發現新人的需求文檔中，基本缺少判斷邏輯的觸發機制描述。

第三方賬號登錄邏輯

第三方授權存在X個，同一人在平臺中存在多個賬號概率極高。例如你的微信賬號有10元，QQ賬號0元，某天登記QQ賬號記憶混亂以為錢沒有了，是BUG！

強制綁定手機號產品，第三方授權登錄后如需綁定手機號，前提為該第三方之前不存在賬號。

例子：

使用微信授權登錄，點擊微信a登錄后彈出綁定手機號頁面，輸入手機號A，獲取驗證碼時進行判斷，如該手機號A不存在賬號，則登錄成功關聯手機號并創建user ID。然而下次QQ登錄，綁定手機號A,判斷該手機號A已存在賬號，但是沒有綁定過QQ，直接登錄至手機號生成的賬號，這種做法能夠保證一個用戶使用X個第三方賬號登錄進入的是同個賬戶。更換另一個微信b登錄綁定，則判斷手機號A已經綁定過微信a，如繼續綁定，則微信a與手機號解綁，微信b綁定并登錄至手機號生成的賬號。

可以得出，微信a已沒有綁定任何手機號，下次使用微信a登錄，綁定手機號B，生成的是新賬號。也就是說user ID的建立判斷是以手機號作為憑證而非open ID，使用第三方授權登錄，綁定不成功后退出，賬戶創建不成功。

選擇綁定手機號為什么不需判斷“是否被同類第三方綁定”？綁定之前，第三方賬號已經存在，所以必須從賬號的概念上思考。

• 情況一：因為賬號不能綁定賬號，所以只需判斷手機號是否存在賬號，如果存在，則提示可以直接登錄，點擊跳至登錄頁；如不存在，則綁定成功并關聯手機號，手機號作為該賬號的憑證，可作為賬號登錄
• 情況二：綁定的手機號不作用于賬戶體系，只是輔助功能，例如密保手機，該手機號可以被N多賬號綁定，不作為賬號登錄，所以不需任何判斷

第三方授權登錄能否去除？對于強制綁定手機號登錄的產品，第三方授權登錄確實是沒必要。但是對于選擇綁定手機號產品而言，可以先埋點，統計用戶使用何種第三方登錄或者不使用的概率再做決定。

具體考慮如下：

• 版本兼容，非熱更新產品用戶依然使用第三方賬號登錄產生何種后果
• 后期換新產品經理，理念是多個入口多個選擇又要加上，可能需重新集成，耗時不少
• 多平臺賬戶系統打通，便于業務交叉導流，A平臺強制綁定手機，B平臺選擇綁定手機，去除將導致B平臺用戶無法登錄A平臺

能否強制綁定手機號將平臺所有第三方賬號合并？

例子：

使用微信/微博/QQ/手機號各生成一個賬號于某平臺，某天用戶反饋，能不能把這幾個賬號的余額合并，這樣就夠著可提現金額，產品拔起刀，老子怎么知道哪個微信號和哪個QQ號是同個人？

同平臺賬號合并，不是隨便通過強制綁定手機號內容整合那么簡單，因為每個賬號都存在各自的行為數據。

• 合并之后，賬號名/昵稱以哪個號為主?
• 訂單，消息，生產內容等整合后的結果是否有坑？會不會出現用戶綁定個手機號，以前不堪入目小號發的內容全都跑進來，導致大號人設崩塌
• 涉及到用戶成長體系，微信號是VIP會員,QQ號是普通會員，合并之后以哪個為主？會不會出現對用戶而言，老子兩個號都差一點能兌換兩臺手機，突然被迫只能兌一臺

當然從平臺角色考慮，合并賬號對于用戶數據以及相關內容信息管理等方面有一定的好處，前提是平臺夠牛，怎么整用戶都整不走，用戶沒意見運營也要殺過來，為什么這個月新增用戶數比以往少了三分之一？

除非是業務需求涉及到大量的交易支付需要用到手機號，例如電商，之前網易考拉不限制用戶的手機號，用戶可通過不停注冊新QQ號，再登錄網易考拉成為新人，領取大禮包。之前有個推廣策略是邀請碼，被邀請的用戶要求是新人，邀請成功后才能各自領取大禮包，這個階段相當于充用戶數據，達到一定體量，就以手機號作為賬號創建的唯一憑證，即便如此也不會強迫綁定手機號合并賬號，只是注冊時輸入手機號判斷是否已存在賬號而已。

總結

注冊登錄頁面是賬戶創建的入口，絕對不能站在UI或者體驗的角度考慮產品問題，涉及到用戶數據變更，做的任何決定都必須與運營部門或者相關部門溝通商量以及結果導向說明。

凡事勿跟隨流行趨勢，需結合業務以及產品發展需求，用戶需求等多重方面考慮以及數據分析，否則牽一發動全身，賬戶體系一出問題，后期就要高成本填坑。

本文由 @?十二 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議