Data Cloud 建置重點：資料串接、身份解析與即時啟用

資料成功接入平台，並不代表身份關聯正確，也不代表下游系統能及時使用。Salesforce Data Cloud 建置的關鍵，是把來源、模型、匹配與啟用看成同一條可追查的路徑。LeadsTech 可協助資料串接與身份解析驗證，釐清來源規格、匹配規則及下游用途。本文聚焦容易被忽略的技術與營運細節，協助企業制定具體的設計和驗收條件。

摘要

Data Cloud 建置應同時驗證資料如何進入、如何關聯及如何被使用。本文沿用 Data Cloud 名稱，Salesforce 現稱此產品為 Data 360。來源識別、模型粒度、匹配規則、摘要值與目的地格式，都可能影響結果。即時能力需依支援條件配置，不能把成功接線或單一步驟快速回應，視為整條流程已達到業務要求。

1. 來源串接先確認識別與更新語意

每筆資料需要穩定的識別

來源識別應在同一範圍內穩定且可追溯。不同系統可能使用相同格式的流水號，因此要清楚保留來源脈絡，避免把兩個系統各自的客戶編號誤認為同一身份。

連接前先確認識別值是否會重用、變更或缺漏。若客戶改用另一個帳戶，舊識別與新識別之間的關係也要有明確規則，不能只靠最近一次名稱或信箱推測。

資料清單應記錄來源物件、主鍵、業務含義及負責人。當筆數或關聯異常時，這些資訊能幫助團隊查找問題，而不是在多套系統之間重複比對無法解釋的編號。

首次載入與持續變更分開驗證

首次載入需要確認資料範圍與完整性，持續更新則要測試新增、修改、刪除及停用。這些事件在不同來源可能採用不同表示方式，建置規格應明確說明。

若接口或檔案可能重送，需驗證相同紀錄再次到達的處理行為。不能因第一次測試成功，就假設日後重試不會重複建立資料或觸發下游動作。

來源中斷後恢復時，應知道從哪個時間或位置繼續處理，並核對補入範圍。恢復操作若沒有清楚界線，容易遺漏資料，或把舊事件當成新事件再次使用。

2. 模型設計要保留資料粒度與關係

客戶、交易與事件不可混為一談

建模前要區分一筆資料代表什麼。聯絡人、企業帳戶、訂單、訂單品項與網站互動，各有不同粒度；若直接把所有欄位放進同一張寬表，可能使資料重複或失去關係。

Salesforce 的 Data Lake Object 與 Data Model Object 分別參與來源資料及共同模型的安排。實作時應保留欄位映射和轉換定義，讓團隊能從應用欄位追溯回原始內容。

關聯設計應以代表資料驗證。例如一個客戶有多筆訂單、多個聯絡方式時，受眾條件是否仍得到預期結果。總筆數正確，並不能證明一對多關係或篩選路徑正確。

時間與狀態需要共同定義

來源事件時間、修改時間及平台接收時間有不同用途。判斷近期購買、最新偏好或資料延遲時，應清楚選擇哪一個欄位，並確認時區與空值處理。

狀態也需要業務解釋。例如「完成」可能代表付款完成、出貨完成或案件結束；只有名稱相同，不能直接視為同一條件。映射時應保存必要的原值及轉換理由。

遇到未知或新增狀態時，要決定先排除、標記或交由人員確認。讓未識別值默默落入預設分類，可能使啟用條件在來源改版後悄悄失準。

3. Identity Resolution 要分清三個決定

匹配：哪些紀錄屬於同一身份

匹配規則決定哪些來源輪廓應連在一起。官方文件說明，同一條匹配規則內的條件需共同成立；配置多條規則時，任一條規則成立便可能形成匹配，因此新增規則可能擴大匹配範圍。

企業應先理解識別品質，再選擇適合的條件組合。姓名、地址或聯絡方式可能變更，也可能被多人共用；不能單凭格式相似，便認定它們是可靠的唯一身份依據。

B2B 情境還需區分人與企業帳戶。同一公司有多位聯絡人，與同一聯絡人在不同來源出現，是兩種不同關係。應依應用選擇個人或帳戶層級的設計。

協調：統一輪廓如何呈現摘要

協調規則處理統一輪廓中的摘要欄位選值，例如來源優先序或最近更新。這個決定與是否屬於同一身份不同，也不表示原系統中的資料會被改寫。

摘要值適合用來理解輪廓，但企業仍須依使用情境決定需要哪個來源。若帳務與行銷各有正式名稱，就應保留用途差異，不宜要求一個摘要欄位替代所有情境。

追溯：保留輪廓與來源的連結

統一輪廓需要能回到相關來源紀錄，才能解釋資料內容與匹配結果。來源連結也有助於檢查哪一筆資料帶入了錯誤或過期資訊。

聯絡方式選擇應另外在啟用情境中確認。某個輪廓有多個信箱或電話時，需要依用途、偏好及來源安排選取，不能假設顯示名稱的協調規則已替所有聯絡方式作出決定。

圖 1：匹配、摘要與來源連結各有角色，不能以單一規則替代。

4. 用反例測試身份解析品質

不只檢查成功匹配

測試集應包括確定相同、確定不同及資訊不足的紀錄。共用公司電話、家庭信箱、名稱近似與缺少識別等情況，能協助團隊看見過度匹配與未能匹配的問題。

假設一家企業有兩位同姓聯絡人共用部門信箱，若只依信箱連結，就可能把不同人的互動放在一起。這是假設測試情境，用來說明規則需要配合資料含義，並非實際客戶結果。

相反地，同一人使用不同信箱也可能無法被連起來。團隊需要判斷是否有足夠可靠的其他依據，或應暫時保留分開，不能為了提高統一比例而放寬所有規則。

變更規則前先觀察影響

每次調整條件，應比較受影響的來源紀錄與統一輪廓，並檢查代表樣本。單看統一數量增加，無法證明結果更準確；減少也不一定代表品質變差。

規則版本、調整原因與測試結果應保存，讓日後查詢差異時有依據。若下游受眾或應用依賴身份結果，也應一起重新驗證，而不是只確認規則可成功執行。

5. 即時啟用要量測完整的時間路徑

先區分不同處理模式

批次、串流與即時能力服務不同需求，支援的資料來源、目的地與設定也可能不同。資料來源快速更新，不代表身份、受眾或接收端會在同一時間完成處理。

Salesforce 官方文件區分串流資料圖與即時資料圖；前者可在數分鐘內反映更新，後者針對支援情境提供更低延遲。建置時應核對實際功能前提，不能只因名稱含有串流便視為即時。

即時資料圖、事件與動作的設計需要配合應用，並確認方案、權限及環境條件。沒有必要時，不宜把所有資料都改成最高頻率，增加處理與維護負擔。

從業務需要回推可接受延遲

把來源更新、平台處理、資料傳送及目的地使用分開記錄，再觀察整體經過的時間。某一段變快，若其他階段仍等待排程，使用者感受到的時效可能沒有改變。

驗收應包含一般負載、集中更新及短暫中斷後恢復的情況。只在少量測試資料下量測一次，可能無法反映正式環境的資料量與接收限制。

時效要求應與業務動作連結。每日服務名單與網站互動當下的推薦，有不同的可接受時間；設計前先對齊目的，才能合理選擇技術路徑及觀察方式。

圖 2：以完整時間路徑評估啟用時效，找出真正等待的階段。

6. 啟用條件、聯絡方式與目的地要一起驗證

受眾條件決定哪些人符合業務需求，啟用時仍需確認要送出哪些欄位、聯絡方式及相關資訊。不同階段的篩選目的不同，不能以其中一個設定代替整體檢查。

