Overview
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 configuration
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).
Advanced settings
When creating a model in DinMo, you can choose whether to materialize it in your data warehouse or keep it non-materialized (live).
A materialized model stores query results as a physical table in your data warehouse (e.g., BigQuery, Snowflake). The table is refreshed on a defined schedule.
A non-materialized model remains a logical view — it is queried in real time each time it’s used.
For more details, consult the corresponding page on model materialization
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:
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.
Model edition
You can easily update your model configuration at any time. From the Setup page, click Edit to modify any information defined during the initial configuration — such as the SQL query, the underlying table or the materialization.
If you modify the SQL query or table used to define the model, columns may be missing or renamed. In this case, DinMo automatically detects schema changes and asks you to choose what to do about the missing columns:
Remap another field
Drop the field
Relationships between models can also be modified from the Setup page (add, modify, delete).
You can also make adjustments directly from the Schema page: rename fields, change the way they are displayed (categorical or redacted), or update their mapping. All modifications are automatically reflected across your workspace to ensure data consistency and up-to-date usage in connected features.
Renaming fields has no impact on dependent objects, but changing a field’s type or deleting it may break underlying elements such as segments or predictions.
To help you manage this safely, DinMo automatically lists all impacted objects and prompts you to confirm before applying the change.
All modifications are propagated across your workspace to keep your data consistent and up to date.
Model enrichment
Calculated Fields
Calculated fields allow you to create new attributes based on existing data in your model. They can be used to transform, enrich, or combine existing columns using formulas and conditional logic. You can create numerical, text, or date-based expressions to support more advanced use cases, such as computing customer lifetime value, deriving engagement scores, or categorizing users based on behavioral thresholds.
Enrichment with AI attributes
If you have enabled the AI option in your workspace, your model can also be enriched with smart fields: RFM segmentation, churn risk, or expected additional value, for example.
Troubleshooting
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:
Last updated