Adobe Experience Platform中資料建模的最佳實務

Experience Data Model (XDM)是核心架構,可透過提供用於下游Adobe Experience Platform服務的通用結構和定義,標準化客戶體驗資料。 遵循XDM標準,所有客戶體驗資料都可以整合在通用的呈現方式中,讓您從客戶行動中獲得寶貴的見解,透過細分定義客戶受眾,並表達客戶屬性以利個人化。

由於XDM具備極強的通用性,而且可依設計自訂,因此在設計結構描述時,請務必遵循資料建模的最佳實務。 本檔案涵蓋將客戶體驗資料對應至XDM時,您必須做出的主要決策和考量。

快速入門

在閱讀本指南之前,請先閱讀 XDM系統概觀 ,以瞭解XDM及其在Experience Platform中的角色。

此外,本指南專門針對架構設計的主要考量事項。 因此,強烈建議您參考架構構 成的基本概念 ,以詳細說明本指南中提及的個別架構元素。

最佳做法摘要

設計資料模型以用於Experience Platform的建議方法可總結如下:

  1. 瞭解您資料的商業使用案例。
  2. 確定應引入的主要資料來源以解決 Platform 這些使用案例。
  3. 識別可能也有興趣的次要資料來源。 例如,如果您組織中目前只有一個業務單位有興趣將其資料發佈至 Platform,則類似的業務單位日後可能也有興趣將類似資料發佈至。 考慮到這些次要來源有助於在整個組織內標準化資料模型。
  4. 為已識別的資料來源建立高階實體關係圖(ERD)。
  5. 將高階ERD轉換為以 Platform中心為中心的ERD(包括描述檔、體驗事件和查閱實體)。

識別執行業務使用案例所需之適用資料來源的相關步驟因組織而異。 本檔案其餘各節著重於在確定資料源後組織和構建ERD的後續步驟,但圖表各組成部分的解釋可能會通知您有關哪些資料源應遷移到哪個資料源的決策 Platform。

建立高級ERD

確定要引入的資料源後 Platform,請建立高級ERD以幫助指導將資料映射到XDM架構的過程。

以下範例代表想要將資料帶入的公司的簡化ERD Platform。 圖中強調了應分類為XDM類別的基本實體,包括客戶帳戶、酒店、地址和幾個常見的電子商務事件。

將實體排序至描述檔、查閱和事件類別

在您建立ERD以識別要引入的基本實體後 Platform,這些實體必須分類至描述檔、查閱和事件類別:

類別 說明
描述檔實體 描述檔實體代表與個人(通常是客戶)相關的屬性。 屬於此類別的實體應由基於類的方案來表 XDM Individual Profile示
查閱實體 查閱實體代表可與個人相關的概念,但無法直接用於識別個人。 屬於此類別的實體應由基於自定義類的方案 表示
事件實體 事件實體代表與客戶可採取的動作、系統事件或您想要追蹤隨時間變化的任何其他概念相關的概念。 屬於此類別的實體應由基於類的方案來表 XDM ExperienceEvent示

實體排序的注意事項

以下各節提供如何將實體分類為上述類別的進一步指引。

客戶屬性

如果實體包含任何與個別客戶相關的屬性,則很可能是描述檔實體。 客戶屬性的範例包括:

  • 個人詳細資訊,例如姓名、出生日期、性別和帳戶ID。
  • 位置資訊,如地址和GPS資訊。
  • 聯絡資訊,例如電話號碼和電子郵件地址。

隨時間追蹤資料

如果您想要分析實體中特定屬性隨時間變化的情形,則最有可能是事件實體。 例如,將產品項目新增至購物車,可在下列項目中被追蹤為新增至購物車事件 Platform:

客戶 ID 類型 產品 ID 數量 時間戳記
1234567 新增 275098 2 10月1日,上午10點32分
1234567 移除 275098 1 10月1日,上午10點33分
1234567 新增 486502 1 10月1日,上午10點41分
1234567 新增 910482 5 10月3日,下午2:15

區段使用案例

在將實體分類時,請務必考慮您要建立的受眾細分,以解決您的特定業務使用案例。

