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檢視每個屬性的來源。

更多閱讀

The Main ID Origin Customizing Settings for Contacts in SAP S/4HANA Marketing and SAP Hybris Marketing

https://blogs.sap.com/2016/10/17/main-id-origin-customizing-settings-contacts-sap-s4hana-marketing-sap-hybris-marketing/#
Contacts in SAP Hybris Marketing – Understanding the Concept of Golden Records

https://blogs.sap.com/2016/08/26/contacts-in-sap-hybris-marketing-understanding-the-concept-of-golden-records/#
How Does SAP Hybris Marketing Build the Golden Record of an Interaction Contact?

https://blogs.sap.com/2016/07/01/how-does-sap-hybris-marketing-build-the-golden-record-of-an-interaction-contact/

SAP Marketing Cloud的Contact匯入配置和資料合併原理

相關文章