不同公司的注冊登錄業務設計需要case by case分析，本文拋磚引玉，歡迎大家探討。

0X00 導言

說到注冊登錄流程，大家想必對各個應用里的注冊登錄頁面都見怪不怪了吧？現在絕大多數APP及網站都有自己的賬號體系，其中注冊登錄就是賬號體系觸達用戶的第一道檻。對于一個應用來說，注冊登錄設計合理，可以助力自己的快速擴展；設計不合理，也很容易導致大量的不必要投入，甚至帶來合規風險。

那怎么樣定義合理及不合理呢？應用需要如何根據自己的業務場景，成長階段設計注冊登錄流程呢？后面我會細細道來。

0X01 注冊登錄業務的宏觀理解

在落地量身打造注冊登錄流程之前，先通過幾個問題，從宏觀方面說說我對注冊登錄流程的理解。

一、注冊登錄流程的需求痛點是？

對于產品經理來說，每個流程或功能點，都代表一個需求；凡是需求，都有需求背景及待解決的問題。

注冊登錄流程的需求背景各有各的不同，但我理解的需求痛點是統一的，即個體與該個體維度的數據無法達成關聯。

在使用該服務的單個用戶進行注冊登錄之前，服務方與該單個用戶在數據上處于無聯系的狀態（網站無個體維度的身份標識，無法將個體維度的數據與個體聯系起來）。注冊登錄環節，是服務方為單個用戶建立身份標識的過程，是服務與享受該服務的用戶在數據層面建立雙向聯系的過程。

延伸一下，在為單個用戶建立身份標識之后，由于需要識別當前嘗試登錄的用戶是否為該身份標識的所有者，因此在創建身份標識的時候需要由身份標識的所有者創建一種理論上只有他自己知道的符號用于識別。后續每次嘗試登錄時均需要通過一道驗證的方式對該身份標識進行校驗，以確認該身份標識與該用戶的對應關系。

因此身份標識和身份標識的識別符號肯定是成套出現的。身份標識 身份標識的識別符號，共同構成了用戶在互聯網中的身份。理論上，我們只能按照身份標識 身份標識的識別符號，來判斷用戶在站內的合法性。

再延伸一下，注冊登錄環節并不是標配。如果服務與享受該服務的用戶在數據層面無需建立雙向聯系（主要為純工具類應用），則無需額外設置該環節。

二、注冊登錄流程具體包括什么內容？

注冊登錄流程是一個流程集，包括正向和逆向流程； 注冊登錄環節主要包括正向流程：注冊流程、登錄流程；逆向流程：找回密碼流程，風控流程。

備注：正向流程是指正常情況下企業業務流方向上的流程；而逆向流程是指下游出現問題時需要對相關問題或業務進行處理的流程。找回密碼是由于用戶忘記密碼產生的，因此歸為逆向流程。

三、注冊登錄環節的影響？

注冊登錄流程作為用戶及站內的中間環節，這個兵家必爭之地的設計，可能會帶來如下影響：

• 正向：如上文所說，可以建立服務于用戶之間的雙向聯系，快速進行推廣，進行個人化營銷，有利于用戶的信息安全等等。
• 反向：有流程就會有損耗，注冊登錄流程對用戶來說，是使用網站服務的額外流程。在現在流量越來越貴的情況下，流程的損耗是必須考慮的要點；流程考慮不到位可能導致的問題是需要付出巨大的額外成本進行流程補全。（假如應用要全量用戶添加昵稱及頭像，如果忘記在注冊登錄環節增加昵稱及頭像補充環節，后續要在其他環節補全需要付出極大的額外成本）

總結：

注冊登錄環節，是服務方為單個用戶建立身份標識的過程。

注冊登錄流程是一個流程集，包括正向和逆向流程。

注冊登錄流程作為用戶行為的關鍵節點，十分重要。

0X02 注冊登錄業務中驗證機制的演變

上文說過，注冊登錄流程是由身份標識 身份標識的識別符號流程組成。由于身份標識的創建是應用自身即可完成的，因此流程的難點主要是身份標識的識別符號的選擇上。

目前的注冊登錄流程發展也是由身份標識的識別符號變化，也就是我們常說的驗證方式決定的。要作為驗證方式需要兩種特性：