例如,公司想瞭解其忠誠度計畫中所有「金級」或「白金級」會員,這些會員去年已購買超過5次。 根據此分段邏輯,可就相關實體的表述方式得出以下結論:

  • 「金級」和「白金級」代表適用於個別客戶的忠誠度狀態。 由於區段邏輯僅關乎客戶目前的忠誠度狀態,因此此資料可建模為描述檔架構的一部分。 如果您希望追蹤一段時間內忠誠度狀態的變更,也可以建立其他的忠誠度狀態變更事件結構。
  • 購買是發生在特定時間的事件,而區段邏輯則與指定時間範圍內的購買事件有關。 因此,此資料應建模為事件架構。

啟動使用案例

除了區段使用案例的考量外,您也應檢視這些區段的啟動使用案例,以識別其他相關屬性。

例如,公司已根據該規則建立受眾區段 country = US。 然後,當將該區段啟動至特定的下游目標時,公司會想根據首頁狀態來篩選所有匯出的描述檔。 因此,應 state 該在適用的描述檔實體中擷取屬性。

匯總值

根據資料的使用案例和詳細程度,您應決定某些值在納入描述檔或事件實體之前是否需要預先匯總。

例如,公司想要根據購物車購買次數建立區段。 您可以選擇將每個時間戳記購買事件納入為其專屬實體,以最低精細度併入此資料。 但是,這有時會以指數方式增加已記錄事件的數量。 若要減少所擷取事件的數目,您可以選擇在一週或一個月 numberOfPurchases 的期間內建立匯總值。 其他集合函式(如MIN和MAX)也可以應用於這些情況。

注意

Experience Platform目前不會執行自動值匯總,不過預計未來將推出此功能。 如果您選擇使用匯總值,則必須在外部執行計算,才能將資料發送到 Platform。

基數

在ERD中建立的基數也可以提供一些關於如何分類實體的線索。 如果兩個實體之間有一對多關係,代表「多」的實體可能會是事件實體。 不過,在某些情況下,「many」是一組查閱實體,在描述檔實體中以陣列形式提供。

注意

由於沒有通用方法適合所有使用案例,因此在根據基數對實體分類時,必須考慮每種情況的利弊。 如需詳細 資訊 ,請參閱下一節。

下表概述了一些常見的實體關係以及可從它們派生的類別:

關係 基數 實體類別
客戶和購物車結帳 一對多 單一客戶可能有許多購物車結帳,這些事件是可隨時間追蹤的事件。 因此,客戶會是描述檔實體,而購物車結帳則會是事件實體。
客戶和忠誠度帳戶 一對一 單一客戶只能有一個忠誠度帳戶,反之亦然。 由於關係是一對一的,「客戶」和「忠誠度帳戶」都表示個人檔案實體。
客戶與訂閱 一對多 單一客戶可能有許多訂閱。 由於公司只關心客戶目前的訂閱,因此「客戶」是描述檔實體,而「訂閱」是查閱實體。

不同實體類的利弊

雖然上節提供了一些一般准則,可決定如何分類實體,但請務必瞭解,在選擇一個實體類別而非另一個實體類別時,通常有利有弊。 以下案例研究旨在說明您在這些情況下如何考慮您的選項。

公司會追蹤客戶的有效訂閱,其中一位客戶可以擁有許多訂閱。 該公司也想納入區段使用案例的訂閱,例如尋找所有有效訂閱的使用者。

在此情況下,公司有兩個潛在選項可在其資料模型中代表客戶的訂閱:

  1. 使用描述檔屬性
  2. 使用事件實體

方法1:使用描述檔屬性

第一種方法是在客戶的描述檔實體中加入一系列訂閱作為屬性。 此陣列中的對象將包 category含、 statusplanNamestartDate的欄位 endDate


專業人員

  • 分段對於預期的使用案例是可行的。
  • 結構將僅保留客戶的最新訂閱記錄。

缺點

  • 每次對陣列中的任何欄位進行更改時,都必須重述整個陣列。
  • 如果不同的資料源或業務單元將資料送入陣列,則跨所有通道保持最新更新的陣列同步將變得十分困難。

方法2:使用事件實體

第二種方法是使用事件結構描述來表示訂閱。 這需要新增訂閱ID、客戶ID和發生訂閱事件的時間戳記,以吸收與第一個方法相同的訂閱欄位。


