資料模型最佳實務

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

Adobe Campaign系統非常靈活，可擴展到初始實施之外。 但是，儘管可能性是無限的，但做出明智決策並建立堅實的基礎是開始設計您的資料模型的關鍵。

要更好地瞭解活動內置表以及它們之間的關係，請參閱 此部分 。

讀出 此部分 以開始使用市場活動架構。

瞭解如何配置擴展架構以擴展Adobe Campaign資料庫的概念資料模型 此頁。

資料模型體系結構

Adobe Campaign是一個功能強大的跨渠道市場活動管理系統，可幫助您調整線上和離線策略以創造個性化的客戶體驗。

以客戶為中心的方法

雖然大多數電子郵件服務提供商都在通過以清單為中心的方式與客戶進行溝通，但Adobe Campaign卻依賴關係資料庫來利用客戶及其屬性的更廣泛視圖。

要訪問每個表的說明，請轉到 Admin > Configuration > Data schemas，從清單中選擇資源，然後按一下 Documentation 頁籤。

注意

Adobe Campaign允許 自定義收件人表。 但是，在大多數情況下，建議利用內置 收件人表 已預先構建了其他表和功能。

Adobe Campaign資料

哪些資料應該發送到Adobe Campaign? 確定您的營銷活動所需的資料至關重要。

注意

Adobe Campaign既不是資料倉庫，也不是報告工具。 因此，不要嘗試將所有可能的客戶及其關聯資訊導入Adobe Campaign，或導入僅用於生成報告的資料。

要決定在Adobe Campaign是否需要某個屬性，請問問自己是否屬於以下類別：

  • 用於 分割
  • 用於 資料管理流程 （例如，聚合計算）
  • 用於 個性化

如果不是陷入其中，你很可能不需要這個屬性在Adobe Campaign。

資料類型選擇

為確保系統的良好體系結構和效能，請遵循以下最佳實踐在Adobe Campaign設定資料。

  • 在大表中，可以插入字串或數字欄位，並向引用表添加連結（使用值清單時）。
  • 的 EXPR 屬性允許將模式屬性定義為計算欄位，而不是表中的物理集值。 這可以允許以不同格式（例如年齡和出生日期）訪問資訊，而無需儲存這兩個值。 這是避免重複欄位的好方法。 例如，「收件人」表使用域的表達式，該表達式已存在於電子郵件欄位中。
  • 但是，當表達式計算複雜時，建議不要使用 EXPR 屬性作為即時計算可能會影響查詢的效能。
  • 的 XML 類型是避免建立過多欄位的好方法。 但是，它也佔用了磁碟空間，因為它使用資料庫中的CLOB列。 它還可能導致複雜的SQL查詢，並可能影響效能。
  • 長度 字串 欄位應始終與列一起定義。 預設情況下，Adobe Campaign的最大長度為16K，但Adobe建議在您已經知道該大小不會超過較短長度時，保持該欄位的較短。
  • 如果您確定源系統中的欄位被高估而無法達到，則可以接受在Adobe Campaign使用的欄位比源系統中的欄位短。 這可能意味著Adobe Campaign的字串較短或整數較小。

欄位選擇

如果欄位具有目標或個性化目的，則需要將其儲存在表中。 換句話說，如果某個欄位未用於發送個性化電子郵件或用作查詢中的標準，則會不必要地佔用磁碟空間。

鍵的選擇

除 autouuid 和 奧托普 在大多數表中預設定義，您應考慮添加一些邏輯或業務密鑰（帳號、客戶機號等）。 以後可將其用於導入/協調或資料包。 有關此的詳細資訊，請參閱 標識符。

高效的密鑰對效能至關重要。 使用Snowflake，可以將數字或基於字串的資料類型插入為表的鍵。

注意

的 autouuid 屬性僅適用於 企業(FDA)部署。

標識符

Adobe Campaign資源有三個標識符，並且可以添加一個附加標識符。

下表介紹了這些標識符及其用途。

標識符 說明 最佳實務
ID
  • ID是Adobe Campaign表的物理主鍵。 對於內置表，它是通用唯一ID(UUID)
  • 此標識符必須唯一。
  • UUID可以在架構定義中可見。
  • 自動生成的標識符不應用作工作流或包定義中的引用。
  • 表中的ID是UUID，不應更改此類型。
