資料模型最佳實務

本檔案概述設計Adobe Campaign資料模型時的主要建議。

概觀

Adobe Campaign系統極具彈性，可延伸至初始實作以外。 不過，儘管可能性無限，但必須做出明智決策並建立堅實的基礎，才能開始設計您的資料模型。

本檔案提供常見的使用案例和最佳實務，以瞭解如何正確設計Adobe Campaign工具。

資料模型架構

Adobe Campaign Standard是功能強大的跨通道宣傳管理系統，可協助您調整線上和線下策略，以建立個人化的客戶體驗。

以客戶為中心的方法

雖然大部分電子郵件服務供應商都是透過以清單為中心的方式與客戶溝通，但Adobe Campaign依賴關係式資料庫，以運用更廣泛的客戶及其屬性檢視。

以客戶為中心的方法如下圖所示。 以灰色 表示的Profile 資源代表正在構建所有功能的主要客戶表：

Adobe Campaign預設資料模型會顯示在本 節。

Adobe Campaign的資料

哪些資料應傳送至Adobe Campaign? 確定您的行銷活動所需的資料至關重要。

若要決定Adobe Campaign是否需要屬性，請判斷屬性是否屬於下列類別：

• 用於劃分的屬 性
• 用於資料管 理進程的屬性 （例如聚合計算）
• 用於個人化的屬 性
• 用於報告的 屬性 （可以根據自訂描述檔資料建立報告）

如果您不是落入其中任何一個，Adobe Campaign中很可能不需要此屬性。

資料類型

為確保系統的良好架構和效能，請遵循下列最佳實務，在Adobe Campaign中設定資料：

• 字串欄位的長度應一律以欄定義。 依預設，Adobe Campaign中的最大長度為255個字元，但Adobe建議您在已知大小不會超過較短長度的情況下，將欄位保持在較短的長度。
• 如果您確定來源系統的大小被高估且無法達到，則Adobe Campaign中的欄位會比來源系統中的欄位短，這是可接受的。 這可能表示Adobe Campaign中的字串較短或整數較小。

配置資料結構

本節概述了配置資源 資料結構時的最佳做法。

識別碼

Adobe Campaign資源有三個識別碼，而且可以新增其他識別碼。

下表說明這些識別碼及其用途。

顯示名稱	技術名稱	說明	最佳實務
	PKey	PKey是Adobe Campaign表的實體主鍵。 此識別碼通常對特定Adobe Campaign例項唯一。 在Adobe Campaign Standard中，一般使用者看不到此值（URL除外）。	通過 API系統，可以檢索PKey值（該值是生成／散列值，而不是物理密鑰）。 建議不要將它用於任何其他目的，而不是透過API擷取、更新或刪除記錄。
ID	name或internalName	此資訊是表中記錄的唯一標識符。 此值可以手動更新。 此識別碼會在部署至不同的Adobe Campaign例項時保留其值。 它的名稱必須與生成的值不同，才能通過包導出。 這不是表的實際主鍵。	請勿使用特殊字元，例如空格""、半欄":"或連字型大小"-"。 所有這些字元都會以底線"_"（允許的字元）取代。 例如，"abc-def"和"abc:def"會儲存為"abc_def"，並互相覆寫。
標籤	標籤	標籤是Adobe Campaign中物件或記錄的商業識別碼。 此對象允許空格和特殊字元。 它不保證記錄的獨特性。	建議您決定物件標籤的結構。 這是最易用的解決方案，可為Adobe Campaign使用者識別記錄或物件。
ACS ID	acsId	可產生其他識別碼： ACS ID。 由於PKey不能用於Adobe Campaign使用者介面，因此此解決方案可讓您取得插入描述檔記錄時產生的唯一值。 只有在將記錄插入Adobe Campaign之前，在資源中啟用該選項時，才能自動產生值。	此UUID可用作協調鍵。 自動生成的ACS ID不能用作工作流或包定義中的引用。 此值是Adobe Campaign例項專屬的。

識別鍵

在Adobe Campaign中建立的每個資源至少必須有一個唯一 識別碼。

建立自定義資源時，有兩個選項：

• 自動產生的金鑰與內部自訂金鑰的組合。 如果您的系統金鑰是複合金鑰或非整數，這個選項就很有趣。 整數在大表格和與其他表格連接時，可提供更高的效能。
• 使用主鍵作為外部系統主鍵。 此解決方案通常較為受歡迎，因為它可簡化資料匯入和匯出的方式，而且不同系統之間的索引鍵一致。

在工作流程中，不應使用識別碼作為參考。

索引

Adobe Campaign會自動將索 引新增 至資源中定義的所有主要和內部索引鍵。

• Adobe建議定義其他索引，因為它可能會改善效能。
• 但是，不要添加太多索引，因為它們在資料庫上使用空間。 許多索引也可能對效能產生負面影響。
• 仔細選擇需要定義的索引。

連結

本節將介紹如何定義與其他資源 的連結。

• 雖然可以在工作流程中加入任何表格，但Adobe建議直接在資料結構定義中定義資源之間的共同連結。
• 連結的定義應與表格中的實際資料一致。 錯誤的定義可能會影響透過連結擷取的資料，例如意外重複記錄。
• 以資源名稱一致命名連結：連結名稱應有助於瞭解遠程表是什麼。
• 請勿將連結命名為「id」為尾碼。 例如，將其命名為"transaction"，而非"transactionId"。

效能

為了確保隨時都能提供更佳的效能，請遵循下列最佳實務。

一般性建議

• 請避免在查詢中使用「CONTAINS」等操作。 如果您知道要篩選的項目，請使用「EQUAL TO」或其他特定篩選運算子套用相同的條件。
• 在工作流程中建立資料時，請避免加入非索引欄位。
• 請試著確保在工作時間完成匯入和匯出等程式。
• 請確定所有日常活動都有排程，並遵守排程。
• 如果一個或幾個日進程失敗，並且如果強制在同一天運行該進程，請確保手動進程啟動時沒有運行衝突的進程，因為這可能影響系統效能。
• 請確定匯入程式期間或執行任何手動程式時，未執行任何每日促銷活動。
• 使用一或多個參考表，而不是在每一列中複製欄位。 使用鍵／值對時，最好選擇數字鍵。
• 短字串仍可接受。 如果參考表格已在外部系統中，重複使用參考表格將有助於與Adobe Campaign的資料整合。

一對多關係

• 資料設計會影響可用性和功能。 如果您設計的資料模型具有許多一對多關係，使用者就很難在應用程式中建構有意義的邏輯。 一對多篩選邏輯對於不具備技術背景的行銷人員而言可能很難正確建構和理解。
• 將所有必要欄位都放在一個表格中是好事，因為這可讓使用者更輕鬆地建立查詢。 有時，如果在表中複製某些欄位，則避免連接也會對效能有好處。
• 某些內建功能將無法參考一對多關係，例如選件加權公式和傳送。

大型表格

以下是使用大型表和複雜連接設計資料模型時應遵循的一些最佳實踐。

• 減少欄數，尤其是識別未使用的欄數。
• 通過避免複雜的連接（如多個條件和／或多個列上的連接）來優化資料模型關係。
• 對於連接鍵，請始終使用數字資料，而不是字串。
• 盡可能減少日誌保留深度。 如果您需要更深入的歷史記錄，您可以匯總計算和／或處理自訂的日誌表，以儲存較大的歷史記錄。