除少數(shù)工具類的應(yīng)用，注冊登錄模塊可以說是產(chǎn)品中最基本的模塊了攒读。對于這個人人都知道的功能朵诫，我還是直奔主題吧。

目的

我一向主張分析任何的功能薄扁，都先從目的（動機(jī)）入手剪返，那么我們先來說目的吧。

1.與用戶產(chǎn)生連接邓梅。

此種連接随夸，可以說是雙向的連接，不過更多情況下震放，是應(yīng)用對用戶的虛擬或者真實身份信息的留存宾毒。例如，當(dāng)你有時候需要下載一個冷門網(wǎng)站的一個很冷門的文件時殿遂，很有可能發(fā)現(xiàn)這個網(wǎng)站要求你必須注冊成為會員后方可下載诈铛。不過即使你因此注冊了，下次你還會來這個網(wǎng)站么墨礁？還記得你在這個網(wǎng)站有賬號么幢竹？沒關(guān)系，對于這個網(wǎng)站來說恩静，它擁有了一部分它想要的信息焕毫，也許是你的郵箱，也許是手機(jī)號驶乾。

說一句題外話邑飒，現(xiàn)在大部分應(yīng)用要求注冊用戶填寫手機(jī)號并非完全出自“與用戶連接”的目的，還有一部分原因是國家監(jiān)管要求级乐。

2.用戶行為信息或其他信息留存疙咸。

行為信息或其他信息存儲在用戶記錄里，除去便于分析用戶行為描繪用戶畫像外风科，對用戶來說撒轮，也便于跨平臺或切換賬戶乞旦。

譬如Chrome的收藏或記住密碼可以跟著你的賬戶，實現(xiàn)手機(jī)端和電腦端同步题山。還有在視頻網(wǎng)站看了一半的視頻兰粉，換個瀏覽器照樣緊跟視頻進(jìn)度，不耽誤一點時間顶瞳。
譬如在亞馬遜官網(wǎng)綁定了信用卡亲桦，你可以在app上直接輸入支付密碼就可以使用，毋需再次綁卡浊仆。

3.便于監(jiān)管和審核UGC客峭。

UGC，User Generated Content抡柿，用戶產(chǎn)生內(nèi)容舔琅。可以自由上傳內(nèi)容的地方總是難免要有審核洲劣。審核的嚴(yán)格程度和規(guī)則自然是各家都不相同备蚓，但是這些內(nèi)容都是依附在用戶賬號下這點，大家都十分一致囱稽。

4.便于用戶后續(xù)消費郊尝、隱私等行為

前面我們已經(jīng)說了在亞馬遜綁卡后可以直接輸入支付密碼消費，其實這種行為也就是“后續(xù)消費”战惊。這種后續(xù)消費行為是通過用戶錄入額外信息來實現(xiàn)的流昏。這種額外信息需要依附于原始的用戶信息上。額外信息不僅包括銀行卡等信息吞获，也包括個人真實身份信息等等况凉。

當(dāng)然現(xiàn)在用戶消費有時也不需要錄入什么額外信息，一個二維碼就可以搞定了各拷。除了街頭賣煎餅的店鋪刁绒，線上應(yīng)用也會將二維碼消費與用戶記錄掛鉤，不然你的視頻會員就白買了-烤黍。-

應(yīng)用端

如果你的應(yīng)用不涉及以上幾個目的知市，或者是部分功能涉及到以上目的，那么你可以考慮下游客模式速蕊。

在對需求分析時的第一步——目的——已經(jīng)完成后嫂丙，接下來討論的是應(yīng)用端。應(yīng)用端決定著流程設(shè)計的策略互例。
應(yīng)用端的不同奢入，使用場景不同，用戶習(xí)慣也不盡相同媳叨，在注冊登錄這個初始步驟腥光，區(qū)分這些還是有些重要的。

Web

Web頁面中糊秆，由于頁面大武福，可以實現(xiàn)多內(nèi)容且便于閱讀的呈現(xiàn)，可以將注冊登錄所有錄入信息項在一頁中展示痘番。便于快速完成任務(wù)捉片，以及讓用戶明確知道任務(wù)進(jìn)度。

App

App的頁面小汞舱，不適合展示過多的信息伍纫，更需要聚焦當(dāng)前小任務(wù)。如現(xiàn)在有很多App將錄入手機(jī)號昂芜、發(fā)送驗證碼莹规、設(shè)置密碼等小任務(wù)拆解在不同的頁面里。這樣拆解的好處除了聚焦當(dāng)前任務(wù)外泌神，還有分散任務(wù)項過多造成的壓力——畢竟當(dāng)前頁面只有一個任務(wù)嘛良漱。

H5

和Web、App最大的不同是欢际，H5沒有單獨的注冊登錄功能母市。H5中的注冊登錄大多是事件流里的主流程外的行為，是系統(tǒng)的辨識行為损趋。
這種非主流程外的行為夾雜在主流程時患久，最主要的考量就是盡量輕量化。以感受上不打斷原流程為宜浑槽。
除了輕量化外墙杯，還應(yīng)盡量將注冊登錄后置，盡可能使用戶接近完成主流程括荡，減少損耗高镐。

