App 註冊步驟如何優化？
【問題拋出】如何優化一個APP的註冊步驟?
【問題描述】：我們看到現在註冊一個App，第一步：填手機；第二步：填驗證碼；第三步：填昵稱，密碼，頭像；步驟倒是沒錯，可我看到為什麼要分頁呢？這個流程一定要像做任務一樣去設計嗎？從場景使用上來看：我註冊一個賬號，憑什麼逗我說這是一個流程，我要的只是一個動作而已。由此可見，註冊仍然具有優化的空間。【提問對象】各位用戶體驗設計和交互社交師們，以及產品經理們來討論討論吧。
將註冊與信息補全分離。
註冊的目標是：用戶擁有與設備無關的唯一識別的ID。
信息補全的目標：補充基本信息，做內容/用戶推薦等。
信息補全的部分，可以放置在必要的時刻進行引導，如發布內容、關注好友進行引導或者強制填寫。這樣避免了冗長的註冊流程。
註冊，要儘可能的簡單，取決於產品設計中User模型的基本屬性都有哪些。
郵箱、手機號、密碼、昵稱......要搞清楚哪些內容是你的產品模型中必不可缺的部分。可以使用手機號/郵箱等先對昵稱進行填充等手段，減少用戶註冊時填寫的內容量。通過第三方賬號登錄，一般可以獲取比較多的個人信息，關係鏈甚至郵箱。
不過鑒於新浪微博API不斷收緊，還是不要太過依賴這些。第三方登錄也不要做太多，微博、微信、QQ足矣。
======
話說註冊做的再簡單，也就只能跟登錄一樣。
之前嘗試了將手機號登錄與註冊合併在一起的做法，貌似也沒什麼問題。
提一下美麗說，十分欣賞它的一鍵註冊，幾十秒就自動註冊成功。
如果沒有大數據的支持，那麼也就沒有所謂的註冊優化。無非就是分步進行。
但是如果真的要使用急劇簡化的方式有一個思路如下：
註冊
1，點擊註冊 2，設備進行識別 PhoneNum，Imei 3，用戶點擊確認註冊 4，上傳至伺服器，並發送簡訊至該PhoneNum 5，用戶進行簡訊驗證確認 6，註冊完成。登陸
1，用戶點擊登陸
2，輸出手機號碼 3，設備識別Imei並進行服務確認 4，完成登陸那麼就是說將用戶的手機號碼作為默認帳號，Imei作為默認的密碼。用戶的密碼只能通過設備進行識別。如果換了設備就永遠不可能再使用該手機號碼進行登陸。大用戶情況也涉及到手機號碼不再使用進行更換密碼的情況。所謂的便捷只可能留下深坑。看了各位回答，我感覺在app註冊方面已經說的很多了，既有圖，也有文。
我想從另一角度來說一下。題主的問題是app註冊步驟如何優化，結合描述信息。我換個說法來提這個問題。現在app應用的註冊流程太麻煩了，很多因為用戶因為註冊而流失了，我們不想因為註冊影響用戶，怎麼辦？自問自答，這裡有兩限定條件
1、APP應用，所以不是web論壇類的2、註冊流程優化的目的是不希望用戶「跑」掉如果沒問題，那麼我就成功的「偷梁換柱」了，呵呵。不過我認為我並沒有曲解題主的問題。既然目的是不希望用戶因為註冊而流失，那麼我們是否可以考慮，把註冊環節作為一個整體來考慮呢？我覺得是完全可以的。用戶你不是嫌註冊麻煩嗎，好那咱就先不註冊，你先用，可勁的用我的APP，等你用的已經離不開的時候，就算我不讓你註冊，你都不樂意了。這招夠狠吧。已經有很多應用在使用了。下面就先舉兩個例子1、搜狐視頻
隨便截了張圖，看到那個登錄了嗎？對了，就是那裡！登錄之後可以同步上去。這裡有一個坑，過會說
2、果殼網的app
同樣，登錄註冊也隱藏的很深，不註冊的情況下，收藏、使用一點兒也不影響。我剛開始看的時候甚至有點驚訝，app的註冊放到這裡，會不會影響用戶註冊的熱情呢。後來發現擔心完全多餘，當你想註冊的時候，自然會去找。
上面兩個例子隨便找的，現在很多app都是這樣設計的，我叫做「先嘗後買」。這裡就又要回去看我們之前的兩個條件了，條件1，必須是app。為什麼呢，因為app是安裝在用戶手機上的，是有本地存儲的，可以少使用，甚至在離線狀態下讓用戶使用，這裡和「web」是有本質區別的。所以在app的模式里，是完全有可能使用「先嘗後買」方式「粘住」用戶的。我們倒著說，下面再看看那些app適合這樣使用，這就涉及的app的分類了。
UGC現在已經不能用火來形容了。100個app里，得有90個都要引入UGC的，就算開始不用，改版只有也肯定要規劃的。所以說起app就不能迴避ugc。按說只要涉及到社區，論壇，評論，歷史記錄等等都需要用戶註冊，但是其實我們看看是否都需要用戶立即註冊呢。我粗略的想了一下，只要不是純社交類的，或者說主要是社交類的都可以先不註冊。工具類的，影視類的，公知類等等吧，比如圖片處理（各種美圖什麼的），視頻觀看（各種網路視頻），知乎日報，果殼等等吧，這些app用戶安裝之後，要麼當個工具用，要不就是公司已經提供了資源（比如電影電視劇）。就算知乎，果殼這樣強UGC的，也可以允許用戶查看別人的問題和回答，就好像百度，google一樣，不註冊你照樣使用。這點很重要，這極大的延伸了不需要註冊就能使用的app的範圍。很多很有實力的web服務，都可以移植到app里，因為他們在web版本里已經有很豐富的內容了，app就是一個展現的渠道。比如很多很有名的論壇網站。總結吧。註冊確實很麻煩，而且容易引起用戶反感，如果註冊本身只是阻礙而不是目的的話，我們是否可以考慮繞過或弱化它，基於上述思想。我考慮把註冊從使用流程中拿出來，作為一個功能單獨實現。這樣可以極大的減小它對用戶使用的影響。以上。我覺得大家都是從怎麼設計註冊去考慮，是否考慮一個更本質的問題，你的app在用戶心中是什麼位置，或者你要達到什麼樣的用戶粘度，只有明確了這些談設計才更有意義吧！參考頁游或者部分手游，初期為了獲得用戶量，一般註冊比較簡單，或者直接生成用戶。但對於想要長期留住用戶的app就要結合自身的能力，指的是有沒有這麼大的吸引力讓用戶填寫那麼多信息，如果是強關係的應用，那用戶自然願意多填寫信息，如果是相對較弱的關係，用戶自然對繁瑣的註冊信息反感！拋磚引玉，希望看到更好的理解！
之前自己也考慮過一些優化流程，看了一些案例和經驗
因為我們非常流氓的想得到用戶的手機號碼，所以在第三方登陸裡面流程二當中強行讓用戶綁定，假如你想再繼續降低門檻，直接第三方登陸就好了。
總結在這個流程裡面，結合登陸註冊頁面。在一個頁面裡面完成註冊或者登陸。放出第三方登陸通道，補上我們想讓用戶綁定的是手機或者郵箱。結合商業性和降低門檻。不註冊。
直接使用設備ID生成賬號。用戶名和頭像什麼的可以在app賬號設置裡面單獨設置（並不強求用戶設置）如果用戶只用一個設備，那麼到這就結束了。
但是我們必須考慮用戶換設備的需求。
兩個方案：1. Email（手機號）綁定用戶點擊綁定，然後開始一個和註冊無異的綁定過程，之後可以通過Email（手機號）登錄。只在用戶需要的時候綁定一次。2. 生成更換設備用的一次性繼承碼很多日式手游都採用這種方式。生成出一個唯一的一段時間內有效的繼承碼，在另一個設備上輸入。然後原設備賬號自動失效，賬號轉到新設備上。用戶每次轉換設備都需要進行一次這個過程。這兩種方案可以同時採用。在某BAT用戶增長組做過2年產品，主要做的就是註冊方面。
先針對樓主的問題說下自己的看法，APP註冊信息分步的原因是：
1、每次都分步可以減少用戶點擊輸入框的次數（比如註冊分為手機號、密碼、手機驗證碼，分成3個頁面的話，進入每個頁面都會自動置入焦點並彈出鍵盤，減少用戶手動置入輸入框的次數）2、不需要用戶手動點擊「獲取簡訊驗證碼」按鈕，因為輸入手機號再進入手機驗證頁面，自動將簡訊發到用戶手機中3、手機屏幕小，加上彈出的鍵盤，放多個輸入項在一個頁面感覺很擁擠4、註冊分步降低流失率，比如用戶上來看到很多輸入項，可能就流失掉了至於分步和不分步註冊轉化率的數據對比，我可以很明確的告訴大家分步的轉化率會高些。我們公司做過A/B test，大家也可以看看facebook APP的註冊流程，也是分步的。facebook用戶增長方面的研究是世界上最專業的。? Android Design in Action —— 初期體驗 鋒客網
只有一個手機號和手機驗證碼輸入框。將登錄、註冊、找回密碼三合一，用戶輸入手機號和正確的手機驗證碼後，進行判斷：
如果手機號已註冊，則登錄相應帳號手機號未註冊，則註冊並登錄。如果你的產品需要一些必填信息，則註冊後進入完善資料頁面之所以需要用手機號生成個uid，原因如下：
1、不同設備，通過同一個手機號可以進入相同的帳號2、有了手機號，可以後續召回用戶至於非必填資料，可以通過場景引導用戶填寫，不必要和註冊混在一起。註冊只是使用你產品的一個鑰匙。
另外不建議第三方登錄，因為第三方平台不會把用戶的郵箱或手機號給你，所以很多第三方登錄都是脫了褲子放屁，第三方登錄後還要在輸入手機號、郵箱並驗證，就是多獲得個第三方頭像或昵稱而已，這樣反而使註冊流程更為複雜，增加流失率。看了幾個答案都沒有提到一個坑：所有的試圖不註冊或者使用第三方賬號登錄替代註冊的，最終都會回歸到正常的註冊流程，並且因為第三方賬號綁定帶來的合併賬號等問題。當然你產品沒做起來，可能就到不了後面這步了。
註冊流程可以簡化，並不意味著可以替代。
這裡面的坑太多了，很多「知名」網站都犯過：http://guang.com後來不得不提供的合併賬號；http://chanyouji.com的純銀覺得用第三方登錄怎麼怎麼好，現在還不得提供郵箱註冊。。。
至於這裡面的原因，有時間就來講。如果是數據派的，我推薦嘗試一下A/B測試的方法來試試
什麼是 A/B 測試？ - Mil Max 的回答
-----------接下來是廣告時間-------------
http://AppAdhoc.com：吆喝科技開發的在線AB測試平台，用數據幫助開發者優化產品，是國內唯一同時支持前端（Web/H5、iOS、Android）及後端（Node.js、PHP、Java）AB測試服務的專業Saas平台。
平台特色：線上灰度發布、多維度數據統計分析、定向測試等等。
通過AB測試來優化產品的方法在海外已經被廣泛應用，現在這種代表先進生產力的方法如同GitHub、Docker、APM一樣也正在逐漸被國內廣大開發團隊所接納。AppAdhoc優化平台能夠幫助用戶提高產品的設計、研發、運營和營銷的效率，降低產品決策風險，同時也能夠幫助用戶用數據優化移動廣告，讓流量的變現價值更大。
不同類型的產品，側重點不一樣。
以我們的產品為例：
產品名稱一倍半——跳槽專用APP產品描述：用戶在app上填寫簡單的個人背景和求職意願（最快30秒內可以完成），我們就推薦合適的職位、hr或者獵頭與其對接。
為什麼使用社交登錄？
使用社交註冊顯而易見的好處是：快，安全，無需驗證，可信度高，記憶成本低。為什麼使用微博，linkedin和qq這三個社交登錄？這是一個求職產品，必然需要用戶提供一些基本的信息，比如：公司名稱，所在城市等。如果在註冊的同時能夠提供這些信息，必然降低之後用戶的使用成本。求職類產品的門檻是所有互聯網中最高的，因為傳統的思維是要求職，先要有簡歷。我們的產品試圖打破這個障礙。我們在權衡：1）獲得必要信息 2）降低註冊成本（註冊時間＋操作次數）
linkedin：授權信息的質量最高，但是國內的用戶量偏低，移動端下載量更低。微博：授權信息的質量一般，國內的用戶量一般，移動端下載量一般。qq：授權信息的質量較差，國內的用戶量無敵，移動端的下載量很高。為什麼不使用郵箱註冊？
任何要求在手機上填寫郵箱的操作都是愚蠢的，如果還要驗證，就是反人性的。當然如果用戶的移動設備上沒有處於登錄狀態的以上三個社交軟體之一，選擇社交登錄依然是要輸入郵箱和密碼。但是，至少不需要驗證。為什麼不使用手機註冊？
1、發簡訊驗證碼有一定成本。小公司暫時不考慮花這個錢2、一上來就跟用戶要手機號，增加用戶的心理負擔。尤其是不知名的產品，剛開始難以獲得信任。當然這種情況會越來越得到緩解，用手機號註冊似乎也是趨勢。僅僅使用這三個社交登錄會有什麼問題？
1、穩定性：受制於第三方的授權登錄，總是有不可控的問題。偶爾token獲取失敗2、唯一性：這裡的唯一性不是只註冊id的唯一性，而是指同一個用戶使用賬戶的唯一性。比如，一個用戶第一次用linkedin授權登錄，而第二次卻使用了qq進行登錄。這相當於創建了一個新的賬戶。雖然社交登錄減輕了用戶註冊已經記憶密碼的負擔，但是用戶得記住第一次所選擇的社交授權方式。多種註冊路徑必然要解決好賬號關聯問題。為什麼會出現「註冊／登錄」這個button？
簡單說，從這個入口進去就可以直接使用我們產品了。出現這個選項的原因是，僅有第三方授權登錄無法通過app store的審核，審核人員要求我們提供自己的註冊／登錄選項。就註冊登錄這一塊最近還在優化。
不同類型的產品，側重點不一樣。需要在大的需求背景當中去考慮。優化註冊步驟，你想問的，如何精簡吧？！
或者定義： 怎麼以更少的步驟，讓用戶註冊進來？答案比較唯一：手機驗證登陸或者第三方登錄驗證，簡訊和網路正常的情況下，是目前最快的方式；弱優先順序的資料完善，後續提示完善即可（再不濟，積分獎勵嘛）；
但是：
問題和描述，完全不是一個意思呀！問題和描述，完全不是一個意思呀！問題和描述，完全不是一個意思呀！你看到的那個app（雖然你沒說），應該是有社交屬性的吧，告訴你一個運營的小結論：
上傳頭像，能有效提高社區的留存率和活躍度，所以會千方百計讓你填頭像！上傳頭像，能有效提高社區的留存率和活躍度，所以會千方百計讓你填頭像！上傳頭像，能有效提高社區的留存率和活躍度，所以會千方百計讓你填頭像！也避免了大量用戶湧入，破壞社區氣氛；
也避免了大量用戶湧入，破壞社區氣氛；也避免了大量用戶湧入，破壞社區氣氛；——梳理問題的邏輯是應該的，下次加油喲。。。同一個功能，多對比不同用戶群的app1.不註冊
自動識別設備（MAC地址之類的），需要許可權，不支持設備轉換，其實微信用得忘記賬號密碼了2.第三方快捷登陸
受制於人3.簡化註冊流程
註冊賬號密碼後直接進入，其他流程全部丟到設置中4.一般註冊
流程化為何分頁？表單一頁不夠用，表單複雜需要填寫大量內容，容易嚇跑用戶，一頁一個任務看起來比較容易完成註冊這個需要和業務一起考慮的，mark一下，白天再答.....
--------------------------------------------------------------------------註冊是個很麻煩的事情，對用戶來說「這只是一個動作」而已，但是對於公司來說確是一個十分頭疼的問題，這涉及到帳號體系的建立。數據層面上：產品是否需要用戶的基本數據。如果僅僅需要雙向認證，那麼只需提供ID和密碼就可以了，但是很多產品往往需要更多的東西，保證自身產品生態的良好運轉。例如：社交軟體，需要知道用戶的性別、昵稱、ID、密碼，這就需要在註冊時讓用戶填寫更多的內容。安全層面上：手機號+動態密碼極大的簡化了用戶註冊的流程，但是這加大了PHP注入的風險，純app的話倒是會好很多平台層面上：跨平台產品在設計流程的時候，需要同時兼顧到各平台的體驗，比如你在web上做郵箱認證，那麼你在app再做郵箱認證就會感覺怪怪的--------------------------------------------------------------------------下面說下我喜歡的方法：由於我做的產品是跨平台工具類的，所以一些使用設備碼的方法並不適用。我比較傾向於體驗式的註冊。1.體驗產品，輸入內容2.手機唯一性確認3.註冊成功4.即時提醒，引導用戶補充內容以上蘋果直接提供手機身份認證服務，從根本幹掉驗證碼。在步驟上簡化比視覺上簡化更有效果。
在未來，指紋密碼將取代文本密碼，也是不可逆轉的趨勢。指紋，需要考慮的因素還有很多，但是是一種思路。
弱賬號體系的，直接使用微信/微博登陸，或者直接讀取用戶的設備號碼（如IMEI/MAC等）生成一個賬號。
強賬號體系的，有兩種做法：1、（相對不流氓的）嘗試讀取用戶的手機號預填，讀取失敗則讓用戶手動填寫，點擊確認後，自動下發簡訊，自動讀取內容完成註冊，如果不能自動讀取到，則讓用戶手動填寫。2、（相對流氓的），直接利用用戶手機向伺服器發送一個隨機串，並用這個隨機串向伺服器查詢賬號信息，完成註冊。發送失敗轉1。
我們從一波活動，一次營銷，若干個燒錢渠道裡帶來了不菲的流量，可是其中卻有不少的流量沒有轉化成真實的用戶，蟬大師一直覺得，一款APP，不乏實現流量增長的方法，但如何留住他們?我們知道其中一個登陸註冊就不知擋住了多少用戶，基於此，現在就讓我們從APP的登陸註冊說起吧。
從我接觸互聯網開始，領導就跟我說，永遠不要讓用戶麻煩!無論是網站還是APP，網站這裡不談，重點說下APP吧，APP推廣俠們在費盡心機拉扯來了些流量後，用戶打開APP，首先看到的便是登陸註冊頁面，然後便是用戶選擇登陸方式了。
一般常見的登陸註冊方式有：
這四種登陸方式中，用戶體驗最好的個人認為是第三方登陸，如QQ登陸、微信登陸、微博登陸。為什麼?因為簡易了用戶的登陸環節，手機+驗證碼+密碼的方式用戶會想，我的手機號是不是有泄露的風險?手機丟了怎麼辦?在運營層面，用戶換了手機號是否會造成這類用戶的流失?郵箱+密碼的方式，用戶在輸入長長的郵箱地址時，會不會不淡定的選擇走人了事?不為別的，因為用戶怕麻煩。
第三方登陸方式相比以上三種做到讓用戶登陸註冊環節簡易化與便捷化
1、登陸即註冊，註冊即登陸
2、用戶無需記密碼與帳號
3、提高了日活與留存
要凡事利與弊總是相互依存的，相對於手機與郵箱濁的登陸註冊方式，第三方登陸雖然實現了簡易化，但卻讓我們無法更多的獲得用戶有價值的信息信息，據蟬大師所知，用第三方QQ登陸時，運營者是無法獲得用戶QQ號的。
所以如何選擇用戶登陸方式，關鍵在於我們想要的是什麼。比如QQ音樂支持QQ與微信註冊登陸，為什麼不支持手機登陸?又比如滴滴打車，必須手機驗證登陸，為什麼不選擇第三方登陸?有時候從競品身上去想問題，去分析自身，也是一個非常值得借鑒的方法。
關於完全放開註冊門檻
我們要優化註冊流程其實就是怕用戶跑掉，那好，我完全開放註冊門檻，用戶儘管用，當用到一段時間後，用戶喜歡產品了，離不開了，註冊其實就是一個簡單的事了，何況我們還能引導，不是嗎?比如工具類APP，遊戲類APP，閱讀類APP一般都支持遊客登陸，後續再適時的引導用戶進行註冊。
例子：小張去一家小商場買豆漿機，看中了一款豆漿機後，想試試這款豆漿機的使用情況，可是銷售員說，商場里暫時沒有可供現場使用的樣機，必須在小張買完後才能使用。為此，小張儘管很喜歡這台豆漿機但只得做罷。於是小張去了另一家大商場買豆漿機，這個商場的銷售員不僅僅當著小張的面試用了這款豆漿機(樣機)整個的使用流程，還貼心的告訴小張日常的使用技巧與注意事項，最後小張就選擇了購買這家商場的豆漿機。
其實APP支持遊客登陸與使用APP各項功能與上面這個例子其實並沒有本質的不同，總得讓用戶先看看吧。人家買東西還得先驗下貨呢。比如一款閱讀類APP，如果不支持遊客登陸瀏覽的話，用戶怎麼知道你的內容優質不優質?工具類APP也是如此，先完全放開註冊門檻，無需註冊即可瀏覽與使用部分功能，後面可適時引導用戶進行註冊。
APP新型登陸註冊
隨著移動互聯網技術不斷發展，其APP的登陸方式也迎來了變革，曾經在電影中看到的指紋、臉部識別等高科技也順勢運用到了APP的登陸方式中。比如大家的支付寶的登陸方式就有指紋識別與臉部識別。這類新型登陸方式較之傳統的登陸方式，給用戶的感覺是更新鮮、更安全、更快捷。
關於APP如何留住用戶的問題，今天簡單的和大家說一說APP註冊與登陸的選擇方式問題，雖然只是細微的一點，但我們在APP運營過程中，不就是要做好各種細節工作嗎?只有把我們細小的問題都做好了，大的方向，我們才能夠有收穫。
推薦閱讀：
※大數據類的產品經理要做哪些事情？
※夫妻都是產品經理/程序員是什麼感受？
※一個網頁如何決定是當前頁打開還是新窗口打開？
※互聯網產品經理每天都做啥？
※如何用數據驅動產品決策？