同意與偏好資料需要正確接入、建模及用於相關篩選。企業應明確指定偏好的來源、用途與更新方式，並測試偏好改變後，下一次啟用及接收端會如何處理。

目的地可能使用不同身份欄位或命名方式，因此要驗證輸出格式、空值與關聯。傳送成功訊息只能說明某一步驟完成，仍需確認資料已被正確理解並用於預期行動。

全量與增量更新也有不同影響。企業應確認目的地如何處理新增、變更與不再符合條件的紀錄，避免每次只加入新資料，卻留下過期的使用資格。

若下游動作可能重複執行，要共同設計辨識重送及避免重複的方法。資料平台、接口與目的地都可能參與，責任不能只留在單一系統的錯誤訊息中。

7. 建置驗收與營運監測如何安排

用同一筆資料串起證據

驗收可選定代表紀錄，逐段保存來源值、映射結果、身份連結、啟用內容與目的地結果。這種追查方式比孤立的畫面截圖更能說明問題位置，也方便不同團隊共同討論。

重要限制要寫入交付文件，包括暫不支援的來源、尚未補齊的識別及人工處理步驟。使用者知道資料邊界，才不會把部分輪廓當成完整資訊使用。

• 來源識別在預期範圍內唯一且穩定。
• 欄位粒度、時間與關係已核對。
• 匹配、摘要選值與來源追溯可解釋。
• 正常、反例及資料不足樣本已測試。
• 啟用條件與目的地行為符合預期。
• 延遲、失敗、重送及恢復有人負責。

監測應連到具體處理方式

觀察資料量、錯誤、延遲與結果差異時，應有明確的通知對象與處理步驟。警示若只有技術名稱，卻沒有影響情境與代表紀錄，接手人員很難判斷優先程度。

來源欄位或業務規則變更前，要通知模型、身份與應用負責人。維護一份依賴清單，能協助團隊知道哪些受眾與目的地需要重新檢查，減少未預期的連鎖影響。

平台用量也需定期檢視，並結合實際方案與處理設定分析。當頻率或來源量明顯變化，應先確認業務必要性，再決定調整方式，不宜只以技術可行性擴大範圍。

異常處理需要區分影響與原因

發現異常時，先確認哪些資料、受眾與業務動作受到影響，再決定是否暫停相關啟用。資料量偏低可能來自來源延遲，也可能是條件改變，不能未查證就重送全部內容。

處理紀錄應包含發生時間、代表識別、最後成功步驟及已採取動作。不同團隊接手時可沿用同一份證據，避免再次執行相同操作，或在不知情下擴大影響。

修復後需要核對缺漏範圍與下游狀態。接口恢復連線不表示所有資料已補齊，也不表示目的地已恢復正確資格；完成條件應回到最初的業務情境。

若問題來自來源品質，應把發現回饋到輸入或維護流程，並保存新的反例作為後續測試。這能讓一次故障轉成可重複使用的檢查，而不只是暫時消除警示。

8. 常見問題（FAQ）

9. 結語

Data Cloud 的可靠性，來自可解釋的識別與模型、經過反例驗證的身份規則，以及能追查到目的地的啟用流程。把這些條件納入建置與驗收，才能讓資料被穩定使用。

LeadsTech 可與企業討論 Salesforce Data Cloud 的資料架構、身份解析及應用整合，協助梳理優先問題與實作範圍。

了解 Salesforce Data Cloud 解決方案

如需檢查既有建置或規劃新的資料應用，可整理來源、更新方式及目前異常，與我們進一步討論。

聯繫我們，討論你的企業需求

10. 延伸閱讀

• CRM vs CDP：企業客戶數據平台應如何選擇？

  從資料用途與營運需求，理解 CRM 與 CDP 的角色差異。

• 台灣 CDP 導入指南：企業如何整合客戶數據

  延伸了解資料整合、治理與導入規劃的考量。