v7

資料模型最佳實務

本檔案會概述設計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既不是Data Warehouse也不是報表工具。 因此，請勿嘗試將所有可能的客戶及其相關資訊匯入Adobe Campaign，或匯入僅用於建立報表的資料。

若要在Adobe Campaign中決定是否需要屬性，請詢問您自己該屬性是否會屬於以下類別之一：

  • 用於以下專案的屬性： 細分
  • 用於以下專案的屬性： 資料管理流程 （例如彙總計算）
  • 用於以下專案的屬性： 個人化

如果沒有落入其中任何一項，您很可能不需要在Adobe Campaign中使用此屬性。

資料型別選擇

為確保系統具備良好的架構和效能，請遵循下列最佳實務，在Adobe Campaign中設定資料。

  • 大型表格通常應該有數值欄位，並包含參考表格的連結（使用值清單時）。
  • 此 運算式 attribute允許將結構描述屬性定義為計算欄位，而不是表格中的實體設定值。 如此可讓您以不同格式（例如年齡和出生日期）存取資訊，而不需要儲存這兩個值。 這是避免欄位重複的好方法。 例如，收件者表格會使用網域的運算式，該運算式已存在於電子郵件欄位中。
  • 不過，當運算式計算複雜時，不建議使用 運算式 屬性作為即時計算可能會影響查詢的效能。
  • 此 XML 輸入是避免建立太多欄位的好方法。 但也會佔用磁碟空間，因為它使用資料庫中的CLOB欄。 這也會導致複雜的SQL查詢，並可能影響效能。
  • 的長度 字串 欄位一律應使用欄定義。 依預設，Adobe Campaign中的長度上限為255，但Adobe建議，如果您已知道大小不會超過較短的長度，請讓欄位保持較短。
  • 如果您確定來源系統中的大小被高估而無法達到，則可以接受Adobe Campaign中的欄位比來源系統中的欄位短。 這可能表示Adobe Campaign中的字串長度較短或整數較小。

欄位選擇

如果欄位具有目標定位或個人化目的，則需要將其儲存在表格中。 換言之，如果欄位未用於傳送個人化電子郵件或用作查詢中的條件，則會佔用磁碟空間，但毫無用處。

對於混合式和內部部署例項，FDA （同盟資料存取，可存取外部資料的選用功能）涵蓋在行銷活動過程中「即時」新增欄位的需求。 如果您有FDA，則不需要匯入所有內容。 如需詳細資訊，請參閱 關於同盟資料存取.

按鍵選擇

除了 autopk 在大多數的表格中預設會定義，您應該考慮新增一些邏輯或業務金鑰（帳號、使用者端號碼等）。 稍後可用於匯入/調解或資料套件。 如需詳細資訊，請參閱 識別碼.

高效率索引鍵對效能至關重要。 數值資料型別一律可作為表格的索引鍵使用。

對於SQLServer資料庫，如果需要效能，可以考慮使用「叢集索引」。 由於Adobe不會處理這個問題，因此您需要在SQL中建立它。

專用表格空間

綱要中的表格空間屬性可讓您指定表格的專用表格空間。

安裝精靈可讓您依型別（資料、暫存和索引）儲存物件。

專用表格空間更適合分割、安全性規則，並可進行流暢且彈性的管理、更佳的最佳化及效能。

識別碼

Adobe Campaign資源有三個識別碼，您可以新增另一個識別碼。

下表說明這些識別碼及其用途。

識別碼 說明 最佳實務
ID
  • ID是Adobe Campaign表格的實體主要索引鍵。 對於現成可用的表格，這是從序列產生的32位元數字
  • 此識別碼通常是特定Adobe Campaign執行個體所獨有的。
  • 自動產生的ID可顯示在結構描述定義中。 搜尋 autopk="true" 屬性。
  • 自動產生的識別碼不應在工作流程或封裝定義中作為參考使用。
  • 不應假設ID一律為遞增的數字。
  • 現成可用表格中的ID是32位元數字，不應變更此型別。 此數字取自區段中相同名稱的「序列」。
名稱（或內部名稱）
  • 此資訊是表格中記錄的唯一識別碼。 此值可以手動更新，通常使用產生的名稱。
  • 此識別碼在Adobe Campaign的其他執行個體中部署時保留其值，且不應空白。
  • 如果要將物件從一個環境部署至另一個環境，請重新命名Adobe Campaign產生的記錄名稱。
  • 當物件具有名稱空間屬性(綱要 例如)，此通用名稱空間將在所有建立的自訂物件間運用。 部分保留的名稱空間不應使用： nms， xtk， nl， ncl， crm， xxl.
  • 當物件沒有任何名稱空間時(工作流程 或 傳遞 例如)，此名稱空間概念會新增為內部名稱物件的前置詞： namespaceMyObjectName.
  • 請勿使用空格「 」、分號「：」或連字型大小「 — 」等特殊字元。 所有這些字元都會取代為底線「_」（允許的字元）。 例如，「abc-def」和「abc：def」會儲存為「abc_def」並互相覆寫。