1. 在服務對象中覆蓋率高；
2. 與真人的關聯度高。

注冊登錄流程的演變，將人性懶惰的一面展現得淋漓盡致。整體而言，驗證方式越來越接近于實人與互聯網的連接，越來越契合人性對邊界的追求。下面來簡單說說目前按驗證方式分類的幾種不同的注冊登錄流程演化之路。

一、密碼

包括的注冊登錄方式：賬號密碼登錄；

密碼其實就是一串理論上只有身份標識所有者記得的字符串。三方賬號登錄其實就是借助三方賬號密碼信息對身份標識進行驗證的方式。本質上也是密碼的變種。使用密碼的好處在于，目前識別字符串的功能所有的設備均可以支持，同時用戶也已經被教育成熟，使用密碼進行校驗。問題在于首先，字符串的標識性不夠強，很多人設置的簡單密碼都相同；其次，字符串的安全性不夠高，相對于現在的黑客技術來說，簡單密碼被破解成本極低；最后，結合第一點和第二點，字符串只有通過不斷提高復雜程度，才能確保其與真人的關聯度及安全性。但這也就意味著用戶的記憶成本會不停提高。目前這種矛盾及其帶來的后果已經確實的發生在我們的生活之中。

鑒于目前密碼還是所有設備都支持的方式，外部依賴性較低，用戶被教育程度最充分的方式，可以作為備選項進行校驗。但已經是一種較為“過時”的校驗方式了。安全性和與真人的關聯度都不夠強，以及為解決這個問題導致的用戶記憶成本提高，這個平衡點的難以把握注定這是一種將隨著技術進步被拋棄的驗證方式。

個體識別度：低

便捷程度：低

技術要求：低

風險程度：高

二、基礎通信方式

包括的注冊登錄方式：手機注冊登錄；郵箱注冊登錄

基礎通信方式具有網絡效應及替代成本高的特點，同時符合作為驗證方式的特性，這也是隨著通信技術的發展及普及帶來的驗證方式升級。其中隨著通信覆蓋率的基本飽和及IM的發展，手機號碼逐漸取代郵箱成為最通用的驗證方式。

在目前階段，由于注冊登錄的便捷性，無需記住密碼的特點，采用基礎通信方式進行身份驗證是最為普遍的。但采用這個方式最蛋疼的點在于，由于運營商手中通信資源的稀缺性，會存在重復放號的可能，這對于依賴手機號碼驗證方式是個巨大挑戰，因此經常需要進行補充流程的校驗。這無形中也提高了用戶的使用成本。

個體識別度：中

便捷程度：中

技術要求：中

風險程度：中

三、證件信息

包括的注冊登錄方式：實名注冊登錄；護照注冊登錄；學生證驗證等

證件作為國家采信的身份校驗信息，符合校驗信息的基本要求。然而有兩個特點限制了他的使用場景，一是敏感性，作為個人身份標識，在網絡安全還比較初級的今天用戶一般不愿透露；二是復雜性，由于國家需要區分的用戶數量之大，導致區分方式會非常復雜，用戶記憶的成本很高。另由于個人信息安全目前極易泄露，導致目前用戶需要以證件號碼及特殊姿勢手持證件照相的形式進行驗證，導致便捷程度極低。這使得該方式也不會成為一種非常通用的方式。

個體識別度：高

便捷程度：低

技術要求：中

風險程度：中

四、生物特征

包括的注冊登錄方式：指紋登錄；虹膜登錄；語音音頻登錄，人臉識別等

理論上完美的實現方式?；旧夏軌驅崿F實人與網絡的連接?，F在的問題在于兩個點，一是技術手段瓶頸；二是可識別性仍有待開發空間。找到人體上最獨一無二的地方，再使用他進行便利的驗證。能夠實現的話就是驗證方式的終極了。目前蘋果的指紋登錄，騰訊的聲音鎖，支付寶的人臉識別等功能正是向終極邁進的方向。

個體識別度：高

便捷程度：高

技術要求：高

風險程度：低

另外目前比較流行的掃碼登錄，三方登錄是基于以上幾種校驗方式進行授權的登錄方式，屬于增加用戶多端登錄便捷性的行為，本質上不屬于驗證方式。

總結：

在服務對象中覆蓋率高、識別度高的方案，都可以作為驗證方式。

注冊登錄流程的演變是人性中懶惰的體現。

注冊登錄流程的演變與技術發展息息相關。

0X03 注冊登錄業務的產品流程設計

限于目前大多數公司的技術能力及業務場景，決定了大家主要采用手機號或者密碼作為驗證標識。在這種情況下，目前主流的注冊登錄產品實現方式為以下動作 時間點的組合：

按驗證動作分：

賬號密碼：

賬號密碼登錄：賬號 密碼

全球手機登錄：手機號 密碼

三方授權登錄：三方賬號 密碼

三方靜默登錄：三方賬號 密碼

手機驗證：

免密登錄：手機號 短信驗證碼

按驗證時間分：

進入應用前

后置流程中

我們先對其中的要素進行說明。

一、賬號密碼

我們來看賬號密碼方式的細分，還可按自有賬號體系以及三方登錄體系進行分類。實踐中當然也可以走組合拳的形式。

1）自有賬號體系流程：

優點：

• 注冊登錄環節的數據均在自己手中，可以獲得更多維度的用戶數據；
• 賬號體系外部依賴少，安全性較強。

缺點：

• 風控流程較多（驗證碼等），需要用戶操作的節點多；
• 需要自己設計風控流程及對抗性高的組件（圖形驗證碼等），成本較大。

2）三方賬號體系流程：

優點：

• 流程短，登錄速度快，注冊轉化率高，背靠三方豐富的用戶信息，有利于網站快速推廣；
• 能快速建立簡單的賬號體系，使用個體維度的信息；
• 與三方互相背書，可以增加在用戶心中的可信度；

缺點：

• 對外部依賴性較強。

特別需要注意的點：

三方登錄的流程最好不要再加額外流程，無論是填寫手機還是增加個人信息補充都會極大降低注冊轉化率，在用戶感知中甚至會比只有賬號流程還復雜，導致三方登錄主要的優點蕩然無存~

具體而言：

• 賬號密碼登錄：普通的賬號密碼登錄，不做贅述。
• 全球手機登錄：手機號 密碼，主要用于有國外用戶注冊登錄需要的賬號體系。
• 三方授權登錄：三方賬號 密碼，需要用戶進行一次授權后使用三方賬號快速注冊登錄。
• 三方靜默登錄：在已登錄三方賬號的情況下靜默使用三方賬號注冊及登錄。

二、手機驗證

優點：

• 登錄便捷，轉化率高。

缺點：

• 運營商二次放號問題是個坑，需要有流程進行判斷；
• 短信費用的預算問題需要考慮；
• 需要準備至少兩個短信通道，以防出現短信通道堵塞或熔斷等導致用戶無法順利注冊的情況。

三、驗證時間

按登錄注冊頁面出現的時間點劃分，一般分為兩種：進入應用前及后置節點中。各有利弊。

1.進入應用前

優點：注冊入口少，維護成本低；用戶信息全面，需要信息可一次收集完畢

缺點：用戶體驗差，在用戶沒有體驗服務的情況下需要注冊，容易造成用戶流失

2. 后置流程

優點：用戶體驗佳，對用戶來說流失成本較高

缺點：入口多，維護成本較大；需要進行全盤規劃才能做好；用戶信息需要分多環節收集

以上的各種要素都是可以同時并存的，不存在互斥關系。應用內可以提供多種注冊登錄方式可供選擇。

最適合的方式？

但這么多種登錄注冊方式中，那一種才是最適合自己的呢？

注冊登錄流程的選擇，是流量需求與風控需求的博弈。注冊登錄環節作為流量漏斗的重要一環，對注冊成功率，各種轉化率的直接影響非常大，因此流量的主要主張為，盡可能縮短流程，降低流程損耗；減少用戶不必要的操作，確保流程流暢；登錄注冊流程盡可能后置，增加客戶留存；而同時注冊登錄流程作為站內用戶的入口環節，對風控來說勢必是不可放松的閘口。其主要主張為，風控組件盡可能多，登錄注冊流程盡可能前置，以及盡可能延長流程，使用戶在該環節留下更多數據供其進行判斷。