專業人員

  • 區段規則可以更有彈性(例如尋找所有在過去30天內變更訂閱的客戶)。
  • 當客戶的訂閱狀態改變時,您不再需要更新客戶描述檔屬性中長且可能複雜的陣列。 如果客戶的訂閱清單同時發生來自多個來源的變更,這特別有用。

缺點

  • 原始預期使用案例的區段變得更複雜(識別客戶最近訂閱的狀態)。 區段現在需要額外的邏輯來標籤客戶的最後一個訂閱事件,以檢查其狀態。

根據分類的實體建立結構

在將實體分類至描述檔、查閱和事件類別後,您就可以開始將資料模型轉換為XDM結構。 為了進行演示,前面顯示的示例資料模型已按照下圖中的相應類別進行了分類:


實體已排序的類別應決定您基於其模式的XDM類。 重申:

  • 配置檔案實體應使用 XDM Individual Profile 類。
  • 事件實體應使用 XDM ExperienceEvent 類。
  • 查閱實體應使用您組織定義的自訂XDM類別。
注意

事件實體幾乎總是由不同的結構描述來表示,但配置檔案或查找類別中的實體可以在單個XDM結構描述中組合在一起,具體取決於其基數。

例如,由於「客戶」實體與LoyaltyAccounts實體有一對一關係,因此「客戶」實體的方案也可能包含一個物件,以包含每個客戶的適當忠誠度欄位。 LoyaltyAccount 但是,如果關係是一對多,則表示「多」的實體可以由單獨的模式或配置檔案屬性陣列表示,具體取決於其複雜性。

以下各節提供有關基於ERD構建方案的一般指導。

採用迭代建模方法

模式 演化規則規定 ,只有架構實施後,才能對其進行非破壞性的變更。 換言之,一旦您新增欄位至架構,且資料已擷取到該欄位,該欄位便無法再移除。 因此,在您首次建立結構描述時,必須採用迭代建模方法,首先是簡化的實作,此實作會逐漸增加複雜性。

如果您不確定是否需要將特定欄位包含在方案中,則最佳做法是將其排除在外。 如果稍後確定該欄位是必要的,則始終可以在模式的下一個小版本中添加該欄位。

身分欄位

在Experience Platform中,標示為身分的XDM欄位可用來整合來自多個資料來源的個別客戶相關資訊。 雖然架構可以有多個欄位標籤為標識,但必須定義單個主標識,才能在中啟用該架構 Real-time Customer Profile。 如需這些欄位 使用案例的詳細資訊 ,請參閱架構構成基礎中的識別欄位一節。

在設計方案時,關係資料庫表中的任何主鍵都可能是主標識的候選。 適用身分欄位的其他範例包括客戶電子郵件地址、電話號碼、帳戶ID和 ECID

Adobe應用程式混合

Experience Platform提供數種現成可用的XDM混合,以擷取與下列Adobe應用程式相關的資料:

  • Adobe Analytics
  • Adobe Audience Manager
  • Adobe Campaign
  • Adobe Target

例如, Adobe Analytics ExperienceEvent Template Mixin 可讓您將特定欄 Analytics位對應至XDM結構。 根據您使用的Adobe應用程式,您應在結構描述中使用這些Adobe提供的混合程式。


Adobe應用程式混合會透過使用欄位自動指派預設的主要身分識別 identityMap ,此欄位是系統產生的唯讀物件,可對應個別客戶的標準身分識別值。

對於Adobe Analytics,ECID是預設的主要身分識別。 如果客戶未提供ECID值,則主要身分會預設為AAID。

重要

使用Adobe應用程式混合時,不應將任何其他欄位標示為主要身分。 如果有其他屬性需要標示為身分,則這些欄位需改為指派為次要身分。

後續步驟

本檔案涵蓋針對Experience Platform設計資料模型的一般准則和最佳實務。 總結:

  • 使用自上而下的方法,在建構結構之前,先將資料表格排序為描述檔、查閱和事件類別。
  • 針對不同用途設計結構描述時,通常有多種方法和選項。
  • 您的資料模型應能支援您的業務使用案例,例如細分或客戶歷程分析。
  • 讓結構描述盡可能簡單,而且只有在需要時才新增欄位。

準備好後,請參閱在UI中建立架構的教學課程 ,以取得如何建立架構的逐步指示、為實體指派適當的類別,以及新增欄位以將資料對應至。

本頁內容