文章對登錄方式進(jìn)行簡單的分析，希望能夠加深你對登錄方式的進(jìn)一步認(rèn)知。

如今手機一打開，看一下自己的軟件商城，各式各樣各種種類的APP琳瑯滿目，讓人應(yīng)接不暇，但是作為使用APP的用戶的角度來看，絕大多數(shù)人注意到的是APP的內(nèi)容，忽略了各式各種種類的APP其實在登錄方式這一塊也是有著明顯的區(qū)別。登錄注冊方式的設(shè)計在一定程度上面也會影響到往后用戶的體驗以及反映公司要獲取用戶信息資料的深淺程度。

因此，如何為自己的APP定位一下用什么登錄方式進(jìn)行登錄呢？為什么用這樣的方式登錄呢？這種登錄方式對用戶以及公司各能帶來什么好處？…….要解決以上種種問題，就得先來分析登錄功能這個的價值。

一、登錄方式的三層面分析

我們從三個層面行進(jìn)登錄方式的分析：

用戶層面

用戶需要一個特定的ID，為其記錄自己存儲的資料，使用的進(jìn)度，收藏的功能、

用戶希望登錄注冊之后，產(chǎn)品可以給用戶推薦更加人性化的服務(wù)，例如根據(jù)自己在平臺瀏覽過的東西，根據(jù)大數(shù)據(jù)給用戶推送自己需要的，想要尋找的產(chǎn)品

在社交類的APP里面，用戶更加希望自己可以在合理的情況下，獲取其他線上好友的真實資料，以便進(jìn)一步的交往。。

功能層面

便于跨設(shè)備同步數(shù)據(jù)，也便于在同一個設(shè)備中隨意切換不同賬戶，并且保持賬戶里面儲存的數(shù)據(jù)狀態(tài)

有社交功能的產(chǎn)品在編寫UGC時，用戶使用電商產(chǎn)品下單購買時，也需要一個登錄注冊的方式來保證UGC的內(nèi)容的辨識度（即這個內(nèi)容是由”我“產(chǎn)生的），以及賬號的安全性

有應(yīng)用內(nèi)付費，VIP會員增值功能的產(chǎn)品，注冊登錄可以確保用戶的權(quán)益

業(yè)務(wù)層面

對于一些像理財，外賣，電商之類的產(chǎn)品，需要詳細(xì)清楚自己用戶的詳細(xì)資料，如真實姓名，手機號碼甚至是具體地址等，注冊完成之后便于推進(jìn)運營的數(shù)據(jù)，以及指導(dǎo)運營的大致方向：如獲取了手機號碼之后可以在各大節(jié)假日或者公司周年慶的時候給用戶發(fā)各種營銷短信從而起到吸引用戶的效果。

總之一句話，在設(shè)計具體功能的時候，產(chǎn)品經(jīng)理應(yīng)該先從上面三個層面進(jìn)行考慮，明確自己的產(chǎn)品的定位什么，為什么消費者服務(wù)，他們這些人的需求點，痛點是什么，以及如何讓這個設(shè)計出來的功能可以更好的服務(wù)于公司的利益層面，為公司在合理的條件下獲取到更有用的信息。

二、常用的幾種登錄方式

我來說說現(xiàn)階段比較常用的四種登錄方式以及他們各自的優(yōu)缺點：

1、手機號碼+驗證碼

優(yōu)勢：移動端基本采用的都是這一種方式，可以掌握用戶的真實信息，有效增強用戶管理，對以后的用戶運營工作很有幫助，就像我上面說的一樣，可以在各大節(jié)假日或者公司周年慶的時候，根據(jù)運營的實際情況，第一時間給用戶發(fā)送短信，增加用戶的參與度以及轉(zhuǎn)化率：甚至對于一些較少上線的用戶，也可以通過給用戶發(fā)送短信吸引這些用戶的回歸，產(chǎn)生一種：回來看看這款產(chǎn)品有沒有發(fā)生新變化的想法

缺點：用戶在采用這種登錄方式時候，一般是五步走：

輸入自己的手機號碼–獲取驗證碼–切換屏幕查看驗證碼–切換屏幕回來–手動輸入驗證碼–登錄

在這個登錄過程中，極容易產(chǎn)生反感情緒，會覺得來回切換很麻煩。

好在現(xiàn)在很多APP都是只需要登錄一次，就長時間登陸，不需要頻繁操作，用戶的反感度就會減輕不少。

評價：該登錄方式可以掌握用戶真實信息，增強用戶管理，易于推進(jìn)運營的工作，適合于外賣，電商，理財類的產(chǎn)品。

該圖截至于小紅書APP，可以看出小紅書這邊就是主推手機號碼登錄，次推密碼登錄。大家可以多去下載幾個電商類的APP，自行體驗一下登錄方式的主推次推分別是什么。

2、第三方登錄（微信/微博/QQ）

優(yōu)勢：相對于手機驗證碼登錄來說，第三方登錄方式無疑是更加方便，最省用戶時間的一種登錄方式，且這種登錄方式將有效性，安全性的問題交給第三方，不需要在這一塊多花力氣，有一種借力的感覺

缺點：無法獲得有價值的用戶信息，同時無法構(gòu)建用戶的管理體系，這種登錄方式最多就是獲取用戶在第三方的用戶名，頭像，性別等等比較淺層的信息，至于像用戶在第三方更深入的資料，一般都是獲取不到的。

所以針對這種情況，一般該類產(chǎn)品會結(jié)合自身的產(chǎn)品屬性以及運營的要求，在用戶使用第三方登錄的時候，會設(shè)置一個場景，去引導(dǎo)用戶在頁面里面行進(jìn)手機號碼的綁定，如：

第三方登錄–首頁引導(dǎo)用戶新手大禮包的獲取–新手大禮包頁面–綁定手機號碼

評價：第三方登錄更加方便便捷，而且第三方大多數(shù)用戶都會使用到，沒有過多限制，但是能獲取的用戶東西往往比較局限，淺面。如果需要更多的東西，還是需要引導(dǎo)用戶去進(jìn)行手機號碼綁定操作的。這種登錄方式更加適合安全性，保密性不需要太強的音樂類，視頻類產(chǎn)品，或者一些小游戲類產(chǎn)品。

這邊我列舉的是愛奇藝的一個截圖，可以看到，他其他登錄方式特別多，有6種第三方登錄的模式可夠選擇。

3、賬號密碼登錄

賬號密碼登錄應(yīng)該算是一種比較古老的登錄方式了，它從在PC端的時候就已經(jīng)跟郵箱賬號登錄一起存在了，現(xiàn)在的移動端產(chǎn)品正有一種慢慢弱化掉賬號密碼登錄這一種方式，成為了次推的登錄方式了。

優(yōu)點：當(dāng)用戶手機不在身邊，或者手機沒電的時候，是無法獲取驗證碼信息的，這種情況下賬號密碼登錄就會顯得極為好用了。

缺點：移動端比較少出現(xiàn)賬號注冊，賬號注冊方式向?qū)Ρ扰c之前倆種更為麻煩。而且現(xiàn)在隨著共享經(jīng)濟(jì)的流行，共享充電寶也逐漸出現(xiàn)在大眾的視野里面，這種手機沒電的尷尬情況也會逐漸減少，這種登錄方式也會慢慢淡出人們的視線吧。

評價：賬號密碼登錄從在PC端登錄方式的主流慢慢變成移動端登錄的次推。但在一定情況下還是有它存在的價值。

4、郵箱賬號登錄

其實現(xiàn)在賬號登錄真的是很少很少用人再用了，除了像網(wǎng)易之類的從做郵箱起步的有自己用戶的大基數(shù)的公司在使用之外，他也是慢慢淡出了人們的視線。這種登錄方式一般不太適合國人的使用習(xí)慣，體驗比較差，而外國人就有使用郵箱登錄的習(xí)慣。當(dāng)然，一些商務(wù)類的APP，用戶群體鎖定為職場人士，這些人就會有使用郵箱的習(xí)慣。

評價：使用這種方式登錄時要重點側(cè)重用戶習(xí)慣，確定好產(chǎn)品的目標(biāo)受眾，更適合像商務(wù)型APP，學(xué)習(xí)型APP的使用。

5、登錄的新趨勢

語音登錄，手勢登錄，指紋登錄……就不一一展開了。有興趣的朋友可以多把弄一些比較新穎的APP，看看別人的產(chǎn)品設(shè)計。

三、觸發(fā)登錄的時機

只有充分了解到在什么情況下面會觸發(fā)登錄，產(chǎn)品經(jīng)理才能更好的做好一系列的登錄流程，在提供的PRD文檔中才不會寫漏，被程序員懟…..耐心，仔細(xì)，邏輯性也是產(chǎn)品經(jīng)理必備的素質(zhì)。我將簡單的在下面幾點新人們介紹一下有什么場景：

1、正式進(jìn)入APP前強制登錄

解釋：打開APP時必須登錄，不然沒法進(jìn)入App

場景：

• 第一次下載APP，沒登錄狀態(tài)
• 用戶使用過APP，手動登出，想再次進(jìn)入App
• 用戶已經(jīng)登錄過APP，但是太久太久沒點進(jìn)去看的時候

2、進(jìn)入APP之后操作某種功能觸發(fā)登錄

解釋：進(jìn)入APP后，操作某種功能即彈出需要登錄的頁面，不登陸即無法在進(jìn)行下一步的操作

場景：獲取本身賬號存儲的數(shù)據(jù)或者像系統(tǒng)輸入數(shù)據(jù)的時候，這類操作就會觸發(fā)登錄。

這種觸發(fā)登錄的時機的例子實在太多太多，我就不一一拿出來說明了。有興趣的人可以隨便打開一個自己的APP，退出登錄界面再點進(jìn)去，操作幾遍，留意一下這些時機會在哪里觸發(fā)。我推薦幾個APP給你們體驗一下。

• 資訊類：知乎，今日頭條
• 社交類：陌陌 ，微信
• o2o：餓了么，大眾點評
• 金融類：支付寶，招商銀行

……

嗯，在這一點我想補充一句話，就是一般登錄成功之后，我們的產(chǎn)品APP必須遵循“從哪里來就到哪里去”的原則，即用戶是在哪個頁面引導(dǎo)到登錄界面，那么登錄成功之后應(yīng)該跳轉(zhuǎn)的也是用戶過來的界面。

雖然市場上很多APP都是登錄成功后直接跳轉(zhuǎn)到個人中心頁面，但是我覺得一切還是要以用戶初心為標(biāo)準(zhǔn)，讓他哪里來的，就回哪里去。

今天就更到這里，下次來談一下注冊應(yīng)該注意的事項。

本文由 @nosomebody? 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議