Overview

Models define which of the data stored in your source will be available to use in DinMo. They correspond to a specific table stored in your source, or to a SQL query.

Models can be:

• Segmented using our no-code segment builder

• Activated, meaning, synchronized to destination platforms

Refer to this page to learn how to create a model in DinMo.

Model types

Models can be either of type Users, of type Events, or of type Custom. The type will affect how data from the model is sent to destination platforms.

• Users: models that describe the characteristics users, customers, leads, etc.

• Events: models that contain temporal information about business events and transactions, such as user events or sales.

• Custom: models that contain any other type of information with business meaning (products, companies, deals), or without business meaning (relationship tables).

Model's schema

A model has a fixed schema in DinMo, with a list of fields configured during creation. In the schema tab of an existing model, users can edit the model's schema:

Primary key

A primary key uniquely identifies each record in the model. It acts as a unique identifier to keep track of records and reconcile the data in your segments with the ones in your destination. Using a primary key allows your destination to recognize your customers uniquely. The primary key is generally the email address or any external user ID for User Models.

The primary key cannot be deleted or edited.

To ensure that DinMo system operates smoothly and that all downstream tasks produce accurate results, it is essential to ensure the uniqueness of the primary key of each model.

For more details, consult the corresponding section on Primary Keys.

Fields

Each field is associated to a unique source column, corresponding either to a column in the source table of the model, or to a column of the output of the SQL query defining the model.

Fields can be added to your model by clicking the corresponding button in the lower part of the schema tab:

Categorical fields

Categorical fiels are defined by the user during the creation of a model. They are fields which have a limited number of distinct values, for instance, the Product Type, or the Country. Defining a field as categorical will improve the way it is displayed:

The Marketing Consent State Property had been defined as categorical

Redacted data

When building or editing your data model, you can identify Personally Identifiable Information (PII) so that it is not visible in the different previews.

To do this, go to your model and simply check the “Redact Data” option.

DinMo will automatically hide this data in all previews, specifying that it is “redacted” data.

This feature aligns with our commitment to data privacy, security, and regulatory compliance.

Standard mapping

Fields may be mapped to specific meanings for DinMo to know how to interpret them. Mapping fields at the model level will remove the need to map them later again. In this example, we indicate to DinMo that the field email contains the Email information.

Models Relationships

The user can configure relationships between existing models using Has Many, Belongs To or Has One relations in the Setup tab. For instance, here, the Customer model is related to the Order model, meaning that there is a customer behind each order being made. Mapping relationships between the different models enable advanced customer segmentation, such as selecting all customers who ordered a given type of product is a question of a few clicks.

Source schema alteration

In some cases, the source of a model may be altered. For instance, if the source table of one model had a critical column deleted or renamed, the model schema will have to be fixed.

When these cases arise, users have either drop the broken fields, or link a new column: