At the core of the D·engage platform is the scalable and highly available relational database where you can store your data and create N-to-N (many-to-many) relations between them.

Accessing the data does not require navigating a rigid pathway through a tree or hierarchy. Users can import, query and update any table in the database, and combine related tables using special join functions to include relevant data contained in other tables in the results. Results can be filtered based on the content of any column, and any number of columns, allowing users to easily create personalized content. All these functionalities are both provided through the use of the web UI and API.

D·engage Platform's relational database is used for contact management, content management and personalization, campaign management, deliverability tracking and advanced analytics. It also enables third-party data sources of any kind to be integrated and activated, thus enriching your existing data and correlating different data pieces together, taking content personalization to the next level.

D·engage Data Space offers a wide range of features and capabilities for creating, retrieving, updating and deleting data and data tables in the system.

This section gives an introduction and an overview on the general functions and terms you will need to familiarize yourself with. Give this a read before you start your data onboarding process.

Master Contact Table

master_contact table is the central table in the Data Space. It is the master table where you will upload your contacts and keep them updated.

This table stores contact related information including contacts's opt-in permissions, channel engagement, contact statuses and more.

Each contact in this table is uniquely identified by the primary key contact_key. Users can add as many columns as they like to the Master Contact Table through API calls or through the web UI.

Note

Creating relations between Master_Contact table and Standalone tables for selected primary keys is possible whereas creating relations between Sys_Contact table and Sendable tables is not allowed. There is no limit in the number of relations created between tables.

Sendable Table

A Sendable table is a type of table which is linked with any of the columns of the master_contact table. Your Campaigns can be directly sent to these types of tables. Since the table is linked to the Master Contact, the required opt-in permissions for different channels are retrieved from the master_contact table automatically.

Creating a Sendable table requires creating a relation between a specific table and the master_contact table by linking any of its columns with the primary key of that corresponding table. Since the selected column is allowed to store TEXT type data, make sure to match a primary key column type TEXT on the corresponding table.

Standalone Table

Standalone tables are used to store any relevant data to be used while creating segments and personalized content for marketing campaigns. N-N relations can be created between different standalone tables for selected primary key values.

You have the option to link a standalone table to master_contact table with the primary key contact_key. When performed, that particular standalone table becomes a Sendable table to which campaigns can be directly sent to.

Note

If a Standalone table has data stored in it, it is not possible to link it to the master_contact table from that point on. We recommended that you convert a standalone table to a Sendable table at the importing stage by linking it via the contact_key.

Big Data Table

Big Data tables are used for storing external event and analytics data. Create relations with these tables and use them for segmentation. Users can opt for a Big Data Table when dealing with large quantities of data, often used for event tracking purposes.

Big Data Tables come preconfigured with key and event_time columns by default, providing essential structure for event data storage.

Note that the structure of Big Data Tables, including the key and event_time columns, cannot be altered.

Upon selection of the desired table creation option, users are directed to a dedicated page providing further guidance and steps to proceed with creating the chosen table type.

Data Types

• TEXT:

TEXT value must not exceed 16384 characters in length and must contain only UTF-8 characters.

• EMAIL:

A valid EMAIL data type consists of an email prefix and an email domain, both in acceptable formats. The prefix appears to the left of the @ symbol. The domain appears to the right of the @ symbol.

For example, in the address example@mail.com, "example" is the email prefix, and "mail.com" is the email domain.

The EMAIL data type length must not exceed **255 characters**, **including the @ sign.**

• DATE:

DATE data type format is YYYY-MM-DD. For example, a valid DATE value should look like 2024-12-18 or 2025-01-30

• DATETIME:

DATETIME data type format is YYYY-MM-DD HH:mm For example, a valid DATE value should look like 2025-12-31 15:30

• PHONE:

PHONE data type starts with a 2 digit Country Code followed by area code and the number; 44xxxxxxxxxx

For example, 

A valid PHONE value for Germany should look like 4989414171717

A valid PHONE value for the UK should look like 447717780000

• INTEGER:

INTEGER data type can store any value between -2,147,483,648 and 2,147,483,647

• DECIMAL:

DECIMAL data type can contain up to 131072 digits before the decimal point; up to 16383 digits after the decimal point. The decimal point separator is a point, not a comma. For example, a valid DECIMAL value should look like 8765.123

• BOOLEAN:

The BOOLEAN data type can get 2 valid values: true, false

Ecommerce Table

Ecommerce Tables are designed to capture key data about customer purchases and product information, forming the foundation for ecommerce-related features.

Ecommerce Tables are only available for accounts with the E-commerce type.

orders table

The Orders table stores users' purchase records. It does not include detailed product information; instead, it contains overall order-level data such as total item count, total amount, order ID, and similar fields.

Each order is linked to a user through the contact key, so data can only be added for existing contacts. To write data into this table, use the Orders API.

Use the UpsertOrders and DeleteOrder API endpoints to provide data into these tables.

orders_detail table

The Orders_Detail table stores the products included in each order.
For every order, there will be one or more records in this table, each representing a specific product in that order. For example, if an order contains three different products, all three product records will appear here.

This table is linked to the Orders table through the order_id, and it is also associated with the user via the contact key.

Use the UpsertOrders and DeleteOrder API endpoints to provide data into these tables.

product table

The Product table stores the list of products offered by the user/company.
Each product must have a unique product_id, which serves as the primary identifier.

If your integration does not require variant-level details (such as size, color, or other variations), the Product table alone is sufficient for a complete and functional setup.

Use the UpsertProduct and DeleteProduct API endpoints to provide data into these tables.

product_variant table

The product_variant table is optional and should be used only when you need to define variations of a single product. Variants represent different versions of the same product. For example, different colors, sizes, or configurations.

Each variant is linked to a product through the product_id, which is the common reference key between the two tables.

This table becomes necessary only in advanced use cases, where variant-level details must be managed or tracked individually.

Use the UpsertProduct and DeleteProduct API endpoints to provide data into these tables.