This document outlines key recommendations while designing your Adobe Campaign data model.
For a better understanding of Campaign built-in tables and their interaction, refer to this section section.
Read out this documentation to get started with Campaign schemas. Learn how to configure extension schemas in order to extend the conceptual data model of the Adobe Campaign database in this document.
Adobe Campaign system is extremely flexible and can be extended beyond the initial implementation. However, while possibilities are infinite, it is critical to make wise decisions and build strong foundations to start designing your data model.
This document provides common use cases and best practices to learn how to architect properly your Adobe Campaign tool.
Adobe Campaign is a powerful cross-channel campaign management system that can help you align your online and offline strategies to create personalized customer experiences.
While most email service providers are communicating to customers via a list-centric approach, Adobe Campaign relies on a relational database in order to leverage a broader view of the customers and their attributes.
This customer-centric approach is shown on the chart below. The Recipient table in grey represents the main customer table around which everything is being built:
To access the description of each table, go to Admin > Configuration > Data schemas, select a resource from the list and click the Documentation tab.
The Adobe Campaign default data model is presented in this document.
Adobe Campaign Classic allows to build a custom customer table. However, in most cases, it is recommended to leverage the standard Recipient table which already has pre-built additional tables and features.
What data should be sent to Adobe Campaign? It is critical to determine the data required for your marketing activities.
Adobe Campaign is neither a data warehouse nor a reporting tool. Therefore, do not try to import all possible customers and their associated information into Adobe Campaign, or import data which will only be used to build reports.
To make the decision whether an attribute would be needed or not in Adobe Campaign, ask yourself if it would fall under one of these categories:
If not falling into any of these, you are most likely not going to need this attribute in Adobe Campaign.
To ensure good architecture and performance of your system, follow the best practices below to set up data in Adobe Campaign.
A field is required to be stored in a table if it has a targeting or personalization purpose. In other words, if a field is not used to send a personalized email or used as a criterion in a query, it takes up disk space whereas it is useless.
For hybrid and on-premise instances, FDA (Federated Data Access, an optional feature that allows to access external data) covers the need to add a field “on-the-fly” during a campaign process. You do not need to import everything if you have FDA. For more on this, see About Federated Data Access.
In addition to the autopk defined by default in most tables, you should consider adding some logical or business keys (account number, client number, and so on). It can be used later for imports/reconciliation or data packages. For more on this, see Identifiers.
Efficient keys are essential for performance. Numeric data types should always be preferred as keys for tables.
For SQLServer database, you could consider using “clustered index” if performance is needed. Since Adobe does not handle this, you need to create it in SQL.
The tablespace attribute in the schema allows you to specify a dedicated tablespace for a table.
The installation wizard allows you to store objects by type (data, temporary, and index).
Dedicated tablespaces are better for partitioning, security rules, and allow fluid and flexible administration, better optimization, and performance.
Adobe Campaign resources have three identifiers, and it is possible to add an additional identifier.
The following table describe these identifiers and their purpose.
|Name (or internal name)||
Primary keys are required for every table created in Adobe Campaign.
Most organizations are importing records from external systems. While the physical key of the Recipient table is the “id” attribute, it is possible to determine a custom key in addition.
This custom key is the actual record primary key in the external system feeding Adobe Campaign.
When an out-of-the-box table has both an autopk and an internal key, the internal key will be set as a unique index in the physical database table.
When creating a custom table, you have two options:
An autopk should not be used as a reference in workflows.
Adobe Campaign primary key is an auto-generated id for all out-of-the-box tables and can be the same for custom tables. For more on this, see this section.
This value is taken from what is called a sequence, which is a database object used to generate a number sequence.
There are two types of sequences:
The sequence is an integer 32-bit value, with a finite maximum number of available values: 2.14 billion. After reaching the maximum value, the sequence is going back to 0, in order to recycle ids.
If the old data has not been purged, the result will be a unique-key violation, which becomes a blocker for the platform health and usage. Adobe Campaign would not be able to send out communications (when it impacts delivery log table) and performances would be highly impacted.
Therefore, a customer sending 6 billion emails annually with a retention period of 180 days for their logs would run out of ids in 4 months. To prevent such a challenge, make sure to have purge settings according to your volumes. For more on this, see this section.
When a custom table is being created in Adobe Campaign with a primary key as an autoPK, a custom dedicated sequence should systematically be associated with that table.
By default, a custom sequence will have values ranging from +1,000 to +2.1BB. Technically, it is possible to get a full range of 4BB by enabling negative ids. This should be used with care and one id will be lost when crossing from negative to positive numbers: the record 0 is typically ignored by Adobe Campaign in generated SQL queries.
Indexes are essential for performance. When you declare a key in the schema, Adobe will automatically create an index on the fields of the key. You can also declare more indexes for queries that do not use the key.
Adobe recommends defining additional indexes as it may improve performance.
However, keep in mind the following:
Managing indexes can become very complex, therefore it is important to understand how they work. To illustrate this complexity, let’s take a basic example such as searching recipients by filtering on the first name and last name. To do this:
Go to the folder that lists all recipients in the database. For more on this, see Managing profiles.
Right-click the First name field.
Select Filter on this field.
Repeat this operation for the Last name field.
The two corresponding filters are added on top of the screen.
You can now perform search filtering on the First name and Last name fields according to the various filter conditions.
Now to speed up search on these filters, you can add indexes. But which indexes should be used?
This example applies to hosted customers using a PostgreSQL database.
The following table shows in which cases the three indexes described below are used or not according to the access pattern displayed in the first column.
|Search criteria||Index 1 (First name + Last name)||Index 2 (First name only)||Index 3 (Last name only)||Comments|
|First name equals “Johnny”||Used||Used||Not used||As the first name is in first position on index 1, it will be used anyway: there is no need to add a criterion on the last name.|
|First name equals “Johnny” AND Last name equals “Smith”||Used||Not used||Not used||As both attributes are searched in the same query, only the index that combines both attributes will be used.|
|Last name equals “Smith”||Not used||Not used||Used||The order of the attributes in the index is taken into account. If you do not match this order, the index may not be used.|
|First name starts with “Joh”||Used||Used||Not used||“Left search” will enable indexes.|
|First name ends with “nny”||Not used||Not used||Not used||“Right search” will disable indexes and a full scan will be performed. Some specific index types could handle this use case, but they are not available by default in Adobe Campaign.|
|First name contains “John”||Not used||Not used||Not used||This is a combination of “left” and “right” searches. Because of the latter, it will disable indexes and a full scan will be performed.|
|First name equals “john”||Not used||Not used||Not used||Indexes are case-sensitive. To make it non case-sensitive, you should create a specific index that includes an SQL function like “upper(firstname)”. You should do the same with other data transformation such as “unaccent(firstname)”.|
Beware of the “own” integrity on large tables. Deleting records that have wide tables in “own” integrity can stop the instance. The table is locked, and the deletions are made one by one. So it’s best to use “neutral” integrity on child tables that have large volumes.
Declaring a link as an external join is not good for performance. The zero-id record emulates the external join functionality. It is not necessary to declare external joins if the link uses the autopk.
While it is possible to join any table in a workflow, Adobe recommends defining common links between resources directly in the data structure definition.
Link should be defined in alignment with the actual data in your tables. A wrong definition could impact data retrieved via links, for example unexpectedly duplicating records.
Name your link consistently with the table name: the link name should help understand what the distant table is.
Do not name a link with “id” as a suffix. For example, name it “transaction” rather than “transactionId”.
By default, Adobe Campaign will create a link using the primary key of the external table. For more clarity, it is preferable to explicitly define the join in the link definition.
An index will be added to the attributes used in a link.
The created-by and last-modified-by links are present in many tables. It is possible to disable the index by using the attribute noDbIndex on the link, if this information is not being used by the business.
When you design a link, make sure that the target record is unique when a 1-1 relationship has been declared. Otherwise the join may return multiple records when only one is expected. This results in errors during delivery preparation when “the query returns more rows than expected”. Set the link name to the same name as the target schema.
Define a link with a cardinality (1-N) in the schema on the (1) side. For example, the relation Recipient (1) – (N) Transaction should be defined in the transaction schema.
Note that a reverse cardinality of a link is (N) by default. It is possible to define a link (1-1) by adding the attribute revCardinality=‘single’ to the link definition.
If the reverse link should not be visible to the user, you can hide it with the link definition revLink=‘NONE’. A good use case for this is to define a link from recipient to the last transaction completed for example. You only need to see the link from recipient to the last transaction and no reverse link is required to be visible from the transaction table.
Links performing an external join (1-0…1) should be used with care as it will impact the system performance.
Adobe Campaign is neither a data warehouse nor a reporting tool. Therefore, to ensure good performance of the Adobe Campaign solution, database growth should stay under control. To achieve this, following some of the best practices below may help.
By default, Adobe Campaign delivery and tracking logs have a retention duration of 180 days. A cleanup process runs to remove any log older than that.
Learn more about data retention in Campaign Privacy and Security guidelines.
Learn more about Campaign Data base cleanup workflow in this section.
Custom tables are not purged with the standard cleanup process. While this might not be required on day one, do not forget to build a purge process for your custom tables as this could lead to performance challenges.
There are a few solutions to minimize the need of records in Adobe Campaign:
You can declare the “deleteStatus” attribute in a schema. It is more efficient to mark the record as deleted, then postpone the deletion in the cleanup task.
In order to ensure better performance at any time, follow the best practices below.
Adobe Campaign relies on third-party database engines. Depending on the provider, optimizing performance for larger tables may require a specific design.
Below are a few common best practices that should be followed when designing your data model using large tables and complex joins.
The table size is a combination of the number of records and the number of columns per record. Both can impact the performance of queries.
On PostgreSQL, a row should not exceed 8KB to avoid TOAST mechanism. Therefore, try to reduce as much as possible the number of columns and the size of each row to preserve optimal performance of the system (memory and CPU).
The number of rows impacts performance as well. The Adobe Campaign database is not designed to store historical data that are not actively used for targeting or personalization purpose - this is an operational database.
To prevent any performance issue related to the high number of rows, only keep the necessary records in the database. Any other record should be exported to a third-party data warehouse and removed from the Adobe Campaign operational database.
Here are a few best practices regarding the size of tables:
Here is an example:
In this example: