SAP Marketing Cloud的Contact導(dǎo)入配置和數(shù)據(jù)合并原理是什么

今天就跟大家聊聊有關(guān)SAP Marketing Cloud的Contact導(dǎo)入配置和數(shù)據(jù)合并原理是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

SAP很多系統(tǒng)的主數(shù)據(jù)都支持從外部系統(tǒng)導(dǎo)入，SAP Marketing Cloud也是如此，contact主數(shù)據(jù)可以來自Hybris Commerce，CRM，ERP或者Twitter，F(xiàn)acebook等社交媒體。來自不同渠道的contact可能對(duì)應(yīng)的是真實(shí)世界里同一個(gè)人，那么就存在一個(gè)過程，該過程的邏輯是將不同渠道的contact數(shù)據(jù)進(jìn)行整合，拼湊出一個(gè)包含完整信息的contact主數(shù)據(jù)存儲(chǔ)到Marketing Cloud系統(tǒng)里，這個(gè)拼湊的過程稱之為合并(merge)，拼湊后形成的完整Contact結(jié)構(gòu)稱為Golden record。

下面這張示意圖里的藍(lán)色圓環(huán)稱為Main facet，代表每個(gè)contact數(shù)據(jù)在某個(gè)源系統(tǒng)上的ID，比如在ERP系統(tǒng)上的ID為123，在Twitter上的ID為456等等。而黃色圓環(huán)是contact在各自源系統(tǒng)里的屬性，比如在Twitter網(wǎng)站上ID為456的一個(gè)contact，其name屬性為jerrywang@sap。黃色圓環(huán)稱之為additional facet.

通過在SAP Marketing Cloud里進(jìn)行一系列配置，告訴系統(tǒng)，當(dāng)檢測(cè)到來自不同數(shù)據(jù)源的contact數(shù)據(jù)，存在至少一個(gè)相同屬性的情況下，應(yīng)該執(zhí)行何種contact操作，也就是合并或者新建。

比如下圖在ERP，F(xiàn)acebook和Web Shop上有三條contact數(shù)據(jù)，其Email地址的值都相同，那么進(jìn)行數(shù)據(jù)導(dǎo)入時(shí)，基于預(yù)定義好的配置，Marketing Cloud認(rèn)為這三條數(shù)據(jù)指向的是同一個(gè)人，所以最后merge出來生成唯一一條contact記錄。

Marketing Cloud具體merge的過程，就是根據(jù)SAP Marketing Cloud系統(tǒng)里的customizing配置，將三條Email地址都相同的記錄作為當(dāng)前merge的輸入，然后逐一將本記錄內(nèi)的屬性“投影”到最終的Golden Record里。如果把Golden Record想象成最終完整的拼圖，那么這個(gè)merge過程就有些類似于拼圖操作——將散布在各個(gè)數(shù)據(jù)源中的零散信息合并成一個(gè)整體，存儲(chǔ)在Marketing Cloud系統(tǒng)內(nèi)以便進(jìn)行后續(xù)處理。

Marketing Cloud里針對(duì)contact導(dǎo)入系統(tǒng)時(shí)的merge操作的相關(guān)customizing設(shè)置，在整個(gè)contact導(dǎo)入過程中起著至關(guān)重要的作用。

和SAP Cloud for Customer等很多云產(chǎn)品一樣，SAP Marketing Cloud的customizing也是在瀏覽器里完成。

點(diǎn)擊Fiori Launchpad里的Manage Your Solution這個(gè)tile，

進(jìn)入Configure Your Solution,

根據(jù)關(guān)鍵字contact進(jìn)行搜索，在搜索結(jié)果列表里找到Contacts and Profiles相關(guān)的配置：

其中第六步， OriginContactID-Configure這一步，就是合并時(shí)針對(duì)來自不同平臺(tái)的contact數(shù)據(jù)，執(zhí)行合并或新建操作的配置。

點(diǎn)擊之后，能看到一個(gè)contact屬性列表，從這些屬性列表不難推斷出SAP Marketing Cloud支持導(dǎo)入contact的數(shù)據(jù)源有S/4HANA，ERP，CRM，Hybris Commerce，SAP Cloud for Customer，Gigya，Qualtrics和社交媒體如Twitter，F(xiàn)acebook等等。

上圖有兩列，分別對(duì)應(yīng)為每個(gè)屬性指定One Per Contact和Shareable為true還是false的界面。前者顧名思義，如果設(shè)置為true，意味著一個(gè)contact在同一個(gè)數(shù)據(jù)源系統(tǒng)里只能擁有一個(gè)唯一值，比如一個(gè)人的護(hù)照號(hào)碼，或者SAP系統(tǒng)里的Customer ID；反之像Email，座機(jī)號(hào)，傳真號(hào)這種屬性，一個(gè)contact在同一個(gè)數(shù)據(jù)源系統(tǒng)里如果允許存在多個(gè)值，則One Per Contact設(shè)置為false。而Shareable屬性置為true，適合那些在同一個(gè)數(shù)據(jù)源系統(tǒng)里允許多個(gè)不同contact具有相同值的屬性，比如一家人的contacts的座機(jī)號(hào)允許相同。

對(duì)每一個(gè)Contact屬性，One Per Contact和Shareable的true/false狀態(tài)排列組合共有四種，其中One Per Contact為true的兩種情況，即使系統(tǒng)在檢測(cè)到匹配的屬性情況下，也可能會(huì)導(dǎo)致contact數(shù)據(jù)的創(chuàng)建，而不是merge，也就是下圖中第二行和第四行標(biāo)注了感嘆號(hào)的情況。

看一些具體的例子：

1. 手機(jī)號(hào)碼屬性的Sharable為false，One Per Contact為false。

來自SAP ERP和Web Shop的這兩條數(shù)據(jù)，mobile字段都相同，Marketing Cloud進(jìn)行合并，合并之后的contact數(shù)據(jù)具有分別來自ERP和Web Shop的兩個(gè)facet。

2. 手機(jī)號(hào)碼屬性的Sharable為false，One Per Contact為true。

在同一個(gè)Web Shop系統(tǒng)里存在兩條contact記錄，雖然其手機(jī)號(hào)碼維護(hù)的值都相同，但是因?yàn)镺ne Per Contact設(shè)置為true，因此Marketing Cloud不進(jìn)行merge，而是新建了兩條Contact記錄，其mobile facet的值都為該相同的手機(jī)號(hào)，而Web Shop ID facet的值分別來自Web Shop系統(tǒng)的原始值。

3. Email屬性的Sharable為true，One Per Contact為false。

來自SAP ERP和SAP CRM的兩條數(shù)據(jù)，Email地址都相同，One Per Contact也維護(hù)的是false，但是因?yàn)樗鼈兊膄ull name不一致，所以最后導(dǎo)入到Marketing Cloud里還是會(huì)分別生成兩條Contact數(shù)據(jù)。

導(dǎo)入到Marketing Cloud中的Contact數(shù)據(jù)，仍然可以通過其標(biāo)簽頁Origin Data查看每個(gè)屬性的來源。

看完上述內(nèi)容，你們對(duì)SAP Marketing Cloud的Contact導(dǎo)入配置和數(shù)據(jù)合并原理是什么有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。