起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識構建賬戶體系實戰篇：賬戶體系該如何構建？
經常有新人剛進公司，看注冊登錄頁面不爽，改！改的不止是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協議
帳號體系和賬戶體系完全兩個概念
樓主真的應該考慮清楚標題和正文的匹配程度，你這說是賬號體系的搭建，和賬戶無關嘛。
深表贊同，寫文章分不清賬戶和帳戶的區別。。。。
如果我用微信登錄完后，重新更改手機號，然后是否就登錄到了新手機號對應的賬號了
已關注二爺，不管別人怎么說，我還是從這學習了
這里如果加上第三方賬號非強制綁定手機號 和解綁手機號流程就更好了
十二這個名字我很欣賞，文章里寫的實戰技巧也很全面，看了2遍，收益匪淺，也看得出來，作者是自己做過的，而且是偏前端的頁面流。
作為一篇賬號體系介紹的文章，這個體系介紹的不大好，但是實踐的內容是非常豐富的。謝謝二爺的分享
兄臺，我想認識你哈哈
1，確實是公司業務發展，需要把下面的子平臺賬號做個統一，剛搞完，有的平臺業務需求強制綁定手機號，有的則不，在第三方那里梳理確實有點麻煩，所以發表點感想出來，寫的不好請多多見諒
2，確實沒寫好，觀點不成熟，這個真抱歉實在不好意思
3，我雖然推崇手機號 驗證碼，但是有人想做強制綁定的時候，我是拿那位程序員給我的建議反回去，我們平臺沒那么大咖哈哈
4，手機號確實是很重要的數據對于公司，我們銷售部要數據做產品推廣，我拿出來都不好意思～哈哈哈
5，謝謝你
請出來解釋下什么叫做賬戶體系，你覺得賬戶體系就僅僅是你所謂的注冊和登錄就完事了？
取其精華就好，作者也是普通的產品人，不要吹毛求疵，請提具體的解決方案。有本事說說你的理解
這寫的都是啥??？ 我是瞧著賬戶體系進來的！結果，連賬戶體系的概念都沒解釋清楚！
看著就欠抽
建議標題不要叫賬戶，容易讓人理解成為結算財務方面的賬戶，叫賬號體系會合適一點。
同意同意
實在是憋不住想說幾句了！為了發表個評論，我居然填寫了手機號注冊了個帳號！?。τ谖闹姓f的“郵箱注冊也逐漸淘汰”，我表示不同意。這種注冊方式的興起始于移動互聯網時代，在手機人手一個的時代，這樣做確實簡單粗暴，一個短信驗證碼就能搞定了。但是我想說：1.郵箱的注冊門檻遠比手機低。還是有很多人沒有手機的！比如未成年人。2.現在中國的中流砥柱們大多都是在城市化造成的“遷徙”過程中頻繁的更換手機號。你知道像你這類的以手機號為中心的思路設計出來的網站坑了多少人嗎？想想由于歸屬地造成的每到一個地方就得換一個手機號和一堆銀行卡的痛苦就知道了。如果都按這個思路去設計，到時候換手機號的時候更換帳號綁定的手機號會想死的！3.并不是所有用戶接觸網絡都是從移動互聯網時代開始的！這種以移動端為中心的思維方式，最好不要強加給所有用戶。讓用戶自己去選擇注冊方式更加合理。至少，我可以說，在網絡上，我可以沒有手機號，但是不能沒有郵箱。每當我遇到只能用手機號去注冊的網站，我大部分情況下都會選擇放棄注冊。對于這種將來換了手機號之后可能會遺失無法統一管理的帳號，注冊了和沒注冊幾乎沒區別。4.人人都是產品經理這個網站是我剛剛注冊的，看到注冊時只能填寫手機號注冊，本來我是拒絕的。但是看到這篇文章實在忍不住想說幾句，所以就注冊了。之后這個帳號不一定會繼續使用。畢竟是以當前手機號為用戶名的”臨時“帳號。我有不止一個手機號，3年內換了5個手機號了。 ?? 這是作為一名程序猿的個人觀點，不吐不快！
十分強硬的贊同@bug輝的觀點，對于小編的理解，不能說全部對，就手機號這一點我只能呵呵，使用手機號注冊純粹是欺騙和誘導用戶的一種不負責的行為，強行獲取用戶隱私數據的同時，還埋下了潛在的信息安全隱患，不知道什么時候，一些垃圾廣告推銷之類的消息莫名其妙的隔三差五的就出現在手機上了，而且手機一丟， 造成的損失將是無可挽回的。賬戶體系的建立是要站在運營者或開發者的角度去考慮，但它有個前提，就是真實的用戶量，并非一推垃圾數據，口口聲站在用戶角度考慮問題，只不過是打著正義的旗幟到處招搖撞騙罷了，偽用戶體驗就是你們這些PM搞出來的。 ??
@零食君@bug輝 手機號注冊是有弊端，從體驗的角度講，便捷性的確是最好的，只有獲取了用戶并創造價值，公司才能生存發展下去，然后再考慮其他的東西。所以沒有哪一個選擇/設計是完美的，只能說這個時候合不合適。所以才會有產品規劃、開發、迭代優化。
手機號+密碼似乎可以解決你 的問題，賬號里加一個更換手機號的管理就可以了。手機號是趨勢，用戶數是產品尤其是初創產品的根。做產品要考慮大部分目標用戶，除非你瞄的就是小眾群體。