利害相關方的肯定都會舉出非常有力的證據來說明利弊，但作為用戶產品，在選擇注冊登錄流程時，更重要的是看具體的行業需要，公司發展階段，及具體渠道需要而定，不能因為業務方的影響而隨意調整流程。

一、行業

不同的行業，面臨的流量與風控的要求不同。如上圖所示，不同的行業由于業務場景的不同需要選擇不同的注冊登錄流程。越接近流量導向，則注冊登錄流程越短（甚至無需注冊登錄亦能享受服務），注冊登錄流程后置可能性加大；越靠近風控導向，則注冊登錄流程越長，注冊登錄流程后置可能性變小。當公司產生發展方向調整的時候，注冊登錄流程也需要進行相應調整。

二、公司發展階段

不同的公司發展階段，也是一樣的道理。發展初期，由于面臨巨大的流量壓力，對更偏向于選擇短平快的，快速搭建賬號體系的方式；發展后期，不管是出于業務拓展，為轉型準備、精確營銷及增加手中數據價值等等的考慮，往往會考慮自建賬號體系，使用自己的注冊登錄流程。

三、具體渠道業務定位

以電商行業舉例，APP，PC及H5，外投渠道，這些渠道承載的使命是不同的，因此如果有必要，也應該根據他們的定位進行符合要求的注冊登錄流程設計，最大化的發揮渠道效果。APP及PC，由于相對來說面向用戶主要以成熟用戶，老用戶為主，功能更加全面，也有包括資產管理等安全要求較高的模塊，因此對這些渠道來說，是需要走相對長的注冊及登錄流程的；至于H5及外投渠道，由于更輕量化，更側重于引導快速交易，因此更傾向于流程后置，縮短流程，減少用戶損耗。

因此需要看下，自己的行業是偏流量導向還是風控導向，公司發展階段如何，具體渠道的業務形式，才可以從上面不同的賬號注冊登錄形式中，選出最適合自己的方式，再進行逆向流程的補充，UI交互的打磨，形成最適合自己的注冊登錄流程。

需要說明的一點是，注冊登錄流程不是一成不變的，在發展的不同階段，有可能會適當的進行調整。甚至于，在同一階段，針對不同渠道的需求，也需要靈活處理。如何做好規劃，這是用戶產品經理的工作重點。

總結：

注冊登錄流程并不是所有應用的標配。

注冊登錄流程不是一成不變的，需要根據所處行業，發展階段及渠道進行判斷。

適合自己的，才是最好的。

0X04 注冊登錄業務的基本要求

作為負責用戶相關的產品經理，我對其中注冊登錄業務的基本要求定為以下三點：

1.穩定性：

首先，穩定性作為用戶業務的核心，是需要重點保證的。電商中，雙十一、雙十二，日常大促等均會出現高峰值用戶注冊登錄請求，一旦注冊登錄業務跪了，后面做的再好也是白搭。

主要從以下幾方面提高穩定性水平：提高架構合理性；日常進行穩定性檢查；大促前壓測；穩定性預案到位等等。

2. 通用性：

通用性并不是每個APP都需要做的，只是我們公司旗下APP有點多（類似盛大，數量多得我考慮過通行證的架構），所以作為負責整條用戶業務線的產品，需要在通用性上下功夫，做好整體規劃。這樣可以減少代碼開發及維護成本的同時，提高流程的可復用性。

主要從以下幾方面提高通用性水平：解耦風控業務（歷史包袱丟開~）；組件化開發，流程可選配。

3. 支撐性：

支撐性是指如何更好的支撐其他業務方工作開展。前期發展速度較快，接入流程不太規范，容易增加后續額外開發成本。因此提高支撐性的首要任務是增加開發及業務接入規范，包括工程及數據層面的規范，從而更快、更好的實現對業務方的支撐。

不同公司的注冊登錄業務基本要求需要case by case進行分析，這里只是拋磚引玉，歡迎探討。限于篇幅，這部分就簡單提及，以后有心得再做分享。

文章有點長，看到結尾的都是真愛~感謝大家，比心~

相關閱讀：

如何設計一個 App 的注冊登錄流程？

登錄注冊產品需求自檢清單，你都寫全了沒？

真實案例分享｜登錄注冊產品需求文檔

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