對接系統(tǒng)

確定了產(chǎn)品注冊登錄的目的和投放的應(yīng)用端后，下面可以開始關(guān)注實際設(shè)計中對接的系統(tǒng)了畸冲。
沒有一個功能是孤立的嫉髓，大部分的功能都需要與其他系統(tǒng)進(jìn)行交互。注冊登錄里邑闲，最常交互的后臺系統(tǒng)就是用戶中心和消息中心了算行。

用戶中心

用戶中心規(guī)定并存儲了用戶的必錄項、非必錄項和其他記錄苫耸。用戶的必錄項是注冊里必須要呈現(xiàn)的基本信息州邢。

在確認(rèn)必錄項的內(nèi)容時，務(wù)必確認(rèn)賬戶與必錄項的關(guān)系：一個賬戶（CustomID）是否對應(yīng)著一個必錄項目褪子？通常情況下賬戶與必錄項是一一對應(yīng)關(guān)系量淌。
如很多應(yīng)用注冊時只要求填寫手機(jī)號和設(shè)置密碼骗村，可以判斷，手機(jī)號+密碼即為必錄項呀枢。
注冊登錄時盡量只要求用戶填寫必錄項胚股，以簡化該功能。

非必錄項與必錄項的對應(yīng)關(guān)系也很重要裙秋。如第三方賬號綁定琅拌、手勢密碼等非必錄項是直接影響登錄流程的。

考慮非必錄項時可以從以下幾個問題入手：

• 一個賬戶是否可以對應(yīng)著多個第三方賬號摘刑？也就是一個賬戶下至多可以綁定幾個微信號进宝、微博號、QQ號枷恕，等等党晋。當(dāng)然可以綁定第三方賬號時，也必須提供解綁功能活尊。
• 一個第三方賬號是否可以對應(yīng)多個賬戶隶校？
• 一個賬戶是否可以對應(yīng)多個手勢密碼或者生物特征密碼（如指紋、聲紋蛹锰、FaceID）深胳？

通常情況下，用戶中心留存的用戶其它身份信息（如實名認(rèn)證信息）或者其他信息不會直接影響注冊登錄流程铜犬，當(dāng)然也建議不要影響注冊登錄舞终，畢竟注冊登錄是用戶以用戶的身份來到應(yīng)用的第一步。

消息中心

消息中心與注冊登錄相關(guān)的只有用戶賬戶驗證時可能觸發(fā)的短信郵件等的發(fā)送癣猾。
需確認(rèn)單個用戶規(guī)定時間內(nèi)收到的短信/ 郵件是否有限制敛劝。

風(fēng)險控制

在梳理完對接的系統(tǒng)的規(guī)則后，基本該收集的信息也已經(jīng)收集的差不多了纷宇，接下來需要為這些信息建立一些安全規(guī)則夸盟。

注冊登錄階段的風(fēng)險控制基本關(guān)注在兩點：賬戶真實性和短信通道的限制。

賬戶真實性

賬戶真實性包括了初始階段錄入的賬戶信息真實性像捶，如手機(jī)號真實性上陕、郵箱真實性等；也包括賬戶驗證時的真實性拓春，如密碼真實性释簿。

目前很多金融應(yīng)用或電商平臺，會至少兩次驗證賬戶硼莽。第一次是登錄庶溶，第二次是當(dāng)發(fā)生交易相關(guān)的行為時，驗證交易密碼。有驗證就有成功和失敗偏螺。安全規(guī)則就是用來規(guī)范失敗的情況的行疏。設(shè)定幾次密碼輸入失敗即進(jìn)入賬戶鎖定或賬戶冷凍，是一個不錯的通用辦法砖茸。

短信通道限制

為防止短信通道被惡意程序攻擊占用隘擎，很多應(yīng)用都會有CAPTCHA（Completely Automated Public Turing test to tell Computers and Humans Apart殴穴，區(qū)分人與機(jī)器人的驗證方式）凉夯。在注冊登錄階段需要考慮的是CAPTCHA的使用情境。如當(dāng)用戶頻繁喚起發(fā)送短信的操作時采幌，是否出現(xiàn)CAPTCHA等等劲够。

不同的CAPTCHA有不同的性格，目前市面上常見的有圖形驗證碼休傍、滑塊征绎、選擇指定的圖形等，具體選擇哪種CAPTCHA嘛磨取，本文不再贅述人柿，有時間的話還是另開一篇來介紹好了。

在以上的系統(tǒng)分析后忙厌，我們已經(jīng)可以得到比較全面的注冊登錄的限制條件和規(guī)則了凫岖。這些內(nèi)容將會在下一步的流程設(shè)計中真正發(fā)揮功效。本篇文章使命完成逢净，就此擱筆哥放。