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

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