回顧互聯網歷史，會發現賬號體系距離2000年已經大不相同，迭代的過程既有軟件的發展，也有硬件的升級。本文作者對賬號體系的變遷和設計思路進行了分析，一起來看一下吧。

一、賬號體系的變遷

這兩天在回顧互聯網歷史的時候，發現賬號體系距離2000年的時候發展太多，20年的時間仿佛彈指一揮間，中間迭代的過程，既有軟件的發展，也有硬件的升級，真的很有趣。

1. 用完即走的時代

自由、開放、共享，是那個時代對互聯網的定義，下載不需要注冊，看帖、回帖不需要注冊（當然那個年代的資源并不多），非常具有代表性的軟件就是BBS、電驢、bittorrent，無需注冊，開放即用，還記得1024嗎？一年僅有幾天開放注冊，但是不注冊也不影響你的瀏覽體驗，“我”和互聯網沒有任何綁定，擼完即走，我很希望未來有機會能重新回到這個時代。

2. 注冊時代的到來

也許是先驅們開始意識到用戶的價值，開始有賬號的概念了，沒錯，賬號就是為了抽象用戶而誕生的，在這個時代，主要通過郵箱（我本人用的是雅虎）、密保問題完成賬號維護的閉環（當然也可以郵件管理員完成部分功能維護），同時代的游戲開始用密?？ɑ蛘遀key進行賬號保護（夢幻西游的將軍令大家還有印象吧？）。

3. 電信驗證的日常

現在來看，這種注冊方式稀松平常，但是實際要這種注冊方式，遠并非人力所能及，需要等待市場和企業滿足以下要素：

• 手機的普及（手機都沒用怎么收驗證碼？用BB機好像也不是不行？）
• 運營商開始提供該種類的對外服務（和國企談創新服務很痛苦）
• 網站的經營者能夠承擔此項成本（早期這項服務可不便宜）

慶幸的是，時代的潮水來翻涌的特別快：塞班沒落，安卓和IOS的興起，移動互聯網飛速發展，不知不覺中，電信類的驗證已成為尋常服務。

4. 實名核身的今日

這個時代，“商業化”已經替代了“自由、開放、共享”，至于到底進步還是后退，留給后人評說，但無可爭議的是，賬號（背后所代表的是用戶）資產已經成為了互聯網企業最重要的2項虛擬資產之一（另一項是技術積累），而連接虛擬（互聯網賬號數據）與現實（核身用戶為真實的自然人）的技術，人臉核身，極大地影響了眾多互聯網服務。

后續我們也會提到人臉核身這項技術，是如何影響產品經理去重新設計賬號體系的。

二、從0開始設計一個賬號體系

1. 重新思考賬號的本質

大部分前臺應用可以抽象為：賬號+服務的集合，拿熟悉的X音APP來舉例，我登錄賬號，完成購買交易、視頻瀏覽等功能。

如此看來，賬號的本質是服務的對象。

如果服務的對象是企業，那么賬號就代表了法人主體；如果是自然人，就是一個實實在在的自然人。

基于這點，我們開始嘗試去描述一個賬號需要能完成哪些操作：

實際在某些場景下，身份驗證可以拿掉，但無疑，一個賬號體系的通用功能，絕不會太復雜。

接下來開始設計賬號創建/登錄功能，而有沒有“核身”的手段，對賬號創建、登錄的流程影響非常大（可能對現今階段設計沒啥影響，因為核身技術很成熟了，但是對比歷史很有趣，就稍微啰嗦下），在這里先簡單分析下實際核身技術在賬號體系實際操作過程中起到了什么樣的價值：

先舉2個代表性的例子進行對比。

1）某行早期用K寶的在線轉賬流程：

2）某行現今的在線轉賬流程：

結論：核身技術讓用戶減少了大量的輸入與操作。

可能文字的表達對比沒那么明顯，從數據側來對比更直觀點：

如果不是考慮到現在人臉核身的成功率不是100%的情況，其實連郵箱或者手機號都可以省略。

但實際設計中，采用方案2注冊/登錄方式的明顯較少（例如交管類app、某些銀行類app），按結果導向，方案2存在某些缺陷。

