📙Core Concepts

Discover the foundational modules of the DinMo platform and understand how they empower you to turn your cloud data into a powerful Customer Data Platform (CDP).

What is DinMo?

DinMo is a customer data activation platform that seamlessly connects to existing cloud data environments, such as Snowflake, Databricks, or BigQuery. By integrating directly with your data warehouse, DinMo eliminates data duplication and empowers business teams with secure, self-service access to customer data, enabling faster and more effective marketing initiatives.

Who are DinMo's Main Users?

DinMo is designed for both data teams and marketing teams within enterprise environments:

• Data Teams: Use DinMo to connect cloud data with business tools, control data access, govern data exposure, and enrich datasets with predictive insights, ensuring consistent and secure data usage across the organization.

• Marketing Teams: Leverage DinMo to independently create, segment, and sync customer data with various platforms, including CRM, advertising, and support tools.

Platform Overview

DinMo's platform is built around a few core modules that enable seamless data activation:

1. Knowledge Layer: A business-friendly abstraction layer that stores business logic, calculated fields, customer audience definitions, and conversions, ensuring data consistency and accessibility.

2. Intelligence Engine: Leverages different AI models to predict future customer behaviors, generate insights, and recommend actions, enhancing customer engagement.

3. Segmentation Engine: Allows business users to create unlimited customer segments and audiences quickly and efficiently without code or SQL.

4. Insights Engine: Provides performance analytics, helping users make data-informed decisions.

5. Activation Engine: Syncs audiences, attributes and events with business tools to fulfill specific marketing and customer engagement use cases.

DinMo bridges the gap between data warehouses (single sources of truth) and business tools, facilitating continuous, real-time data access and activation across platforms. This ensures all your platforms are always connected to the fresh data in your single source of truth.

DinMo's customers can leverage various DinMo modules as they grow, ultimately building a robust composable CDP on top of their data warehouse.

From here, we can dive deeper into each concept and module for a comprehensive understanding of DinMo’s functionality and value. Let me know if you need further details on any part!

Sources

A source refers to the data warehouse where all the data you want to get value from is stored. Snowflake, or Google BigQuery are among the most common DataWarehouses. Note that your data always stays in your source, DinMo never imports or stores something from it.

To add a source into your DinMo workspace, you simply need to connect your data warehouse to the platform, ensuring that DinMo has the necessary permissions to read the data and execute jobs.

DinMo uses the source to store some info into specific schemas/datasets:

• DINMO_SEGMENTS: views of the query of the segments and models created within DinMo

• DINMO_STATS: tables that contain statistics about your segments

• DINMO_DELTA_STORAGE: snapshots of a historical run of segments queries that enable DinMo to calculate the changes that occur on a segment and update, therefore, the destination.

• DINMO_IDENTITY: For workspaces with the Identity Resolution module enabled, this this dataset stores the output tables generated by the identity resolution projects.

• DINMO_PREDICTIONS: For workspaces with the predictions module enabled, this dataset stores the output tables generated by the predictions models.

For guidance on connecting your designated data source, consult the corresponding section Connect a Source

Knowledge Store

The Knowledge Store is a dedicated space for data teams to connect business knowledge stored in tables to DinMo, enriching it with AI predictions (e.g., LTV, churn, product recommendations) and preparing data through identity resolution. It provides a rich no-code experience for business users, while being created and maintained by data experts familiar with the DataWarehouse. These capabilities enable seamless preparation and reuse of data models, enhancing flexibility and analytical power.

Models

Models are the fundamental building blocks behind DinMo's data model, representing specific types of objects. Models define which of the data stored in your source will be available to use in DinMo. Each model is analogous to a table in a database and serves as a container for all relevant information about the objects it represents.

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).

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 a user ID for User Models.

Models Relationships

Models are related by relations like has many , has one or belongs to.

For instance, 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 leveraging related model fields. For instance, selecting all customers who ordered a given type of product is a question of a few clicks.

Models Fields

Each model has its own set of fields, which can be either an Identifier, or an Attribute:

• Identifiers: These individual identification keys allow you to recognize your customers across all your owned platforms or walled gardens like Ads Platforms. (example: user_id, email, phone, first name, last name, etc.).

• Attributes: These are characteristics or properties of a model that can be used by business users to filter entities and create segments (for example: first order, country, number of orders, etc.).

• Custom Attributes: DinMo's users can enrich the data stored in their data warehouse by creating new attributes. A custom attribute is created as a SQL query that generates a two-column table: a key that can help recognize customers in the parent model and the value of an attribute in the second column.

Categorical Fields

Categorical Fields 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. By defining a field as categorical, it will be displayed in a much more intuitive manner when creating filters:

The Marketing Consent State field had been defined as categorical

Identity Resolution

The Identity Resolution module in DinMo enables organizations to consolidate and manage customer identities across multiple data sources. This ensures a unified and accurate view of each customer by resolving identities based on configurable rules and identifiers.

