做爲一個互聯網產品,用戶量的增加是一個很是重要的衡量指標。 這是一個集合了銷售,市場,運營,技術的綜合能力。 本文將以非技術部分爲引子,而後落地爲技術方案,來針對 用戶增加 的目標來進行產品設計。git
互聯網產品實現用戶增加,最開始部分就是來自於市場和運營人員的工做。github
用戶增加的 非技術 工做有:算法
這部分非技術的工做落實到技術部分,就須要以下幾大系統作好支撐:瀏覽器
不管是哪一種技術方式,最後都會迴歸到一個很樸實地技術問題上面:「用戶的身份認證」。安全
目前對用戶的身份認證最基本的方法分爲以下三種:服務器
根據你所知道的信息來證實你的身份(what you know,你知道什麼), 好比:本身的人生經歷相關問答,還有帳號名和密碼微信
根據你所擁有的東西來證實你的身份(what you have,你擁有什麼), 好比:手機和U盾網絡
根據獨一無二的身體特徵來證實你的身份(what you are,你是誰), 好比:指紋,虹膜,面部特徵架構
以上三種方法中, 基於 信息祕密 和基於 生物特徵 分別因爲使用成本和認證成本的關係, 沒有成爲當今的主流,因此本文在內容安排上將重點講目前使用最普遍的 基於信任物體 的認證方式。app
基於信息祕密是傳統身份認證主要實現方法有兩種:
其中第1條,是在傳統的用戶註冊時身份認證最經常使用的方式,具備低成本和低平臺依賴性的特色。
在一些安全要求更嚴格的場景,則會啓用 「常見問題的問答」,好比:
最後的效果是:
可是這樣的反作用也特別明顯: 可能最後用戶本身也不記得本身設置的是什麼回答了, 其實這些問題本質上仍是設置的密碼。
此方法的特色:
目前普通網絡用戶能接觸到的常見的基於生物特徵的認證有:
在一些軍工或者金融系統裏面,更高級的生物特徵認證有:
這些都會涉及到更高級的傳感器或者更高級的軟件算法,基於成本的問題,通常級別的信息系統都沒有采用。
目前的一些廣義的 auth2.0 的方案基本上均可以概括爲此類。
此方法的特色是:認證方式能夠徹底拋棄密碼了。
關於 基於信任的物體 能夠借用去年熱播的電視劇 《琅琊榜》 裏面的一個橋段來解釋:
「朝堂上要爭論 ‘有罪的太子母親’ 是否有資格參加皇室大型祭祀活動的問題, 隱居山裏的 周玄清 先生是這個學術領域的泰斗, 可是通常人都沒法請他出山, 可是梅長蘇則經過他已故的師傅黎崇先生(和周先生是舊時摯友)的信物--玉蟬, 將周老先生請出山,在朝堂辯論中取得勝利」
轉化爲當下信息系統的身份認證的語言就是:
但願利用周玄清先生的能力去取得辯論的勝利。
梅長蘇面貌已經徹底變了,通常的舊人徹底認不出來。 固然像蒙大統領和霓凰郡主這樣可以深度學習, 從多個維度提取特徵,並最終認出易容後的男主,這個設定有點BUG。
周玄清信任舊時摯友黎崇
擁有玉蟬,基本上就等於和黎崇先生有非同尋常的關係
周玄清能夠在不須要黎崇親自出面的狀況下,見信物就「受權」給梅長蘇
梅長蘇在取得受權的狀況下,享受到了周先生的服務
在當今現實生活中 信任物體 有以下幾種表現形式:
其實的解釋就是:
本系統 信任 某個平臺或者設備, 用戶若是可以出具你在那個平臺上有帳號或者設備使用權限的證實, 那麼此用戶就能夠成爲本系統的用戶而直接進入本系統。
可以利用好目前已經有的一些可信平臺,或者可信設備,能夠自然導流並沉澱用戶到本身的系統中。
這些平臺或者設備要有以下前提條件:
目前符號這樣條件的基礎帳號有:
這幾種認證方式都是基於 "我擁有" 的原則來進行身份惟一性鑑定的。
傳遞信息的主流手段有以下幾種:
而後和接收帳號進行組合,獲得以下的驗證矩陣表:
備註: Y 表示存在此方法;N 表示不存在此方法。
接下來的內容將針對此部分的認證方式進行詳細分析和展開。
「數字驗證碼」 的基本原理是:
服務器生成一串數字串,而後將這個信息發送到能收到用戶接收信息的帳號上, 而後根據用戶獲取此數字串後的輸入作對比, 以確認用戶所擁有此帳號的信息獲取權限,從而完成受權。
一個由 「數字驗證碼」 做爲驗證方式的註冊系統, 其主要步驟以下:
服務端生成一個隨機數字串(通常是4到6位)
服務端將信息主動推送到用戶信息接收帳號(文字或者音頻)
用戶完成註冊,進入信息系統
固然不一樣的信息接收方式,也會有以下幾個維度的不一樣:
對每一個指標進行量化評分(1~5分),咱們能夠獲得以下的對比表:
收信載體覆蓋成本 :
毫無疑問手機號碼是覆蓋率最高的收集載體了,基本上不須要系統服務商去擔憂用戶覆蓋率的問題; 電子郵箱因爲QQ郵箱的功勞,在覆蓋率上也沒有太遜色;微信做爲裝機率極高的超級app,覆蓋率上也沒有太遜色。
認證帳號記憶成本 :
手機號碼是最容易被用戶記憶住;郵箱地址次之; 微信因爲只對第三方開放一個隨機長字符串,因此在第三方能得到的認證帳號是徹底沒有可記憶性的。
認證信息生成成本 :
認證信息獲取成本 :
認證信息使用成本 :
這三者都差很少,都是記住驗證碼,而後輸入驗證碼。
關係鏈獲取成本 :
若是不考慮關係鏈,又特別在乎成本問題,其實微信方式也是個不錯的選擇。
使用以下步驟能夠實現揚長避短:
本質上是:須要預先爲信息接收裝置綁定一個容易記憶的帳號。
基於 數字驗證碼 認證方法整個過程當中,交互過程以下:
評價:
主要原理:信息系統服務商將帶token的url發送到指定的信息接收裝置中, 而後用戶從信息接收裝置中直接點擊打開url請求數據,完成受權。
以移動app登陸場景爲例子,主要遵循以下步驟:
服務商向接收載體發送帶token的url
app使用token參數進行輪詢
只要輪詢檢查到url已經被請求過,則app認爲用戶認證經過
這實際上是對比短信驗證碼是更優秀的一種認證方式,由於它省去了用戶記憶驗證碼,和輸入難碼的環節。 整個驗證過程,交互動做以下:
評價:
此方法的缺點是:拋棄了那些使用連瀏覽器都沒法打開的老古董手機的用戶。 顯然按照目前的形勢來看,能夠不用考慮這部分稀缺用戶的感覺了。
這種方式應該是目前最早進的一種認證方式了,只是開發難度稍微高一些。 可是若是開發能力不是問題,仍是建議儘可能使用此方法。
微信提供了三個途徑來開放其用戶信息:
可是若是不限制第三方服務商的服務在微信瀏覽器裏面使用的話,則認證方法只剩兩種:
這兩種方式都很是值得技術人員去研究理解並學會鑑賞。
其主要門檻在於:
若是以上三條不存在問題,那麼建議首選此方法。
這兩類認證方法的步驟以下:
評價:
本文從「用戶快速增加」的 產品及運營目標 出發, 引出了「如何在技術上實現對用戶進行快速身份認證以減小用戶使用本系統門檻」的問題。 而後針對目前主流的一些認證技術和具體實踐中常見的認證明現方式進行了分析, 並針對目前最多見的 基於信任物體 的幾種具體認證方法進行了量化分析和評級。
最終的結論是: 微信的掃碼和app調用是最值得推薦的認證方式。
但願本文的 分析過程及分析結果 可以對你們在進行產品設計和技術選型時有所啓發。
本文主要解決在「利用現有的基礎信息平臺設施」的條件下信息系統關於用戶的兩個問題:
可是若是有更多的需求,例如,「對用戶進行詳細的權限角色限定」則須要開發商自行處理了。
開發商本身開發一個屬於本身信息體系的身份認證app, 從手機號碼/電子郵箱/微信這些帳號體系中完成自身app的 新用戶註冊和登陸功能 , 而後在app裏面進行角色和權限劃分。這樣能夠此app爲基礎,開發出針對本系統的不少特點的功能出來。
這就有點相似於:微信的註冊體系和登陸體系是依賴於手機號碼和短信的, 可是進入到微信系統後,它作出了掃碼登陸和調用app登陸這樣優秀體驗的認證方式。
最終若是app的功能足夠有特點,也一樣是可以把由第三方引入的用戶給沉澱下來,最終徹底脫離第三方。
app能夠做的功能有不少,例如:
等等,更多的功能就靠本身的想像力了。
做者: | Harmo哈莫 |
---|---|
做者介紹: | https://zhengwh.github.io |
技術博客: | http://www.cnblogs.com/beer |
Email: | dreamzsm@gmail.com |
QQ: | 1295351490 |
時間: | 2016-07 |
版權聲明: | 歡迎以學習交流爲目的讀者隨意轉載,可是請 【註明出處】 |
支持本文: | 若是文章對您有啓發,能夠點擊博客右下角的按鈕進行 【推薦】 |