建立合併原則

在本課程中，您將建立合併原則，以排定多個資料來源合併至設定檔的優先順序。

Adobe Experience Platform可讓您將來自多個來源的資料彙集在一起，並將其結合，以檢視每個個別客戶的完整檢視。 彙總此資料時，合併原則會決定資料的優先順序，以及要合併哪些資料以建立該統一檢視。

在本課程中，我們將堅持使用使用者介面，但也會有用於建立合併原則的API選項。

資料架構師 ​需要在本教學課程之外建立合併原則。

在開始練習之前，請觀看此短片，以進一步瞭解合併原則：

需要的許可權

在設定許可權課程中，您已設定完成本課程所需的所有存取控制。

關於合併原則與聯合結構描述

您可能會記得，在批次擷取的課程中，我們上傳了兩個記錄，包含相同客戶的稍微不同的資訊。 在Loyalty資料中，客戶的名字是Daniel，而他住在New York City，但在CRM資料中，客戶的名字是Danny，而他住在Portland。 客戶資料會隨著時間而改變。 他可能從Portland移至New York City。 其他專案也會變更，例如電話號碼和電子郵件地址。 當兩個資料來源為同一個使用者提供不同資訊時，合併原則可協助您決定如何處理這些型別的衝突。

那麼，為什麼Danny會以名字取勝？ 讓我們來看一下：

為設定檔啟用多個結構描述時，系統會自動為所有已啟用設定檔的結構描述建立聯合結構描述，記錄共用基底類別的結構描述。 您可以前往「聯合結構描述」標籤，檢視聯合結構描述。

請注意，ExperienceEvent類別沒有聯合結構描述。 雖然ExperienceEvent資料仍會出現在設定檔中，因為它是以時間序列為基礎，每個事件都包含時間戳記和ID，所以衝突並不是問題。

現在，如果您不喜歡該預設合併原則，該怎麼辦？ 如果Luma決定他們的忠誠度系統在衝突時應該是真相的來源呢？ 為此，我們將建立合併原則。

在UI中建立合併原則

驗證合併原則

讓我們看看合併原則是否如預期般執行：

使用有限的資料集建立合併原則

使用資料集優先順序建立合併原則時，設定檔中只會包含您在右側包含的相同基底類別的資料集。 讓我們設定另一個合併原則

驗證合併原則

現在來看看此合併原則的功用：

CRM ID是Luma Loyalty Dataset中的身分欄位，但只能使用主要身分來查閱設定檔。 那麼，讓我們使用主要身分Luma Loyalty Id來查閱設定檔。」

深入瞭解合併原則

在設定檔搜尋中，將使用的合併原則變更回Default Timebased，並選取​ 顯示設定檔 ​按鈕。 丹尼回來了！

這是怎麼回事？ 嗯，設定檔合併並非一次性專案。 系統會根據多種因素（包括使用何種合併原則），即時組裝即時客戶設定檔。 您可以根據想要的客戶檢視，建立要在不同內容中使用的多個合併原則。

合併原則的主要使用案例是資料治理。 例如，假設您擷取第三方資料至Platform，該資料無法用於個人化使用案例，但​ 可以 ​用於廣告使用案例。 您可以建立排除此第三方資料集的合併原則，並使用此合併原則來建立廣告使用案例的區段。

其他資源

現在讓我們移至資料治理架構。