本文檔概述了設計Adobe Campaign資料模型時的主要建議。
要更好地瞭解活動內置表及其交互作用,請參閱 此部分 的子菜單。
讀出 本文檔 以開始使用市場活動架構。 瞭解如何配置擴展架構以擴展Adobe Campaign資料庫的概念資料模型 此文檔。
Adobe Campaign系統極其靈活,可以擴展到最初的實施之外。 但是,儘管可能性是無限的,但做出明智決策並建立堅實的基礎是開始設計您的資料模型的關鍵。
本文檔提供了常見使用案例和最佳做法,以瞭解如何正確設計您的Adobe Campaign工具。
Adobe Campaign是一個功能強大的跨渠道市場活動管理系統,可幫助您調整線上和離線策略以創造個性化的客戶體驗。
雖然大多數電子郵件服務提供商都在通過以清單為中心的方式與客戶進行溝通,但Adobe Campaign卻依賴關係資料庫來利用客戶及其屬性的更廣泛視圖。
以客戶為中心的方法如下圖所示。 的 收件人 灰色表表示正圍繞其構建一切的主要客戶表:
要訪問每個表的說明,請轉到 Admin > Configuration > Data schemas,從清單中選擇資源,然後按一下 Documentation 頁籤。
Adobe Campaign預設資料模型在 此文檔。
Adobe Campaign Classic允許構建自定義客戶表。 但是,在大多數情況下,建議利用標準 收件人表 已預先構建了其他表和功能。
哪些資料應該發送到Adobe Campaign? 確定您的營銷活動所需的資料至關重要。
Adobe Campaign既不是資料倉庫,也不是報告工具。 因此,不要嘗試將所有可能的客戶及其關聯資訊導入Adobe Campaign,或導入僅用於生成報告的資料。
要決定在Adobe Campaign是否需要某個屬性,請問問自己是否屬於以下類別:
如果不是陷入其中,你很可能不需要這個屬性在Adobe Campaign。
為確保系統的良好體系結構和效能,請遵循以下最佳實踐在Adobe Campaign設定資料。
如果欄位具有目標或個性化目的,則需要將其儲存在表中。 換句話說,如果某個欄位未用於發送個性化電子郵件或用作查詢中的標準,則會佔用磁碟空間,而它無用。
對於混合型和內部部署型實例,FDA(聯合資料存取,一種允許訪問外部資料的可選功能)涵蓋了在活動過程中「即時」添加欄位的需要。 如果你有食品藥品管理局,你就不需要進口任何東西。 有關此的詳細資訊,請參閱 關於聯合資料存取。
除 奧托普 在大多數表中預設定義,您應考慮添加一些邏輯或業務密鑰(帳號、客戶機號等)。 以後可將其用於導入/協調或資料包。 有關此的詳細資訊,請參閱 標識符。
高效的密鑰對效能至關重要。 數值資料類型應始終作為表的鍵。
對於SQLServer資料庫,如果需要效能,可以考慮使用「聚簇索引」。 由於Adobe不處理此問題,因此需要在SQL中建立它。
方案中的表空間屬性允許您為表指定專用表空間。
安裝嚮導允許您按類型(資料、臨時和索引)儲存對象。
專用表空間更適合分區、安全規則,並允許流暢、靈活的管理、更好的優化和效能。
Adobe Campaign資源有三個標識符,並且可以添加一個附加標識符。
下表介紹了這些標識符及其用途。
標識符 | 說明 | 最佳實務 |
---|---|---|
ID |
|
|
名稱(或內部名稱) |
|
|
標籤 |
|
|
在Adobe Campaign建立的每個表都需要主鍵。
大多陣列織正在從外部系統導入記錄。 雖然Recipient表的物理鍵是"id"屬性,但可以另外確定自定義鍵。
此自定義鍵是外部系統饋送Adobe Campaign的實際記錄主鍵。
當現成表同時具有自動密鑰和內部密鑰時,內部密鑰將被設定為物理資料庫表中的唯一索引。
建立自定義表時,有兩個選項:
在工作流中,不應將自動編輯用作引用。
Adobe Campaign主鍵是所有出廠設定表的自動生成的ID,對於自定義表可以是相同的。 如需詳細資訊,請參閱本節。
此值取自稱為 序列,是用於生成編號規則的資料庫對象。
序列有兩種類型:
序列是一個32位的整數值,其可用值的最大數量有限:21.4億。 在達到最大值後,序列將返回0以回收ID。
如果舊資料未清除,則結果將是唯一密鑰違規,這將成為平台運行狀況和使用情況的阻止程式。 Adobe Campaign將無法發送通信(當它影響到交付日誌表時),效能將受到很大影響。
因此,如果客戶每年發送60億封電子郵件,其日誌的保留期為180天,則4個月內就會用完ID。 要防止出現此類問題,請確保根據卷設定清除設定。 如需詳細資訊,請參閱本節。
當在Adobe Campaign建立具有主鍵autoPK的自定義表時,應將自定義專用序列系統地與該表關聯。
預設情況下,自定義序列的值範圍為+1,000到+2.1BB。 從技術上講,通過啟用負ID,可以獲得4BB的全範圍。 應謹慎使用,從負數到正數時,將丟失一個id:記錄0通常被Adobe Campaign在生成的SQL查詢中忽略。
要瞭解更多關於序列耗盡的資訊,請觀察 這個視頻。
索引對效能至關重要。 在架構中聲明密鑰時,Adobe將自動在密鑰的欄位上建立索引。 您還可以為不使用鍵的查詢聲明更多索引。
Adobe建議定義附加索引,因為它可能會提高效能。
但是,請記住以下幾點:
管理索引可能會變得非常複雜,因此瞭解索引如何工作非常重要。 為了說明這種複雜性,讓我們舉一個基本的示例,例如,通過對名字和姓氏進行篩選來搜索收件人。 操作步驟:
轉到列出資料庫中所有收件人的資料夾。 有關此的詳細資訊,請參閱 管理配置檔案。
按一下右鍵 First name 的子菜單。
選取 Filter on this field。
對 Last name 的子菜單。
兩個對應的濾鏡被添加到螢幕頂部。
現在,您可以對 First name 和 Last name 欄位。
現在,要加快對這些篩選器的搜索,可以添加索引。 但應使用哪些索引?
此示例適用於使用PostgreSQL資料庫的托管客戶。
下表顯示了在哪些情況下,根據第一列中顯示的訪問模式使用或不使用下面描述的三個索引。
搜索條件 | 索引1(名+姓) | 索引2(僅名) | 索引3(僅姓氏) | 注釋 |
---|---|---|---|---|
名字等於強尼。 | 已用 | 已用 | 未使用 | 由於名字在索引1上處於第一位置,因此仍將使用它:不需要在姓氏上添加條件。 |
名字等於"Johnny",姓氏等於"Smith" | 已用 | 未使用 | 未使用 | 由於在同一查詢中搜索兩個屬性,因此將只使用合併兩個屬性的索引。 |
姓氏等於"史密斯" | 未使用 | 未使用 | 已用 | 索引中屬性的順序被考慮在內。 如果與此順序不匹配,則可能不使用索引。 |
名字以"Joh"開頭 | 已用 | 已用 | 未使用 | 「左搜索」將啟用索引。 |
名字以"ny"結尾 | 未使用 | 未使用 | 未使用 | 「正確搜索」將禁用索引,並將執行完全掃描。 某些特定索引類型可以處理此使用情形,但預設情況下在Adobe Campaign不可用。 |
名字包含"John" | 未使用 | 未使用 | 未使用 | 這是「left」和「right」搜索的組合。 由於後者,它將禁用索引,並執行完全掃描。 |
名字等於"john" | 未使用 | 未使用 | 未使用 | 索引區分大小寫。 要使其不區分大小寫,應建立包含SQL函式(如「upper(firstname)」)的特定索引。 您應該對其他資料轉換(如「unaccent(firstname)」)執行同樣的操作。 |
謹防大桌上的「自己」誠信。 刪除具有「自有」完整性的寬表的記錄可以停止實例。 表被鎖定,刪除操作逐個進行。 所以最好在大容量的子表上使用"中性"完整性。
將連結聲明為外部連接對效能不利。 零ID記錄模擬外部連接功能。 如果連結使用autopk ,則無需聲明外部連接。
雖然可以將任何表加入工作流中,但Adobe建議直接在資料結構定義中定義資源之間的公用連結。
連結應與表中的實際資料對齊定義。 錯誤的定義可能影響通過連結檢索到的資料,例如意外地複製記錄。
使用表名稱一致命名連結:連結名稱應有助於瞭解遠程表是什麼。
不要將「id」作為尾碼的連結命名。 例如,將其命名為「transaction」,而不是「transactionId」。
預設情況下,Adobe Campaign將使用外部表的主鍵建立連結。 為了更清晰,最好在連結定義中顯式定義連接。
索引將添加到連結中使用的屬性。
建立者連結和上次修改者連結在許多表中都存在。 如果業務未使用此資訊,則可以通過在連結上使用屬性noDbIndex來禁用索引。
設計連結時,確保在聲明1-1關係時目標籤錄是唯一的。 否則,當僅需要一條記錄時,連接可能會返回多個記錄。 當「查詢返回的行數超出預期」時,這會在準備交貨期間導致錯誤。 將連結名稱設定為與目標架構相同的名稱。
在(1)側的架構中定義帶基數(1-N)的連結。 例如,應在事務架構中定義關係收件人(1)-(N)事務。
請注意,連結的反向基數預設為(N)。 通過將屬性revCardinality='singe'添加到連結定義中,可以定義連結(1-1)。
如果用戶不能看到反向連結,則可以使用連結定義revLink='隱藏它無「 」。 這方面的一個很好的使用案例是,例如,定義從收件人到完成的最後一個事務的連結。 您只需查看從收件人到最後一個事務處理的連結,並且不需要從事務處理表中看到任何反向連結。
執行外部連接(1-0…1)的連結應謹慎使用,因為它將影響系統效能。
Adobe Campaign既不是資料倉庫,也不是報告工具。 因此,為確保Adobe Campaign解決方案的良好效能,資料庫增長應保持在控制之下。 為了實現這一目標,遵循以下一些最佳做法可能會有所幫助。
預設情況下,Adobe Campaign交付和跟蹤日誌的保留期為180天。 運行清除進程以刪除早於該進程的所有日誌。
瞭解有關中資料保留的詳細資訊 市場活動隱私和安全准則。
瞭解有關市場活動資料庫清理工作流的詳細資訊 此部分。
自定義表不會使用標準清除過程清除。 雖然在第一天可能不需要這樣做,但不要忘記為自定義表構建清除流程,因為這可能會導致效能挑戰。
有幾種解決方案可最大限度地減少對Adobe Campaign記錄的需求:
可以在架構中聲明「deleteStatus」屬性。 將記錄標籤為已刪除,然後延遲清除任務中的刪除,這樣更有效。
為確保在任何時間都能獲得更好的效能,請遵循以下最佳做法。
Adobe Campaign依靠第三方資料庫引擎。 根據提供程式的不同,為較大的表優化效能可能需要特定的設計。
以下是使用大型表和複雜連接設計資料模型時應遵循的一些常見最佳做法。
表大小是記錄數和每個記錄列數的組合。 這兩種方法都會影響查詢的效能。
在PostgreSQL上,行不應超過8KB以避免 吐司 機制。 因此,請盡量減少列數和每行的大小,以保留系統(記憶體和CPU)的最佳效能。
行數也會影響效能。 Adobe Campaign資料庫不用於儲存未用於目標或個性化目的的歷史資料 — 這是一個操作資料庫。
要防止與行數過多相關的任何效能問題,請僅在資料庫中保留必要的記錄。 任何其他記錄應導出到第三方資料倉庫,並從Adobe Campaign業務資料庫中刪除。
以下是關於表大小的一些最佳做法:
下面是一個示例:
在此示例中: