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