本檔案會概述設計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既不是Data Warehouse也不是報表工具。 因此,請勿嘗試將所有可能的客戶及其相關資訊匯入Adobe Campaign,或匯入僅用於建立報表的資料。
若要在Adobe Campaign中決定是否需要屬性,請詢問您自己該屬性是否會屬於以下類別之一:
如果沒有落入其中任何一項,您很可能不需要在Adobe Campaign中使用此屬性。
為確保系統具備良好的架構和效能,請遵循下列最佳實務,在Adobe Campaign中設定資料。
如果欄位具有目標定位或個人化目的,則需要將其儲存在表格中。 換言之,如果欄位未用於傳送個人化電子郵件或用作查詢中的條件,則會佔用磁碟空間,但毫無用處。
對於混合式和內部部署例項,FDA (同盟資料存取,可存取外部資料的選用功能)涵蓋在行銷活動過程中「即時」新增欄位的需求。 如果您有FDA,則不需要匯入所有內容。 如需詳細資訊,請參閱 關於同盟資料存取.
除了 autopk 在大多數的表格中預設會定義,您應該考慮新增一些邏輯或業務金鑰(帳號、使用者端號碼等)。 稍後可用於匯入/調解或資料套件。 如需詳細資訊,請參閱 識別碼.
高效率索引鍵對效能至關重要。 數值資料型別一律可作為表格的索引鍵使用。
對於SQLServer資料庫,如果需要效能,可以考慮使用「叢集索引」。 由於Adobe不會處理這個問題,因此您需要在SQL中建立它。
綱要中的表格空間屬性可讓您指定表格的專用表格空間。
安裝精靈可讓您依型別(資料、暫存和索引)儲存物件。
專用表格空間更適合分割、安全性規則,並可進行流暢且彈性的管理、更佳的最佳化及效能。
Adobe Campaign資源有三個識別碼,您可以新增另一個識別碼。
下表說明這些識別碼及其用途。
識別碼 | 說明 | 最佳實務 |
---|---|---|
ID |
|
|
名稱(或內部名稱) |
|
|
標籤 |
|
|
在Adobe Campaign中建立的每個表格都需要主索引鍵。
大多陣列織都從外部系統匯入記錄。 雖然收件者表格的實體索引鍵是"id"屬性,但您也可以判斷自訂索引鍵。
此自訂金鑰是外部系統中饋送Adobe Campaign的實際記錄主金鑰。
當現成可用的表格同時具有autopk和內部索引鍵時,內部索引鍵將會設定為實體資料庫表格中的唯一索引。
建立自訂表格時,您有兩個選項:
Autopk不應作為工作流程中的參考。
Adobe Campaign主索引鍵是所有現成可用表格自動產生的id,且自訂表格可以相同。 如需詳細資訊,請參閱本節。
此值擷取自所謂的 序列,用來產生編號規則的資料庫物件。
序列有兩種型別:
此序列是32位元的整數,可用值的數量上限有限:21.4億。 達到最大值後,為了回收ID,順序將返回到0。
如果舊資料尚未清除,則結果將會導致唯一索引鍵違規,而這會成為平台健全狀態和使用狀況的封鎖程式。 Adobe Campaign將無法傳送通訊(當它影響傳送記錄表格時),效能將受到嚴重影響。
因此,客戶每年傳送60億封電子郵件,其記錄檔的保留期為180天,4個月內就會用完id。 為避免此類挑戰,請確保根據您的磁碟區有清除設定。 如需詳細資訊,請參閱本節。
在Adobe Campaign中以主索引鍵作為autoPK來建立自訂表格時,自訂專用序列應該系統地與該表格相關聯。
依預設,自訂序列的值介於+1,000到+2.1BB之間。 技術上,啟用負值ID即可獲得完整的4BB範圍。 這應謹慎使用,從負數到正數交叉時,會遺失一個ID:在產生的SQL查詢中,Adobe Campaign通常會忽略記錄0。
如需序列耗竭的詳細資訊,請觀看 此影片.
索引對於效能至關重要。 當您在結構描述中宣告索引鍵時,Adobe會自動在索引鍵的欄位上建立索引。 您也可以為未使用索引鍵的查詢宣告更多索引。
Adobe建議定義其他索引,因為這可以改善效能。
不過,請記住以下事項:
管理索引可能會變得非常複雜,因此瞭解索引如何運作非常重要。 為了說明此複雜性,我們以一個基本範例為例,例如透過篩選名字和姓氏來搜尋收件者。 操作步驟:
移至列出資料庫中所有收件者的資料夾。 如需詳細資訊,請參閱 管理設定檔.
以滑鼠右鍵按一下 First name 欄位。
選取 Filter on this field。
對以下專案重複此操作: Last name 欄位。
熒幕上方會新增兩個對應的篩選器。
您現在可以在以下位置執行搜尋篩選: First name 和 Last name 根據各種篩選條件篩選欄位。
現在,若要加速對這些篩選器的搜尋,您可以新增索引。 但應使用哪些索引?
此範例適用於使用PostgreSQL資料庫的託管客戶。
下表顯示根據第一欄中顯示的存取模式,是否使用下述三個索引的情況。
搜尋條件 | 索引1 (名字+姓氏) | 索引2 (僅限名字) | 索引3 (僅限姓氏) | 評論 |
---|---|---|---|---|
名字等於「Johnny」 | 已使用 | 已使用 | 未使用 | 由於名字在索引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)的連結。 例如,應在交易結構描述中定義關係Recipient (1) - (N) Transaction。
請注意,依照預設,連結的反向基數是(N)。 您可以透過將屬性revCardinality='single'新增至連結定義來定義連結(1-1)。
如果使用者看不到反向連結,您可以使用連結定義revLink='來隱藏它無'. 舉例來說,一個很好的使用案例是定義從收件者到上次完成交易的連結。 您只需要檢視從收件者到上次交易的連結,交易表格中不需要顯示反向連結。
執行外部聯結(1-0…1)的連結應謹慎使用,因為它會影響系統效能。
Adobe Campaign既不是Data Warehouse也不是報表工具。 因此,為了確保Adobe Campaign解決方案提供良好的效能,資料庫的成長應受到控制。 若要達成此目的,遵循以下最佳實務可能會有所幫助。
依預設,Adobe Campaign傳送和追蹤記錄的保留時間為180天。 清除程式會執行以移除任何超過該時間的記錄。
進一步瞭解中的資料保留 Campaign隱私權與安全性方針.
深入瞭解Campaign資料庫清理工作流程 在本節中.
自訂表格不會使用標準清理程式清除。 雖然這可能不是第一天的必要操作,但別忘了為自訂表格建立清除程式,因為這可能會導致效能挑戰。
有幾個解決方案可將Adobe Campaign中對記錄的需求降至最低:
您可以在結構描述中宣告「deleteStatus」屬性。 將記錄標示為已刪除,然後在清除工作中延遲刪除會更有效率。
為了確保隨時提供更優異的效能,請遵循下列最佳實務。
Adobe Campaign仰賴協力廠商資料庫引擎。 視提供者而定,針對大型表格最佳化效能可能需要特定設計。
以下是使用大型表格和複雜聯結設計資料模型時應遵循的一些常見最佳實務。
表格大小是記錄數和每筆記錄欄數的組合。 兩者都會影響查詢效能。
在PostgreSQL上,資料列不應超過8KB,以避免 快顯通知 機制。 因此,請儘量減少欄數及每列的大小,以保留系統的最佳效能(記憶體和CPU)。
列數也會影響效能。 Adobe Campaign資料庫並非設計用來儲存未主動用於目標定位或個人化用途的歷史資料 — 這是作業資料庫。
若要避免任何與大量列相關的效能問題,只需將必要的記錄保留在資料庫中。 任何其他記錄應匯出至協力廠商資料倉儲,並從Adobe Campaign作業資料庫中移除。
以下是有關表格大小的一些最佳實務:
範例如下:
在此範例中: