本檔案概述設計您的Adobe Campaign資料模型時的主要建議。
如需深入瞭解促銷活動內建表格及其互動,請參閱本節一節。
請閱讀本檔案以開始使用促銷活動結構。 瞭解如何配置擴展方案以擴展本文檔中的Adobe Campaign資料庫的概念資料模型。
Adobe Campaign系統極為靈活,可以擴展至最初的實施範圍之外。 不過,儘管可能性無限,但必須做出明智決策並建立堅實的基礎,才能開始設計您的資料模型。
本檔案提供常見的使用案例和最佳範例,以瞭解如何正確設計您的Adobe Campaign工具。
Adobe Campaign Standard是功能強大的跨通道宣傳管理系統,可協助您調整線上和線下策略,以建立個人化客戶體驗。
雖然大多數電子郵件服務供應商都是透過以清單為中心的方式與客戶溝通,但Adobe Campaign仍依賴關係資料庫,以運用更廣泛的客戶及其屬性檢視。
以客戶為中心的方法如下圖所示。 Recipient灰色表格代表正在構建所有內容的主要客戶表:
要訪問每個表的說明,請轉至Admin > Configuration > Data schemas,從清單中選擇資源,然後按一下Documentation頁籤。
Adobe Campaign預設資料模型顯示在本文檔中。
Adobe Campaign Classic允許建立自訂客戶表。 但是,在大多數情況下,建議使用已預先建立其他表格和功能的標準收件者表格。
哪些資料應該傳送至Adobe Campaign? 確定行銷活動所需的資料至關重要。
Adobe Campaign既不是資料倉庫,也不是報告工具。 因此,請勿嘗試將所有可能的客戶及其相關資訊匯入Adobe Campaign,或匯入僅用於建立報表的資料。
要決定是否需要某個屬性在Adobe Campaign,請問問自己是否屬於以下類別:
如果不是落入其中任何一個圈套,你很可能不需要Adobe Campaign的這個屬性。
為確保系統的良好架構和效能,請遵循下列最佳實務,在Adobe Campaign設定資料。
如果欄位具有定位或個人化目的,則必須將其儲存在表格中。 換言之,如果欄位不是用來傳送個人化電子郵件,或是用作查詢中的標準,則會佔用磁碟空間,但是卻毫無用處。
對於混合式和內部部署例項,FDA(Federated Data Access,允許存取外部資料的選用功能)涵蓋在促銷活動程式中新增「即時」欄位的需求。 如果你有食品藥物管理局的話,您不需要進口任何產品。 有關詳細資訊,請參見關於同盟資料存取。
除了大多數表中預設定義的autopk外,您還應考慮添加一些邏輯或業務密鑰(帳戶號、客戶機號等)。 它稍後可用於導入/協調或資料包。 如需詳細資訊,請參閱識別碼。
高效的密鑰對效能至關重要。 數值資料類型應始終作為表的鍵。
對於SQLServer資料庫,如果需要效能,可考慮使用「聚簇索引」。 由於Adobe不處理此問題,因此您需要在SQL中建立它。
方案中的表空間屬性允許您為表指定專用表空間。
安裝嚮導允許您按類型(資料、臨時和索引)儲存對象。
專用表空間更適合分區、安全規則,並允許流暢、靈活的管理、更好的優化和效能。
Adobe Campaign資源有三個識別碼,並且可以添加一個附加的識別碼。
下表說明這些識別碼及其用途。
識別碼 | 說明 | 最佳實務 |
---|---|---|
ID |
|
|
名稱(或內部名稱) |
|
|
標籤 |
|
|
在Adobe Campaign建立的每個表都需要主鍵。
大多陣列織都從外部系統導入記錄。 雖然「收件者」表格的實體金鑰是「id」屬性,但您也可以另外決定自訂金鑰。
此自訂金鑰是外部系統餵送Adobe Campaign時的實際記錄主要金鑰。
當現成可用的表同時具有自動鍵和內部鍵時,內部鍵將被設定為物理資料庫表中的唯一索引。
建立自訂表格時,有兩個選項:
在工作流程中,不應使用自訂作品做為參考。
Adobe Campaign主鍵是自動生成的所有現成可用表ID,對於自定義表可以是相同的。 如需詳細資訊,請參閱本節。
此值取自稱為sequence的值,此為用於生成數字序列的資料庫對象。
序列有兩種類型:
序列是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" | 已使用 | 未使用 | 未使用 | 由於同一查詢中同時搜索了兩個屬性,因此將只使用結合兩個屬性的索引。 |
姓氏等於"Smith" | 未使用 | 未使用 | 已使用 | 索引中的屬性順序被考慮在內。 如果您不符合此順序,則可能不會使用索引。 |
名字開頭為"Joh" | 已使用 | 已使用 | 未使用 | 「左搜索」將啟用索引。 |
名字結尾為"ny" | 未使用 | 未使用 | 未使用 | 「右搜索」將禁用索引,並執行完全掃描。 某些特定索引類型可處理此使用案例,但在Adobe Campaign,預設不提供。 |
名字包含"John" | 未使用 | 未使用 | 未使用 | 這是「左」和「右」搜尋的組合。 由於後者,它將禁用索引並執行完全掃描。 |
名字等於"john" | 未使用 | 未使用 | 未使用 | 索引區分大小寫。 要使其不區分大小寫,您應建立包含SQL函式(如「upper(firstname)」)的特定索引。 您應該對其他資料轉換(例如「unaccent(firstname)」)執行相同的動作。 |
小心大桌上的「自己」誠信。 刪除具有「擁有」完整性的寬表的記錄可以停止實例。 表被鎖定,刪除操作逐個執行。 因此,最好對具有大卷的子表使用「中性」完整性。
將連結聲明為外部連接不利於效能。 零ID記錄模擬外部連接功能。 如果連結使用autopk,則無需聲明外部連接。
雖然可以在工作流中連接任何表,但Adobe建議直接在資料結構定義中定義資源之間的公共連結。
連結的定義應與表格中的實際資料一致。 錯誤的定義可能會影響透過連結擷取的資料,例如意外重複記錄。
以表名稱一致命名連結:連結名稱應有助於瞭解遠程表是什麼。
請勿將連結命名為「id」為尾碼。 例如,將其命名為"transaction",而非"transactionId"。
預設情況下,Adobe Campaign將使用外部表的主鍵建立連結。 為了更清楚,最好在連結定義中明確定義連結。
索引將添加到連結中使用的屬性中。
The 「建立者」和「上次修改者」連結在許多表中都顯示。 如果業務未使用該資訊,則可以通過在連結上使用屬性noDbIndex來禁用該索引。
當您設計連結時,請確定目標籤錄在宣告1-1關係時是唯一的。 否則,當僅需要一條記錄時,連接可能會返回多個記錄。 這會在「查詢傳回的列比預期多」時,在傳送準備期間產生錯誤。 將連結名稱設定為與目標方案相同的名稱。
在架構(1)側定義具有基數(1-N)的連結。 例如,應在事務方案中定義關係收件人(1)-(N)事務。
請注意,連結的反向基數預設為(N)。 通過將屬性revCardinality='single'添加到連結定義中,可以定義連結(1-1)。
如果使用者看不到反向連結,您可使用連結定義revLink='NONE'來隱藏該連結。 例如,最好的使用案例是定義從收件者到最後完成交易的連結。 您只需查看從收件人到最後一個事務處理的連結,並且不需要從事務處理表中查看任何反向連結。
執行外部連接(1-0…1)的連結應小心使用,因為它將影響系統效能。
Adobe Campaign既不是資料倉庫,也不是報告工具。 因此,為了確保Adobe Campaign解決方案的良好效能,資料庫增長應保持在可控範圍內。 為達成此目的,請遵循下列一些最佳實務。
依預設,Adobe Campaign傳送和追蹤記錄檔的保留期為180天。 執行清除程式以刪除任何早於該進程的日誌。
進一步瞭解促銷活動隱私與安全性方針中的資料保留。
在本節](…/…/production/using/database-cleanup-workflow.md)中進一步瞭解促銷活動資料庫清除工作流程[。
自定義表不會使用標準清除流程進行清除。 雖然第一天可能不需要這個選項,但別忘了為自訂表格建立清除程式,因為這可能會導致效能挑戰。
有幾種解決方案可將Adobe Campaign記錄的需求降到最低:
您可以在架構中宣告"deleteStatus"屬性。 將記錄標籤為已刪除,然後延遲清除任務中的刪除會更有效。
為了確保隨時都能提供更佳的效能,請遵循下列最佳實務。
Adobe Campaign依賴第三方資料庫引擎。 根據提供方的不同,為較大的表優化效能可能需要特定的設計。
以下是使用大型表和複雜連接設計資料模型時應遵循的一些常見最佳做法。
表大小是記錄數和每個記錄列數的組合。 這兩種方法都會影響查詢的效能。
在PostgreSQL上,行不應超過8KB以避免TOAST機制。 因此,請盡量減少列數和每行的大小,以保留系統(記憶體和CPU)的最佳效能。
行數也會影響效能。 Adobe Campaign資料庫不是用於儲存不主動用於定位或個人化目的的歷史資料——這是一個操作資料庫。
要防止與行數較多相關的任何效能問題,請僅在資料庫中保存必要的記錄。 應將任何其他記錄導出到第三方資料倉庫,並從Adobe Campaign業務資料庫中刪除。
以下是關於表大小的一些最佳做法:
以下是範例:
在此範例中: