Data Cloud 導入顧問指南：資料建置、整合與持續優化

企業導入客戶資料平台，往往同時涉及業務規則、來源系統、身份解析與下游應用。Salesforce Data Cloud 顧問的價值，在於協助團隊把這些依賴整理成可執行、可驗證及可維護的方案。LeadsTech 可從資料架構與系統整合規劃，協助企業釐清 Data Cloud 導入範圍及交接責任。本文說明顧問應負責的工作、企業需保留的決策，以及合作成果的驗收方式。

摘要

Data Cloud 導入顧問應協助企業釐清應用、設計架構、建立資料及身份規則，並完成來源到目的地的驗證與交接。Salesforce 現稱此產品為 Data 360，本文沿用 Data Cloud。企業仍需指定資料與業務主責人，核准用途及驗收成果。合作品質應以可追溯的文件、測試證據與接手能力衡量，而不是只看已設定的功能數量。

1. 為什麼資料平台需要跨部門協作

資料問題經常跨越系統邊界

一個客戶可能同時出現在 CRM、交易、客服與行銷來源。各系統有自己的識別、更新方式與正式紀錄，導入不能只把資料搬進同一個地方，還要說明它們之間的業務關係。

當來源部門、平台團隊與應用人員各自完成局部工作，整條路徑仍可能中斷。例如資料已到平台，但身份無法對應；或受眾已送出，接收端卻不知道如何採取行動。

顧問可以協助整理這些依賴，提出可選方案與限制，並把工作分配到適當負責人。企業需要的是共同理解，而不是讓某個團隊單獨承擔所有資料問題。

合作範圍應依內部能力決定

若企業已有成熟資料團隊，可將顧問工作聚焦於特定平台能力、整合或驗收。若缺少跨系統規劃經驗，則可能需要從應用盤點及架構開始，範圍不必完全相同。

既有平台也可以先做問題診斷。資料延遲、身份錯誤或維護困難，可能來自來源品質、規則或營運安排，不能未分析就假設需要全面重建。

合作前應說明企業希望補足哪些能力，以及交付後由誰接手。這能讓外部專業形成可保留的成果，而不是只在專案期間依賴少數人的經驗。

2. 顧問應交付什麼可驗證成果

架構與資料規格

顧問應整理來源、處理、模型與目的地的完整路徑，說明必要欄位、識別及更新方式。文件需要讓業務和技術團隊都能理解每項資料為何存在，以及由誰維護。

架構選擇也應留下理由。例如哪些資料接入平台，哪些評估支援的資料聯邦方式，以及這些安排如何回應時效、查詢與營運需求。單張產品圖不足以表達實作條件。

規格應保留來源欄位到共同模型的映射，包含日期、時區、狀態及關係的定義。當來源改版或結果異常時，企業才有依據判斷哪些設定需要調整。

規則與測試證據

身份匹配、摘要選值及啟用條件應分別記錄，並說明適用範圍。顧問不能只展示輪廓已形成，還需要協助企業理解哪些來源被連在一起，以及結果如何使用。

測試證據應包含輸入、預期結果與實際輸出，並能追到目的地。必要時加入反例與失敗情境，讓企業知道方案在哪些條件下可用，哪些限制仍待處理。

交付清單還應列出尚未納入的來源、人工步驟及待決事項。把邊界說清楚，有助於企業安排後續工作，避免將部分完成的資料視圖誤認為完整解決方案。

圖 1：以架構、規則與證據確認交付，而不只檢查功能是否已設定。

3. 需求訪談要形成共同的業務決定

顧問可從代表任務開始訪談，例如客服查找訂單、業務準備跟進或行銷建立排除名單。每個任務都應說明使用者、必要資料、時間要求與預期動作。

企業需要指定能核准規則的人。哪些來源是正式依據、哪些條件代表資格，以及偏好改變後如何處理，都是業務決策，不能完全交由技術人員自行推測。

優先序應兼顧價值與準備程度。若某個需求重要但缺少可靠識別，可以先安排資料驗證；若另一個需求範圍清楚且來源可用，則可能更適合作為第一期。

會議結果應轉成可檢查的需求與接受條件。像「提供完整客戶視圖」這類描述，還需要補上來源、欄位、更新時間與使用方式，才能成為可驗收的工作。

需求改變時，顧問應說明對模型、身份、測試及下游的影響，企業再決定是否納入本期。範圍管理的目的，是讓新增工作有明確取捨與責任，而不是阻止合理改善。

4. 資料建置與整合如何分工

顧問負責設計，企業提供正式定義

顧問可協助檢查來源、設計映射與整合，但企業的資料擁有人需要確認欄位含義、品質及使用安排。若兩個系統對同一狀態有不同解釋，應由相關業務共同決定如何使用。

資料清理也要分清來源修正與平台轉換。對長期輸入錯誤，只在新平台補救可能掩蓋根本原因；對必要格式差異，則可建立有文件的轉換與驗證。

樣本應由企業確認具代表性，包含正常、缺漏、重複與歷史變更。顧問據此設計測試，雙方才能共同評估實際資料，而不是只使用理想化範例。

整合要涵蓋日常更新與失敗處理

來源連接完成後，還需測試新增、修改、刪除、停用與重送。接口或檔案恢復時，要確認從哪裡補入，以及如何避免重複資料或下游動作。

顧問應協助建立追查線索，讓來源識別、處理時間及目的地結果能連在一起。異常發生時，團隊需要知道資料停在哪一段，而不只是收到一個不易理解的錯誤代碼。

外部系統或供應商的配合事項，應明列在專案依賴中。帳戶、權限、接口限制與測試時段，都可能影響整合成果，不能只用平台配置完成度判斷進度。

5. 身份解析與啟用要以結果驗收

用代表紀錄與反例檢查

身份解析應依資料品質與用途設計匹配規則。顧問需要協助企業辨認共用電話、部門信箱、名稱近似等情況，避免把不同客戶過度連結。

協調規則決定統一輪廓中的摘要欄位值，並不等於自動改寫來源紀錄。顧問應說明摘要與來源的角色，讓企業知道何時需要另外設計正式資料更新流程。

驗收時同時查看應連結、應分開及資訊不足的樣本。只看統一比例或總筆數，無法證明身份品質；必須能解釋個別結果及對應規則。

從啟用一路確認到業務動作

啟用設計要說明資料送到哪裡、如何選擇聯絡方式、哪些欄位會輸出，以及企業核准的用途和偏好如何套用。每個決定都應能在測試中觀察。

接收端應參與驗收，確認身份可對應、格式可使用及預期動作可完成。平台顯示傳送成功，仍不能代替目的地的實際結果。

即時、串流與批次能力各有支援條件，顧問應依情境核對方案及設定，並量測完整時間路徑。不能因單一步驟反應快，就承諾所有資料與下游動作都立即完成。

6. 正式上線與交接如何安排

切換計畫應包括環境、連接帳戶、資料範圍、啟用安排與核對方式。顧問和企業要共同確認每個必要前提，不能只把測試環境設定搬過去就視為完成。

初期可控制來源或應用範圍，觀察資料品質、延遲及目的地結果，再決定是否擴大。若有尚未解決事項，應記錄影響、處理方式與負責人。

交接資料應包含架構、映射、規則版本、依賴及異常處理。除了文件，還應讓接手人員親自追查一筆資料、檢查一次啟用，以及演練問題通報。

企業需要知道誰有權修改設定、誰可暫停啟用，以及恢復前需要哪些驗證。停止後續資料傳送，不一定會撤回目的地已完成的動作，相關處理要一起規劃。

• 來源、模型與識別規格可取得。
• 身份與啟用規則有核准紀錄。
• 正常、反例與失敗樣本已驗證。
• 目的地能完成預期業務動作。
• 已知限制與待處理項目有負責人。
• 內部團隊能執行基本監測與追查。

7. 上線後如何建立持續優化

先觀察，再判斷原因與改動

顧問可協助企業整理資料量、品質、延遲、身份差異與啟用結果，將技術訊號連回業務情境。改善清單應說明影響及預期結果，方便企業決定優先序。

某個受眾突然減少，可能來自來源延遲、偏好更新或條件調整。應先確認原因，再決定修正哪一段，避免為了恢復數量而直接放寬規則。

每次改動後重跑代表測試，並觀察下游結果。當新的反例被發現，應加入後續驗證資料，讓經驗保留在可使用的流程中。

圖 2：從監測找到原因，再以測試確認改動，形成持續改善循環。

用量、擴展與簡化一起管理

平台用量應結合實際方案、資料範圍與處理頻率檢查。顧問應能說明哪些設定對應哪些用途，協助企業在新增需求前理解影響，而不是承諾不變的成本。

增加來源或應用前，先評估是否可沿用既有模型與規則。若每個部門都另建相似結構，維護會愈來愈難，顧問應協助辨認可共用與應分開的部分。

持續優化也包括清理失效設定、過期測試與無人使用的啟用。讓架構保持可理解，有助於新成員接手，並減少日後改動時難以辨認的依賴。

8. 如何選擇合適的導入顧問

以方法與交付評估合作能力

詢問顧問如何處理與企業相近的來源、身份及目的地問題，並請其說明分析方式、限制及驗收證據。產品名稱或功能清單，無法替代對實際情境的理解。

比較方案前先對齊範圍，包括資料盤點、清理責任、模型、身份、整合、測試及交接。若包含工作不同，總額和時程就不能直接比較。

顧問也應說明企業需要提供哪些資料與決策，以及前提未完成時如何處理。清楚揭露依賴，比把所有不確定性隱藏在看似完整的計畫中更有助於合作。

用小範圍合作驗證共同工作方式

假設一家企業希望把客服資訊加入業務跟進，可先選代表帳戶與必要案件欄位，要求顧問提出資料路徑、身份規則及工作台驗證方式。這是假設合作情境，不代表實際客戶成果。

企業提供正式定義與樣本，顧問完成設計與測試，雙方共同確認業務是否能理解資料並採取合適行動。這能讓合作方式與交付品質變得具體。

若初期發現主要問題在來源識別，後續計畫就應先改善識別；若資料可用但操作不順，則優先處理接收端流程。合作方向應跟著證據調整，而不是機械式增加功能。

支援安排也應區分操作問題、系統異常與新增需求，說明通報方式及需要提供的證據。企業與顧問可定期回顧處理紀錄，找出重複發生的原因，再決定改善文件、設定或來源流程，避免每次都以臨時方式解決相同問題。

9. 常見問題（FAQ）

10. 結語

Data Cloud 顧問的價值，在於把資料與應用需求落實為可驗證成果，並協助企業建立接手及持續改善的能力。清楚分工、完整證據與可理解的架構，是合作品質的重要基礎。

LeadsTech 可與企業討論 Salesforce 資料平台的導入、整合與優化需求，從優先情境規劃具體工作。

了解 LeadsTech Salesforce 顧問服務

如需評估新導入或既有建置，可整理主要來源、目的地與目前問題，與我們討論合適的合作範圍。

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

11. 延伸閱讀

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

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

• CRM 導入為何失敗？如何選擇合適顧問

  檢視需求、責任與合作方式，建立可落實的導入安排。