干貨分享!最全 “用戶賬號” 設計分享
編輯導語:用戶賬號要如何設計?賬號的構架是什么?本篇文章中,作者列出了用戶賬號構架的詳解,分析了用戶賬號建設的幾個階段,推薦想要學習如何構建用戶賬號的群體閱讀。
一、背景
用戶賬號(指的C端賬號,分享也是基于此)其實是一個不那么新奇的功能,一直在隨著互聯網的變遷而變化;用戶賬號是一個比較底層比較核心的模塊,在企業不斷擴張以及業務不斷增加的情況下,怎么做好一個 “體驗好”,“安全性強”,“易對接” 的賬號中臺其實是不容易的,接下來就給大家分享一些實戰中的一些總結!
二、賬號的架構
經過一些實戰中的積累,總結了一個賬號產品的架構分享給大家,接下來分按照不同的模塊進行詳細的說明:(文章中任何的圖片不得在本人沒有授權的情況下,隨意轉載)
三、用戶賬號架構詳解
1. 賬號的功能模塊
(1)登錄/注冊方式說明
目前大多數的登錄邏輯里面是包含了注冊的,也就是說用戶登錄如果沒有注冊就默認幫助用戶注冊并登錄成功,這樣體驗會更好,如下流程:
第一種,用戶名+密碼 注冊:
注冊方式:用戶自己輸入符合平臺規則的用戶名+密碼即可注冊。
優缺點:目前大部分的平臺已經不使用這種方式了,因為這種安全性不高且與用戶的關聯性不大。
適用場景:有些場景用戶沒有手機號或第三方的賬號就只能用這種形式了,例如:如果你的產品用戶是小學生,沒有手機也沒有手機號只能使用這種注冊方式了。
第二種,手機號+短信驗證碼 注冊:
注冊方式:用戶自己輸入手機號,平臺將發送驗證碼給到用戶,用戶填寫正確的驗證碼后即注冊成功。
優點:適用面廣,用戶接受程度高,注冊較簡單,安全性高,可觸達用戶。
缺點:短信容易收不到(可以通過手機號+語音驗證碼解決),填寫短信驗證碼的時候有一些麻煩(Android系統可以通過獲取短信內容自動填充來優化體驗)。
適用場景:APP,H5,web,小程序,電腦客戶端都適用。
是否需要第三方服務:需要短信服務商。
第三種,手機號+語音驗證碼 注冊:
注冊方式:用戶輸入自己的手機號,平臺將給到用戶打語音電話并告訴用戶驗證碼,用戶填寫正確的驗證碼后即注冊成功。
優點:用戶可以在收不到短信驗證碼的時候,可以通過語音驗證碼來收。
缺點:第三方語音驗證碼服務比較貴,成本比較高。
適用場景:在收不到短信驗證碼的場景下可以使用(一定要控制在用戶第一次點擊短信驗證碼,且沒有輸入驗證碼的情況下,再展示語音驗證碼,來控制成本)。
是否需要第三方服務:需要,語音驗證碼服務商。
第四種,第三方賬號(微信,QQ,支付寶) 注冊:
注冊方式:用戶授權平臺可以獲取用戶的 userID,頭像,昵稱等信息即注冊成功。
優點:用戶注冊登錄簡單,用戶接受度廣。
缺點:沒有觸達的方式不方便后期的運營,容易出現同一個用戶存在多個賬號,因為有可能用戶選擇用不同的第三方賬號分別去登陸。
適用場景:純工具類,或者社區類的產品可以使用這種注冊方式,以及產品業務比較早期的階段,為了讓用戶盡快體驗到產品的核心價值。
是否需要第三方服務:第三方授權用戶信息的接口。
第五種,第三方賬號+手機號 注冊:
注冊方式:用戶向平臺授權個人信息后,還需要填寫手機號+驗證碼才能注冊。
優點:用戶接受度廣,有了用戶的手機號不存在多賬號,后期的運營可以觸達到用戶。
缺點:首次注冊時,需要授權還需要填寫手機號。
適用場景:適用大多數的業務場景,有一些產品早期會將綁定手機號的操作放在用戶進行某項核心操作前例如下單前,發布作品前等。
是否需要第三方服務:第三方授權用戶信息的接口,短信驗證碼服務。
第六種,手機號一鍵登錄 注冊:
注冊方式:用戶向平臺授權本機的手機號,授權同意后即注冊成功。
優點:用戶注冊登錄簡單,用戶接受度廣。
缺點:有少數場景用戶選擇非本機號,所以要結合用戶手動輸入手機號一起使用。
適用場景:適用大多數的業務場景。
是否需要第三方服務:運營商獲取本機手機號SDK
第七種,郵箱+驗證碼(手機號+驗證+密碼),注冊:
注冊方式:用戶輸入郵箱+驗證+密碼即可注冊成功
優點:國外比較常見的注冊方式,國內用戶使用場景比較少
缺點:注冊比較繁瑣。
適用場景:做海外市場比較常見
是否需要第三方服務:第三方郵件服務
有一些其他的密碼登錄的方式,適用于手機不在身邊或沒有手機的用戶使用:
- 手機號+密碼 登錄
- 郵箱+密碼 登錄
- 用戶名+密碼 登錄
(2)修改密碼
第一步,手機號+驗證碼+新密碼:
修改方式:當用戶驗證碼注冊時填寫的手機號或者用戶賬號綁定的手機號,即可修改為新的密碼
第二步,郵箱+驗證碼+新密碼:
修改方式:當用戶驗證碼注冊時填寫的郵箱或者用戶賬號綁定的郵箱,即可修改為新的密碼
第三步,舊密碼+新密碼:
修改方式:當用戶填寫的舊密碼與用戶設置的密碼一致時,即可修改為新的密碼
(3)個人中心
個人中心本質:就是用戶身份信息的管理,以及一個小型的用戶畫像,既可以為業務提供通用的用戶數據,也可以為用戶畫像的基礎數據。
個人中心數據來源:一部分讓用戶自行填寫,例如用戶注冊完成后讓用戶選擇或者填寫一些數據;另一部部分是對用戶登錄數據或者操作數據的一些收集。
- 用戶名:用戶自己手動設置;
- 密碼:用戶自己手動設置;
- 用戶昵稱:系統幫助自動生成,然后只允許用戶修改一次且不能重復;
- 用戶ID:一般是純數字,作為用戶身份的標識。(這里面稍不注意會有很多安全性的問題,一會兒在賬號安全重點說);
- 性別:用戶手動選;
- 簽名:用戶自己輸入;
- 手機號的綁定與解綁;
- 郵箱的綁定與解綁;
- 第三方賬號的綁定與解綁;
- 頭像:系統幫助自動生成,然后只允許用戶修改;
- 國籍:注冊時選,或者用戶手動添加;
- 職業:注冊時選,或者用戶手動添加;
- 常用地址:定位獲取,或者用戶手動輸入(比方說用戶如果在下單中有填寫最好幫用戶存下來,方便其他的模塊使用);
- 用戶出生日期:用戶自己填寫;
- 用戶登錄日志:幫助用戶記錄;
- 歷史設備:幫助用戶記錄;
(4)賬號的注銷
? ? ??對于注銷這個功能是不得不提供的一個功能,目前很多應用市場上架前對應用進行審核時如果發現這個應用沒有注銷的功能,可能會不讓上架
? ? ??用戶提交注銷前一定要對用戶的身份進行校驗,第一個防止非本人操作,第二個系統層面會更加安全
? ? ? 用戶提交注銷后一定要預留一個用戶反悔的時間,一般是半個月或者一個月,因為注銷用戶對企業本身來說是一種損失,我們也需要盡力服務好用戶減少這種流失
2. 提供對外接入的方式
(1)提供對外接入方式時95%以上提供統一頁面(頁面需要做的靈活已配置),因為方便管理并且可以大大的增加效率;如果提供過多的API出去后期想優化一些有關頁面的需求時,一方面:推動溝通的成本非非常高,另一方面:不是所有的團隊都有那么多資源可以及時配合你去做技術修改的;例如:公司周年慶需要改登錄頁的風格以及畫面,如果提供的統一的頁面,只需要你自己修改通知到其他團隊就行,如果你提供的是API那就麻煩了所有的應用全部都要跟著改動。
(2)剩下的5%提供API,總有一些業務的場景你是很難覆蓋全的,這部分可以通過API來提供;總之一能用統一頁面的就不要使用API 。
3. 賬號的管理后臺
賬號管理后臺,是為了方便做賬號配置,數據監控,異常處理等綜合的管理平臺:
(1)? 應用管理模塊: 對接入應用進行管理,記錄應用的基礎信息,并提供需給應用做單獨配置的功能,例如:接入統一賬號的應用名稱,應用的唯一標識ID,應用的說明,應用所屬部門,應用對應的負責人等等,這些信息是發現有誰在使用賬號以及后續賬號出現需要功能迭代溝通時的基礎數據非常重要,包括需要單獨給應用做特殊的配置也需要放在這里。
(2)用戶管理模塊:對注冊用戶進行管理,記錄脫敏后一些基礎信息,并提供一些給用戶標記或輔助操作的功能;例如:有時候公司的運營自己注冊了用戶,但是很多操作的數據都是為了做測試的數據,這部分如果數據量過大的話 一定需要跟真實用戶作區分,標記為內部用戶;還有一些惡意用戶需要標記為黑名單用戶杜絕這類用戶再次登錄。
(3)賬號配置模塊:用于賬號整體配置的模塊。例如:提供統一頁面的配置,配置頁面顏色的風格,頁面控件,頁面的logo等;還包括短信驗證碼,語音驗證碼,圖形驗證碼的配置等。
(4)賬號日志模塊:記錄所有對賬號服務進行增,刪,改,查相關操作日志的模塊,不管是 用戶,后臺運營人員,還是接口調用方;目的為了監控,追蹤,溯源。
(5)數據分析模塊:統計賬號提供的功能使用數據情況。例如:用戶填寫數據導整個注冊完成的成功率以及所花費的時間。
(6)接口管理模塊:提供接口開關,接口調用量統計,核心接口失敗警告燈服務。
(7)協議管理模塊:提供協議的上傳以及協議簽約記錄的模塊。重點說明:目前工信部對互聯網個人的隱私管理的非常嚴格,所以用戶服務的條款與隱私協議是賬號必須模塊。如果對這塊不是很了解的可以看我之前的文章。
4. 基礎數據模塊
賬號中臺是一個核心偏底層的服務,作為產品經理一定要清楚的,你的模塊中有哪些比較核心的數據,以及這些數據都是用做什么,這樣你在設計的產品或處理復雜異常場景的時候你會得心應手。
(1)賬號的狀態:正常,凍結,注銷。
(2)用戶基礎信息
設備信息:(設備名稱,設備型號,設備ID),
地址信息:(常登錄地址,公司/家的位置),
用戶信息:(姓名,年齡,郵箱,手機號,性別,職業,學歷,昵稱,證件號),
第三方賬號信息:(昵稱,頭像,第三方ID,姓名)。
(3)應用信息(使用賬號的應用信息)
應用名稱,創建時間,應用描述,應用類型(APP/web/h5/小程序),應用所屬部門ID(departmentID),產品ID(productID),應用類型ID(applicationID)
(4)接口的場景:注冊,登錄,修改密碼,綁定手機號等。
其實底層數據都是給以后能的規劃打基礎,特別是作為幾十個或上百個業務使用的賬號中臺,底層數據非常的重要。
接下來重點說一些基礎數據都是有什么作用的:
? ? 設備信息:
- 可以為用戶提供用戶歷史登錄設備,以及非常用設備登錄等安全提醒的功能。
- 可以限制同一個賬號同時登錄設備數量的限制,如果所在的業務有會員等業務這個功能是非常需要的。
? ? 應用信息,接口場景:
有這四層的數據,賬號平臺可以清楚的知道 用戶是從哪個應用端注冊進來的;有這四層的數據,賬號后續想根據不同的業務,產品,應用做個性化的配置,才有標記為。(層級的劃分,根據公司的組織架構來,如果創業型公司建議,前期對增加一些層級備用,防止公司做大后,需要額外的增加)
這些底層數據很重要,一定要把賬號整體的規劃想全,然后第一個版本就要吧底層的數據做好;這樣后面做起來就輕松很多,如果前期不把基礎打牢固,后面再想去收集這些數據會異常艱難。
所以其實真正做產品的高手,不是遇到需求時才解決;而是先把可能預見到的需求早就想了一遍,然后在第一個版本就把基礎打好。
5. 底層能力:這邊指的是賬號服務,需要的一些第三方的能力
(1)圖形驗證碼
使用場景:主要是通過手機號接受驗證碼的場景,在手機號接受短信前,先通過圖形驗證碼防止被惡意的刷數據。
注意事項:不要每次都彈驗證碼,一定要給一定的數量限制,例如同一個手機號一天在平臺獲取短信驗證碼的次數超過5次就需要進行圖形驗證碼的校驗。
(2)短信驗證碼
使用場景:使用手機號進行注冊或登錄場景
(3)語音驗證碼
使用場景:使用手機號進行注冊或登錄,但是用戶收不到短信的場景
注意事項:控制用戶使用語音驗證碼的場景,例如同一個頁面用戶聯系點擊了兩次獲取短信驗證碼,但是沒有填寫或者填寫不正確的場景,展示語音驗證碼的入口。
(4)郵箱驗證碼
使用場景:使用郵箱進行注冊或登錄的場景
(5)文本鑒別
使用場景:對用戶輸入的文本進行安全性,合規性,鑒黃等的鑒別;例如用戶在輸入用戶名,用戶簽名等等
注意事項:一定需要搭配一個 文本黑白名單的功能一起使用,因為有很多的文本第三方公司是存在誤殺或者遺漏的場景,而且他們短時間又不能快速的解決。
(6)一鍵登錄
使用場景:APP用戶使用本機手機號進行注冊的場景
注意事項:搭配手動輸入手機號+驗證碼的場景一起使用,因為有些用戶不想使用本機作為注冊的手機號。
(7)圖片鑒別
使用場景:對用戶上傳的圖片進行安全性,合規性,鑒黃等的鑒別,例如用戶上傳頭像
在引入第三方能力時有一些經驗可以分享:
引入第三方的服務商時,一定要從 服務可用性,業務場景覆蓋度,產品的體驗,客服的相應速度,技術支持的力度,價格,接入的復雜度,數據的安全性等多個維度綜合評估。
相同能力的第三方服務商一定要一到兩個兜底的服務商。例如:圖形驗證碼當一個服務商的當天失敗的次數超過一定次數,系統自動切換到下一個備用的服務商,進而保證系統的穩定性。
6. 賬號安全
(1)安全設計規范
由公司安全產品經理,提供的一些設計中常見的安全規避方案。例如:用戶的手機號,姓名,密碼等在數據庫需要加密保存,展示在頁面時需要脫敏處理等等。(產品平時遇到安全性的問題是,自己也要多加總結)
(2)安全風控功能
弱密碼稽查:密碼在之前沒有做格式的限定,導致用戶設置的密碼過于簡單,在用戶登錄成功后提示用戶修改密碼的復雜度 或 定期通過密碼庫的查詢,發現有密碼安全性低的情況通知到用戶去修改。
手機號/郵箱的綁定與解綁通知:用戶進行核心資產的解綁時,需要通過短信或郵件通知到用戶。
異地登錄提醒:當發現用戶的賬號在非常用地登錄時需要通知到用戶或者增加驗證碼步驟。
非常用設備登錄提醒:當發現用戶的賬號在非常用設備登錄時需要通知到用戶或者增加驗證碼步驟。
設備登錄數限制:同一個賬號在相同的設備上只能登錄一個等等
輸錯次數鎖定:同一個用戶登錄時密碼連續輸出5次,把賬號凍結一天等。
用戶注銷提醒:用戶發起注銷操作時,一定需要通過短信或者郵箱通知到具體用戶。
運營商二次放號:解決之前的手機號停機后,被運營商再次放號給到其他人使用的場景。
(3)常見的安全風控問題
提示手機號已注冊問題:
例子:某官網,在用戶注冊時,只要用戶輸入手機號已經注冊,在輸入框失去焦點時就提示用戶該手機號已注冊;導致競品拿不同的手機號去試,凡是已經有注冊的用戶就一個個給用戶打電話推銷自己的產品;導致了公司花費了巨額費用引入的用戶,被競品親而一舉的盜取,損失慘重。
解決方案:a, 登錄注冊一體化,不要分開;b,像這種非要提示的,建議驗證身份后再提示,會損失一些用戶體驗。
用戶ID自增問題:
例子:某官網,在用戶注冊時,將用戶的ID展示出來了,而且用戶ID的生成方式為自增;被競品抓到漏洞,導致競品很輕易的知道公司新增用戶數,不停的使用ID自增的方式暴力破解通過用戶ID獲取用戶信息的接口,造成用戶數據的泄露。
解決方案:用戶ID隨機分配 以及 內部接口使用的ID與外面用戶展示的ID分開。
密碼被暴力破解的問題:
例子:某官網,在用戶注冊時,沒有做用戶名 以及 密碼復雜度的校驗,導致用戶大量的輸入 123456 這種類似的密碼。競品通過暴力破解隨意登錄網站并對用戶造成困擾。
解決方案:使用密碼注冊時,一定要有復雜度校驗,不管是前端頁面還是后端接口。
登錄設備不限制問題:
例子:某付費視頻網站,在用戶登錄是沒有限制登錄設備數量,導致不法份子購買一個賬號后,以低價大量的將此賬號賣給其他的用戶,導致了公司收入大量受損。
以上幾個例子一方面說明,賬號本身十分的重要,一不小心就容易出問題。我們在設計的時候一定要有安全意識跟思維,這種安全意識跟思維只有慢慢的積累或者學習才能形成。
四、用戶賬號建設的幾個階段
用戶賬號并不是說一定要按照我提供的這種方式來設計,如果說業務單一簡單就完全不必想我這樣規劃,我這方案比較適合中大型的互聯網公司。
企業的不同階段,其實對用戶賬號的需求也是不太一樣的,企業的發展上我們大致可以分為:前期試錯,擴大規模,精細化運營尋找第二曲線;每個階段賬號的側重點是不同的,我們需要結合業務,進行一步步的迭代。
1. 前期試錯階段(紅色部分)
(1)提供賬號的登錄注冊,修改密碼,主要等基礎的功能。
(2)搭好賬號的基礎數據,為賬號以后的功能拓展打好基礎。
(3)提供統一的注冊登錄頁面,方便不同業務進行試錯對接。
2. 擴大規模階段(綠色部分)
(1)提供賬號的管理后臺,增賬號 對接,運營過程中的效率 與 異常監控。
(2)接入第三方的能力提升賬號的合規性與安全性。
(3)規劃賬號安全的整體方案,提升賬號的安全性。
3. 精細化運營,尋找第二曲線(藍色部分)
(1)提供賬號多樣的接入方式。
(2)提供海外賬號等多種類型的賬號。
五、總結
用戶賬號是一個非常底層的模塊,只要面向用戶業務應用都需要用到;如何做到用戶體驗好,安全性高,易接入的賬號是比較復雜的。
- 在設計賬號的過程中,有非常多需要注意的點,接下來給大家做一個注意事項的匯總:
- 用戶賬號中心其實相當于一個小中臺或微服務,中臺最主要就是抽象共性,將邏輯標準化;賬號其實也一樣,當你在做規劃的時候一定要想全,暫時不需要的一些功能通過配置先關掉,或預留技術方案方便下次升級的時候成本小。
- 賬號的底層數據非常重要,在做第一個版本的時候就需要預留字段或上報。
- 用戶賬號在提供對外對接的方式時,一定要盡可能的提供統一頁面的接入,這樣對于以后的迭代以及統一的管理更加的高效。
- 用戶賬號的 安全與合規非常的重要,一定要在設計與規劃的過程中多總結,一次安全事故對于公司來說就是非常大的損失,對于產品的靠譜能力是嚴重減分的。
本文由@陳宏偉 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
您好,公司做的是垂類業務,有2b的saas平臺和2c的小程序,請問b和c的賬號是否需要在最底層統一通行證賬號,然后在分表各自維護業務信息呢?
大佬,方便加個微信不,我最近在做用戶中心的設計,跪求指導
您好,我也是產品經理,近期在學習相關的東西,可以加微信請教下后臺相關的東西嗎
非常好,感謝
非常全,非常優秀,非常有啟發
抱拳!
你好,想問一下對于一個剛剛穩定的新項目來說,賬號體系如何進行迭代和規劃
打好基礎,然后以業務支撐為主,這個時候如果業務拓展新的渠道,那么賬號就需要快速支持;如果業務沒有任何拓展知識在嘗試穩定中,那么就要看新項目使用的用戶數量,看看是否對體驗細節進一步加強,包括安全性
很有幫助,謝謝
有問題歡迎評論 我將幫忙來解答
歡迎留言