如何從零開始開展 CDP 的用戶數據基礎建設？企業的首要任務是理清 CDP 上下游的數據情況，以用戶為主體梳理數據應用場景，比如業務數據如何收集、用戶數據在什么情況下輸出、用戶觸達場景有哪些等。全域用戶關聯作為 CDP 系統的基礎能力支撐，會對上游數據的收集以及下游業務系統造成影響，所以在方案設計之初需要盡可能對上下游相關的數據現狀進行盤點。

典型的數據現狀盤點流程包括：

1、數據源梳理：梳理各業務線涉及到的業務系統。

2、用戶主體 ID 梳理：梳理各業務系統中用于標記用戶主體和數據相關的 ID，比如設備 ID、企 微 ID、Union ID、Open ID、Cookie ID 等。

3、用戶屬性梳理：梳理各業務系統中用戶標識 ID 對應的數據屬性，業務 ID 對應的用戶業務屬性有卡號、身份、微信號、手機號等。

4、識別用戶標識數據在源端存儲的質量：例如在數據梳理的過程會發現一個手機號對應多個證件號，這時候需要對數據源產生的原因進行分析，找到異常數據產生的原因，如何在用戶關聯過程中處理。

5、ID 應用場景梳理：梳理圍繞 CDP 應用的整個業務流程中，涉及用戶 ID 應用的典型場景，比如 CDP 全域數據接入場景、用戶分群數據輸出場景等。

輸出用戶 ID 關聯方案的首要步驟是明確各業務線中哪些 ID 參與用戶的關聯，并確定 ID 的優先級、數量、父節點等信息。

1、ID 優先級：優先級的設定是為了解決當一條數據中有多個 ID，又無法關聯時，數據歸屬的問題。按照設定，數據會歸屬優先級更高的 ID 所對應的用戶。

2、業務唯一 ID：系統中唯一標識一個用戶的 ID 類型，其優先級最高。以電商業務為例，用戶的登錄 ID 由于和用戶購物等行為直接產生關聯且可以通過很多途徑獲取到，往往可以作為「業務唯一 ID」來定義。

3、數量：取決于實際業務中一個用戶可以擁有單個還是多個該類型的 ID，可以用來校驗關聯關系是否符合規則。

4、父節點：在一些業務生態中，ID 之間存在著父子關系。父節點的定義可以用于解綁時一并解綁子節點，比如在微信生態中，Union ID 是 Open ID 的父節點，如果要將 Union ID 進行解綁，則附屬的所有 Open ID 也將隨之被解綁掉。

完整梳理 ID 之后，就可以針對性地采用埋點、ETL 等方式，完成用戶關聯的持續落地了。通俗來講，就是明確將哪些業務系統中的哪些數據提取出來再導入 CDP 系統中。業務中每一個事件對應的屬性和涉及的 ID 都需要在埋點和 ETL 方案中體現，可以大大減少技術人員的理解成本。

完成全域用戶關聯后，會在用戶數據中發現歷史關聯錯誤的數據。根據新的關聯結果，需要對這些錯誤數據進行解綁并綁定至正確的歸屬用戶，重新完善用戶全生命周期畫像，從而提升 CDP 的用戶數據質量。

舉例來說，在用戶關聯過程中，基于同一個用戶的唯一昵稱「A」同時對應兩個用戶「張三 2020 年注冊」「李四 2021 年注冊」，由此識別為同一個用戶，需要對重復關聯數據進行合并。在這種情況下，可以參考最早觸達用戶的時間來完成用戶屬性的修復:「張三」2020 年注冊早于「李四」2021 年注冊，因此選擇將數據關聯至「張三」下。

同理，當歷史數據中存在其他類似的「唯一用戶 ID」并與當前產生沖突時，需要根據時間先后順序，將兩個「唯一用戶 ID」進行合并，完成數據關聯的回溯。

企業在進行用戶 ID 關聯的過程中，會遇到用戶關聯同類屬性沖突的情況，在進行屬性合并的過程中，可以遵循以下四個規則:

第一，預置規則：特殊類型屬性使用固定的預置規則來處理，比如按照訪問時間先后順序進行屬性合并。

第二，缺省規則：默認以數據生成最早的時間為準，如果沒有數據生成時間的相關字段就按照 ID 的優先級進行合并。

第三，設置基準規則：設置某個來源的數據為基準，例如相比 CRM 銷售人員手動錄入的信息數據和業務系統自動獲取的訂單數據，訂單數據的準確性和穩定性顯然更高，則選擇以業務系統訂單數據為基準。

第四，設置首末次規則：以最先接入數據的屬性為準或者保持最末次的屬性。

日常業務中會出現當前用戶關聯信息錯誤的情況，比如，用戶更換手機導致設備 ID 變更等，這種情況就需要將現有的綁定關系解綁；另一方面，我們也發現，曾經認為某個 ID 和用戶不相關，但后來經過人工等方式確認兩者是相關的，這種情況就需要能夠在自動關聯未成功的情況下，以手動的方式將一個獨立 ID 關聯到現有用戶上去。

以神策數據的 ID-Mapping 全域用戶關聯為例，數據校驗及測試驗收整體可以分為五個部分:

1、用戶關聯是否成功

完成全域用戶關聯的部署之后，首先應檢查對應埋點方案的上報邏輯是否生效，比如，搜索埋點方案中設計的對應事件是否正常存在。

2、用戶關聯全端執行情況

確認事件上報后，可以基于埋點事件確認不同 SDK 類型上報的關聯 ID/綁定 ID 的總次數。在前后端都調用的情況下，如果不同 SDK 間上報次數相差很多，則需要排查調用時機是否出了問題。

3、用戶關聯報錯校驗

這一步驟旨在確認事件上報的準確性，使用 ID-Mapping 可以在「神策數據治理」→「數據質量」→「埋點數據查詢」過程中，查看是否有大量用戶關聯的報錯，并確認錯誤數據量、錯誤分類、錯誤原因等細節信息。

4、ID 格式校驗

檢查業務 ID 的格式、長度等是否符合預期。一般來說，業務 ID 都會有相對固定的格式或長度，例如手機號一般都是 11 位，微信生態的 Union ID 和 Open ID 也都有固定的長度，驗收人員可以使用 SQL 檢查是否有不符合預期的數據。

5、ID 關聯情況排查

一般可以分為三種情況:

第一，只有登錄 ID 的用戶：此類用戶的特征是業務意義上的登錄 ID 有值，其他 ID 均為空。查詢只有登錄 ID 用戶的數量占比，如果發現此類用戶占比過高，則可以推斷出用戶關聯可能出現問題，登錄用戶沒有與其他觸點的 ID 成功關聯上。

第二，只有某個特定觸點相關 ID 的用戶：例如只有微信生態 Union ID 或 Open ID 的用戶，其他業務 ID 均為空。如果此類用戶占比過高，則表示該觸點可能沒有與其他觸點打通。

第三，只有設備 ID 的用戶：例如發現用戶表中存在大量只用 Android_id 的用戶，則標明對應 Android 的用戶關聯可能沒有做。

從業務邏輯上來說，一個用戶肯定是先有 xxx ID 再有 yyy ID，對此類用戶關聯情況進行排查時，可以進行 SQL 查詢，如果查詢結果不符合業務邏輯，則需要進一步排查是否確實沒有實現關聯的用戶，還是用戶關聯出現了問題，或者 ID 數據本身存在錯誤。