起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識盤點【注冊、登錄】產品設計路上爬過的坑
作為最基礎的常備功能， 注冊/登錄往往是產品第一個版本中最容易被忽視的環節，越是看似容易，陷阱越多；介紹相關產品思路的文章很多，講交互的多，結合運營的少；本文更多的是記錄那些坑坑洼洼，希望對大家有幫助。
1.0非?；A
1.1因「私有化」而存在
不是所有的產品都需要注冊/登錄，除非[私有內容/私有操作]具有足夠的吸引力。
- 注冊：用戶告訴系統Who is Tom；系統記錄Tom和口令；
- 登錄：用戶告訴系統I am Tom；系統辨別Tom和口令；
1.2Passport產品線及近親
通常把注冊、登錄、找回密碼、修改密碼、賬戶關聯這幾件事歸為Passport產品線；它的近親是Profile產品線，包含用戶資料、個人設置等。
1.3登錄是高頻，其他是低頻
注冊、找回密碼、修改密碼都是低頻操作，但都屬于迫切程度比較高，也最容易引發挫敗感，導致用戶投訴及放棄使用產品。
1.4術語：查重、校驗、驗證、匹配
- 查重，“查詢是否有重復存在”的簡稱，比如：排除以手機為主鍵的重復注冊；
- 校驗，檢查數據是否符合格式，比如：輸入的時候為一個手機號碼；
- 驗證，確認真實性，比如手機和郵箱真的是用戶本人使用，指紋、人臉識別；
- 匹配，用戶提交的數據是否與存儲中的數據一致。
1.5術語：Spam與Anti-Spam
Spam指使用腳本、機器人進行惡意批量提交或遍歷破解的行為； Anti-Spam指防止Spam的系統措施。
1.6術語：單點登錄OOS
也就是所謂的通行證，注冊/登錄一次，可在所有的子產品（跨域）中通用一個Passport和相同的Profile信息。
2.0注冊主鍵選擇
主鍵是數據庫設計中的一個概念，為了保證唯一性，新增用戶時必須進行[主鍵查重]。
2.1以用戶名為主鍵注冊
Anti-Spam：非常弱（批量Spam賬戶）。 擴展性：高，隨時可切換為以其他數據為主鍵。 使用場景：私有內容/私有操作較少的情況，比如僅提供了回復、投票、點贊等[輕操作]； 產品雛形期，進行測試的新產品（開發比較容易）。
便利設計：
注冊和登錄可合并在同一個界面（不考慮找回密碼時）；
注冊時可順便把用戶名當作昵稱搜集。
注意事項：
為了讓用戶找回密碼，必須設置密保問題，找回密代價很高（把自己用戶名給忘記了）。
2.2以郵件地址為主鍵注冊
Anti-Spam：中等（自從QQ郵箱出來，被遍歷攻擊的事兒也是不少?。?。 擴展性：中，可以隨時切換為手機主鍵。 使用場景： 郵箱容易記憶，適長期頻繁使用的產品；適合在web端需要依賴Newsletter進行營銷的產品；非實名用戶系統，郵件主鍵的代價最小，轉化率較好。
便利設計：
To B產品使用企業郵箱注冊，自動關聯企業主賬戶。
注意事項：
郵箱是隱私，掩碼顯示，如果包含社交功能，注冊時可能需要采集昵稱；
進入各大郵件運營商的白名單，是一件頭疼的事兒，搞不好就直接進垃圾郵件了。
2.3以手機為主鍵注冊
Anti-Spam：弱（各種遍歷、各種騷擾，需要采取措施）。
擴展性：低，幾乎不可逆（用戶也不答應）。
使用場景：帶有支付功能的電商、消費類產品；實名用戶系統，需要用戶的絕對信任，初期轉化率低，最好從郵件主鍵過度；只有移動版本的產品。
便利設計：
根據手機號自動匹配地區城市、電信運營商（也有一部分用戶是攜號轉網的#_#）。
注意事項：
手機是絕對隱私，能不顯示就不顯示，顯示必須掩碼，如果包含社交功能，注冊時可能需要采集昵稱；國外手機號幾乎不可以，短信通道需要至少雙備，如果驗證短信中包含一些根本想不到的敏感詞，會很慘；用戶更換手機，運營商回收舊號碼賣給新用戶，都會大量存在，請一定給出解決方案。
2.4由第三方賬戶創建（并登錄）
Anti-Spam：高（等于是把驗證權交給別人了）。 擴展性：高，可以在第三方驗證后再創建自有賬戶。
使用場景：幾乎適合各種類型的用戶自主注冊賬戶。
便利設計：可以根據第三方授權拿來一大堆Profile里邊的信息（除了密碼）。
注意事項：把雞蛋放在了別人的籃子里，一定要心甘情愿；登錄之后再創建自有賬戶，會存在一定的轉化率損失；去第三方申請授權，要有耐心，而且通常在產品初期拿不到太多的Profile數據。
2.5社會卡證類主鍵（身份證、信用卡）注冊
Anti-Spam：高，因為規律性比較差，但也不排除社會工程hack手段。 擴展性：都到了這步了，算是個終極。。 使用場景：特殊場合和人群，需要展示特殊的功能；實名用戶系統，需要用戶的絕對信任；必須關聯在線支付/移動支付才能使用的產品；通常都不會包含社交功能。
便利設計：
直接關聯到用戶真實身份和征信。
注意事項：
通常驗證都是通過第三方信用組織進行，比如提交信用卡關聯的身份信息，由支付機構或銀行匹配之后發送一個驗證短信/郵件/二維碼；同樣是把雞蛋放在別人的籃子里（通常是親爹的籃子）。
2.6其他主鍵
用汽車牌照做主鍵，真的可以有；不是不可以，但是盡量還是別摸著石頭過河；注冊主鍵在真實社會里一定是具有非重復且個人專有的特點。
2.7多主鍵復合注冊
當然可以啦，注冊時沒必要提示用戶哪個是主鍵，反正登錄的時候會提示。
2.8切換主鍵時注意事項
其切換主鍵之前，一定要對數據進行篩查，情況可能是這樣的，用戶使用郵件主鍵生成了一個用戶，當系統切換手機為主鍵時，用戶會因迷惑而創建另外一個新賬戶，此時可能涉及到用戶數據合并的問題。如果這些沒有想清楚，就不要隨便更換主鍵。
3.0個人注冊（To C）
3.1查重錯誤，不要在注冊環節隨便給出
填寫一個手機號碼，異步查詢是否可以注冊，雖給用戶帶來了方便，但也給駭客提供了可乘之機：寫一個腳本就能遍歷出來哪些號段多少個號碼注冊過產品！ 請在驗證碼正確之后給出結果，或者單獨跳轉URL給出查重類錯誤
3.2前端校驗和后端校驗都要進行
跨域攻擊是最簡單的手段咯，注冊這么大的事兒，一定要進行前后校驗（登錄之后，可以根據系統壓力再進行簡化，登錄之前，還是謹慎為妙）。
3.3以郵箱和手機注冊主鍵，第一步只做一件事：驗證主鍵
沒有驗證過的郵箱和手機會弄臟用戶數據，臟庫是無法切換登錄主鍵的！ 注冊的第一步，只做一件事情就好了，不要讓用戶填寫其他信息（填寫密碼也不行）。
3.4分步注冊，暫存數據，只有在用戶提交密碼那一刻，才創建正式數據
如果第一步是校驗主鍵，那么應該暫存數據，只有在主鍵驗證完畢，下一步用戶填寫密碼并提交之后，再創建正式數據。（這個坑是這樣的：用戶第一步提交郵箱，但是驗證郵件沒收到，此時可能用戶會再次啟動注冊，如果前面已錄入正式數據，可能會顯示這個“這個Email已經注冊過了”）。
3.5有必要重復確認密碼么？
沒必要！設置這個的初衷無非是避免用戶注冊時輸錯密碼，輸錯=忘記密碼，就去找回密碼咯。
3.6只采集必要數據，填寫項目越少越好
在注冊環節，標注[必填]是個爆弱的設計，如果是選填，就別讓用戶在注冊環節提交。
3.7包含社交的產品一定要讓設置頭像成為必填
注冊之后，需要很大的運營代價才會讓用戶上傳頭像，因此這一步驟最好是前置。
3.8昵稱需要查重么？
需要！避免李逵和李鬼；盡量杜絕錄入火星文和特殊字符（視情況額定）。
3.9驗證碼何時出現？
參考后面 章節7.3
3.10讓用戶發送密碼短信到特定號碼進行手機注冊，這很矬
誰會用？有多少用戶愿意自己付出短信成本？除非特別緊急的情況下。
3.11同意《用戶使用協議》
讓用戶勾選閱讀并遵守《用戶使用協議》，不如把注冊按鈕改為“同意用戶協議，提交注冊”
3.12邀請碼注冊要走單獨流程
輸入邀請碼或點擊邀請郵件中加密連接進行注冊，可關聯邀請者ID，需要的單獨設計注冊界面。
3.13注冊與登錄合并設計（快速注冊）
以用戶名和手機為注冊主鍵的時候，可以這樣設計；但以郵箱注冊的時候，用戶需要跳出到郵件系統，快速注冊就沒意義了；快速注冊以后自動進入登錄狀態。
3.14注冊結束后，必須讓用戶再登錄一次（快速注冊除外）
這不僅僅是個儀式感，而且是安全的需要，增加自動腳本Spam賬戶的難度。
3.15注冊應該避免設計成light box（快速注冊除外）
注冊復雜程度不一，并且會經常迭代改善產品，因此校驗代碼和各種邏輯判斷非常多，如果做成light box效果，可能會拖累很多界面的加載速度，也會讓維護和測試變得麻煩。
3.16注冊后的（首次登錄后）歡迎與提醒，設立URL暫存池
注冊完成有結果提示和簡單的歡迎，然后就需要讓用戶進行跳轉； 記錄用戶點擊注冊之前的界面URL，在用戶跑完注冊/登錄流程之后，回到那個URL（“從哪里來，就回到哪”）； 如果無法判斷用戶注冊登錄前的URL，那么跳轉到一個最核心的私有內容界面； 用戶可以選擇回到Profile管理；
4.0企業商家注冊/入駐（To B）
4.1商家注冊（申請）建立在個人賬戶基礎上
先完成個人賬戶注冊，再創建商家；在注冊商家的同時，創建一個個人賬戶；以上兩種方法都可以。因為商家賬戶的管理者通常是員工，如果該員工離職，企業會要求進行管理權轉移，把商家掛在個人賬戶下面，靈活度最高。
4.2在注冊之前分流角色，而不是注冊過程中
企業商家用戶通常按行業分類，比如賣方需要提供代理證明，而買方需要填寫收貨地址；此時最好設置為兩個入口，而不要在注冊的過程中進行條件分支。
4.3審核期過度界面
通常企業商家注冊都需要一個運營審核過程，此時，用戶可登錄個人賬戶使用一些基本功能，請把審核進度明示給用戶，同時給予企業商戶功能的演示介紹。
4.4企業子賬戶應該是邀請的，而不是隨便填寫的
不要讓企業商戶管理員直接填寫子賬戶的用戶名和密碼，建議企業子賬戶以email為主鍵，走邀請的流程，讓其他員工自己驗證郵件、填寫驗證手機和密碼，這樣做責權清晰，安全性最高。
4.5企業管理員不能直接修改子賬戶密碼
企業管理員觸發一個驗證郵件給子賬戶，子賬戶可以自行通過加密連接修改密碼；必要時，管理員可以凍結那個強制要求修改密碼的子賬戶的權限。
5.0登錄
5.1登錄主鍵提示
在主鍵input當中，允許用戶填寫不同的主鍵，雖然校驗比較麻煩，但是用戶便利了。
5.2注意登錄錯誤信息拋出方法
單獨拋出“該用戶不存在”或者“密碼不正確”可能會是不科學的，因為很可能方便了別有用心的人，比較安全做法是“用戶名不存在或密碼不匹配”。
5.2記住用戶和記住密碼是兩種不同的功能
一種是保存“主鍵”，另外一種是保存“主鍵+口令”。記住用戶名，就一定要有切換用戶的功能；保存口令，要看產品的使用頻率，使用頻率越高保存周期越短（在便利和安全之間的平衡），保存周期最好不要超過3個月（甚至可以設置3個月強制更換密碼）
5.3驗證碼何時出現？
參考后面 章節7.3
5.4防止重復登錄
這個經常被忽略，同客戶端，后來登錄的踢掉前面的session;允許web、手機app、HDapp同時登錄，但每個終端智能保持一個session哦
5.5盡量設計成light box或類似效果，登錄之后“從哪里來，就回到哪”
注冊、登錄前暫存URL，還是一個很重要的登錄彩蛋。
5.6二維碼登錄
如果有移動app，通過App掃二維碼可以直接登錄web版本。
5.7長期未登錄、陌生移動設備登錄，加一個判斷，通知到郵件
長期未登錄，突然在異地登錄，在陌生的移動設備上首次登錄都屬于異常的情況，此時要增加用戶判斷的環節，并發送通知到郵件。（手機號碼可以換，郵件地址不會隨便換吧）
6.0找回密碼/修改密碼
6.1密碼的安全
除了足夠的位數要求、大小寫和特殊字符要求，可以通過判斷要求用戶不允許把密碼修改為曾經用過的密碼（開發量略大），不能使用常見密碼、純數字密碼、生日密碼等。指紋、虹膜、手勢……密碼的種類會越來越多的。
6.2按問題找回密碼，或創造問題找回密碼
直接輸入郵箱和手機就能找回密碼，不是一個好設計，應該還是要進一步判定身份；設置找回密碼問題是通常的設計；可以嘗試“下面多用戶哪些是你曾經的聯系人”、“請輸入你曾經用過的密碼”“下面哪些寶貝你曾經購買過”等等；為了防止Spam，設置一個驗證碼也可以。
6.3按郵箱找回密碼
發送一個密碼找回函，用戶通過加密連接修改密碼，密函有效期盡量短一些； 如果用戶說“郵箱密碼忘記了，或者郵箱不用了”，那就無法修改密碼，人工服務也不行！
6.4按照手機找回密碼
手機發送要防遍歷Spam，手機驗證碼有效期越短越好，10~20分鐘就可以。 要提供“這個手機號碼已不再使用”的解決方案，僅以手機為主鍵，且手機丟失、號碼不再使用的情況，要求進行驗證。
比如“下面多用戶哪些是你曾經的聯系人”、“請輸入你曾經用過的密碼”“下面哪些寶貝你曾經購買過”等等，然后再進行解綁和重新綁定；必要時加入身份證信息上傳功能；實在不行了，再轉人工服務；手機丟了怎么辦？手機不是有屏保密碼么？不設屏保密碼，那責任在誰？
6.5找回密碼/修改密碼之后，必須讓用戶再登錄一次
依然是一個安全問題，也是給Spam腳本增加難度。
6.6找回密碼/修改密碼與提醒
用手機找回密碼，就不要發手機提醒了，發個郵件是可以的； 用郵件找回密碼，不需要特殊的提醒； 只用問題就找回密碼，發個郵件比較好；
郵箱本身有密碼，手機本身可能無密碼（易被濫用），因此，用郵箱找回密碼安全級別較高。
6.7人工密碼服務
必須通過系統內保存的郵件發送相關的身份證明，不能隨便找個郵箱或者qq就發送了； 不是修改密碼，而是人工發送一條密碼找回函到注冊時的主鍵郵箱； 人工解綁、綁定手機的這個功能，不推薦，道德風險比較大； 呼叫中心成本比較高，現在流行用微信做人工服務；
7.0驗證郵件、驗證短信和驗證碼
7.1要控制郵件發送的頻率
雖然用戶可能不反感，但是郵箱提供商可能直接認為是垃圾郵件地址了； 可以努力通過技術手段或者購買服務，進入各大郵件運營商的白名單；
7.2手機短信這個坑啊
如果大量依賴手機主鍵，短信運營商至少要找兩家，進行雙備份；要有[熔斷]機制，在某一時間段內，不允許連續發送短信到某個手機（防止Spam）。曾經遇到過惡意的將驗證碼連續發送到某個手機（當然不是黑客自己的號碼），用戶直接投訴，整個短信通道被運營商封殺，直接跪了；多次沒收到短信，要給予時間間隔，此間不允許發送，要求客戶耐心等待；短信內容要提前發送測試，總有一些敏感詞，臣妾想不到??；
7.3驗證碼何時出現
Anti-Spam的驗證碼降低了用戶感受，因此，推薦在初次使用時不出現驗證碼，在1~3次錯誤之后，出現驗證碼；盡量讓驗證碼新奇好玩一些，減輕用戶反感。
8.0Passport產品經理須知
8.1需要專職的產品人員和運營人員負責Passport？
如果是電商、線上交易類的，幾乎必須專人負責了；如果包含支付環節，又木有專人負責，最好直接使用成熟的登錄/注冊設計，不要標新立異；如果整個產品只有一個人操辦，那么恭喜了，這個文檔也許有些幫助。
8.2注冊轉化率那點事兒
要看追求何種目標，如果是以注冊量為KPI，注冊過程越簡單越好，在注冊之前盡量給與更多的利益展示；
8.3注冊統計
通過促銷活動注冊的用戶，要單獨進行渠道統計，雖然理論上這些幾乎都不會成為持久的DAU，但總是需要知道各種渠道的效果對比
8.4與運營團隊配合解決問題
本文羅列的問題，僅能算作一些基礎，實際運營過程中，用戶在注冊/登錄問題是千奇百怪的，大家還是要有個心理準備。
為1%的用戶創建100%的功能，得不償失，但產品經理總是要給出一些答案。
本文實乃一家之言，難免有疏漏，敬請海涵
本文由@鴻津 ?公眾號：Hozin?(hozin-com)授權發布于人人都是產品經理?，未經許可，禁止轉載。
多主鍵復合注冊是注冊時收集多個字段，1主鍵含有收集的多個字段，組成復合主鍵 ；2將收集的多個字段都設置為主鍵，形成聯合主鍵。哪個意思呢？新人小白一個還請賜教。
??
大贊，寫的太好了，許多是還沒考慮的。多謝前輩指點~
本來想自己研究一下的，發現前輩總結的夠完善了，直接學習了。
感謝 很有幫助
贊！講得很細，好多問題在我實際設計中都遇到過。