標籤
  • 標籤是Adobe Campaign中物件或記錄的商業識別碼。
  • 此物件允許空格和特殊字元。
  • 它無法保證記錄的唯一性。
  • 建議決定物件標籤的結構。
  • 這是為Adobe Campaign使用者識別記錄或物件的最好記解決方案。

自訂內部索引鍵

在Adobe Campaign中建立的每個表格都需要主索引鍵。

大多陣列織都從外部系統匯入記錄。 雖然收件者表格的實體索引鍵是"id"屬性，但您也可以判斷自訂索引鍵。

此自訂金鑰是外部系統中饋送Adobe Campaign的實際記錄主金鑰。

當現成可用的表格同時具有autopk和內部索引鍵時，內部索引鍵將會設定為實體資料庫表格中的唯一索引。

建立自訂表格時，您有兩個選項：

  • 自動產生的索引鍵(id)和內部索引鍵（自訂）的組合。 如果您的系統索引鍵是複合索引鍵或非整數，此選項會很有趣。 整數在大表格中及與其他表格結合時，可提供更高的效能。
  • 使用主鍵作為外部系統主鍵。 此解決方案通常為較佳選擇，因為它可簡化匯入和匯出資料的方法，並在不同系統間使用一致的金鑰。 如果索引鍵名為「id」，且必須填入外部值（而非自動產生），則應停用Autopk。
重要

Autopk不應作為工作流程中的參考。

序列

Adobe Campaign主索引鍵是所有現成可用表格自動產生的id，且自訂表格可以相同。 如需詳細資訊，請參閱本節。

此值擷取自所謂的 序列，用來產生編號規則的資料庫物件。

序列有兩種型別：

  • 已共用：多個表格會從相同序列中挑選其id。 這表示如果一個資料表使用ID 'X'，其他共用相同序列的資料表都不會有該ID 'X'的記錄。 XtkNewId 是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建議定義其他索引，因為這可以改善效能。

不過，請記住以下事項：

  • 索引使用方式會與您的存取模式繫結。 最佳化索引通常是資料庫設計的關鍵部分，必須由專家處理。 新增索引通常是附加至資料庫維護的重複工作流程。 這項工作會隨著時間推移逐步進行，以解決發生時的效能問題。
  • 索引會增加整體資料表大小（以儲存索引本身）。
  • 在資料行上新增索引可以改善資料讀取存取(SELECT)的效能，但可能會降低資料寫入存取(UPDATE)的效能。
  • 由於這會影響資料插入期間的效能，因此應該限制索引的大小和數量。
  • 必要時不要新增索引。 確定此為必要專案，並提升查詢的整體效能（測試與學習）。
  • 一般而言，如果您知道查詢不會傳回超過10%的記錄，索引會很有效率。
  • 請仔細選取需要定義的索引。
  • 請勿從現成可用的表格中移除原生索引。

範例

管理索引可能會變得非常複雜，因此瞭解索引如何運作非常重要。 為了說明此複雜性，我們以一個基本範例為例，例如透過篩選名字和姓氏來搜尋收件者。 操作步驟：

  1. 移至列出資料庫中所有收件者的資料夾。 如需詳細資訊，請參閱 管理設定檔.

  2. 以滑鼠右鍵按一下 First name 欄位。

  3. 選取 Filter on this field。

  4. 對以下專案重複此操作： 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天。 清除程式會執行以移除任何超過該時間的記錄。

  • 如果您想要保留更長的記錄時間，應根據資料庫大小和傳送的訊息數量，謹慎做出此決定。 提醒您，Adobe Campaign序列是32位元整數。
  • 建議不要在這些表格中一次擁有超過10億筆記錄（大約佔可用的21.4億id的50%），以限制使用所有可用id的風險。 有些客戶需要將保留期間降低到180天以下。

進一步瞭解中的資料保留 Campaign隱私權與安全性方針.

深入瞭解Campaign資料庫清理工作流程 在本節中.

重要

自訂表格不會使用標準清理程式清除。 雖然這可能不是第一天的必要操作，但別忘了為自訂表格建立清除程式，因為這可能會導致效能挑戰。

有幾個解決方案可將Adobe Campaign中對記錄的需求降至最低：

  • 將資料匯出至Adobe Campaign外部的Data Warehouse。
  • 產生彙總值，此彙總值會使用較少的空間，但足以供您的行銷實務使用。 例如，您不需要Adobe Campaign中的完整客戶交易歷史記錄來追蹤上次購買。

您可以在結構描述中宣告「deleteStatus」屬性。 將記錄標示為已刪除，然後在清除工作中延遲刪除會更有效率。

效能

為了確保隨時提供更優異的效能，請遵循下列最佳實務。

一般性建議

  • 避免在查詢中使用「CONTAINS」等操作。 如果您知道應該篩選哪些專案，並想要篩選這些專案，請套用包含「等於」或其他特定篩選運運算元的相同條件。
  • 在工作流程中建立資料時，請避免加入未編制索引的欄位。
  • 請嘗試並確保匯入和匯出等程式在工作時間外進行。
  • 請確定所有日常活動都有排程，並遵守排程。
  • 如果有一或數個每日處理作業失敗，且必須在同一天執行，請確定啟動手動處理作業時沒有執行衝突的處理作業，因為這會影響系統效能。
  • 請確定在匯入程式期間或執行任何手動程式時，沒有執行任何每日行銷活動。
  • 使用一或多個參考表格，而不是在每列中複製欄位。 使用索引鍵/值配對時，最好選擇數字索引鍵。
  • 簡短字串仍可接受。 如果外部系統中已有參考表格，重複使用相同表格將有利於與Adobe Campaign的資料整合。

一對多關係

  • 資料設計會影響可用性和功能。 如果您在設計資料模型時有許多一對多關係，這會讓使用者更難以在應用程式中建構有意義的邏輯。 非技術行銷人員可能很難正確建構和瞭解一對多篩選邏輯。
  • 將所有重要欄位放在一個表格中很好，因為這樣可讓使用者更輕鬆地建立查詢。 有時候，如果可以避免聯結，跨表格複製某些欄位對效能也有好處。
  • 某些內建功能將無法參考一對多關係，例如「優惠加權」公式和「傳送」。

大型表格

Adobe Campaign仰賴協力廠商資料庫引擎。 視提供者而定，針對大型表格最佳化效能可能需要特定設計。

以下是使用大型表格和複雜聯結設計資料模型時應遵循的一些常見最佳實務。

  • 使用其他自訂收件者表格時，請確定每個傳遞對應都有專屬的記錄表格。
  • 減少欄數，特別是識別未使用的欄。
  • 避免複雜的聯結（例如多個條件和/或數個欄上的聯結），最佳化資料模型關係。
  • 若是聯結金鑰，請一律使用數值資料，而非字元字串。
  • 儘可能減少記錄保留的深度。 如果您需要更深入的記錄，您可以彙總計算和/或處理自訂記錄表，以儲存更大的記錄。

表格大小

表格大小是記錄數和每筆記錄欄數的組合。 兩者都會影響查詢效能。

  • A 小型 表格類似於「傳送」表格。
  • A 中型 表格與收件者表格的大小相同。 每個客戶有一筆記錄。
  • A 大尺寸 表格類似於廣泛記錄表格。 每個客戶有許多記錄。
    例如，如果您的資料庫包含1000萬收件者，則Broad記錄表格會包含約1億到2億則訊息，而Delivery表格則會包含數千筆記錄。

在PostgreSQL上，資料列不應超過8KB，以避免 快顯通知 機制。 因此，請儘量減少欄數及每列的大小，以保留系統的最佳效能（記憶體和CPU）。

列數也會影響效能。 Adobe Campaign資料庫並非設計用來儲存未主動用於目標定位或個人化用途的歷史資料 — 這是作業資料庫。

若要避免任何與大量列相關的效能問題，只需將必要的記錄保留在資料庫中。 任何其他記錄應匯出至協力廠商資料倉儲，並從Adobe Campaign作業資料庫中移除。

以下是有關表格大小的一些最佳實務：

  • 設計欄位較少且數值資料較多的大型表格。
  • 請勿使用大數字型別的欄（例如：Int64）來儲存小數字，如布林值。
  • 從表格定義中移除未使用的欄。
  • 請勿在Adobe Campaign資料庫中保留歷史資料或非作用中資料（匯出和清理）。

範例如下：

在此範例中：

  • 此 交易 和 異動料號 表格很大：超過1,000萬。
  • 此 產品 和 儲存 表格較小：小於10,000。
  • 產品標籤和參考已放在 產品 表格。
  • 此 異動料號 表格只有連結至 產品 表格，數值。

本頁內容