編輯導語：帳號是用戶的身份標識，產品在設計過程中，便需要針對帳號體系的搭建進行考量。不過帳號體系也有類別區分，在不同類型的產品中，帳號體系的后端結構設計又該如何實現呢？本篇文章里，作者便對帳號體系的后端信息結構設計做了總結，一起來看一下。

上一篇文章，我們介紹了帳號的價值，以及不同類型的產品對帳號的需求差異。這篇文章，我們詳細介紹一下帳號體系的后端結構設計，即為了實現帳號體系的全部功能，帳號體系的后端應該如何設計。

一、帳號體系的分類

從帳號應用的范圍維度，可以把帳號分為“僅為自研應用提供服務”的帳號體系，和“開放給第三方開發商使用”的帳號體系。

第1種帳號體系，僅在開發者自己研發的應用中使用，帳號數據不會被第三方應用獲取和使用。

而第2種帳號體系，不僅在自研的應用中使用，還可以通過開放平臺提供給第三方應用使用，是大平臺、國民級開發商的舞臺，本文暫不涉及。

僅為自研應用提供服務的帳號體系，按自研應用數量，又可以分為兩種：

1. 單應用的帳號體系：只在開發者研發的單個應用上使用的帳號體系。大部分開發者、業務單一的開發者都屬于這一類。如脈脈、即刻、keep等。
2. 矩陣應用的帳號體系：同一個開發者研發的若干個應用，使用同一套帳號體系。部分業務多樣、或推出了多個關聯應用的開發者，屬于這一類。如美團旗下，多個矩陣應用使用同一套帳號體系，如美團外賣、大眾點評、美團優選、美團買菜、貓眼電影。

對于單應用的帳號體系，用戶修改帳號信息時，只對單一應用有效。而對于矩陣應用的帳號體系，用戶修改帳號信息，將同時影響使用了該帳號體系的全部矩陣應用。

例如，用戶修改即刻App中的綁定手機號，只會對該用戶使用即刻App有影響。

若用戶美團App中修改手機號號碼，會有如下提示：

接下來，我們就這兩種帳號體系的信息結構做詳細分析。

二、單應用的帳號體系

單應用帳號體系只為單個應用服務，其信息結構相對簡單，主要包括4部分：UserID、第三方帳號、密碼、設備號、其他業務字段，如下圖：

1. UserID

UserID是用戶在應用中的唯一身份標識，通常也稱為用戶ID。系統或其他用戶都可以通過UserID，準確找到該用戶。UserID會在用戶在注冊帳號時，系統根據規則自動生成。

• 用戶注冊QQ帳號時，系統會按一定的規則從未被使用的號池中給用戶分配一個QQ號。
• 用戶注冊小紅書時，會按規則生成一串純數字的小紅書號。

UserID必須至少滿足兩個要求：唯一、不可修改。

只有UserID是唯一的，才能通過它準確定位一個用戶，而不是多個用戶，或錯誤地定位用戶。

不可修改是因為UserID通常會被引用到很多個功能中，若可以隨意修改，會帶來極大的刷數據成本，甚至會引發系統數據混亂。

在即刻App中，動態、評論、關注、點贊、分享、收藏等功能都需要引用用戶身份標識號，以記錄相關數據的操作人。

如果修改了某個用戶的身份識別號，那么該用戶所有的動態、評論、關注、點贊、分享、收藏數據中的身份識別號都需要修改，否則就會導致數據操作人找不到，引發數據混亂。

2. 第三方帳號

隨著第三方帳號（如微信號、QQ號、手機號）的大規模普及，直接使用第三方帳號，替代UserID登錄系統成為主流的設計方式。

UserID有兩個很明顯的缺陷，導致被第三方帳號替代。一是UserID是一個不需要用戶關注的信息，因為用戶幾乎沒有直接使用UserID的場景。二是記住各個應用的UserID成本很高，因為每一個應用生成的UserID都不一樣。

如果用戶日常使用50個應用，那他必須記住50個完全不一樣的編號，那將會是一個災難。

而像微信號、QQ號、手機號這類第三方帳號，幾乎每一個人都擁有一個，也都能唯一標識用戶身份。

如果將第三方帳號跟UserID一一關聯，并使用它們來登錄應用，將給用戶帶來極大的便利。

3. 密碼

登錄應用時，除了輸入帳號并不能確定當前用戶是該帳號的所有人，還必須要通過某種方式來驗證用戶身份，以確保帳號不被盜用。

目前大部分應用都通過讓用戶輸入與UserID一一對應，且只能被帳號所有人知道的密碼，來完成身份驗證。

為了確保密碼不被惡意破解，還需要對密碼的復雜度做要求。如至少8個字符、必須包括大小寫字母和數字。

隨著第三方帳號和手機號的普及，逐漸發展出了更多驗證身份的方式：

