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