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), 從而生成最終的單一記錄。