用戶身份標識與帳號體系實踐
互聯網的帳號自帶備忘機制；
一、業務背景
通常在系統研發的過程中，需要不斷適配各種業務場景，擴展服務的領域和能力，一般會將構建的產品矩陣劃分出多條業務線，以便更好的管理；
由於各個業務線的數據入口和管理策略的不同，這樣從不同路徑下沉澱的數據，可能因為系統邊界問題從而被孤立；如果用戶數據被分裂，會因為數據不全面給分析決策帶來誤導；
比較經典的場景，用戶從應用端完成註冊之後，通常不會過多提供自身資訊，由於業務需要不斷豐富用戶畫像，所以用戶數據通常會被調度到獨立的管理系統中，通過不同的觸點回饋進行資訊擴展，比如採集埋點數據，線下接觸，營銷電話等；
這種情況從操作上是有明顯感知的場景，顯然用戶在應用庫中的數據和在管理庫是存在很大差異的，在真實的情況中用戶可能在不同的應用和場景中會產生重複，必然會導致用戶數據難以統一維護；
二、唯一標識
用戶的行為數據在當下的互聯網產品中，是極其具有分析價值的，不同的應用端不管是否處於登錄狀態，在產品中產生的數據都是有記錄的手段，進而在數據層面分析識別；
這些編號最大的特點就是具有唯一性，可以標識用戶在不同終端不同狀態的操作資訊，而當這些數據沉澱到系統時，會根據埠和操作類型進行存儲，不同的終端下其數據唯一標識也不相同；
從數據分析的角度上來看，顯然不希望用戶的行為資訊被分裂並且各自孤立，這樣對多終端多狀態下的用戶行為數據進行全域關聯，是行之有效的方式，其基本原理涉及到ID的映射技術；
三、Id映射
基於上述的業務情況，在產品矩陣中提供用戶身份的全局統一標識至關重要，用戶實體在不同業務線所產生的行為數據，通過唯一序列號進行識別，這樣進行用戶分析時看到的畫像比較全面；
在當下的互聯網產品中，基於手機號創建應用帳號的模式已經是常見功能，手機號註冊之後，再通過手機號去關聯相應的終端ID，從而使各種孤立的數據被鏈接起來；
其實現的原理並不複雜，首先需要提供一套映射庫，當新的手機號被系統識別採集時，在映射庫中新建一條數據，手機號和對應的唯一ID，此後其他路徑的數據，如果手機號相同則綁定在該ID下面；
四、數據關聯
在ID映射機制下，雖然各個業務線數據相對孤立，數據之間不會產生直接影響，但是實際上已經被唯一ID串聯起來，這樣將ID關聯的數據進行綜合分析，準確性會提高很多；
不管從任何路徑或渠道下採集的數據，如果存在手機號的維度，或者手機號相關聯的序列號標識，判斷該手機號是否存在全局映射ID，沒有則在映射庫中創建對應關係，如果有則直接綁定即可；
在執行數據的全局調度和分析時，則通過映射庫的標準關係，基於ID標識將全部業務線的數據進行查詢和統籌分析，從而生成相對全面的數據檔案，以及標準的分析邏輯；下面給出一個參考性的結構設計：
這裡存在數據關聯的邏輯，ID標識與手機號都是唯一的且一對一，但是手機號與終端的序列號可能存在一對多，甚至是多對多；帳號與應用中產生的行為數據，雖然追求準確性，但是精確度不會過度要求；
這種情況下就需要執行相應的業務策略，比如同一個手機號可能登錄過不同手機中的相同應用，手機中的應用也可能被多個帳號登錄過，此時則需要基於策略做關聯上的取捨，可能是帳號登錄時長，或者登錄前後的時段，無法一概而論；
五、註冊登錄
以手機號作為帳號主體為例，開放的應用並不會明顯區別註冊和登錄，以此簡化操作避免阻斷掉用戶，在通過手機號登錄時，如果是未註冊的用戶直接進行資訊初始化即可；
- 用戶在登錄表單中，輸入手機號並獲取驗證碼；
- 在登錄服務中，生成並維護驗證碼的時效；
- 驗證碼需要藉助對接的第三方簡訊平台推送到用戶手機中；
- 登錄表單填充驗證碼之後提交登錄資訊進行驗證；
- 當登錄驗證成功之後，如果用戶未註冊則初始化帳號體系；
- 帳號體系校驗和維護之後，通過非同步方式關聯ID標識；
- 最後需要給用戶端返回Token身份令牌，作為帳號識別；
註冊登錄集成在一起的復用介面比較複雜，但是以最短的路徑讓用戶快速使用產品，通過行為數據採集分析，從而可以精準識別用戶需求，進行正確的引導和營銷，發揮出數據的真正價值；
這裡給出一份帳號管理的結構設計參考，通常情況下用戶的主表維度會圍繞可登錄的帳號來設計，而涉及到資訊採集的數據會寫入用戶檔案表，由於不同業務場景對資訊依賴不同，所以在用戶註冊之後會引導各種數據採集的頁面；
用戶身份識別和帳號作為系統非常基礎的核心能力，在設計的時候既要有用戶體驗，同時要重視數據的安全性；作為核心能力在前期設計的時候就需要一定的前瞻性，做好可能性的規劃和結構預留，避免後續的迭代跨度過大。
六、參考源碼
編程文檔：
//gitee.com/cicadasmile/butte-java-note
應用倉庫：
//gitee.com/cicadasmile/butte-flyer-parent