1. 手機號+短信驗證碼：用戶輸入了系統臨時生成的短信驗證碼，即表明當前登錄用戶是帳號所有人；
2. 手機號一鍵登錄：通過移動運營商的身份校驗接口，驗證用戶身份；
3. 第三方帳號授權登錄：通過已登錄的第三方應用的接口，驗證用戶身份。

這些驗證身份的方式，不需要用戶記密碼，也不需要擔心密碼忘記，操作上更便捷、更快速，也更安全，逐漸替代帳號+密碼的身份驗證方式，成為產品設計的主流方案。

4. 設備號

設備號是用來標識用戶使用應用的硬件編號。如web端用cookie作為設備號，iOS用UUID、IDFV、IDFA，Android用UUID、Android ID。

在帳號信息中，記錄用戶使用的設備號，可以用來標記用戶常用設備，確保用戶帳號安全。當用戶在一個新設備上登錄應用時，系統能及時發現，并觸發安全校驗。

還有部分應用對用戶的可用設備做了限制，如印象筆記的免費用戶，只能在兩個設備上同時使用。此時，也需要記錄用戶的設備號。

5. 其他業務信息

除了以上幾個系統需要的信息，還有一些業務層面需要用到的信息，如用戶昵稱、頭像。通常在需要顯示用戶信息的地方出現，如用戶詳情頁、評論列表、會話列表等。不僅彰顯了用戶的個性，還為用戶識別、查找其他用戶提供了便利。

不同的產品需求不同，帳號體系中的業務信息，要根據業務的需要來定義。

三、矩陣應用的帳號體系

同一個公司開發的多個應用，稱之為矩陣應用。

1. 共用帳號體系的原因

相對于使用獨立的帳號體系，矩陣應用共用一套帳號體系，無論是對企業還是到用戶，都是一個更好的選擇。

對企業來說，能大幅度減少企業的開發和維護成本。矩陣應用中的每一個應用，大多由多個團隊獨立開發。如果每個應用都單獨開發和維護一套帳號體系，有多少個應用就要重復開發多少次，成本隨著應用數線性增加。

而多個應用共用一套帳號體系，企業只需要開發一次，當有新應用時，只需要簡單接入，成本大幅度降低。

同時，共用一套帳號體系，還能強化品牌認知，帶來更高的商業價值。 帳號體系獨立開發，會導致使用多個應用的同一個用戶在不同的應用中，有完全不一樣的帳號，用戶也會默認為，這是多個不同的企業開發的產品。這對于企業建立完整的用戶畫像非常不利，企業獲得的用戶數據不足，對用戶的理解就不夠完整，能轉化的商業價值也就更少。

若共用一套帳號體系，用戶會認為這是同一家企業的產品，對企業的品牌認知就好得到強化。同時，多個應用中產生的用戶數據，能關聯到同一個帳號下，企業獲取的用戶數據更豐富，對用戶的理解更深入，通過個性化推薦和精細化運營，自然能帶來更大的商業價值。

對用戶來說，共用一套帳號體系能獲得更便捷的服務。帳號體系獨立，用戶必須分別注冊帳號、使用不同的帳號登錄應用，同樣的帳號資料需要設置多遍。而共用帳號體系，用戶只需要注冊一個帳號，就能登錄全部矩陣應用，且用戶數據還能自動同步。很明顯，用戶操作更便捷。

2. 矩陣應用帳號體系的信息結構

矩陣應用帳號體系需要在單應用帳號體系的基礎上，增加應用層面的身份標識（AppUserID），以明確用戶是哪些應用的使用者。其信息結構如下：

之所以要增加應用層的身份標識，主要有2個價值。

1）記錄用戶在每一個應用中的行為信息，并利用這些信息做特定的運營動作。

運營人員設計了一個面向該應用新用戶的促銷活動，若以UserID生成時間為準，就會導致大量最近幾天才開始使用該應用的新用戶被排除在活動范圍之外。

通過AppUserID生成時間，即可準確篩選出該應用的新用戶。

2）統計矩陣應用在平臺用戶中的滲透率，為應用精準導流。根據各應用的AppUserID數量和平臺UserID數量，即可計算出各個應用在平臺用戶中的滲透率。若某個應用需要其他應用導流，以增加其用戶量，可在其他應用中向該用戶精準推薦該應用。

四、總結

按使用范圍，可以將帳號體系分為單應用帳號體系和矩陣應用帳號體系。單應用帳號體系的信息結構主要包括UserID、第三方帳號、密碼和頭像昵稱等業務信息，而矩陣帳號體系則在單應用帳號體系的基礎上，增加AppUserID。在設計帳號體系時，信息結構是最重要的部分。

#專欄作家#

誓博，微信公眾號：產品慎思錄。人人都是產品經理專欄作家。5年產品經驗，電商售后平臺后端產品負責人。

本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議