一、業務背景

通常在系統研發的過程中，需要不斷適配各種業務場景，擴展服務的領域和能力，一般會將構建的產品矩陣劃分出多條業務線，以便更好地管理；

由于各個業務線的數據入口和管理策略的不同，這樣從不同路徑下沉淀的數據，可能因為系統邊界問題從而被孤立；如果用戶數據被分裂，會因為數據不全面給分析決策帶來誤導；

比較經典的場景，用戶從應用端完成注冊之后，通常不會過多提供自身信息，由于業務需要不斷豐富用戶畫像，所以用戶數據通常會被調度到獨立的管理系統中，通過不同的觸點反饋進行信息擴展，比如采集埋點數據，線下接觸，營銷電話等；

這種情況從操作上是有明顯感知的場景，顯然用戶在應用庫中的數據和在管理庫是存在很大差異的，在真實的情況中用戶可能在不同的應用和場景中會產生重復，必然會導致用戶數據難以統一維護；

二、唯一標識

用戶的行為數據在當下的互聯網產品中，是極其具有分析價值的，不同的應用端不管是否處于登錄狀態，在產品中產生的數據都是有記錄的手段，進而在數據層面分析識別；

這些編號最大的特點就是具有唯一性，可以標識用戶在不同終端不同狀態的操作信息，而當這些數據沉淀到系統時，會根據端口和操作類型進行存儲，不同的終端下其數據唯一標識也不相同；

從數據分析的角度上來看，顯然不希望用戶的行為信息被分裂并且各自孤立，這樣對多終端多狀態下的用戶行為數據進行全域關聯，是行之有效的方式，其基本原理涉及到ID的映射技術；

三、Id映射

基于上述的業務情況，在產品矩陣中提供用戶身份的全局統一標識至關重要，用戶實體在不同業務線所產生的行為數據，通過唯一序列號進行識別，這樣進行用戶分析時看到的畫像比較全面；

在當下的互聯網產品中，基于手機號創建應用賬號的模式已經是常見功能，手機號注冊之后，再通過手機號去關聯相應的終端ID，從而使各種孤立的數據被鏈接起來；

其實現的原理并不復雜，首先需要提供一套映射庫，當新的手機號被系統識別采集時，在映射庫中新建一條數據，手機號和對應的唯一ID，此后其他路徑的數據，如果手機號相同則綁定在該ID下面；

四、數據關聯

在ID映射機制下，雖然各個業務線數據相對孤立，數據之間不會產生直接影響，但是實際上已經被唯一ID串聯起來，這樣將ID關聯的數據進行綜合分析，準確性會提高很多；

不管從任何路徑或渠道下采集的數據，如果存在手機號的維度，或者手機號相關聯的序列號標識，判斷該手機號是否存在全局映射ID，沒有則在映射庫中創建對應關系，如果有則直接綁定即可；

在執行數據的全局調度和分析時，則通過映射庫的標準關系，基于ID標識將全部業務線的數據進行查詢和統籌分析，從而生成相對全面的數據檔案，以及標準的分析邏輯；下面給出一個參考性的結構設計：

這里存在數據關聯的邏輯，ID標識與手機號都是唯一的且一對一，但是手機號與終端的序列號可能存在一對多，甚至是多對多；賬號與應用中產生的行為數據，雖然追求準確性，但是精確度不會過度要求；

這種情況下就需要執行相應的業務策略，比如同一個手機號可能登錄過不同手機中的相同應用，手機中的應用也可能被多個賬號登錄過，此時則需要基于策略做關聯上的取舍，可能是賬號登錄時長，或者登錄前后的時段，無法一概而論；

五、注冊登錄

以手機號作為賬號主體為例，開放的應用并不會明顯區別注冊和登錄，以此簡化操作避免阻斷掉用戶，在通過手機號登錄時，如果是未注冊的用戶直接進行信息初始化即可；

• 用戶在登錄表單中，輸入手機號并獲取驗證碼；
• 在登錄服務中，生成并維護驗證碼的時效；
• 驗證碼需要借助對接的第三方短信平臺推送到用戶手機中；
• 登錄表單填充驗證碼之后提交登錄信息進行驗證；
• 當登錄驗證成功之后，如果用戶未注冊則初始化賬號體系；
• 賬號體系校驗和維護之后，通過異步方式關聯ID標識；
• 最后需要給用戶端返回Token身份令牌，作為賬號識別；

注冊登錄集成在一起的復用接口比較復雜，但是以最短的路徑讓用戶快速使用產品，通過行為數據采集分析，從而可以精準識別用戶需求，進行正確的引導和營銷，發揮出數據的真正價值；

這里給出一份賬號管理的結構設計參考，通常情況下用戶的主表維度會圍繞可登錄的賬號來設計，而涉及到信息采集的數據會寫入用戶檔案表，由于不同業務場景對信息依賴不同，所以在用戶注冊之后會引導各種數據采集的頁面；

用戶身份識別和賬號作為系統非常基礎的核心能力，在設計的時候既要有用戶體驗，同時要重視數據的安全性；作為核心能力在前期設計的時候就需要一定的前瞻性，做好可能性的規劃和結構預留，避免后續的迭代跨度過大。

六、參考源碼

編程文檔：https://gitee.com/cicadasmile/butte-java-note

應用倉庫：https://gitee.com/cicadasmile/butte-flyer-parent