搞產品設計有一句老話：拋開實際場景談設計就是耍流氓。

方案2看起來體驗更好更簡單（好像挺符合奧卡姆剃刀原理），但是實操中卻有以下不足：

• 掃臉操作成本、費用成本更高：畢竟現在仍用許多超過40歲的用戶對這種操作摸不到頭腦（可能在大城市的白領們很難理解？但去四五線城市看看那里的叔叔阿姨就明白了）；
• 注冊門檻高：我就看個帖子，看個短視頻（以社交、內容為核心類的應用），為啥要我實名？更何況過渡收集客戶信息還有可能引發投訴；
• 影響流量買賣的固有結算模式（按注冊定價，如果換成核身注冊，無疑賣方的利潤空間會下降太多）。

基于以上的綜合考慮，我們可以設計一個能平衡以上各個因素的方案：

該模型將賬號分為三個模塊：

1. 賬號信息模塊，該模塊只用來描述賬號，和用戶本人是一對多的關系，一個人可以建立多個賬號；
2. 實名信息模塊，該賬號用來核身，和客戶是一對一的關系，一個客戶有且僅有一個實名身份；
3. 業務信息模塊，該模塊用來存放業務所需要的信息，舉個栗子，如果是X乎看個帖子，就不需要地址信息，因為提供內容給用戶不需要知道用戶的家庭地址；但如果是外賣應用，那就需要地址信息了，否則不知道將外賣送到哪里。這里的信息依賴于細分業務場景。

組成賬號的信息抽象完成（更細節的請基于各位產品同學的實際業務場景來填充設計），接下來設計建立賬號的流程：

這個流程更人性化，讓用戶有需求的時候再去完善信息，避免了強行手機信息引起用戶反感，并且抽象得當，可以完成任何場景下的注冊/登錄需求。

那我們就此完事兒了嗎？稍等下，我覺得還差一點。

因為現有的服務并不都是“開放注冊制”了。

因為我本人經歷的關系（既做過互聯網C端的服務系統，也做過金融行業B端的系統），經常不自覺的將B端與C端的系統功能進行比較，在賬號的這個問題下，我發現一件很有意思的事：

• 針對C端用戶，一般服務的目標是全人類（比如短視頻），服務對象的基數太大，所以一般由用戶自主注冊，并對注冊不設門檻，這類通過用戶自己創建賬號的方式，我稱為“開放注冊制”；
• 而B端的系統卻不是這樣，就拿最常見的EHR、OA、ERP系統為例，通常是由企業的管理員，在新員工入職，拿到工號，再到對應系統賦權、創建的；而用戶收到的則是內網地址和初始的登錄賬號信息與密碼，這種創建賬號的方式，我稱為“定向分發制”。

誠然，我們剛剛的設計方案，能普適“開放注冊制”這種方式，但是當我們嘗試套用在“定向分發制”之上，好像流程就顯得稍有冗長了，因為此類場景下，用戶的信息是由服務方主動創建的，在用戶初次登錄前，實際系統已經有了用戶信息，沒有再次注冊的必要，只要能驗證用戶的身份信息，就可以給到客戶對應的服務，這里拿銀行金融服務舉例：

在這里看，實際“注冊”信息是線下開卡完成的（還記得柜員讓你開通手機銀行嗎？），注冊完成后，下載對應的APP，核身通過后就可以使用 查詢，轉賬等服務了，本質上他依賴的是你的真實身份，而不是賬號信息，也不需要在手機上“重復注冊”，實現上接近方案2，那么針對“定向分發制”的優化方案完成。

以上是我覺得設計一個賬號體系需要重點去思考的點，當然，如果要實操，還請腳踏實地的去做市場分析、可行性分析、流程設計、UI/UX等設計，畢竟模型和細分業務場景還是有較大的距離的。

結語：從2000年至今，類似核身的技術突破數不勝數，科技真的極大的改變了我們的工作與生活，對下一個20年，我也很好奇科技會以什么樣的方式去改變人類社會（希望早日登上火星）。