Salesforce Data Cloud 導入指南：資料整合、統一輪廓與上線

客戶資料分散在 CRM、交易、網站與客服系統時，企業往往能取得報表，卻難以把資訊轉成一致的行動。Salesforce Data Cloud 導入應先釐清應用目的，再建立資料、身份與啟用流程。本文說明從規劃到上線的主要步驟，協助團隊定義可驗收成果。

摘要

Data Cloud 建置需要連接資料來源、整理共同模型、設定身份解析，再將合適資料送到業務應用。Salesforce 現將此產品稱為 Data 360，本文沿用題目的 Data Cloud 名稱。導入應以有限且可驗證的情境開始，確認資料品質、用途、處理時效與責任，再擴大來源及應用。平台功能與可用連接方式，仍需依企業方案及環境確認。

1. 第一步：選擇可落地的應用情境

從業務動作反推資料需求

先說明誰會使用資料，以及資料到位後要改變什麼工作。例如客服希望在回覆前查看近期交易，或行銷希望排除已完成購買的人員。這比單純要求「整合所有客戶資料」更容易形成建置範圍。

每個情境應列出使用者、觸發條件、需要的欄位、目的地與預期行為。若資料尚未到齊，要說明流程會等待、沿用舊值或停止，避免後續團隊自行猜測。

業務主管也要定義成功證據。資料能否找到、身份關聯是否正確、接收端能否完成指定動作，都是可測試項目；營收或轉換變化則還受到內容、服務與市場因素影響。

決定第一期邊界

第一期可選一個明確情境及必要來源，先走通完整流程，再增加複雜度。範圍小並不等於只接資料，而是從來源到實際使用端都要得到驗證。

將暫不處理的來源、歷史年份與應用列入後續清單，並記錄依賴。這能避免訪談期間不斷加項，也讓各部門理解哪些需求需要先補足資料或營運條件。

2. 第二步：盤點來源、品質與使用責任

建立資料清單與共同定義

資料清單應包括來源系統、擁有人、識別欄位、更新方式、用途及保留需求。相同欄位名稱未必代表相同內容，例如「客戶」可能分別指會員、聯絡人或企業帳戶。

先對齊粒度，再討論欄位映射。一張訂單可能包含多筆品項，一個企業帳戶可能有多位聯絡人；若把不同層級混在一起，後續統計與受眾條件便容易出現重複。

針對重要欄位，記錄空值、重複、格式及可追溯性。資料問題要有主責人和處理方式，不能只把清理工作移到新平台，卻沒有改善來源端的輸入流程。

決定必要範圍與存取方式

先選用途需要的欄位與歷史範圍，再評估連接器、接口或支援的資料聯邦方式。企業已有資料倉庫時，也應比較複製、查詢與混合安排的適用條件。

Zero Copy 並不表示所有來源都能直接使用，或所有處理都不涉及快取與更新設定。需要依來源支援、查詢行為及應用要求確認，避免只因名稱便跳過架構評估。

帳戶存取、來源限制及資料用途應由企業相關負責人確認。導入團隊要知道誰可批准新增欄位、誰可查看敏感資訊，以及來源規格改變時如何通知。

歷史資料與日常更新分開規劃

歷史資料有助於理解客戶過去行為，但未必所有欄位都值得保留。企業應根據應用所需期間、品質與可追溯性決定範圍，並標明不完整資料可能造成的限制。

首次載入與日常更新需要各自的核對方法。前者可依來源期間與樣本確認完整性，後者則需確認新增及變更有持續到達；兩者不能只用同一個總筆數判斷成功。

若來源以刪除或停用表示不同意義，也應提前記錄。停用帳戶、取消訂單與修正錯誤紀錄，可能需要不同下游處理，不能一律視為資料消失即可。

3. 第三步：串接資料並建立可理解的模型

從來源結構轉成業務語意

資料接入後，仍需映射到可供應用理解的模型。Salesforce 的資料架構區分 Data Lake Object 與 Data Model Object；實務上要清楚保留來源結構與共同業務定義之間的對應關係。

映射文件應說明每個重要欄位來自哪裡、經過哪些轉換及如何使用。日期、時區、金額單位與狀態值尤其需要一致，否則同一段期間可能得到不同結果。

資料關聯也需要驗證。客戶、聯絡方式、交易與互動之間，應有可解釋的識別與連結，不能只因欄位名稱相近就視為能夠正確串接。

讓更新與失敗處理可追蹤

除了首次載入，也要測試新增、更新、刪除及重送情況。若來源重新提供同一筆資料，應確認是否更新既有紀錄，或意外產生重複內容。

記錄來源事件時間、平台處理狀態與接收結果，有助於查找資料停在哪一段。企業應能區分沒有新資料、資料尚未處理及處理失敗，而不是只看最後一次連線成功。

每個來源都需要異常處理責任與恢復方式。當接口中斷或欄位改名時，團隊要知道受影響情境、通知對象及補送後的驗證方法。

圖 1：串接、建模、身份統一與啟用，構成從資料到應用的完整路徑。

4. 第四步：建立統一客戶輪廓

身份解析要有明確規則

Identity Resolution 的匹配規則用來判斷哪些來源紀錄屬於同一人或帳戶。規則應根據識別品質與業務情境設計，不能把姓名相近或共用聯絡方式直接等同於相同身份。

整理規則時，可準備確定相同、確定不同及難以判斷的樣本。共用電話、公司信箱、拼字差異與歷史資料缺漏，都可能影響匹配結果，需要由業務與資料團隊共同檢查。

驗證不只看統一後減少多少筆紀錄，也要檢查錯誤連結與應連未連的情況。若只追求較高整併比例，可能把不同客戶錯誤放在一起，影響後續溝通。

統一輪廓與來源紀錄各有角色

協調規則用來選擇統一輪廓中的摘要欄位值，例如依來源優先序選取名稱。它與身份匹配是不同決定，也不代表自動修改原本 CRM 或交易系統的資料。

企業應保留來源可追溯性，讓使用者知道某個值代表哪個情境。需要正式更新來源資料時，應另外定義寫回流程、主責及驗證，不能把統一輪廓當成已完成所有主資料治理。

5. 第五步：把資料送到可執行的應用

受眾與啟用需共同設計

若應用是行銷受眾，應定義納入、排除及聯絡方式選擇；若應用是客服或業務操作，則要確認畫面、流程或接收系統實際需要的欄位與格式。

啟用前應核對資料用途與企業核准的偏好規則，並驗證不應被使用的資料確實被排除。取得一筆客戶紀錄，不代表每個通路或每種用途都可直接使用。

目的地是否收到資料，只是其中一項證據。還需確認欄位能被識別、身份可對應，以及目的地完成預期動作；成功傳輸但無法使用，仍不算完成情境。

用整條流程定義時效

資料新鮮度取決於來源更新、接入、處理、輪廓及啟用安排。部分情境可採即時能力，其他流程可能依排程運作，不宜把平台名稱中的「即時」理解為所有步驟都沒有延遲。

從業務可接受的時間開始訂定要求，再驗證每一段的實際行為。若情境只需要每日更新，就不必未經評估便提高所有處理頻率，增加維護與用量負擔。

6. 第六步：測試、切換與正式上線

用代表樣本驗證整條路徑

測試應從來源紀錄一路追到目的地。樣本需要涵蓋資料缺漏、身份衝突、條件變更、取消資格及傳送失敗，並記錄預期結果與實際證據。

技術團隊確認連接、模型與處理行為，業務團隊確認資料能支援工作。雙方應共同簽認重要情境，避免系統測試通過後才發現欄位定義與操作需求不同。

正式切換前要核對環境、權限、連接帳戶與設定依賴。測試環境可運作的設定，不一定已在正式環境具備相同條件，需要逐項確認並安排切換後抽查。

• 資料來源、欄位及主責已記錄。
• 模型關聯與更新行為已驗證。
• 身份匹配與摘要值有樣本證據。
• 目的地能接收並使用資料。
• 排除條件與異常路徑已測試。
• 營運監測、暫停與恢復責任已確認。

圖 2：上線驗證需要同時涵蓋資料、身份、目的地與接手人員。

保存驗收基準與已知限制

每個驗收情境應保留資料版本、執行時間與結果，方便日後重現。若資料持續更新，單靠某一天的畫面截圖難以解釋差異，需要把當時使用的條件一起保存。

尚未納入的來源、缺漏欄位及暫時以人工處理的步驟，應放在交付清單中，由業務負責人了解影響。明確揭露限制，有助於避免使用者把部分客戶視圖誤認為完整資訊。

以有限範圍觀察正式運作

正式上線可先控制來源、受眾或應用範圍，觀察資料量、錯誤、延遲與下游結果。擴大前應確認這些訊號穩定，並由指定人員決定是否增加範圍。

若需要暫停啟用，團隊也要理解已送到目的地的資料如何處理。停止後續傳送，不一定等於撤回先前的動作，這些依賴應在切換前與接收團隊對齊。

7. 第七步：建立持續維護與改善機制

來源欄位、業務條件與使用方式都會改變，因此上線後應有人定期查看資料品質、身份規則、啟用結果與平台用量。異常要能連回影響的情境，而不只是留下技術紀錄。

新增需求時，先評估是否能沿用既有模型與資料，再決定是否新增來源或處理。避免每個部門各自建立相似物件，讓共同定義逐漸失去一致性。

用量管理應結合實際方案、處理頻率與應用範圍，不宜直接套用固定估算。先在可控情境觀察，再依現行計費與合約安排調整，讓技術決策與營運預算保持連結。

假設一家 B2B 企業希望在客服回覆前取得近期交易，可先串接必要客戶與訂單資料，驗證身份及顯示方式，再考慮加入行銷互動。這是假設導入情境，不代表既有客戶成效。

此情境的首要成果是客服能理解資料來源與更新時間，並順利完成回覆；後續再評估是否減少查找步驟。先證明工作能完成，才能合理討論擴大應用的價值。

讓維護團隊能獨立追查

交接時可安排接手人員追查一筆指定資料，從來源、映射、身份關聯一路確認到目的地。若必須依賴建置者口頭提示，表示文件或管理介面仍有需要補足之處。

營運指引應說明正常觀察方式、異常判斷及通知對象，並區分資料問題與設定問題。當來源團隊和應用團隊使用相同案例與時間紀錄溝通，問題通常更容易定位。

重要設定變更前，應評估受影響的輪廓、受眾與下游流程，再重跑代表測試。這能讓後續擴展沿用已建立的信任基礎，而不是每次增加需求都重新猜測資料含義。

8. 常見問題（FAQ）

9. 結語

Data Cloud 導入應把資料、身份與業務行動串成可驗證的流程。從清楚情境開始，逐步完成來源、模型、輪廓及啟用，再以監測和責任分工支援持續運作。

LeadsTech 可協助企業討論 Salesforce Data Cloud 的資料整合與應用規劃，將優先需求轉成具體建置範圍。

了解 Salesforce Data Cloud 解決方案

如需評估現有來源與第一期導入方向，可整理目前系統、主要問題與預期應用，與我們進一步討論。

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

10. 延伸閱讀

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

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

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

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