SAP很多系统的主数据都支持从外部系统导入，SAPMarketingCloud也是如此。联系人主数据可以来自HybrisCommerce、CRM、ERP或Twitter、Facebook等社交媒体。不同渠道的联系人可能对应的是现实世界中的同一个人，所以有一个过程。这个过程的逻辑是整合不同渠道的联系人数据，拼凑出一个包含完整信息的联系人主数据，存储在MarketingCloud系统中，这个拼凑的过程叫做合并，拼凑后形成的完整的Contact结构叫做金唱片。下图中的蓝色圆圈称为Mainfacet，表示每个联系人数据在某个源系统上的ID，比如ERP系统上的ID123，Twitter上的ID456等。黄圈是联系人在各个源系统中的属性。例如，Twitter网站上ID为456的联系人的姓名属性为jerrywang@sap。黄色圆圈称为附加刻面。通过SAPMarketingCloud中的一系列配置，告诉系统当检测到来自不同数据源的联系人数据，并且至少存在一个相同属性时，应该进行什么样的联系人操作。那就是合并或者创建一个新的。例如，如下图，ERP、Facebook、WebShop上有3条联系人数据，都具有相同的email地址值。导入数据时，MarketingCloud根据预定义的配置，认为这三条数据指向同一个人，所以最后合并出来生成唯一的联系人记录。MarketingCloud的具体合并过程是根据SAPMarketingCloud系统中的自定义配置，将邮箱地址相同的三条记录作为本次合并的输入，然后将这条记录中的属性“投射”到最终的金唱片一张一张。如果把金唱片想象成最终完成的拼图，那么这个合并过程有点类似于拼图操作——将分散在各个数据源中的零散信息合并为一个整体，存储在MarketingCloud系统中，以供后续处理.在MarketingCloud中，联系人导入系统时合并操作的相关自定义设置，在整个联系人导入过程中起着至关重要的作用。和SAPCloudforCustomer等很多云产品一样，SAPMarketingCloud的定制也是在浏览器中完成的。点击FioriLaunchpad中的ManageYourSolution磁贴，进入ConfigureYourSolution，根据关键字contact搜索，在搜索结果列表中找到Contacts和Profiles相关的配置：第六步OriginContactID-Configure，就是合并的时候用于对来自不同平台的联系人数据执行合并或新操作的配置。单击后，您可以看到联系人属性列表。从这些属性列表中不难推断，SAPMarketingCloud支持导入联系人的数据源包括S/4HANA、ERP、CRM、HybrisCommerce、SAPCloudforCustomer、Gigya、Qualtrics和社交媒体如Twitter、Facebook等。上图中有两列，分别对应的是指定OnePerContact和Shareable每个属性是true还是false的接口。前者，顾名思义，如果设置为true，意味着一个联系人在同一个数据源系统中只能有一个唯一值，比如一个人的护照号码，或者SAP系统中的CustomerID；否则，像Email、座机号码、传真号码这样的属性，如果在同一个数据源系统中允许一个联系人有多个值，则OnePerContact设置为false。Shareable属性设置为true，适用于允许多个不同联系人在同一个数据源系统中具有相同值的属性，例如允许一个家庭的联系人座机号码相同。对于每个联系人属性，存在每个联系人一个和可共享的四种真/假状态组合。其中，OnePerContact为true的两种情况，即使系统检测到匹配属性，也可能会导致联系人数据。是创建，不是合并，也就是下图中第二、四行标有感叹号。看一些具体的例子：（1）手机号属性的Sharable为false，OnePerContact为false。来自SAPERP和WebShop的两个数据具有相同的移动字段，MarketingCloud将它们合并。合并的联系人数据有两个方面，分别来自ERP和网上商店。(2)手机号属性的Sharable为false，OnePerContact为true。同一个网店系统中有两条联系人记录。虽然他们的手机号码保持相同的值，但由于OnePerContact设置为true，MarketingCloud不会合并，而是创建两条新的Contact记录。mobile的分面值都是同一个电话号码，WebShopID的分面值来自于WebShop系统的原始值。(3)Email属性的Sharable为true，OnePerContact为false。来自SAPERP和SAPCRM的两份数据有相同的email地址，OnePerContact也维护为false，但由于全名不一致，最终导入Marketing时还是会生成两份Contact数据云。导入到MarketingCloud的联系人数据仍然可以通过其选项卡页面来源数据查看每个属性的来源。我们在使用nodejs修改联系人时，需要指定要修改的联系人实例的guid。此guid属于技术属性，默认情况下在MarketingCloudUI上不可见。如何找到这个属性值？其实就是在浏览器地址栏的url中：当然这个guid也可以在Chrome开发者工具的网络选项卡中找到：总结本文首先介绍一下SAPMarketingCloudContact（联系人）的概要设计模型，然后从实例出发，从本章开始，介绍在将不同数据源的联系人数据导入云系统时，如何合并不同维度的属性，从而生成最终的单条记录。
