資料建模的最佳實務

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架構的過程。

以下範例代表公司想要將資料匯入Platform的簡化ERD。 圖中強調了應分類為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:使用描述檔屬性

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


專業人員

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

缺點

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

方法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欄位組允許您將Analytics特定欄位映射到XDM方案。 根據您正在使用的Adobe應用程式,您應該在方案中使用這些Adobe提供的欄位組。


Adobe應用程式欄位組通過使用identityMap欄位自動分配預設的主標識,該欄位是系統生成的只讀對象,用於映射單個客戶的標準標識值。

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

重要

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

後續步驟

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

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

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

本頁內容