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), 从而生成最终的繁多记录。