Users can create identity resolution projects to identify similar profiles in Models connected to DinMo and merge them together in an output Model called Golden Records.

More details about the specific core concepts of the identity resolution are available in this section Identity resolution

Segments

A segment is a subset of a parent model.

For instance, it is possible to create a segment of “users living in Europe” or a segment of “users who spent more than 100€”, from the Customers model.

All segments are associated to a parent model. Segments hence share the same properties, mapping, configuration, and primary key of their parent models.

For guidance on creating a segment, consult the corresponding section Create a segment.

Activations

Activation is the process of synchronizing a segment’s or a model's data to a predefined destination.

You can configure multiple activations from the same Knowledge Store to different destinations, ensuring all parts of your business are working off the same source of truth.

Sync

An activation process triggers a sync. A sync is a technical term that refers to the operations that will be made on the destination to reflect the changes observed in the segment query’s data between two executions.

Sync operations

When syncing a segment to a destination, four operations can be made to ensure the data within keeps up to date:

• Insert a new record and its attributes

• Delete an existing record

• Clear all existing records

• Update a record's attributes

Mapping

Mapping involves defining how fields from a segment should be matched with the standard user information used by marketing destinations. This includes identifying which column corresponds to specific details, such as email, phone number, or last name. Additional custom columns can also be mapped at the synchronization level for destinations that support it.

Sync modes

DinMo supports three types of sync modes, depending on the type of data being sent or the intent:

• Full sync: This will insert all segment records into the destination. It is the default sync mode when syncing a segment for the first time. It can also be triggered when the user asks for a full refresh of the segment.

• Incremental Sync: This mode is specifically designed for events. Incremental syncs transmit only the most recent event data, optimizing bandwidth usage.

• Delta Sync: This mode is exclusive to dimensional segments. It updates the destination in the destination by inserting and deleting records based on calculations of the differences between the segments. Furthermore, it updates attributes of the segment members in the destination when they undergo changes.

Destinations

A platform refers to any external tool or service to which you can send source data. This is where the data is usually accessed and utilized by the end users.

Examples of platforms include advertising platforms (such as Facebook Ads or Google Ads), customer relationship management software (such as Hubspot or Salesforce), or customer support tools (such as Zendesk). Other types of platforms, such as Facebook Catalog, are also supported on DinMo.

A destination refers to a specific target configuration of data synchronization within a platform.

A destination is defined by:

• Core parameters defining where your data will be sent. This information cannot be changed after the creation of the destination. Core parameters typically include:

  • The Destination Platform (for example, Google Ads, or Meta Ads)

  • The Destination Configuration (for example, the ad account, or the pixel ID)

• A specific service. For instance, two distinct use cases can be setup with our Meta integration:

  • Synchronizing audiences

  • Exporting conversion events

  One destination must be configured for each of the target use cases the user wishes to implement.

For guidance on connecting your designated destination, consult the corresponding section Connect a Destination

As each destination has unique requirements, refer to the Destinations documentation for guidance.

Destination platforms

These are typically where end-users consume data, including CRM systems, ad platforms, marketing automation tools, and support tools. DinMo seamlessly integrates with these destination platforms, providing a unified data solution. To add a destination platform, you establish a connection to the platform authorizing DinMo to create objects or/and update them with your source data.

Destination services

Destination services refer to what you are syncing/updating in a destination platform.

DinMo can update three types of objects within a destination platform:

• Events: such as conversion events for Facebook Ads or conversion actions for Google Ads. This is the default destination type of event segments. DinMo syncs events to destination platforms in batch to optimize the data transfer process and ensure efficient handling of large volumes of event data. By grouping events together and sending them as batches, DinMo minimizes the number of individual requests made to the destination platforms, reducing network overhead and improving overall performance. The sync frequency is set when configuring the activation and can be up to real-time.

• Lists: in some platforms, they can also be called segments or audiences, such as Customer List in Facebook Ads, static segments in Selligent Cloud, or cohorts in Braze. They are used to indicate membership of the platform contacts or users (ex., HubSpot contacts table) to a specific based on specific rules. This is the destination of User Segment in DinMo.

• Attribute objects: such as contacts tables within a CRM or catalog items in advertising platforms. They are dimensional entities that describe an identifiable contact. They contain attributes that change slowly, like (lifetime value, address, etc.).

Default activation settings

Default activation settings simplify the activation configuration process by allowing you to set it up just once, eliminating the need for repetitive configuration.

Default activation settings define how your data should be sent to the related destination. Default parameters can always be changed when creating an activation, but is proposed by default in order to simplify the activation process. Default activation settings typically include:

• The identifiers to match your model segments with the target’s data (example: user id, email, phone, first name, last name, etc.)

• The attributes within the target to be updated with segment attributes (if relevant)

• The time frequency at which DinMo will update the destination

Default activation settings are only supported for audience synchronizations. This is because other services typically involve specific configuration for each new activation.