Get started with Campaign data model about-data-model
The conceptual data model of the ۶Ƶ Campaign database consists in a set of built-in tables and their interaction. Main tables and concepts are listed in this page.
Overview data-model-overview
۶Ƶ Campaign relies on a relational database containing tables that are linked together. The basic structure of the ۶Ƶ Campaign data model can be described as follows.
Recipient table recipient-table
The data model relies on a main table which is by default the Recipient table (NmsRecipient). This table enables to store all the marketing profiles.
For more on the Recipient table, see this section.
Delivery table delivery-table
The data model also includes a part dedicated to store all the marketing activities. Usually it is the Delivery table (NmsDelivery). Each record in this table represents a delivery action or a delivery template. It contains all the necessary parameters for performing deliveries such as target, content, etc.
Logs tables log-tables
Another part of the data model enables to temporarily store all the logs associated with the execution of the campaigns.
Delivery logs are all messages sent to recipients or devices across all channels. The main Delivery logs table (NmsBroadLog) contains the delivery logs for all recipients.
The main Tracking logs table (NmsTrackingLog) stores the tracking logs for all recipients. The tracking logs refer to reactions of recipients, such as email openings and clicks. Each reaction corresponds to a tracking log.
Delivery logs and tracking logs are deleted after a certain period, which is specified in ۶Ƶ Campaign and can be modified. Therefore, it is highly recommended to export the logs on a regular basis.
Technical tables technical-tables
Finally, part of the data model consists in technical data used for the applicative process, including operators and user rights (NmsGroup), folders (XtkFolder).
Using the built-in Recipient table default-recipient-table
The built-in Recipient table in ۶Ƶ Campaign provides a good starting point for building your data model. It has a number of predefined fields and table links that can be easily extended. This is particularly useful when you are mainly targeting recipients, because it fits a simple recipient-centric data model.
The benefits of using the built-in Recipient table are as follows:
- Working built-in with functionalities such as subscriptions, seed lists, and more.
- Providing a marketing database with a recipient-centric data model.
- Faster implementation.
- Easy maintenance by support and partners.
However, it is possible to extend the Recipient table, but not to reduce the number of fields or links in the table.
Also, as the Recipient table is part of the product, both the table and its associated form evolve as the product changes. Therefore extra maintenance is needed to check that any extensions are still valid upon upgrade.
Extending the data model extending-data-model
When starting with ۶Ƶ Campaign, you need to assess the default data model to check which table is the best suited to store your marketing data.
If relevant, you can use the default Recipient table with the out-of-the-box fields, such as described in this section.
If needed, you can extend it with two mechanisms:
- Extend an existing table with new fields. For example, you can add a new “Loyalty” field to the Recipient table.
- Create a new table, for example a “Purchase” table listing all the purchases made by each profile of the database, and link it to the Recipient table.
For more on configuring extension schemas to extend the conceptual data model, see About schema edition.
Using a custom recipient table custom-recipient-table
When designing your ۶Ƶ Campaign data model, you can use the built-in recipient table, or decide to create a custom recipient table table to store you marketing profiles.
Indeed, if your data model does not fit the recipient-centric structure, you can set up other tables as the targeting dimension within ۶Ƶ Campaign. For example, this can be relevant when you need to target households, accounts (like mobile phones) and companies/sites rather than simply recipients.
All the principles and steps needed when using a custom recipient table are detailed in this section.
The benefits of using a custom Recipient table are as follows:
-
Flexible data model - The built-in recipient table is useless if you do not need most of the Recipient table fields, or if the data model is not recipient-centric.
-
Scalability - Large volumes require a streamlined table with few fields for an efficient design. The built-in recipient table would have too many useless fields, which could impact performance and lack efficiency.
-
Data location - If data resides on an external existing marketing database, it may require too much effort to use the built-in recipient table. Creating a new one based on an existing structure is simpler.
-
Easy migration - No maintenance is needed to check that all extensions are still valid upon upgrade.
Related topics
Learn more about Campaign data model in these sections:
-
Description of the main tables - For more on the default Campaign Classic data model description, refer to this section.
-
Full description of each table - To access the complete description of each table, go to Admin > Configuration > Data schemas, select a resource from the list and click the Documentation tab.
-
Campaign schemas - The physical and logical structure of the data carried in the application is described in XML. It obeys a grammar specific to ۶Ƶ Campaign, called a schema. For more on ۶Ƶ Campaign schemas, read out this section.
-
Data model best practices - Learn Campaign data model architecture and related best practices, in this section.