SAP 很多系统的主数据都支持从外部系统导入，SAP Marketing Cloud 也是如此，contact 主数据可以来自 Hybris Commerce，CRM，ERP 或者 Twitter，Facebook 等社交媒体。来自不同渠道的 contact 可能对应的是真实世界里同一个人，那么就存在一个过程，该过程的逻辑是将不同渠道的 contact 数据进行整合，拼凑出一个包含完整信息的 contact 主数据存储到 Marketing Cloud 系统里，这个拼凑的过程称之为合并(merge)，拼凑后形成的完整 Contact 结构称为 Golden record。

下面这张示意图里的蓝色圆环称为 Main facet，代表每个 contact 数据在某个源系统上的 ID，比如在 ERP 系统上的 ID 为 123，在 Twitter 上的 ID 为 456 等等。而黄色圆环是 contact 在各自源系统里的属性，比如在 Twitter 网站上 ID 为 456 的一个 contact，其 name 属性为 jerrywang@sap。黄色圆环称之为 additional facet.

通过在 SAP Marketing Cloud 里进行一系列配置，告诉系统，当检测到来自不同数据源的 contact 数据，存在至少一个相同属性的情况下，应该执行何种 contact 操作，也就是合并或者新建。

比如下图在 ERP，Facebook 和 Web Shop 上有三条 contact 数据，其 Email 地址的值都相同，那么进行数据导入时，基于预定义好的配置，Marketing Cloud 认为这三条数据指向的是同一个人，所以最后 merge 出来生成唯一一条 contact 记录。

Marketing Cloud 具体 merge 的过程，就是根据 SAP Marketing Cloud 系统里的 customizing 配置，将三条 Email 地址都相同的记录作为当前 merge 的输入，然后逐一将本记录内的属性“投影”到最终的 Golden Record 里。如果把 Golden Record 想象成最终完整的拼图，那么这个 merge 过程就有些类似于拼图操作——将散布在各个数据源中的零散信息合并成一个整体，存储在 Marketing Cloud 系统内以便进行后续处理。

Marketing Cloud 里针对 contact 导入系统时的 merge 操作的相关 customizing 设置，在整个 contact 导入过程中起着至关重要的作用。

和 SAP Cloud for Customer 等很多云产品一样，SAP Marketing Cloud 的 customizing 也是在浏览器里完成。

点击 Fiori Launchpad 里的 Manage Your Solution 这个 tile，

进入 Configure Your Solution,

根据关键字 contact 进行搜索，在搜索结果列表里找到 Contacts and Profiles 相关的配置：

其中第六步， OriginContactID-Configure 这一步，就是合并时针对来自不同平台的 contact 数据，执行合并或新建操作的配置。

点击之后，能看到一个 contact 属性列表，从这些属性列表不难推断出 SAP Marketing Cloud 支持导入 contact 的数据源有 S/4HANA，ERP，CRM，Hybris Commerce，SAP Cloud for Customer，Gigya，Qualtrics 和社交媒体如 Twitter，Facebook 等等。

上图有两列，分别对应为每个属性指定 One Per Contact 和 Shareable 为 true 还是 false 的界面。前者顾名思义，如果设置为 true，意味着一个 contact 在同一个数据源系统里只能拥有一个唯一值，比如一个人的护照号码，或者 SAP 系统里的 Customer ID；反之像 Email，座机号，传真号这种属性，一个 contact 在同一个数据源系统里如果允许存在多个值，则 One Per Contact 设置为 false。而 Shareable 属性置为 true，适合那些在同一个数据源系统里允许多个不同 contact 具有相同值的属性，比如一家人的 contacts 的座机号允许相同。

对每一个 Contact 属性，One Per Contact 和 Shareable 的 true/false 状态排列组合共有四种，其中 One Per Contact 为 true 的两种情况，即使系统在检测到匹配的属性情况下，也可能会导致 contact 数据的创建，而不是 merge，也就是下图中第二行和第四行标注了感叹号的情况。

看一些具体的例子：

(1) 手机号码属性的 Sharable 为 false，One Per Contact 为 false。

来自 SAP ERP 和 Web Shop 的这两条数据，mobile 字段都相同，Marketing Cloud 进行合并，合并之后的 contact 数据具有分别来自 ERP 和 Web Shop 的两个 facet。

(2) 手机号码属性的 Sharable 为 false，One Per Contact 为 true。

在同一个 Web Shop 系统里存在两条 contact 记录，虽然其手机号码维护的值都相同，但是因为 One Per Contact 设置为 true，因此 Marketing Cloud 不进行 merge，而是新建了两条 Contact 记录，其 mobile facet 的值都为该相同的手机号，而 Web Shop ID facet 的值分别来自 Web Shop 系统的原始值。

(3) Email 属性的 Sharable 为 true，One Per Contact 为 false。

来自 SAP ERP 和 SAP CRM 的两条数据，Email 地址都相同，One Per Contact 也维护的是 false，但是因为它们的 full name 不一致，所以最后导入到 Marketing Cloud 里还是会分别生成两条 Contact 数据。

导入到 Marketing Cloud 中的 Contact 数据，仍然可以通过其标签页 Origin Data 查看每个属性的来源。

我们使用 nodejs 对 contact 进行修改时，需要指定待修改 contact 实例的 guid。

这个 guid 属于 technical 属性，在 Marketing Cloud UI 上默认情况下不可见。如何找到这个属性值呢？

其实就在浏览器地址栏的 url 里：

当然在 Chrome 开发者工具的 network 标签页里也能找到这个 guid：

总结

本文首先介绍了 SAP Marketing Cloud Contact(联系人)模型的概要设计，接着从实际例子出发，介绍了来自不同数据源的联系人数据导入云系统时，不同维度的属性是如何进行合并(merge), 从而生成最终的单一记录。