名稱（或內部名稱）
  • 此資訊是表中記錄的唯一標識符。 此值可以手動更新，通常使用生成的名稱。
  • 此標識符在部署到Adobe Campaign的其他實例時保留其值，不應為空。
  • 如果對象要從環境部署到另一個環境，請更名Adobe Campaign生成的記錄名稱。
  • 當對象具有命名空間屬性(架構 例如)，此公共命名空間將用於所有建立的自定義對象。 不應使用某些保留的命名空間： nms。 xtk​的子菜單。 請注意，某些命名空間僅是內部的。 了解更多資訊。
  • 當對象沒有任何命名空間(工作流 或 交貨 例如)，此命名空間概念將作為內部名稱對象的前置詞添加： 命名空間MyObjectName。
  • 請勿使用特殊字元，如空格「」、半列「：」或連字元「 — 」。 所有這些字元都將替換為下划線「_」（允許的字元）。 例如，「abc-def」和「abc:def」將儲存為「abc_def」，並互相覆蓋。
標籤
  • 標籤是Adobe Campaign中對象或記錄的業務標識符。
  • 此對象允許空格和特殊字元。
  • 它不能保證記錄的唯一性。
  • 建議確定對象標籤的結構。
  • 這是標識Adobe Campaign用戶的記錄或對象的最方便用戶的解決方案。

在 企業(FDA)部署,Adobe Campaign主鍵是所有內置表的自動生成UUID。 UUID也可用於自定義表。 了解更多

即使ID數量是無限的，您也應該考慮資料庫的大小，以確保達到最佳效能。 要防止出現任何問題，請確保調整實例清除設定。 如需詳細資訊，請參閱本節。

自定義內部鍵

在Adobe Campaign建立的每個表都需要主鍵。

大多陣列織正在從外部系統導入記錄。 雖然Recipient表的物理鍵是"id"屬性，但可以另外確定自定義鍵。

此自定義鍵是外部系統饋送Adobe Campaign的實際記錄主鍵。

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

  • 自動生成的密鑰(id)和內部密鑰（自定義）的組合。 如果系統鍵是複合鍵或不是整數，則此選項很有意義。 使用Snowflake，整數或基於字串的鍵將在大表中提供更高的效能，並與其他表連接。
  • 使用主鍵作為外部系統主鍵。 此解決方案通常是首選的，因為它簡化了資料導入和導出的方法，並且在不同的系統之間具有一致的密鑰。 奧圖烏伊德 如果鍵名為「id」，並預期用外部值填充（不是自動生成），則應禁用該鍵。
注意
  • 工作流中不應將autouuid用作引用。
  • 的 autouuid 屬性僅適用於 企業(FDA)部署。

謹防大桌上的「自己」誠信。 刪除具有「自有」完整性的大表的記錄可能會停止實例。 表被鎖定，刪除操作逐個進行。 所以最好在大容量的子表上使用"中性"完整性。

將連結聲明為外部連接對效能不利。 零ID記錄模擬外部連接功能。 在 企業(FDA)部署，如果連結使用 autouuid。

雖然可以將任何表加入工作流中，但Adobe建議直接在資料結構定義中定義資源之間的公用連結。

連結應與表中的實際資料對齊定義。 錯誤的定義可能影響通過連結檢索到的資料，例如意外地複製記錄。

使用表名稱一致命名連結：連結名稱應有助於瞭解遠程表是什麼。

不要將「id」作為尾碼的連結命名。 例如，將其命名為「transaction」，而不是「transactionId」。

預設情況下，Adobe Campaign將使用外部表的主鍵建立連結。 為了更清晰，最好在連結定義中顯式定義連接。

基數

設計連結時，確保在聲明1-1關係時目標籤錄是唯一的。 否則，當僅需要一條記錄時，連接可能會返回多個記錄。 當「查詢返回的行數超出預期」時，這會在準備交貨期間導致錯誤。 將連結名稱設定為與目標架構相同的名稱。

在(1)側的架構中定義帶基數(1-N)的連結。 例如，應在事務架構中定義關係收件人(1)-(N)事務。

請注意，連結的反向基數預設為(N)。 通過將屬性revCardinality='singe'添加到連結定義中，可以定義連結(1-1)。

如果用戶不能看到反向連結，則可以使用連結定義revLink='隱藏它​無「 」。 這方面的一個很好的使用案例是，例如，定義從收件人到完成的最後一個事務的連結。 您只需查看從收件人到最後一個事務處理的連結，並且不需要從事務處理表中看到任何反向連結。

執行外部連接(1-0…1)的連結應謹慎使用，因為它將影響系統效能。

資料保留

Adobe Campaign既不是資料倉庫，也不是報告工具。 因此，為確保Adobe Campaign解決方案的良好效能，資料庫增長應保持在控制之下。 為了實現這一目標，遵循以下一些最佳做法可能會有所幫助。

關於保留，Campaign 中的內建記錄表有預先設定的保留期間，通常將其資料儲存時間限制在六個月或更短時間。

以下是內建表格的預設保留值。請注意，保留設定是由 Adobe 技術管理員在實施期間所設定，每個實作的值可能會因客戶需求而有所不同。

  • 整合追蹤：1 年
  • 傳遞記錄：6 個月
  • 追蹤記錄：1 年
  • 已刪除傳遞：1 週
  • 匯入拒絕：6 個月
  • 訪客設定檔：1 個月
  • 優惠方案主張：1 年
  • 事件：1 個月
  • 事件處理統計資料：1 個月
  • 已封存事件：1 年
  • 忽略的管線事件：1 個月
注意

自定義表不會使用標準清除過程清除。 雖然在第一天可能不需要這樣做，但不要忘記為自定義表構建清除流程，因為這可能會導致效能挑戰。

有幾種解決方案可最大限度地減少對Adobe Campaign記錄的需求：

  • 在Adobe Campaign以外的資料倉庫中導出資料。
  • 生成集合值，以減少空間，同時滿足您的營銷慣例。 例如，您不需要Adobe Campaign的完整客戶交易記錄記錄來跟蹤上次採購。

可以在架構中聲明「deleteStatus」屬性。 將記錄標籤為已刪除，然後延遲清除任務中的刪除，這樣更有效。

作為受管理的Cloud Services用戶，請與Adobe顧問或技術管理員聯繫，以瞭解有關保留的詳細資訊，或者您需要為自定義表設定保留。

效能

為確保在任何時間都能獲得更好的效能，請遵循以下最佳做法。

一般性建議

  • 避免在查詢中使用「CONTAINS」等操作。 如果知道預期的內容並希望過濾，請將相同條件與「EQUAL TO」或其他特定篩選器運算子一起應用。
  • 請確保在工作時間之外執行導入和導出等過程。
  • 確保有所有日常活動的時間表，並遵守時間表。
  • 如果日進程中的一個或幾個失敗，並且必須在當天運行，請確保在手動進程啟動時沒有運行衝突的進程，因為這可能會影響系統效能。
  • 確保在導入流程期間或執行任何手動流程期間未運行任何每日市場活動。
  • 使用一個或多個引用表，而不是在每行中複製欄位。 使用鍵/值對時，最好選擇數字鍵。
  • 短字串仍然可接受。 如果引用表已在外部系統中就位，則重新使用它將有助於與Adobe Campaign的資料整合。

一對多關係

  • 資料設計影響可用性和功能性。 如果您設計的資料模型具有許多一對多關係，則用戶在應用程式中構造有意義的邏輯會更加困難。 一對多過濾邏輯對於非技術營銷人員來說很難正確構造和理解。
  • 將所有基本欄位放在一個表中是件好事，因為它使用戶更容易生成查詢。 有時，如果可以避免聯接，則在表間複製某些欄位也對效能有利。
  • 某些內置功能將不能引用一對多關係，例如「提供加權公式」和「交付」。

大表

Adobe Campaign依靠第三方資料庫引擎。 根據提供程式的不同，為較大的表優化效能可能需要特定的設計。

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

  • 使用其他自定義收件人表時，請確保每個傳遞映射都有專用的日誌表。
  • 減少列數，特別是通過標識未使用的列數。
  • 通過避免複雜的連接（例如在若干條件和/或幾列上的連接）來優化資料模型關係。
  • 對於聯接鍵，可以使用基於數字或字串的值。
  • 盡可能減少日誌保留深度。 如果需要更深的歷史記錄，可以聚合計算和/或處理自定義日誌表以儲存更大的歷史記錄。

表的大小

表大小是記錄數和每個記錄列數的組合。 這兩種方法都會影響查詢的效能。

  • A 小尺寸 表與「傳遞」表類似。
  • A 中等大小 表與收件人表的大小相同。 每個客戶有一條記錄。
  • A 大尺寸 表與Broad日誌表類似。 每個客戶都有許多記錄。
    例如，如果資料庫包含1000萬收件人，則Broad日誌表包含大約1億到2億條消息，而Delivery表包含幾千條記錄。

行數也會影響效能。 Adobe Campaign資料庫不用於儲存未用於目標或個性化目的的歷史資料 — 這是一個操作資料庫。

要防止與行數過多相關的任何效能問題，請僅在資料庫中保留必要的記錄。 任何其他記錄應導出到第三方資料倉庫，並從Adobe Campaign業務資料庫中刪除。

以下是關於表大小的一些最佳做法：

  • 設計欄位較少、數字資料較多的大型表。
  • 不要使用大數列類型來儲存小數字，如布爾值。
  • 從表定義中刪除未使用的列。
  • 不要將歷史資料或非活動資料保留在Adobe Campaign資料庫中（導出和清除）。

本頁內容