本檔案概述設計Adobe Campaign資料模型時的主要建議。
如需深入了解Campaign內建表格及其互動,請參閱 本節 區段。
閱讀 本檔案 以開始使用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(同盟資料存取,此選用功能可存取外部資料)涵蓋在行銷活動程式期間需要新增「即時」欄位。 如果您有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:Adobe Campaign通常會在產生的SQL查詢中忽略記錄0。
欲知序列耗盡的更多資訊,請看 此影片.
索引對效能至關重要。 當您在架構中宣告索引鍵時,Adobe會自動在索引鍵的欄位上建立索引。 您也可以為未使用索引鍵的查詢聲明更多索引。
Adobe建議定義其他索引,因為這可能改善效能。
不過,請記住下列事項:
管理索引可能會變得非常複雜,因此了解索引的運作方式非常重要。 為了說明此複雜性,我們以一個基本範例來說明,例如透過篩選名字和姓氏來搜尋收件者。 操作步驟:
移至列出資料庫中所有收件者的資料夾。 有關詳細資訊,請參閱 管理設定檔.
以滑鼠右鍵按一下 First name 欄位。
選取 Filter on this field。
對 Last name 欄位。
兩個對應的篩選器會新增至畫面頂端。
您現在可以對 First name 和 Last name 欄位。
現在,若要加快對這些篩選器的搜尋,您可以新增索引。 但應該使用哪些索引?
此示例適用於使用PostgreSQL資料庫的托管客戶。
下表顯示了以下三個索引在哪些情況下根據第一列中顯示的訪問模式被使用或不使用。
搜尋條件 | 索引1(名字+姓氏) | 索引2(僅名字) | 索引3(僅姓氏) | 評論 |
---|---|---|---|---|
名字等於「強尼」 | 已使用 | 已使用 | 未使用 | 由於名字在索引1上的第一個位置,因此仍將使用它:無需在姓氏上新增條件。 |
名字等於「Johnny」,姓氏等於「Smith」 | 已使用 | 未使用 | 未使用 | 由於同一查詢中同時搜索了兩個屬性,因此將只使用結合這兩個屬性的索引。 |
姓氏等於「Smith」 | 未使用 | 未使用 | 已使用 | 索引中的屬性順序被考慮在內。 如果不符合此順序,則可能不使用索引。 |
名字以"Joh"開頭 | 已使用 | 已使用 | 未使用 | 「左搜索」將啟用索引。 |
名字的結尾是「nny」 | 未使用 | 未使用 | 未使用 | 「正確搜索」將禁用索引,並執行完整掃描。 某些特定索引類型可以處理此使用案例,但預設情況下無法在Adobe Campaign中使用。 |
名字包含「John」 | 未使用 | 未使用 | 未使用 | 這是「左」和「右」搜尋的組合。 因為後者,它將禁用索引,並執行完整掃描。 |
名字等於「john」 | 未使用 | 未使用 | 未使用 | 索引區分大小寫。 要使其不區分大小寫,應建立包含SQL函式(如"upper(firstname)")的特定索引。 您應該對其他資料轉換(例如「unaccent(firstname)」)執行相同操作。 |
請注意大表上的「自己」完整性。 刪除具有「自有」完整性的寬表的記錄可以停止實例。 表已鎖定,且逐個刪除。 因此,最好對具有大容量的子表使用「中性」完整性。
將連結聲明為外部連接對效能不利。 零ID記錄模擬外部連接功能。 如果連結使用autopk,則不需要聲明外部聯接。
雖然可以在工作流中連接任何表,但Adobe建議直接在資料結構定義中定義資源之間的公用連結。
連結的定義應與表格中的實際資料一致。 錯誤的定義可能會影響透過連結擷取的資料,例如意外重複記錄。
以表格名稱一致地為連結命名:連結名稱應有助於了解遠距表格的內容。
請勿將連結命名為尾碼為「id」。 例如,將其命名為「transaction」,而非「transactionId」。
依預設,Adobe Campaign會使用外部表格的主要索引鍵建立連結。 為了更清楚明瞭,最好在連結定義中明確定義連結。
索引將新增至連結中使用的屬性。
建立者連結和上次修改者連結在許多表格中顯示。 如果業務未使用此資訊,則可通過在連結上使用屬性noDbIndex來禁用索引。
當您設計連結時,請確定在宣告1-1關係時目標籤錄是唯一的。 否則,當只需要一條記錄時,連接可能會返回多條記錄。 這會在傳送準備期間發生錯誤,當「查詢傳回的列數超過預期」時。 將連結名稱設定為與目標架構相同的名稱。
在(1)側的架構中,定義含有基數(1-N)的連結。 例如,應在事務架構中定義關係收件人(1)-(N)事務。
請注意,連結的反向基數預設為(N)。 通過將屬性revCardinality='single'添加到連結定義中,可以定義連結(1-1)。
如果用戶不能看到反向連結,則可以使用連結定義revLink='來隱藏它無'。 例如,一個很好的使用案例是定義從收件者到最後完成交易的連結。 您只需查看從收件者到最後一個交易的連結,並且無需從交易表中看到任何反向連結。
執行外部聯接的連結(1-0…1)應謹慎使用,因為它將影響系統效能。
Adobe Campaign既非資料倉庫,也非報表工具。 因此,為確保Adobe Campaign解決方案的良好效能,應控制資料庫的增長。 為達成此目標,遵循下列一些最佳實務可能有所幫助。
依預設,Adobe Campaign傳送和追蹤記錄的保留期間為180天。 清除程式會執行以移除任何早於該程式的記錄。
進一步了解中的資料保留 Campaign隱私權與安全性准則.
深入了解Campaign資料庫清理工作流程 在本節.
自訂表格不會透過標準清除程式清除。 雖然在第一天可能不需要這項操作,但別忘了為自訂表格建立清除程式,因為這可能會導致效能挑戰。
有幾種解決方案可將Adobe Campaign中記錄的需求降至最低:
您可以在架構中宣告「deleteStatus」屬性。 將記錄標示為已刪除,然後延遲清除任務中的刪除會更有效。
為了隨時確保效能更佳,請遵循下列最佳實務。
Adobe Campaign仰賴協力廠商資料庫引擎。 根據提供程式,為較大表優化效能可能需要特定設計。
以下是使用大型表和複雜聯接設計資料模型時應遵循的一些常見最佳做法。
表大小是記錄數和每個記錄的列數的組合。 兩者都會影響查詢的效能。
在PostgreSQL上,行不應超過8KB以避免 吐司 機制。 因此,請盡量減少列數和每行的大小,以保留系統(記憶體和CPU)的最佳效能。
列數也會影響效能。 Adobe Campaign資料庫的設計目的並非儲存未用於鎖定目標或個人化目的的歷史資料 — 這是一個運作資料庫。
要防止與高行數相關的任何效能問題,請僅在資料庫中保留必要的記錄。 任何其他記錄應匯出至協力廠商資料倉庫,並從Adobe Campaign作業資料庫中移除。
以下是一些關於表格大小的最佳實務:
以下是範例:
在此範例中: