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 导入指南：企业如何整合客户数据

  延伸了解数据整合、治理与导入规划的考量。