# Welcome Learn how to configure DinMo, model customer data, build audiences, activate them across business tools, and operate your composable CDP. Welcome to the DinMo documentation. DinMo helps data and marketing teams turn warehouse data into trusted customer audiences, profiles, journeys, and activations. Use this home page to find the right starting point, understand the main product areas, and jump into the workflow you need. ## Start here | If you are... | Start with | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | New to DinMo | [Get started with DinMo](/guides/get-started-with-dinmo) | | A data team setting up the workspace | [Initial Configuration of DinMo](/guides/get-started-with-dinmo/initial-configuration-of-dinmo) | | A marketer building audiences | [Create and Activate Segments on DinMo](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo) | | Looking for definitions | [Core Concepts](/core-concepts) | | Connecting a warehouse | [Data Sources](/integrations/data-sources) | | Sending data to a tool | [Destination Platforms](/integrations/destination-platforms) | | Managing users and governance | [Workspace management](/workspace-management/set-up) | ## What you can do with DinMo | Area | What it helps you do | Key pages | | ------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Models | Expose warehouse tables to business users with clear identifiers, attributes, and relationships. | [Models overview](/models/overview), [Primary Keys](/models/primary-keys) | | Segments | Build reusable customer audiences from models and related data. | [Visual Builder](/segments/visual-builder), [Breakdowns](/segments/breakdowns), [Overlap Analysis](/segments/overlap-analysis) | | Activations | Sync audiences, attributes, and events to marketing, CRM, ads, support, and storage destinations. | [Activations overview](/activations/overview), [Sync Scheduling](/activations/sync-scheduling), [Troubleshooting Syncs](/activations/troubleshooting-syncs) | | Identity Resolution | Deduplicate customer records, create golden records, and attach events to known profiles. | [Identity Resolution](/identity-resolution/overview), [Profile Resolution](/identity-resolution/profile-resolution), [Event Stitching](/identity-resolution/event-stitching) | | Customer Hub | Give business users a unified customer view with profiles, metrics, audiences, and performance insights. | [Customer Hub](/customer-hub/overview), [Getting Started](/customer-hub/getting-started) | | Journeys | Build and monitor multi-step customer journeys from segments, waits, conditions, and activations. | [Journey overview](/journey/journey), [Getting Started](/journey/getting-started) | | AI Predictions | Use predictive models for churn, lifetime value, and product recommendations. | [AI Predictions](/ai-predictions/overview), [LTV and Churn](/ai-predictions/ltv-and-churn) | | DinMo Ingest | Bring source-platform data into your warehouse for activation and analysis workflows. | [DinMo Ingest](/integrations/dinmo-ingest) | ## Common workflows ### Launch your first activation 1. [Connect a Source](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/connect-a-source) 2. [Create your Models](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-your-models) 3. [Create a Destination](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) 4. [Create your first Segment](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) 5. [Activate your first Segment](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) ### Build a trusted customer layer 1. [Understand Models](/models/overview) 2. [Configure primary keys](/models/primary-keys) 3. [Create your first Profile Resolution project](/identity-resolution/profile-resolution/get-started) 4. [Review Identity Resolution output tables](/identity-resolution/profile-resolution/output-tables) 5. [Configure Customer Hub](/customer-hub/getting-started) ### Operate and govern the workspace 1. [Set Up](/workspace-management/set-up) 2. [Managing Users, Roles & Permissions](/workspace-management/managing-users-roles-and-permissions) 3. [Audit Logs](/workspace-management/audit-logs) 4. [Enterprise Single Sign-On](/workspace-management/enterprise-single-sign-on-sso) 5. [Security & Privacy overview](/security-and-privacy/overview) ## Browse the docs | Section | Use it for | | ---------------------------------------------------- | ---------------------------------------------------------------------- | | [Guides](/guides/get-started-with-dinmo) | Step-by-step setup and onboarding workflows. | | [Integrations](/integrations/data-sources) | Warehouse sources, destination platforms, and DinMo Ingest connectors. | | [Models](/models/overview) | Data model setup, primary keys, and computed fields. | | [Segments](/segments/visual-builder) | Audience creation and audience analysis. | | [Activations](/activations/overview) | Sync behavior, scheduling, and troubleshooting. | | [Identity Resolution](/identity-resolution/overview) | Profile resolution, event stitching, and warehouse outputs. | | [Customer Hub](/customer-hub/overview) | Customer profiles, metrics, audiences, and APIs. | | [Journey](/journey/journey) | Journey creation, concepts, monitoring, and best practices. | | [Security & Privacy](/security-and-privacy/overview) | Security model, networking, privacy, and compliance. | *** ### Ready to get started? Book a demo and we will walk through the best way to launch your first DinMo use case. [Book a demo](https://www.dinmo.com/contact/) ### Need help? Our team is here to help with setup, modeling, activation, and troubleshooting. [Contact us](mailto:hello@dinmo.com?subject=Docs%20help) ### Feature requests? Tell us which connector, workflow, or improvement would make DinMo more useful for your team. [Request a feature](mailto:hello@dinmo.com?subject=Feature%20request) [Privacy Policy](https://www.dinmo.com/legals/privacy/) | [Terms of Service](https://www.dinmo.com/terms-of-service/) # 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? In a world where customer data is key to marketing performance, DinMo offers a modern, modular, and quick-to-deploy alternative to traditional Customer Data Platforms. We believe that data should no longer be the exclusive domain of technical teams, but rather a lever that is accessible, controllable, and directly actionable by business units. DinMo is recognized as the pioneer and European leader in “Composable” CDP. 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. {% hint style="info" %} If you do not have a cloud data warehouse or your data sources are not compatible with no-copy, we can still host an intermediate database and manage it for you. :bulb: Learn more about this option in **DinMo Storage**. {% endhint %} ## 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 provides a complete platform, built around plug-and-play modules, to accelerate your marketing team’s data transformation — without technical overhead. ### Core components Our basic module corresponds to **DinMo Activate**, which allows to create segments in just a few clicks and sync them to all your business tools (CRM, Ads, etc.) via our powerful reverse ETL. More specifically, the **DinMo Activate** module consists of: * **Knowledge Store**: stores business logic, calculated fields, customer audience definitions, and conversions, ensuring data consistency and accessibility. It's your perfect business-friendly abstraction layer! * **Segmentation Engine**: allows business users to create unlimited customer segments and audiences quickly and efficiently without code or SQL. * **Activation Engine**: syncs audiences, attributes and events with business tools to fulfill specific marketing and customer engagement use cases. ### Optional modules We offer additional modules to build your own CDP, without overlapping functionality with what you already have available internally. * [**DinMo Intelligence**](/ai-predictions/overview): boost your performance with AI models — churn prediction, customer scoring, product recommendations and more. * [**DinMo Identity**](/identity-resolution/overview): unify your data with automated deduplication, cleansing, and reconciliation of online & offline journeys. * [**DinMo Hosting**](/data-hosting/dinmo-storage): get a managed cloud data warehouse hosted in Europe — with full reinternalization flexibility. * [**Customer Hub**](/customer-hub/overview): gain a unified customer view, actionable insights, a testing platform, and clear data governance across teams. This module helps users make data-informed decisions. * **DinMo Web & App Tracking**: capture behavioral data from your sites and apps effortlessly. DinMo's customers can leverage various DinMo modules as they grow, ultimately building a robust composable CDP on top of their own data and marketing stacks.
*** :arrow\_down: From here, we can dive deeper into each concept and module for a comprehensive understanding of DinMo’s functionality and value. ## Sources
{% hint style="success" %} 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 data warehouses.\ In a composable mode, note that your data **always stays in your source**. DinMo never imports or stores something from it. {% endhint %} 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. {% hint style="info" %} For guidance on connecting your designated data source, consult the corresponding section [Connect a Source](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/connect-a-source) {% endhint %} ## Knowledge Store
{% hint style="success" %} 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 data warehouse. These capabilities enable seamless preparation and reuse of data models, enhancing flexibility and analytical power. {% endhint %} ### 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 identity resolution are available in [Identity Resolution](/identity-resolution/overview). ## Segments
{% hint style="success" %} A segment is a subset of a parent model. {% endhint %} 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. {% hint style="info" %} For guidance on creating a segment, consult the corresponding section [Create a segment](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment). {% endhint %} ## Activations
{% hint style="success" %} Activation is the process of synchronizing a segment’s or a model's data to a predefined destination. {% endhint %} 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.
### **Run types and Sync modes** Sync modes define how data is applied from a source to a destination during an activation.\ They determine whether records are created, updated, deleted, or simply exported, depending on the selected mode and destination capabilities. In addition to sync modes, activations also rely on run types. Run types define how much data is processed during each execution * **Full**: A Full Sync processes the entire dataset from the source. It is automatically used for the first activation run and can also be triggered manually when needed. * **Delta**: A Delta Sync processes only data that has changed since the previous run. This is the default behavior for recurring activations and allows for faster, incremental synchronization. Each activation runs with exactly one sync mode, but a destination can support different sync modes and run types. * **UPSERT:** *Upsert* creates new records and updates existing ones. Records that no longer exist in the source are not removed from the destination. This is the default and most commonly used sync mode.
* **UPDATE ONLY**: *Update only* updates records that already exist in the destination. New records are ignored and never created. This mode is typically used to enrich or refresh existing data without the risk of adding new records.
* **INSERT ONLY**: *Insert only* creates new records only. Existing records in the destination are left unchanged. This mode is suited for append-only use cases or scenarios where existing data must not be overwritten.
* **DELETE ONLY**: *Delete only* removes records from the destination. No records are created or updated. This mode is used when an activation is dedicated exclusively to data deletion.
* **MIRROR**: *Mirror* keeps the destination strictly aligned with the source. New records are created, existing records are updated, and records missing from the source are deleted. As a result, the destination becomes an exact replica of the source dataset.
* **SNAPSHOT** *(File-based destinations only)*: *Snapshot* generates a complete export of the dataset at a given point in time. Each run produces a full file containing all records. This mode is commonly used for full file exports, backups, or systems that require full dataset refreshes. * **DIFF** *(File-based destinations only)*: *Diff* exports only the changes since the previous sync.\ Added, updated, and removed records are exported separately. This mode enables downstream systems to process each type of change independently. ## Destinations
{% hint style="success" %} 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. {% endhint %} 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. {% hint style="success" %} A **destination** refers to a specific target configuration of data synchronization within a platform. {% endhint %} **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. {% hint style="info" %} For guidance on connecting your designated destination, consult the corresponding section [Connect a Destination](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) As each destination has unique requirements, refer to the [Destinations](#destinations) documentation for guidance. {% endhint %} ### 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 {% hint style="success" %} Default activation settings simplify the activation configuration process by allowing you to set it up just once, eliminating the need for repetitive configuration. {% endhint %} **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. ## Tags Tags are reusable labels that help you organize and find DinMo objects across your workspace. They work like folders without moving an object or limiting how it can be used. Use tags to group objects by business domain, team, use case, owner, lifecycle stage, or environment. For example: `Marketing`, `CRM`, `Loyalty`, `Production`, or `Testing`. Tags make it easier to browse and filter objects as your workspace grows. They do not change an object's configuration, data, or behavior. Tags are available on models, segments, and computed fields. If you have access to Workspace Settings, see [Manage tags](/workspace-management/tags) to review where tags are used, edit their names, or delete tags that are no longer needed. ## Templates Templates let you save a reusable configuration and use it as a starting point for creating new DinMo objects. They help teams standardize recurring workflows and avoid rebuilding the same configuration from scratch. Templates are designed to support multiple types of DinMo objects. Segment templates are currently available; support for additional object types can be added over time. To learn how to create, manage, and reuse a segment template, see [Segment Templates](/segments/templates). *** ### Ready to get started? Book a demo and we will walk through the best way to launch your first DinMo use case. [Book a demo](https://www.dinmo.com/contact/) ### Need help? Our team is here to help with setup, modeling, activation, and troubleshooting. [Contact us](mailto:hello@dinmo.com?subject=Docs%20help) ### Feature requests? Tell us which connector, workflow, or improvement would make DinMo more useful for your team. [Request a feature](mailto:hello@dinmo.com?subject=Feature%20request) [Privacy Policy](https://www.dinmo.com/legals/privacy/) | [Terms of Service](https://www.dinmo.com/terms-of-service/) # Get started with DinMo Learn how to put your data in motion using DinMo In this section, we will guide you through the step-by-step process of going from first log-in to activating your first-party data and seamlessly transferring it to your preferred destination platforms. {% hint style="success" %} ## **Getting Started** Read the following pages to get started with our [Composable CDP](https://www.dinmo.com/cdp/composable-cdp/): 1. [Initial Configuration of DinMo](/guides/get-started-with-dinmo/initial-configuration-of-dinmo) 2. [Create and Activate Segments on DinMo](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo) thanks to our [Reverse ETL](https://www.dinmo.com/reverse-etl/) engine {% endhint %} {% hint style="info" %} ## **Learn the Main Concepts** We invite you to read the [Core Concepts](/core-concepts) section to help you navigate better with the main concepts we use at DinMo. {% endhint %} *** ## Ready to get started? Book a demo and we will walk through the best way to launch your first DinMo use case. [Book a demo](https://www.dinmo.com/contact/) ## Need help? Our team is here to help with setup, modeling, activation, and troubleshooting. [Contact us](mailto:hello@dinmo.com?subject=Docs%20help) ## Feature requests? Tell us which connector, workflow, or improvement would make DinMo more useful for your team. [Request a feature](mailto:hello@dinmo.com?subject=Feature%20request) [Privacy Policy](https://www.dinmo.com/legals/privacy/) | [Terms of Service](https://www.dinmo.com/terms-of-service/) # Initial Configuration of DinMo All necessary technical operations are concentrated in the initial configuration phase, which takes less than one hour. Following this phase, non-technical users can use DinMo autonomously. {% hint style="success" %} Here is a step-by-step tutorial explaining how DinMo should be configured: 1. [Connect a Source](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/connect-a-source) 2. [Create your Data Model](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-your-models) 3. [Create a Destination](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## **Need Help?** We are here to help you with any of your needs. [Send us a message](mailto:support@dinmo.io) and one of our product specialists will get back to you. # Connect a Source The first step in your DinMo journey is to connect to a source of data, enabling DinMo to access and manipulate it. ## Case 1: You already have a data warehouse To add a new source to your DinMo workspace, follow this setup sequence: * First, navigate to the Settings section. This section is only available for Admin users, make sure you have the right role. * Then, click on *Sources*.
* Click "Add a new source" * Choose the target data warehouse you wish to establish a connection with.
* Then, please follow the step-by-step instructions specific to the chosen DataWarehouse, as the connection steps will depend on it. You will find these tutorials in the [Data Sources section](/integrations/data-sources). {% hint style="info" %} DinMo will **never** store data located on your source. Furthermore, every computation made by DinMo will be processed in your data warehouse. {% endhint %} ## Case 2: You have subscribed to DinMo Hosting To add activate DinMo Hosting, follow this setup sequence: * First, navigate to the Settings section. This section is only available for Admin users, make sure you have the right role. * Then, click on *Databases*.
* Click "Add a new Database" * Select the data warehouse provider where you want to host the data and follow the technical documentation displayed. # Create your Models Once DinMo is connected to a source, creating a Data Model teaches DinMo the business context to the tables stored in the data warehouse. 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. Models can be: * Segmented using our no-code segment builder * Activated, meaning, synchronized to destination platforms {% hint style="info" %} For e-commerce, typical data model includes the following models: * Customers (related to the Orders Entity) * Orders (related to the Customers and Order Lines Entities) * Order Lines (related to the Orders and Products Entities) * Products (related to the Order Lines Entities) Additional models (for instance, web events) are sometimes added if data is available on the source. {% endhint %} * **Step 1:** To create your models, go to the Models section in the navigation bar.
Then, for every model of interest, do the following steps: * **Step 2:** Click "New Model" in the upper right.
* **Step 3:** Specify whether the model you wish to create contains Users, Events or other types of information (Custom). For Users models, one row should correspond to one person.\ \ For Events models, one row should correspond to one temporal event (for instance, a conversion).\ \ For Custom models, one row can represent anything.
* **Step 4:** Define your model.
You can then either do it by writing an SQL query, or by picking an existing table in your source.
* **Step 5:** In the second step of the creation flow, define the model's schema:
\ Only the ticked columns will be available in your final model. We recommend only ticking the columns you intend to use on DinMo, in order to limit the number of fields displayed.\ \ You may rename the model fields, and define some as categorical\ \ \&#xNAN;*Categorical fields are properties which have a limited number of distinct values, for instance, the Product Type, or the Country. By defining a property as categorical, it will be displayed in a much more intuitive manner when creating filters using this property:*
* **Step 6**: Fill in the required information in the Configure page:
Give your model a display name, and optionally, a description. \ Specify which field of the model corresponds to the primary key (called event id for Events models, and user id for Users models). This corresponds to the field uniquely identifying each element of the model. {% hint style="warning" %} 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](/models/primary-keys). {% endhint %} For user models only, you may optionally add additional mappings to teach DinMo the meaning of specific fields (for instance, the email address). Finally, you may map relationships between this model and other existing models. You will need to specify for both model which field should be used as the matching key, and what type of relation it corresponds to: "HAS ONE", "BELONGS TO" or "HAS MANY". For instance, a customer has many orders, and an order belongs to a customer.
# Create a Destination Before being able to send data to a destination platform, it should first be connected to DinMo. To set up a new destination, follow these steps: 1. Navigate to the Destinations section
2. Click on "New destination" in the upper right
3. Select the platform you want to send data to. You can use an existing platform connection if you already created a destination for a given platform connection.\ \ Otherwise, if you cannot find the platform you seek, click "Connect a new platform".\
4. If you clicked on "Connect a new platform", choose your target platform under the "Available platforms to connect" section.\ \ Click on "Connect a new platform" next to your target platform. This will open a side panel in which you will be able to connect to the platform.
5. Once your platform is selected, click on Continue in the lower right part of the screen.
6. As a final step, specify the destination service, indicating the use case you wish to implement in the chosen platform. Some destinations will ask for additional parameters after selecting the chosen destination option.\
7. Once you are done, hit "Save" in the lower right. Your destination is now created!
8. **Only for some destinations:** Some destinations support default activation settings. We highly recommend setting them up to enable all workspace's users to activate data to this destination in just one click, without the need to configure anything.
If you require the precise step-by-step instructions for a specific destination, please read the [Destinations section](/integrations/destination-platforms). Congrats, you’ve added your first Destination! {% hint style="info" %} ## You cannot find your destination platform? [Send us a message](mailto:support@dinmo.io) and we will develop the connector for you! {% endhint %} # Create and Activate Segments on DinMo Once the initial setup is done, non-technical users can benefit from DinMo's no-code experience to efficiently segment and sync data to destination platforms {% hint style="success" %} Here is a step-by-step tutorial explaining how to create a segment and sync it to a destination platform: 1. [Create your first segment](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) 2. [Activate your first segment](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ## **Need Help?** We are here to help you with any of your needs. [Send us a message](mailto:support@dinmo.io) and one of our product specialists will get back to you. # Create your first Segment A segment is a sub part of a model, which can be activated to destination platforms. On DinMo, you need to create a segment in order to sync data to a destination platform. To create a new segment, follow this setup sequence: 1. First, navigate to the Segment page and click on **“New segment”** on the upper right
2. Select the segment type you wish to create. It can either be a user segment, an event segment, or a custom segment. 3. Select your parent model of the segment, then put as many filters as you wish to create the target segment. Refer to [this page](/segments/visual-builder) for more information on the visual builder features.\
4. Preview the data, and hit Continue if you are satisfied with your segment.
5. Name your segment, add a short description to simplify the navigation.\
6. Hit "Create". Congrats, you’ve created your first segment! You are now ready to sync it to your preferred destination platforms. # Activate your first Segment The last step is to activate your segment, meaning, to create a data pipeline to a destination platform Here are the steps involved in the activation of the segment (via [Reverse ETL](https://www.dinmo.com/reverse-etl/) process) you created in the last section: 1. Go to the "Segment" section of the app, and click on your segment\
2. On the upper right, click on "Activate".
3. Tick the activation targets to which you want your segment to be sent. If you tick multiple activation targets, your segment will be sent to all of chosen platforms at once. The sync configuration will be the one defined by default in the activation target. If you wish to change it, click on "Advanced".\ \ If no Activation Target is shown, it means that no activation target has been configured for the parent entity of the selected segment. In that case, or if no appropriate activation target is shown, [create a new destination](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination). You cannot activate a segment without an activation target.\
4. Hit "Activate". Congratulations, you just created your first sync! You will soon be able to visualize your segment on your destination platform. Note that for some platforms, it is required to wait 24 to 48h before the sync is complete on their side. {% hint style="info" %} ## Need help with Syncs? Read the [Destinations section](/integrations/destination-platforms) of our docs to get a step-by-step tutorial on how to create a sync for each supported destination. {% endhint %} # Workspaces & Organizations DinMo users are grouped into workspaces and organizations. We explore the meanings of each notion in this page. ## Organizations {% hint style="info" %} An organization is a higher-level entity that represents a company, group, or institution using DinMo. It enables companies to centralize billing for all their workspaces in just on end point, but also to manage administrative and security policies that should be applied everywhere. {% endhint %} A user can be a member of several workspaces belonging to different organizations. A user can be assigned the Organization Admin role in the "Manage Workspaces" tab. This role enables a user to: * Create workspaces in this organization * Manage users of this organization * Set up security policies for all workspaces belonging to the organization ### Creating a new organization An organization is automatically created during the first sign-up of a user, as long as the following rules are respected: * The signed-up email address domain is not already assigned to another organization * The signed-up email address is a professional email address It is not allowed to create a new organization outside of the sign-up workflow in the app. If you intend to do so, please contact our support team. ## Workspaces {% hint style="info" %} A workspace is an instance of the platform that is typically granted access to a team or a business unit inside a company. Each workspace possesses its own data sources, destinations, segments, activations, etc. {% endhint %} A workspace belongs to a parent organization (see below). ### Creating a new workspace *Important: To create a new workspace inside an organization, the user must be granted the "Organization Admin" role.* 1. The user can then create a new workspace by clicking on "Manage Workspaces" in the navigation bar.
2. In the dropdown, select the parent organization of the workspace you are about to create.
3. Then, click "New Workspace".\
4. As a final step, give a name to your workspace.
You might then want to refer to the [Get started with DinMo](/guides/get-started-with-dinmo) guide to learn how to start your DinMo journey from this new workspace. {% hint style="info" %} For more details on workspace setup and management, refer to [Managing Users, Roles & Permissions](/workspace-management/managing-users-roles-and-permissions). {% endhint %} ### Managing workspace members Users can be granted two different roles in a workspace: * **Admin role:** An admin has full access on the workspace and can do anything.
* **Member role:** A member can create segments, entities, activations, destinations, but cannot access the workspace settings. He is not allowed to invite new users and manage existing users, nor is he allowed to create or edit a source. Member management is located in the settings of a workspace, in the Member section:
{% hint style="info" %} For more information on workspace set-up and user management, please refer to [this dedicated section](/workspace-management/managing-users-roles-and-permissions). {% endhint %} # Need Help? If you need help with anything, you can always contact us by mail at ** or in-app via the live chat in the bottom right corner.
# Data 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 data warehouses.
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 activation target. * `dinmo_predictions`: : For workspaces with the predictions module enabled, this table stores the output generated by the predictions models. You can add as many sources as you want on your workspace. {% hint style="info" %} DinMo will never store data located on your source. Furthermore, every computation will be processed on your DataWarehouse only. {% endhint %} ## Source configuration {% hint style="info" %} If you already have a data warehouse, you can follow the guides below to connect your data source. Otherwise, consult the DinMo Storage documentation. {% endhint %} ### Step-by-step guides You will find below the step-by-step instructions to connect a source to DinMo, specific to each DataWarehouse provider: * [Google BigQuery](/integrations/data-sources/google-bigquery) * [Snowflake](/integrations/data-sources/snowflake) * [Amazon Redshift](/integrations/data-sources/aws-redshift) * [PostgreSQL](/integrations/data-sources/postgresql) * [Databricks](/integrations/data-sources/databricks) * [Microsoft Fabric](/integrations/data-sources/microsoft-fabric) * [ClickHouse](/integrations/data-sources/clickhouse) Note that only **Admin** users can create and manage sources. ### Advanced settings For all the sources listed above, it is possible to set an advanced setting, in particular to choose the time of day when DinMo performs analytical tasks. All you have to do is click on your source (available in your workspace settings) and go to advanced settings. The schedule can be modified to suit your needs. {% hint style="info" %} Only workspace admins can do this operation. {% endhint %}
*** ## Ready to get started? Book a demo and we will walk through the best way to launch your first DinMo use case. [Book a demo](https://www.dinmo.com/contact/) ## Need help? Our team is here to help with setup, modeling, activation, and troubleshooting. [Contact us](mailto:hello@dinmo.com?subject=Docs%20help) ## Feature requests? Tell us which connector, workflow, or improvement would make DinMo more useful for your team. [Request a feature](mailto:hello@dinmo.com?subject=Feature%20request) [Privacy Policy](https://www.dinmo.com/legals/privacy/) | [Terms of Service](https://www.dinmo.com/terms-of-service/) # AWS Redshift Connecting DinMo to Amazon Redshift Amazon Redshift can be used as a DinMo source for models, segments, activations, analytics, and AI attributes. DinMo supports several Redshift setup patterns: | Area | Supported options | | -------------------- | ---------------------------------------------------------------------------------- | | Authentication | Password authentication or IAM authentication | | Network connectivity | Direct connection, SSH tunnel, or AWS Systems Manager Session Manager (SSM) tunnel | | Redshift deployment | Provisioned clusters and Redshift Serverless | IAM authentication and SSM tunneling can be used together. In that setup, DinMo reaches the private Redshift endpoint through SSM and uses temporary Redshift credentials obtained through AWS IAM, without storing a long-lived Redshift password. ## Prerequisites * Access to your Amazon Redshift cluster or Redshift Serverless workgroup with administrative privileges. * The ability to create users, schemas, and grant privileges in Redshift. * A DinMo workspace with access to workspace settings. * For IAM authentication: the ability to create an AWS IAM role and policy that DinMo can assume. * For SSM tunneling: an SSM-managed target, such as an EC2 instance or managed instance, that can reach the Redshift endpoint from inside your VPC. ## Step 1: Add Amazon Redshift as a source In your DinMo workspace: 1. Navigate to **Workspace Settings**. 2. Go to the **Sources** tab. 3. Click **Add New Source**. 4. Select **Amazon Redshift** from the list of available sources.
Amazon Redshift source selection in DinMo

Select Amazon Redshift from the source catalog.

## Step 2: Choose an authentication method Choose how DinMo should authenticate to Redshift. | Method | When to use it | Required in DinMo | | -------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | Password | You want to create a dedicated Redshift database user with a password. | Username and password | | IAM | You want DinMo to use AWS IAM and temporary Redshift credentials instead of a long-lived database password. | Username, AWS region, cluster ID, and AWS role ARN | If you use IAM authentication, create the Redshift user without a password: ```sql CREATE USER DINMO_USER WITH PASSWORD DISABLE; ``` If you use password authentication, create the Redshift user with a strong password: ```sql CREATE USER DINMO_USER WITH PASSWORD ''; ``` ## Step 3: Create DinMo schemas and grant access DinMo needs write access to technical schemas used to run activations, store delta snapshots, compute statistics, and manage identity outputs. The `dinmo_identity` schema is used to store [Identity Resolution](/identity-resolution/overview) outputs. Run the following SQL commands in your Redshift database: ```sql -- Create schemas used by DinMo CREATE SCHEMA IF NOT EXISTS dinmo_delta_storage; CREATE SCHEMA IF NOT EXISTS dinmo_segments; CREATE SCHEMA IF NOT EXISTS dinmo_stats; CREATE SCHEMA IF NOT EXISTS dinmo_predictions; CREATE SCHEMA IF NOT EXISTS dinmo_identity; -- Grant the DinMo user access to these schemas GRANT CREATE, USAGE ON SCHEMA dinmo_delta_storage TO DINMO_USER; GRANT CREATE, USAGE ON SCHEMA dinmo_segments TO DINMO_USER; GRANT CREATE, USAGE ON SCHEMA dinmo_stats TO DINMO_USER; GRANT CREATE, USAGE ON SCHEMA dinmo_predictions TO DINMO_USER; GRANT CREATE, USAGE ON SCHEMA dinmo_identity TO DINMO_USER; ``` Then grant DinMo read access to each schema that contains data you want to use in DinMo: ```sql -- Replace with the schema where your source tables and views are stored GRANT USAGE ON SCHEMA "" TO DINMO_USER; GRANT SELECT ON ALL TABLES IN SCHEMA "" TO DINMO_USER; ALTER DEFAULT PRIVILEGES IN SCHEMA "" GRANT SELECT ON TABLES TO DINMO_USER; GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA "" TO DINMO_USER; ALTER DEFAULT PRIVILEGES IN SCHEMA "" GRANT EXECUTE ON FUNCTIONS TO DINMO_USER; ``` Repeat these grants for each schema that DinMo should be able to query. ## Step 4: Configure the Redshift source in DinMo Back in DinMo, fill in the connection details: * **Host**: the Redshift endpoint, without the port or database name. * **Database**: the Redshift database name. * **Port**: the Redshift port. The default is `5439`. * **Username**: the Redshift user created for DinMo, for example `DINMO_USER`. * **Source name**: the display name used in DinMo. For Redshift Serverless, enable the serverless option and provide the workgroup name. ### Password authentication For password authentication, enter the password created for `DINMO_USER`. ### IAM authentication For IAM authentication, provide: * **AWS Region**: the AWS region where the Redshift cluster runs. * **Cluster ID**: the Redshift cluster identifier. * **AWS Role ARN**: the IAM role DinMo will assume in your AWS account. DinMo uses the role to request temporary Redshift credentials through AWS. The DinMo interface provides the AWS role and policy commands to apply in your account, including the required Redshift `GetClusterCredentials` permission. ## Step 5: Choose the network connection type Choose how DinMo should reach your Redshift endpoint. | Connection type | Description | Main requirements | | ----------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Direct connection | DinMo connects directly to the Redshift endpoint. | The endpoint must be reachable from DinMo, usually with IP allowlisting. | | SSH tunnel | DinMo connects through a bastion host using SSH port forwarding. | A public SSH bastion that can reach Redshift, an SSH username, and the generated DinMo public key. | | SSM tunnel | DinMo connects through AWS Systems Manager Session Manager port forwarding. | An SSM-managed target that can reach Redshift, its AWS region, and an AWS role ARN DinMo can assume. | {% hint style="success" %} Tunneling lets DinMo reach a Redshift endpoint in a private network or VPC without exposing the Redshift database directly to the public internet. {% endhint %} ### SSH tunnel If you choose **SSH tunnel**, enter: * The SSH bastion hostname or IP address. * The SSH bastion port. * The SSH username. * The generated DinMo SSH public key in the user's `~/.ssh/authorized_keys` file on the bastion. ### SSM tunnel If you choose **SSM tunnel**, enter: * **SSM managed target ID**: the target used for port forwarding, such as an `i-*` EC2 instance ID or `mi-*` managed instance ID. * **SSM target AWS Region**: the AWS region where the SSM-managed target runs. * **SSM AWS Role ARN**: the IAM role DinMo will assume to start the SSM session. The SSM-managed target must be able to reach the Redshift host and port from inside your AWS network. DinMo uses AWS Session Manager port forwarding; no public SSH endpoint or SSH key is required for this connection type. When SSM tunneling is enabled, DinMo provides AWS role and policy commands in the source setup flow. These include the required `ssm:StartSession`, `ssm:ResumeSession`, and `ssm:TerminateSession` permissions for the selected target. Click **Save & Test** to verify the connection. If the test succeeds, your Redshift source is connected to DinMo.
Amazon Redshift source configuration form in DinMo

Configure the Redshift connection and test it before saving.

## Handling privilege issues when using dbt ### Understanding the issue When dbt or similar transformation tools run, tables are often dropped and recreated. This can remove privileges for `DINMO_USER` because: * Default privileges in Redshift are user-specific. They only apply to objects created by the user who set them. * Tables recreated by dbt may not inherit privileges set by another user. ### Solution overview To ensure `DINMO_USER` keeps access to newly created tables, you can: 1. Set default privileges for the dbt user. 2. Use dbt grants to apply privileges after each model run. ### Solution 1: Set default privileges for the dbt user Identify the dbt user and the schema where dbt creates tables, then run: ```sql -- Replace with your schema -- Replace dbt_user with the user that creates or recreates dbt models ALTER DEFAULT PRIVILEGES FOR USER dbt_user IN SCHEMA GRANT SELECT ON TABLES TO DINMO_USER; ``` Grant access to existing tables as well: ```sql GRANT SELECT ON ALL TABLES IN SCHEMA TO DINMO_USER; ``` The `ALTER DEFAULT PRIVILEGES` command must be run by the dbt user or by a superuser. If several users create tables, repeat the command for each user. ### Solution 2: Use dbt grants You can configure dbt to grant access to `DINMO_USER` after models are created or refreshed. In your `dbt_project.yml` file: ```yaml models: your_project_name: +grants: select: ['DINMO_USER'] ``` For a specific schema or folder: ```yaml models: your_project_name: your_schema_name: +grants: select: ['DINMO_USER'] ``` This makes permission updates part of your dbt workflow and avoids losing access when tables are recreated. ## Troubleshooting * **Connection test fails**: verify the host, port, database, username, authentication method, and network connection type. * **IAM authentication fails**: verify the AWS region, cluster ID, role ARN, trust policy, external ID, and `redshift:GetClusterCredentials` permission. * **SSM tunnel fails**: verify the SSM target ID, SSM target region, IAM role, Session Manager permissions, and network access from the SSM target to the Redshift endpoint. * **Privilege errors**: ensure `DINMO_USER` has `USAGE` and `SELECT` privileges on the required schemas and tables. * **Access issues with recreated tables**: confirm default privileges or dbt grants are configured for the user that creates the tables. ## Support If you need help connecting Redshift to DinMo, contact your account manager or . # Databricks This guide provides detailed instructions for integrating Databricks with DinMo Databricks is a widely-used platform for data engineering, data science, and analytics, built around Apache Spark and SQL. This guide provides detailed instructions for integrating Databricks with DinMo, covering setup, required permissions, and troubleshooting. It is designed to help you set up a secure and efficient connection between Databricks and DinMo, similar to our Redshift integration. ## Prerequisites Before starting the integration, ensure you have: * Access to a Databricks workspace (AWS, Azure, or GCP). * Permissions to create users, schemas, and assign privileges in Databricks. * A DinMo workspace with access to add new data sources. {% hint style="info" %} Use DinMo’s fixed IPs when network security policies in you organization require specific IP allowlisting, such as firewall or VPC configurations. See our [Networking](/security-and-privacy/networking) section for more guidance and find the IPs DinMo use to connect to your systems. {% endhint %} ## Connecting Databricks to DinMo ### **Step 1: Create Connection Credentials for DinMo** To enable DinMo to connect securely to your Databricks workspace, you'll need to generate a Personal Access Token and gather specific connection details. Follow these steps to set up the necessary credentials: 1. **Access Your Databricks Workspace** * Log in to your Databricks **Account Console**. * Navigate to the **Workspaces** page. * Select the workspace that DinMo will connect to. * Click **Open workspace** to enter the selected workspace. 2. **Generate a Personal Access Token** * In the workspace, click on your profile icon in the top-right corner and select **Settings**. * From the left-hand menu, choose **Developer** (or **Access Tokens**). * Click on **Generate New Token**. * Provide a name for the token, such as "DinMo Integration". * For the **Lifetime**, you can leave it blank to prevent the token from expiring. * Click **Generate** and securely save the token value; you'll need it later for DinMo's configuration.
#### Step 2: Create DinMo Schemas in Databricks Before proceeding with DinMo's configuration, you need to set up specific schemas and grant the necessary permissions in your Databricks workspace. This setup allows DinMo to store technical data and access the tables and views required for its operations. **Permissions Required** DinMo requires two types of permissions: 1. **Data Tables and Views**: For the tables and views you want to use in DinMo (which can reside in any catalog), grant the following permissions to the DinMo user: * `SELECT` * `MODIFY` 2. **DinMo Technical Schemas**: For DinMo's dedicated schemas (`dinmo_segments`, `dinmo_stats`, `dinmo_delta_storage`, and `dinmo_predictions`), grant **ALL PRIVILEGES** to the DinMo user. **Creating Schemas and Granting Permissions** *Optional – Specify a Catalog:* You may choose to include a Databricks catalog, which is the top level in Unity Catalog's three-tier namespace (`catalog.schema.table`). If you specify a catalog, DinMo's technical schemas will be created within that catalog. If left unspecified, the schemas will be created in the default catalog. You can still access data from other catalogs for model creation by referencing the full path in DinMo's SQL interface.
**Steps:** 1. **Create DinMo Technical Schemas** Run the following SQL commands in your Databricks workspace to create the necessary schemas: ```sql -- Create schemas for DinMo's technical data CREATE SCHEMA IF NOT EXISTS [catalog_name].dinmo_delta_storage; CREATE SCHEMA IF NOT EXISTS [catalog_name].dinmo_segments; CREATE SCHEMA IF NOT EXISTS [catalog_name].dinmo_stats; -- If you're using DinMo's predictions module CREATE SCHEMA IF NOT EXISTS [catalog_name].dinmo_predictions; ``` *Note:* Replace `[catalog_name]` with your actual catalog name if you're using a specific catalog. Omit `[catalog_name]` if using the default catalog. 2. **Grant Permissions to DinMo User** Grant the necessary privileges to the DinMo user by executing the following commands: ```sql -- Grant full privileges on the technical schemas to the DinMo user -- Replace `dinmo_user@yourdomain.com` with the email of the Databricks account that created the API key. GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_delta_storage TO `dinmo_user@yourdomain.com`; GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_segments TO `dinmo_user@yourdomain.com`; GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_stats TO `dinmo_user@yourdomain.com`; -- If using DinMo's predictions module GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_predictions TO `dinmo_user@yourdomain.com`; ``` *** **Why Create Dedicated Schemas?** {% hint style="success" %} **Why Create Dedicated Schemas?** DinMo uses dedicated schemas to manage its technical data, including segment queries, activation snapshots, and statistical information. Organizing this data in separate schemas enhances: * **Organization:** Keeps technical data isolated from your business data. * **Security:** Allows for precise access control and auditing. * **Performance Management:** Improves query performance by optimizing how data is stored and accessed. {% endhint %} #### Step 3: Add Databricks as a Source in DinMo
1. **Navigate to Workspace Settings**: * In your DinMo workspace, go to **Workspace Settings**. 2. **Add New Source**: * Click on the **Sources** tab. * Select **Add New Source**. 3. **Choose Databricks**: * From the list of available sources, select **Databricks**. 4. **Collect Connection Details within your Databricks account** * Within the workspace, go to the **Compute** section from the left-hand menu. * Decide whether DinMo will connect to a **SQL Warehouse** or an **All-Purpose Cluster**: * **For SQL Warehouses**: * Select the desired SQL Warehouse. * Navigate to the **Connection Details** tab
* **For All-Purpose Clusters**: * Select the cluster you intend to use. * Go to the **Configuration** tab. * Scroll down and expand **Advanced Options**. * Click on the **JDBC /ODBC** tab.
* Gather the following details: * **Server Hostname**: The URL of your Databricks workspace. * Example: `adb-1234567890123456.7.azuredatabricks.net`. * Found in the workspace URL or under **Compute** > **SQL Warehouses** > **Connection Details**. * **HTTP Path**: The HTTP Path to your SQL Warehouse or cluster. * Found under **Compute** > **SQL Warehouses** or **Clusters** > **Connection Details**. * **Port**: Typically `443` for HTTPS connections. * **Access Token**: Personal access token created in Step 1 * **Schema**: The default schema that DinMo will use to connect to your Databricks * (Optional) **Catalog**: If DinMo technical schemas in Step 2 were created in a specific catalog, this field should match that catalog. If left empty, it defaults to the workspace’s default catalog.
5. **Finish Databricks configuration within DinMo** * **Fill in the connection form** with the with the collected credentials * **Test and Save**: * Click **Save & Test** to verify the connection. * If successful, the Databricks source is now connected to DinMo. {% hint style="success" %} Before allowing to create a new source DinMo will check: * Network connectivity * Databricks credentials * Permission to list schemas and tables (at least in the initial schema) * Permission to write to DinMo's dedicated schemas `dinmo_segments`, `dinmo_stats`, `dinmo_delta_storage` and `dinmo_predictions` {% endhint %} **Additional Recommendations** * **Dedicated User Account**: Consider creating a specific user account for DinMo. This practice enhances security by allowing better auditing and access control. * **Permissions**: Ensure that the account or token used has the necessary permissions to access the compute resources and data required by DinMo. * **Security Note**: Always store your access tokens and credentials securely. Do not share them publicly or commit them to version control systems. By completing these steps, DinMo will be able to connect to your Databricks workspace securely, allowing for seamless integration and data operations. ### **Troubleshooting Common Issues** When integrating DinMo with Databricks, you might encounter some common issues. Below are some of the main problems and their solutions. 1. **Mismatch of Catalog Specification** * **Problem**: The catalog specified in DinMo's configuration doesn't match the catalog used when creating the technical schemas in **Step 2**. * **Solution**: Ensure that the catalog you enter during DinMo's configuration is the same one where you created the DinMo technical schemas in Step 2. If you left the catalog unspecified (i.e., you used the default catalog) when creating the schemas, then leave the catalog field blank in DinMo's configuration. This alignment is crucial for DinMo to locate and access the necessary schemas. 2. **Insufficient Permissions for DinMo User** * **Problem**: DinMo cannot access required tables or schemas due to inadequate permissions granted to the DinMo user. * **Solution**: Verify that the DinMo user has the necessary permissions: * **For Data Tables and Views**: Ensure `SELECT` permissions are granted on all tables and views you want to use in DinMo. ```sql GRANT SELECT ON TABLE [catalog_name].schema_name.table_name TO `dinmo_user@yourdomain.com`; ``` * **For DinMo Technical Schemas**: Ensure `ALL PRIVILEGES` are granted on the schemas created in Step 2. Also ensure that the email in the SQL script is the one linked to the Databricks account that created the API key. ```sql GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_delta_storage TO `dinmo_user@yourdomain.com`; GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_segments TO `dinmo_user@yourdomain.com`; GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_stats TO `dinmo_user@yourdomain.com`; -- If using DinMo's predictions module GRANT ALL PRIVILEGES ON SCHEMA [catalog_name].dinmo_predictions TO `dinmo_user@yourdomain.com`; ``` * **Action**: Re-run the permission-granting SQL commands if necessary, replacing placeholders with your actual catalog name and DinMo user email. 3. **Invalid or Expired Personal Access Token** * **Problem**: DinMo fails to connect to Databricks due to an invalid or expired Personal Access Token. * **Solution**: * **Generate a New Token**: * Go to your Databricks workspace and click on your profile icon in the top-right corner. * Select **Settings** and navigate to the **Access Tokens** section under **Developer** (or directly under **User Settings**). * Click on **Generate New Token**. * Provide a meaningful name (e.g., "DinMo Integration") and, if possible, set the token to never expire by leaving the lifetime field blank. * Click **Generate** and securely copy the new token. * **Update DinMo Configuration**: * Go to DinMo's configuration settings for the Databricks connection. * Replace the old token with the new one you just generated. * Save the configuration and attempt to reconnect. *** If you encounter an error or question not listed below and need assistance, don't hesitate to reach out to your account manager. We're here to help. # Google BigQuery Connecting DinMo to Google BigQuery: Step-by-Step Guide ## Overview The connection process involves generating a Google Cloud service account, and granting it with the following roles: * `BigQuery User` * `Data Viewer` DinMo will automatically create the following datasets to store its technical data: * `dinmo_segments`: storing views of the query of the segments and entities created within DinMo * `dinmo_stats`: storing tables that contain statistics about your segments * `dinmo_delta_storage`: storing 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_predictions`: storing AI attributes such as churn likelihood and expected lifetime value. These datasets should not be altered in your BigQuery project. ## Source setup details {% hint style="info" %} Learn how to create a source in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/connect-a-source) {% endhint %} In the connection process: * You will need to fill in the Google Cloud Project id. This information is displayed in the Google Cloud interface: ![Welcome page](https://storage.googleapis.com/dinmo-prod-static/img/bq-doc/welcome-page.png) Note that the Google Cloud project id might sometimes differ from the Google Cloud project name. * You should fill in the internal project id field only if you want DinMo to store its technical data in a separate project. If left blank, DinMo will be storing these data in the project mentioned above.
* The project region refers to where the tables are stored. DinMo only supports one region per BigQuery source, so please ensure you store your data in the same region.\ \ In case you decided to use two separate projects, please ensure that the location region remains the same for both projects.
* The source name is only used as a display name in DinMo.
* To generate a DinMo service account, simply click the corresponding button. Depending if you chose to store data in a separate project or not, it will generate two or four blocks of codes. Simply copy these blocks of code and run them in your BigQuery console, without changing their values.
* **Step 4:** Hit *Save & Test* in the bottom right of the page. If the tests do not encounter any issue, your source will be connected! **Note:** when testing the connection, the Google BigQuery project must contain a table, otherwise, an empty project will cause an error in the test. Here is the revised troubleshooting guide for BigQuery. It follows the exact structure of your Redshift documentation but is technically adapted for Google Cloud. It focuses on the core issue: Table recreation by dbt wipes out table-level permissions. ### Handling Privilege Issues when using dbt (BigQuery) #### Understanding the Issue When using dbt to transform data in BigQuery, models (tables and views) are frequently dropped and recreated as part of the transformation process. This results in a loss of privileges for the DinMo Service Account because: 1. Table Permissions are volatile: In BigQuery, if you grant access specifically on a table, that permission is attached to that specific object. 2. Recreation breaks the link: When dbt runs, it deletes the old table and creates a fresh one. The new table does not inherit the manual permissions granted on the previous version. Consequently, if the DinMo Service Account does not have permissions at the Dataset level, it loses access immediately after a dbt run. #### Solution Overview To ensure the DinMo Service Account retains access to newly created tables, you can: 1. Grant roles at the Dataset level (Recommended). This creates a "default privilege" where all current and future tables inherit access. 2. Use dbt’s built-in grants configuration to automatically re-grant the privilege every time the table is recreated. #### Solution 1. Granting Dataset-Level Privileges (Recommended) The most robust solution is to grant the BigQuery Data Viewer role to the DinMo Service Account on the entire Dataset. This ensures that even if dbt drops and recreates tables, the Service Account retains access via the parent Dataset. **Detailed Steps** 1\. Identify the Service Account and Target Dataset * Service Account: The email address of the DinMo Service Account (e.g., `dinmo-sa@your-project.iam.gserviceaccount.com`). * Dataset: The dataset where dbt creates your tables (e.g., `analytics_prod`). 2\. Grant the Role Run the following SQL command in the BigQuery console. This ensures all tables inside the dataset are accessible. ```cmd -- Replace 'your_project.your_dataset' with your actual project and dataset -- Replace the email with your actual DinMo Service Account email GRANT `roles/bigquery.dataViewer` ON SCHEMA `your_project.your_dataset` TO "serviceAccount:dinmo-sa@your-project.iam.gserviceaccount.com"; ``` Important Notes: * The `serviceAccount:` prefix is mandatory in BigQuery SQL when granting to a Service Account. * This method eliminates the need to configure permissions inside dbt. #### Solution 2. Using dbt's Built-in Grants Configuration If your security policies prevent you from granting Dataset-level access (forcing you to grant access table-by-table), you must configure dbt to automatically re-grant the role after every run. **Steps to Implement** Configure Grants in dbt In your `dbt_project.yml` file, add the following configuration. This tells dbt to issue a `GRANT` command immediately after creating the table. ```yml models: your_project_name: +grants: roles/bigquery.dataViewer: - 'serviceAccount:dinmo-sa@your-project.iam.gserviceaccount.com' ``` * Role: You must use the full IAM role string: `roles/bigquery.dataViewer`. * Principal: You must use the `serviceAccount:` prefix before the email address. Configure Grants for Specific Folders (Optional) If DinMo only needs access to a specific subset of data, you can apply the grant to a specific folder: ```yaml models: your_project_name: marketing_models: +grants: roles/bigquery.dataViewer: - 'serviceAccount:dinmo-sa@your-project.iam.gserviceaccount.com' ``` **How It Works** * dbt's `grants` Feature: dbt creates the table, then immediately runs a separate DCL statement to grant access to the Service Account. * Consistency: Because the grant is part of the dbt code, the permission is restored every time the table is recreated, preventing the "lost access" error. **Important Notes** * dbt Version: Ensure you are using dbt v1.0 or later. * Prefixes: Unlike Redshift, BigQuery requires the `serviceAccount:` prefix. If this is omitted in the dbt config, the grant will fail or be ignored. # PostgreSQL Connecting DinMo to PostgreSQL: Step-by-Step Guide Go to the workspace settings, then to the Source tab, and click "Add New Source". * **Step 1:** Select PostgreSQL from the list of available sources
* **Step 2:** Create a DinMo user on your DataWarehouse and the DinMo technical datasets.\ \ DinMo needs to read all the tables that you want to use to build models and segments. It also needs to write access to 3 schemas that will be used to store technical (segment queries, segment stats, activation snapshots).
We recommend you to create a specific user for DinMo and grant it the needed permissions. You can do so by running the following SQL snippet. ```sql -- Give the DinMo user the ability to sign in with a password CREATE USER DINMO_USER WITH PASSWORD ''; -- Create the schemas that DinMo will use to store technical data that enables to run your activations CREATE SCHEMA IF NOT EXISTS DINMO_DELTA_STORAGE; CREATE SCHEMA IF NOT EXISTS DINMO_SEGMENTS; CREATE SCHEMA IF NOT EXISTS DINMO_STATS; CREATE SCHEMA IF NOT EXISTS DINMO_PREDICTIONS; -- Grant the DinMo user full access to these schemas GRANT CREATE, USAGE ON SCHEMA DINMO_DELTA_STORAGE TO DINMO_USER; GRANT CREATE, USAGE ON SCHEMA DINMO_SEGMENTS TO DINMO_USER; GRANT CREATE, USAGE ON SCHEMA DINMO_STATS TO DINMO_USER; GRANT CREATE, USAGE ON SCHEMA DINMO_PREDICTIONS TO DINMO_USER; -- Let the DinMo user read and query the schemas that contain the data that you want to use in the DinMo Platform -- Replace with the name of the schema where you store the tables and views that will be used in the DinMo Platform -- Repeat this operation for all the schemas that store relevant data that you want to connect to DinMo GRANT USAGE ON SCHEMA "" TO DINMO_USER; GRANT SELECT ON ALL TABLES IN SCHEMA "" TO DINMO_USER; ALTER DEFAULT PRIVILEGES IN SCHEMA "" GRANT SELECT ON TABLES TO DINMO_USER; GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA "" TO DINMO_USER; ALTER DEFAULT PRIVILEGES IN SCHEMA "" GRANT EXECUTE ON FUNCTIONS TO DINMO_USER; ``` Please edit the `` fields in the script to define your own credentials and parameters.
* **Step 3:** Fill in the required information
* Host: The hostname or IP address of your cluster.
* Database: The name of the database in your cluster.
* Port: The port number of your cluster. The default is 5439, but yours may be different.
* User and password: The credentials you created in the script above.
* **Step 4:** Hit "Save & Test". This will launch a test ensuring that the connection is working. If so, congratulations, your source setup is finished! *** If you encounter an error or question not listed below and need assistance, don't hesitate to reach out to your account manager or . We're here to help! # Snowflake Connect Snowflake to DinMo with a dedicated service user, warehouse, and technical database. Use Snowflake as the warehouse foundation for DinMo. Once connected, DinMo can query governed customer data from Snowflake to power models, segments, Customer Hub, predictions, and Identity Resolution, while writing DinMo-generated technical tables back to a dedicated Snowflake database. ## Overview A Snowflake source has two responsibilities: * read the business data that DinMo users can model and activate * store DinMo technical outputs such as segment snapshots, statistics, predictions, and Identity Resolution tables This keeps customer data in Snowflake and makes DinMo activity easy to audit through Snowflake roles, warehouses, query history, and dedicated schemas. ## Recommended setup For new Snowflake sources, we recommend using: * a dedicated service user for DinMo * a dedicated Snowflake role with only the permissions DinMo needs * key pair authentication * a dedicated warehouse for DinMo workloads * a dedicated internal database such as `DINMO_DB` The role needs `USAGE` on the warehouse, `SELECT` access to the business schemas DinMo should read, and write access to DinMo's internal schemas. Password authentication should only be used for existing setups that have not migrated yet. {% hint style="info" %} Snowflake supports service users for non-human access and key pair authentication for programmatic connections. See the Snowflake documentation for [user types](https://docs.snowflake.com/en/sql-reference/sql/create-user) and [key pair authentication](https://docs.snowflake.com/en/user-guide/key-pair-auth). {% endhint %} ## Create a dedicated warehouse Create a warehouse for DinMo workloads so you can monitor credit usage, tune sizing, and avoid impacting other workloads. ```sql CREATE WAREHOUSE IF NOT EXISTS IDENTIFIER('DINMO_WAREHOUSE') WAREHOUSE_SIZE = XSMALL WAREHOUSE_TYPE = STANDARD AUTO_SUSPEND = 60 AUTO_RESUME = TRUE INITIALLY_SUSPENDED = TRUE; ``` You can start with `XSMALL` and increase the size if queries queue or previews become slow. ## Create the DinMo role, user, and internal database Run the script below from a Snowflake role that can create users, roles, warehouses, databases, schemas, and grants. Update the values between `< >` before running it. ```sql -- Edit these values before running the script. SET INPUT_ROLE = 'ACCOUNTADMIN'; SET DINMO_SERVICE_USER = 'DINMO_SERVICE_USER'; SET DINMO_ACCESS_ROLE_NAME = 'DINMO_ACCESS_ROLE'; SET DINMO_WAREHOUSE = 'DINMO_WAREHOUSE'; SET DATA_MODEL_DATABASE = ''; SET DEFAULT_NAMESPACE = ''; SET DINMO_INTERNAL_DATABASE = 'DINMO_DB'; USE ROLE IDENTIFIER($INPUT_ROLE); -- Create the role used by DinMo. CREATE ROLE IF NOT EXISTS IDENTIFIER($DINMO_ACCESS_ROLE_NAME); -- Give DinMo compute access. GRANT USAGE ON WAREHOUSE IDENTIFIER($DINMO_WAREHOUSE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); -- Give DinMo read access to the business data database. GRANT USAGE ON DATABASE IDENTIFIER($DATA_MODEL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT USAGE ON ALL SCHEMAS IN DATABASE IDENTIFIER($DATA_MODEL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT SELECT ON ALL TABLES IN DATABASE IDENTIFIER($DATA_MODEL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT SELECT ON ALL VIEWS IN DATABASE IDENTIFIER($DATA_MODEL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT USAGE ON FUTURE SCHEMAS IN DATABASE IDENTIFIER($DATA_MODEL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT SELECT ON FUTURE TABLES IN DATABASE IDENTIFIER($DATA_MODEL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT SELECT ON FUTURE VIEWS IN DATABASE IDENTIFIER($DATA_MODEL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); -- Create the internal database and schemas used by DinMo. CREATE DATABASE IF NOT EXISTS IDENTIFIER($DINMO_INTERNAL_DATABASE); USE DATABASE IDENTIFIER($DINMO_INTERNAL_DATABASE); CREATE SCHEMA IF NOT EXISTS DINMO_DELTA_STORAGE; CREATE SCHEMA IF NOT EXISTS DINMO_SEGMENTS; CREATE SCHEMA IF NOT EXISTS DINMO_STATS; CREATE SCHEMA IF NOT EXISTS DINMO_PREDICTIONS; CREATE SCHEMA IF NOT EXISTS DINMO_IDENTITY; -- Give DinMo write access only to its internal database and schemas. GRANT USAGE ON DATABASE IDENTIFIER($DINMO_INTERNAL_DATABASE) TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT ALL PRIVILEGES ON SCHEMA DINMO_DELTA_STORAGE TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT ALL PRIVILEGES ON SCHEMA DINMO_SEGMENTS TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT ALL PRIVILEGES ON SCHEMA DINMO_STATS TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT ALL PRIVILEGES ON SCHEMA DINMO_PREDICTIONS TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); GRANT ALL PRIVILEGES ON SCHEMA DINMO_IDENTITY TO ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME); -- Create the DinMo service user. CREATE USER IF NOT EXISTS IDENTIFIER($DINMO_SERVICE_USER) TYPE = SERVICE DEFAULT_ROLE = $DINMO_ACCESS_ROLE_NAME DEFAULT_WAREHOUSE = $DINMO_WAREHOUSE DEFAULT_NAMESPACE = $DEFAULT_NAMESPACE; GRANT ROLE IDENTIFIER($DINMO_ACCESS_ROLE_NAME) TO USER IDENTIFIER($DINMO_SERVICE_USER); ``` `DINMO_IDENTITY` is required when Identity Resolution is enabled. `DINMO_PREDICTIONS` is required when AI Predictions is enabled. The other internal schemas are used for segments, statistics, and snapshot storage. ## Restrict access to selected schemas The setup script above grants read access to every current and future schema in the business database. This is convenient for a first setup, but some security teams prefer schema-level grants. To restrict access, replace the business database grants with grants like these, and repeat them for each schema DinMo should read: ```sql GRANT USAGE ON DATABASE TO ROLE DINMO_ACCESS_ROLE; GRANT USAGE ON SCHEMA . TO ROLE DINMO_ACCESS_ROLE; GRANT SELECT ON ALL TABLES IN SCHEMA . TO ROLE DINMO_ACCESS_ROLE; GRANT SELECT ON ALL VIEWS IN SCHEMA . TO ROLE DINMO_ACCESS_ROLE; GRANT SELECT ON FUTURE TABLES IN SCHEMA . TO ROLE DINMO_ACCESS_ROLE; GRANT SELECT ON FUTURE VIEWS IN SCHEMA . TO ROLE DINMO_ACCESS_ROLE; ``` If dbt or another transformation tool drops and recreates tables, keep the `FUTURE` grants in place on every schema DinMo needs to read. ## Configure the source in DinMo 1. In DinMo, go to the workspace settings. 2. Open the **Sources** tab. 3. Click **Add New Source**. 4. Select **Snowflake**. 5. Fill in the Snowflake connection fields.
Snowflake source configuration form in DinMo

Configure the Snowflake source with the service user, role, warehouse, business database, and internal database.

Use the values from the script: * **Account identifier**: the account identifier from your Snowflake URL. See Snowflake's [account identifier documentation](https://docs.snowflake.com/en/user-guide/admin-account-identifier#finding-the-organization-and-account-name-for-an-account). * **Database**: the business database that contains the source data DinMo can read. * **Internal database**: the database where DinMo stores technical data. If you kept the script default, use `DINMO_DB`. * **Warehouse**: the warehouse DinMo should use. If you kept the script default, use `DINMO_WAREHOUSE`. * **Role**: the role assigned to the DinMo service user. If you kept the script default, use `DINMO_ACCESS_ROLE`. * **Username**: the DinMo service user. If you kept the script default, use `DINMO_SERVICE_USER`. * **Authentication method**: choose **Key Pair**. * **Source name**: the display name shown in DinMo. If your account URL is `https://xxx.europe-west2.gcp.snowflakecomputing.com/`, enter `xxx.europe-west2.gcp` as the account identifier. Do not include `https://` or `.snowflakecomputing.com`. ## Configure key pair authentication After choosing **Key Pair** in DinMo, click **Generate a Public Key** and run the generated SQL in Snowflake.
Generated Snowflake public key SQL in DinMo

Run the generated SQL in Snowflake to attach the public key to the DinMo service user.

The generated SQL updates the DinMo service user with the public key used for authentication. Do not modify the generated key value. If your security team generates the public key before the source is configured in DinMo, you can set it directly on the service user with `RSA_PUBLIC_KEY`. {% hint style="warning" %} Password authentication is not recommended for new Snowflake sources. Use it only for existing setups that have not migrated to key pair authentication yet. {% endhint %} ## Test the connection Click **Save & Test** in DinMo. If the test succeeds, the Snowflake source is ready to use. If the test fails, check the troubleshooting section below before changing the connection configuration. ## Troubleshooting **Connection test fails** Check that the account identifier, warehouse, database, role, username, and authentication method match the Snowflake objects created for DinMo. If you use key pair authentication, confirm that the public key generated by DinMo was assigned to `DINMO_SERVICE_USER`. **The user cannot assume the role** Confirm that the role was granted to the service user: ```sql GRANT ROLE DINMO_ACCESS_ROLE TO USER DINMO_SERVICE_USER; ``` **DinMo cannot see source tables** Confirm that `DINMO_ACCESS_ROLE` has `USAGE` on the relevant database and schemas, plus `SELECT` on current and future tables or views. If tables are recreated by dbt or another tool, verify the `FUTURE TABLES` and `FUTURE VIEWS` grants on each relevant schema. **DinMo cannot create technical tables or views** Confirm that the internal database and schemas exist and that `DINMO_ACCESS_ROLE` has write access to them: ```sql GRANT USAGE ON DATABASE DINMO_DB TO ROLE DINMO_ACCESS_ROLE; GRANT ALL PRIVILEGES ON SCHEMA DINMO_DB.DINMO_DELTA_STORAGE TO ROLE DINMO_ACCESS_ROLE; GRANT ALL PRIVILEGES ON SCHEMA DINMO_DB.DINMO_SEGMENTS TO ROLE DINMO_ACCESS_ROLE; GRANT ALL PRIVILEGES ON SCHEMA DINMO_DB.DINMO_STATS TO ROLE DINMO_ACCESS_ROLE; GRANT ALL PRIVILEGES ON SCHEMA DINMO_DB.DINMO_PREDICTIONS TO ROLE DINMO_ACCESS_ROLE; GRANT ALL PRIVILEGES ON SCHEMA DINMO_DB.DINMO_IDENTITY TO ROLE DINMO_ACCESS_ROLE; ``` **You use several databases** Create one DinMo source per Snowflake database, or make sure models use fully qualified table names such as `database.schema.table`. If you still encounter an issue, contact your account manager or . # Microsoft Fabric Connecting DinMo to Azure Fabric Warehouse: Step-by-Step Guide This guide provides detailed instructions for integrating Microsoft Fabric Warehouse with DinMo. Microsoft Fabric Warehouse is a SQL-based analytics engine within Microsoft Fabric. DinMo connects to Fabric Warehouse through its SQL endpoint using a dedicated Microsoft Entra service principal. This guide explains how to configure the connection, grant the required permissions, create DinMo’s technical schemas, and troubleshoot the most common issues. ## Prerequisites Before starting the integration, ensure you have: * Access to a Microsoft Fabric workspace containing a **Warehouse** item. * Permissions to manage access to the Fabric workspace and the Warehouse. * Permissions to create database users, schemas, and grant SQL permissions in the target Warehouse. * A DinMo workspace with access to add new data sources. > If your organization enforces network restrictions, make sure DinMo’s IPs are allowlisted. See our Networking section for more details. ## Connecting Microsoft Fabric to DinMo ### Step 1: Create a dedicated Service Principal for DinMo To enable DinMo to connect securely to your Microsoft Fabric Warehouse, create a dedicated Microsoft Entra application / service principal. 1. Log in to the **Microsoft Entra admin center**. 2. Go to **Identity > Applications > App registrations**. 3. Click **New registration**. 4. Choose a name such as `DinMo Fabric Integration`. 5. Select **Accounts in this organizational directory only**. 6. Click **Register**. 7. Save the following values: * **Application (client) ID** * **Directory (tenant) ID** Then create a credential for this application: 1. Go to **Certificates & secrets**. 2. Create a new **Client secret**. 3. Save the secret value securely. DinMo will use the following credentials to connect: * Tenant ID * Client ID * Client Secret > We recommend creating a dedicated service principal for DinMo rather than reusing an existing application identity. This makes auditing, rotation, and permission management much easier. ### Step 2: Enable Service Principal access in Microsoft Fabric By default, Microsoft Fabric may block service principal access depending on your tenant configuration. In Microsoft Fabric: 1. Open the **Admin portal**. 2. Go to **Tenant settings**. 3. Under **Developer settings**, enable: * **Service principals can use Fabric APIs** If your setup later relies on external storage access from Fabric (for example through `COPY INTO` or `OPENROWSET`), you may also need additional Fabric / OneLake settings depending on your environment. ### Step 3: Grant the Service Principal access to the Warehouse DinMo connects to the Fabric **Warehouse** (not to the Lakehouse SQL endpoint, for now). In Microsoft Fabric: 1. Open the workspace containing the target Warehouse. 2. Open the Warehouse permissions page. 3. Add the DinMo service principal. 4. Grant it at least the permission required to connect and read data through SQL. DinMo also requires SQL-level permissions inside the Warehouse itself. ### Step 4: Create DinMo technical schemas in Fabric Warehouse Before configuring the source in DinMo, create the schemas DinMo will use to store technical data. DinMo typically stores technical objects in dedicated schemas such as: * `dinmo_segments` * `dinmo_stats` * `dinmo_delta_storage` * `dinmo_predictions` * `dinmo_identity` (if the Identity Resolution module is enabled) Why create dedicated schemas? * **Organization**: DinMo’s technical objects stay isolated from your business tables. * **Security**: Access can be scoped precisely to DinMo-owned schemas. * **Operations**: Incremental sync state, materializations, and technical outputs remain easy to monitor and maintain. Run the following SQL commands in your Fabric Warehouse: ```sql IF NOT EXISTS (SELECT 1 FROM sys.schemas WHERE name = 'dinmo_segments') BEGIN EXEC('CREATE SCHEMA [dinmo_segments]'); END; IF NOT EXISTS (SELECT 1 FROM sys.schemas WHERE name = 'dinmo_stats') BEGIN EXEC('CREATE SCHEMA [dinmo_stats]'); END; IF NOT EXISTS (SELECT 1 FROM sys.schemas WHERE name = 'dinmo_delta_storage') BEGIN EXEC('CREATE SCHEMA [dinmo_delta_storage]'); END; IF NOT EXISTS (SELECT 1 FROM sys.schemas WHERE name = 'dinmo_predictions') BEGIN EXEC('CREATE SCHEMA [dinmo_predictions]'); END; IF NOT EXISTS (SELECT 1 FROM sys.schemas WHERE name = 'dinmo_identity') BEGIN EXEC('CREATE SCHEMA [dinmo_identity]'); END; ``` ### Step 5: Create a database user mapped to the Service Principal Create a database user for the DinMo service principal inside the Warehouse. > Replace `` with the display name of your Microsoft Entra application or service principal, according to your organization’s naming convention. ```sql CREATE USER [] FROM EXTERNAL PROVIDER; ``` If your Fabric environment does not allow this exact command pattern for service principals, your data team can create the corresponding user using the Entra object identifier and then grant permissions to that user. The end result must be a SQL user mapped to the DinMo service principal. ### Step 6: Grant permissions to DinMo DinMo requires two types of permissions: 1. **Read permissions** on the business schemas, tables, and views that will be used in DinMo 2. **Read and write permissions** on DinMo’s technical schemas **6.1 Grant read access to business schemas** Replace `` with the schema(s) containing the data you want to use in DinMo. ```sql GRANT SELECT ON SCHEMA::[] TO []; ``` If you prefer to scope access more tightly, you can grant `SELECT` only on specific tables and views instead of the full schema. Example: ```sql GRANT SELECT ON OBJECT::[dbo].[customers] TO []; GRANT SELECT ON OBJECT::[dbo].[orders] TO []; GRANT SELECT ON OBJECT::[dbo].[events] TO []; ``` **6.2 Grant control on DinMo technical schemas** DinMo needs to create and manage objects in its dedicated schemas. ```sql GRANT CONTROL ON SCHEMA::[dinmo_segments] TO []; GRANT CONTROL ON SCHEMA::[dinmo_stats] TO []; GRANT CONTROL ON SCHEMA::[dinmo_delta_storage] TO []; GRANT CONTROL ON SCHEMA::[dinmo_predictions] TO []; GRANT CONTROL ON SCHEMA::[dinmo_identity] TO []; ``` If some DinMo modules are not enabled in your workspace, you may omit the corresponding schemas. ### Step 7: Add Microsoft Fabric as a source in DinMo Once the Warehouse and permissions are ready, configure the source in DinMo. 1. In your DinMo workspace, go to **Workspace Settings**. 2. Open the **Sources** tab. 3. Click **Add New Source**. 4. Select **Microsoft Fabric**. * **Required connection details** Fill in the following fields: * **Host / Server**: the Fabric SQL endpoint hostname * **Port**: `1433` * **Database**: the exact name of the target Warehouse * **Tenant ID**: the Microsoft Entra tenant ID * **Client ID**: the service principal application ID * **Client Secret**: the secret generated earlier * **Source name**: the display name you want in DinMo > The **Database** field must match the Fabric Warehouse name exactly. This value is required for the SQL connection to succeed. Then click **Save & Test**. Before allowing the source to be created, DinMo will validate: * Network connectivity * Fabric credentials * Access to the target Warehouse * Permission to read business schemas and tables * Permission to write to DinMo’s technical schemas If the test succeeds, your Microsoft Fabric source is now connected to DinMo. ### Additional recommendations * **Use a dedicated Service Principal** for DinMo. * **Scope read access only to the schemas or tables needed** for DinMo use cases. * **Keep DinMo technical objects isolated** in dedicated schemas. * **Use a dedicated Warehouse** for DinMo if you want to isolate performance and administration. * **Rotate client secrets regularly** and update the DinMo connection before expiration. * **Document the Warehouse name explicitly** since Fabric requires it in the connection string. ## Troubleshooting common issues ### 1. Connection test fails **Problem:** DinMo cannot connect to Fabric. **Checks:** * Verify the SQL endpoint hostname * Verify the port is `1433` * Verify the Warehouse name is entered exactly in the **Database** field * Verify the Tenant ID, Client ID, and Client Secret * Verify the service principal has access to the Warehouse in Fabric ### 2. Service Principal authentication works but SQL access fails **Problem:** The service principal exists in Entra, but DinMo cannot query the Warehouse. **Solution:** * Ensure the service principal has been granted access to the Warehouse in Fabric * Ensure a corresponding SQL user exists in the Warehouse * Ensure SQL permissions were granted to that SQL user ### 3. Missing permissions on technical schemas **Problem:** DinMo connects successfully but cannot create tables, views, or technical objects. **Solution:** * Verify that `CONTROL` was granted on: * `dinmo_segments` * `dinmo_stats` * `dinmo_delta_storage` * `dinmo_predictions` * `dinmo_identity` if applicable ### 4. Missing permissions on business tables **Problem:** DinMo cannot preview or query the data model. **Solution:** * Grant `SELECT` on the required schemas, tables, and views * If your business data spans multiple schemas, repeat the grants for each relevant schema ### 5. Newly created Service Principal still fails on some Fabric operations **Problem:** The service principal appears correctly configured, but some Fabric-related operations still fail unexpectedly. **Solution:** * In some Fabric environments, a newly created service principal may require an initial successful Fabric API call before all access paths behave as expected * Confirm tenant settings and re-test after the service principal has been fully initialized ### 6. External storage commands fail later **Problem:** Commands such as `COPY INTO` or `OPENROWSET` fail even though the SQL connection itself works. **Solution:** * Validate the Fabric tenant settings related to service principals * Validate that the service principal has been properly initialized in Fabric * Validate that any required external storage access policies are in place *** If you encounter an error or question not listed above and need assistance, do not hesitate to reach out to your account manager. # ClickHouse Connecting DinMo to ClickHouse: Step-by-Step Guide Go to the workspace settings, then to the Source tab, and click "Add New Source". * **Step 1:** Select ClickHouse from the list of available sources
* **Step 2:** Create a DinMo user on your DataWarehouse and the DinMo technical datasets.\ \ DinMo needs to read all the tables that you want to use to build models and segments. It also needs to write access to a database that will be used to store technical data (segment queries, segment stats, activation snapshots).
We recommend you create a specific user and role for DinMo and grant them the needed permissions. You can do so by running the following SQL snippet. ```sql -- Create the technical database that DinMo will use to store its internal data CREATE DATABASE IF NOT EXISTS dinmo_technical_data; -- Give the DinMo user the ability to sign in with a password CREATE USER IF NOT EXISTS DINMO_USER IDENTIFIED WITH bcrypt_password BY ''; CREATE ROLE IF NOT EXISTS DINMO_ROLE; GRANT DINMO_ROLE TO DINMO_USER; -- Let the DinMo Role read and query the database that contains the data that you want to use in the DinMo Platform -- You can have fine-grained access control by granting permissions only on specific tables or views instead of the whole database -- Replace with the name of the database where you store the tables and views that will be used in the DinMo Platform GRANT SELECT ON .* TO DINMO_ROLE; -- Grant the DinMo Role full access to the technical database GRANT SELECT ON dinmo_technical_data.* TO DINMO_ROLE; GRANT CREATE, DROP TABLE ON dinmo_technical_data.* TO DINMO_ROLE; GRANT CREATE, DROP VIEW ON dinmo_technical_data.* TO DINMO_ROLE; GRANT INSERT ON dinmo_technical_data.* TO DINMO_ROLE; ``` Please edit the `` fields in the script to define your own credentials and parameters.
* **Step 3:** Fill in the required information
* Url: The url or IP address.
* Database: The name of the database.
* Port: The port number. The default is 8443, but yours may be different.
* User and password: The credentials you created in the script above.
* **Step 4:** Hit "Save & Test". This will launch a test ensuring that the connection is working. If so, congratulations, your source setup is finished! *** If you encounter an error or question not listed below and need assistance, don't hesitate to reach out to your account manager or . We're here to help! # Destination Platforms A destination 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.
A destination is defined by different parameters: * **A destination platform**\ \ Examples of destination 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 service**\ \ This refers to the business use case you wish to implement in the destination. DinMo often support different services within a given destination platform. For instance, users can use DinMo to update audiences on Google Ads, but also, send conversions, or adjust conversions values.
* **Default activation settings**\ \ Default activation settings are optional and only available for some destination services. They simplify the activation configuration process by allowing you to set it up just once, eliminating the need for repetitive configuration. After setting up a destination on DinMo, you can start sending data right away, no extra configuration will be needed. {% hint style="info" %} For guidance on connecting your designated destination, consult the corresponding section [Create a Destination](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} *** ## Ready to get started? Book a demo and we will walk through the best way to launch your first DinMo use case. [Book a demo](https://www.dinmo.com/contact/) ## Need help? Our team is here to help with setup, modeling, activation, and troubleshooting. [Contact us](mailto:hello@dinmo.com?subject=Docs%20help) ## Feature requests? Tell us which connector, workflow, or improvement would make DinMo more useful for your team. [Request a feature](mailto:hello@dinmo.com?subject=Feature%20request) [Privacy Policy](https://www.dinmo.com/legals/privacy/) | [Terms of Service](https://www.dinmo.com/terms-of-service/) # Actito ## Supported destination services {% hint style="info" %} Learn more about all of our Destination service types on our [Core Concepts page](/core-concepts). {% endhint %} DinMo supports the following destination services: * [Synchronize user attributes](/integrations/destination-platforms/actito/synchronize-users-attributes), to update or create contact attributes * [Synchronize custom tables,](/integrations/destination-platforms/actito/synchronize-custom-tables) to update or create new rows in custom tables * [Export contact lists](/integrations/destination-platforms/actito/export-contact-lists), to keep an audience updated in Actito ## Destination Setup Please do the following steps to add Actito as a destination in DinMo: 1. Go to the Destinations section in the navigation bar. 2. Click "Add a new destination". 3. Select "Actito". 4. Enter the name of the destination, then your login and API key to connect to Actito.\ \
To generate an API key for Actito, go to the License configuration page and click on API Accesses. Click on "Create an API access" to get a new API key. You will also have the Actito API Domain at the same time.
# Synchronize users attributes ## Overview In this destination service, DinMo will export and update attributes in the Actito **Profiles table** and, optionally, insert new profiles.\ To achieve this, you will need to follow these three steps: 1. **Creating an Actito destination:** Refer to the corresponding section for detailed instructions. 2. **Creating a user segment or model:** This should include all profiles and their attributes that will be updated in Actito. 3. **Activating the model or segment to the Actito destination:** This initiates the data synchronization. Refer to the corresponding section for guidance. Every time an activation runs, DinMo evaluates the latest audience data and syncs the resulting changes to the destination according to the selected sync mode and run type: * **Insert:** Each activation sends only newly detected records to the destination and inserts them without modifying or deleting existing data. * **Update:** Each activation sends only records that have changed and updates existing records in the destination, without inserting new ones or deleting data. * **Upsert:** Each activation sends new and changed records to the destination, inserting missing records and updating existing ones as needed. * **Mirror:** Each activation synchronizes the destination to match the source by inserting new records, updating changed ones, and permanently deleting records that are no longer present in the source. ## Destination setup To start synchronizing contacts, you are first required to create a Actito destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo model created, you can create an activation to start sending data to Actito right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Sync modes Sync modes determine how data is synchronized between your data source and your Actito application. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Actito destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
INSERTProcesses only new records detected since the last sync and inserts them into the destination. Existing records are never modified or removed.
  • Append-only datasets
  • Event or log ingestion
  • Historical data tracking
  • Detects new records using delta keys
  • Inserts new records only
  • Ignores existing and deleted records
  • Fastest and least intrusive sync mode
UPDATEProcesses only changed records detected since the last sync and updates existing records in the destination. New records are ignored.
  • Enriching or correcting existing datasets
  • Attribute updates without data growth
  • Systems where record creation is handled elsewhere
  • Detects modified records using delta keys
  • Updates existing records only
  • Does not insert or delete records
  • Assumes records already exist in the destination
UPSERTProcesses new and changed records, inserting new records and updating existing ones as needed.
  • Standard synchronization use cases
  • Incremental data refresh
  • Large datasets with moderate change rates
  • Detects new and updated records
  • Inserts missing records
  • Updates existing records
  • Does not delete records
  • Balances data freshness and performance
MIRRORKeeps the destination fully synchronized with the source by applying inserts, updates, and deletions detected since the last sync.
  • Maintaining an exact replica of the source
  • Operational systems requiring strict consistency
  • Data pipelines with frequent deletes
  • Detects all changes using delta logic
  • Inserts new records
  • Updates changed records
  • Deletes records missing from the source
  • Requires connector support for delete operations
{% hint style="danger" %} **Warning — Use Mirror Mode with Caution** **Mirror sync mode permanently deletes records from the destination when they are no longer present in the source.**\ This includes contacts and related data. Once deleted, these records **cannot be recovered** unless they are reintroduced from the source in a future sync. Mirror mode should therefore be used **only when the source is the single source of truth** and when permanent deletions are an intended and fully controlled behavior.\ Always validate deletion rules and run Mirror syncs carefully, especially on production environments. {% endhint %} ### Fields mapping In the **Fields Mapping** section, you must specify the field in your DinMo model corresponding to the **external ID** in Actito.\ This field is used to match the records in your model to existing profiles in Actito. ### Synchronized attributes In this section, you can define the attributes you want to synchronize. DinMo ensures the values of the mapped attributes are always up to date in Actito. To map an attribute: * On the left side, select the field in DinMo containing the attribute’s value. * On the right side, type the exact name of the attribute as it appears in Actito. > **Note:** If the attribute you specify does not exist in Actito, DinMo will automatically create it. ### **Scheduling options** In this section, specify how often the data should be inserted/updated/deleted in Actito. ### Warnings In this section, specify if you want to receive warning for your Actito activation. {% hint style="info" %} Consult this specific documentation to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Synchronize custom tables ## Overview In this destination service, DinMo will export and update attributes in the Actito **Custom table** of your choice and, optionally, insert new profiles. \ To achieve this, you will need to follow these three steps: 1. **Creating an Actito destination:** Refer to the corresponding section for detailed instructions. 2. **Creating a segment or model:** This should include all objects and their attributes that will be updated in Actito. 3. **Activating the model or segment to the Actito destination:** This initiates the data synchronization. Refer to the corresponding section for guidance. Every time an activation runs, DinMo evaluates the latest audience data and syncs the resulting changes to the destination according to the selected sync mode and run type: * **Insert:** Each activation sends only newly detected records to the destination and inserts them without modifying or deleting existing data. * **Update:** Each activation sends only records that have changed and updates existing records in the destination, without inserting new ones or deleting data. * **Upsert:** Each activation sends new and changed records to the destination, inserting missing records and updating existing ones as needed. * **Mirror:** Each activation synchronizes the destination to match the source by inserting new records, updating changed ones, and permanently deleting records that are no longer present in the source. ## Destination setup To start synchronizing your custom objects, you are first required to create a Actito destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo model created, you can create an activation to start sending data to Actito right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Sync modes Sync modes determine how data is synchronized between your data source and your Actito application. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Actito destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
INSERTProcesses only new records detected since the last sync and inserts them into the destination. Existing records are never modified or removed.
  • Append-only datasets
  • Event or log ingestion
  • Historical data tracking
  • Detects new records using delta keys
  • Inserts new records only
  • Ignores existing and deleted records
  • Fastest and least intrusive sync mode
UPDATEProcesses only changed records detected since the last sync and updates existing records in the destination. New records are ignored.
  • Enriching or correcting existing datasets
  • Attribute updates without data growth
  • Systems where record creation is handled elsewhere
  • Detects modified records using delta keys
  • Updates existing records only
  • Does not insert or delete records
  • Assumes records already exist in the destination
UPSERTProcesses new and changed records, inserting new records and updating existing ones as needed.
  • Standard synchronization use cases
  • Incremental data refresh
  • Large datasets with moderate change rates
  • Detects new and updated records
  • Inserts missing records
  • Updates existing records
  • Does not delete records
  • Balances data freshness and performance
MIRRORKeeps the destination fully synchronized with the source by applying inserts, updates, and deletions detected since the last sync.
  • Maintaining an exact replica of the source
  • Operational systems requiring strict consistency
  • Data pipelines with frequent deletes
  • Detects all changes using delta logic
  • Inserts new records
  • Updates changed records
  • Deletes records missing from the source
  • Requires connector support for delete operations
{% hint style="danger" %} **Warning — Use Mirror Mode with Caution** **Mirror sync mode permanently deletes records from the destination when they are no longer present in the source.**\ This includes contacts and related data. Once deleted, these records **cannot be recovered** unless they are reintroduced from the source in a future sync. Mirror mode should therefore be used **only when the source is the single source of truth** and when permanent deletions are an intended and fully controlled behavior.\ Always validate deletion rules and run Mirror syncs carefully, especially on production environments. {% endhint %} ### Fields mapping In the fields mapping section, you have to configure how the columns in your segment data should be mapped to fields in your destination. {% hint style="info" %} Some of the fields are marked as required by the destination platform to better map your data. {% endhint %} You can also map all other fields that already exist in your custom table in Actito. The dropdown menu on the right (Actito platform field) lists all possible fields.
### Create custom attributes In this section, you can define the attributes you want to create in Actito and continue synchronize. DinMo ensures the values of the mapped attributes are always up to date in Actito. To map an attribute: * On the left side, select the field in DinMo containing the attribute’s value. * On the right side, type the exact name of the attribute as it appears in Actito. > **Note:** If the attribute you specify does not exist in Actito, DinMo will automatically create it. ### **Scheduling options** In this section, specify how often the data should be inserted/updated/deleted in Actito. ### Warnings In this section, specify if you want to receive warning for your Actito activation. {% hint style="info" %} Consult this specific documentation to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Export contact lists ## Overview In this destination service, DinMo will create external target lists and keep them up to date in Actito. To do so, you will need to go through these three steps: * Creating an Actito destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users that will populate your Actito contact list. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Actito destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Actito external target list * Any user leaving your DinMo segment will be removed from your Actito external target list * Any profile attribute changes will be synchronized with Actito, either by updating existing attributes or creating new ones. In this service, DinMo will not create new contacts in Actito. ## Destination setup To start exporting lists, you are first required to create a Actito destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Actito right away. The segment will be exported as a contact list in Actito. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Activation Name and Description In this section, the name you enter will be the name given to the external target list created in Actito. By default, and if you activate your segment using the default activation settings, the name of the list will be the DinMo segment name. ### Fields mapping In the Fields mapping section, you are asked to specify which field corresponds to the email address of the users of the segment. The user can choose between email, phone number, or Actito external ID as the mandatory matching key for the profile sync.\ The user can select additional profile attributes from the existing options in Actito. The user also has the option to create new custom attributes, which will be added during the first synchronization. ## On Actito Once a DinMo segment has been exported to an Actito external target list, you can leverage it within the Actito interface by enabling expert mode and selecting the 'File' targeting module. From there, you can choose the relevant external target list containing the synced DinMo segment.
This allows you to use the segment for targeted campaigns, ensuring that the latest audience data from DinMo is available for activation. Additionally, the expiration date column in Actito provides visibility into how long the last retrieved file remains valid, helping you manage audience efficiently.
For more information about Actito's external target lists, you can check out [this documentation](https://developers.actito.com/docs/use-cases/external-target-list/#using-an-external-target-list). # All My SMS Sending data to All My SMS: Step-by-Step Guide ## Supported destination services {% hint style="info" %} Learn more about all of our Destination service types on our [Core Concepts page](/core-concepts). {% endhint %} DinMo supports the following destination service: * Export contact lists, to keep an audience updated in Actito ## Destination Setup Please do the following steps to add All My SMS as a destination in DinMo: 1. Go to the Destinations section in the navigation bar. 2. Click "Add a new destination". 3. Select "All My SMS". 4. Enter the name of the destination, then your login and API key to connect to All My SMS.\
\ To find your login, go to All My SMS platform, hit "My Profile" under "My Account" tab. You will then see your login on the top of the page:\
To generate an API key, hit API KEY & Parameters under the API & Modules tab. Then, click on "Generate a new API key", and copy and paste its value on DinMo/
5. Click Continue, then Connect. ## Syncing Audiences DinMo supports audiences sync to All My SMS. DinMo will create Lists for all your DinMo activations, by inserting and removing phone numbers to keep your lists up to date. ### Sync Setup Here are the necessary steps involved in the creation of a new sync to Google Ads: 1. Navigate to the Activations tab, and click "New Activation" in the upper-right corner of the screen.
2. Select "User Segment", then click "Continue".
3. Choose your All My SMS platform in the dropdown, and click “Continue.”\

4. Indicate which property corresponds to the phone number.
5. Under the Scheduling options, choose the time interval at which you want your segment to be synced to All My SMS. A daily sync is sufficient for most use cases.
6. Click “Continue,” then “Create”. # Attentive DinMo supports the following destination service: * [Export contact lists](/integrations/destination-platforms/attentive/export-contact-lists), to create segments * [Synchronize users](/integrations/destination-platforms/attentive/synchronize-users), to update or create contact attributes ## Destination Setup ### API Key creation First of all, you'll need to create an API key in attentive in order to connect DinMo. Here's how you can do it: * Log in to your **Attentive account.** * Navigate to the **App Marketplace** by clicking on your profile icon and selecting **Marketplace**. * Click on **+ Create App** in the top-right corner. * Fill in the required details: * **App Name**: Enter an internal-facing name for your app *(e.g. DinMo App)* * **Contact Email**: Provide an email address where Attentive can reach you if needed. * In the **Permissions** section, set the desired access levels for each API, as described below:
* Click **Create**. * A modal will appear displaying your **API Key**. Click **Copy** to save it securely. {% hint style="warning" %} **Important**: This is the only time you will be able to view and copy your API key. If you lose it, you'll need to regenerate a new one {% endhint %} ### Setup in DinMo Then, do the following steps to add Attentive as a destination in DinMo: * Go to the ***Destinations*** section in the navigation bar. * Click "**Add a new destination**". * Select "**Attentive**". * Enter the name of the destination and your Attentive API Key. # Export contact lists ## Overview In this destination service, DinMo will create lists of user and keep them up to date in Attentive. To do so, you will need to go through these three steps: * Create a Attentive destination. Refer to the [corresponding section ](/integrations/destination-platforms/attentive)for more info. * Create a user model or segment composed of all the users that will populate your list in Attentive.\ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activate the segment to the Attentive destination to start sending data. Refer to the corresponding section for more info. {% hint style="warning" %} Due to a Attentive limitation, DinMo will not directly create a list in Attentive. Instead, it will create and update an attribute in the users table, which will be set to `True` for all the users who are part of the list. {% endhint %} * To finalize the list creation, navigate to the Attentive interface, then creating a new list by filtering all the users where the attribute value is `True`.
Each time the activation will be running: * Any new user entering your DinMo model or segment will have its attribute updated to `True` in Attentive * Any user leaving your DinMo model or segment will have its attribute updated to `False` in Attentive {% hint style="info" %} Note that only users who have an external ID (email or phone) linked to an existing Attentive user will be considered by DinMo. In this destination service, DinMo will not create new user. {% endhint %} ## Destination setup To start exporting lists, you are first required to create a Attentive destination with the corresponding destination service. ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your contacts lists to Attentive will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your activations if you wish to. ## Activation configuration Once the destination has been setup, and your DinMo model or segment created, you can create an activation to start sending data to Attentive right away. The model or segment will be exported as an attribute value in Attentive (`True` / `False`). Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) ### Audience Name The audience name will be the name of the attribute that will be created in the users table in Attentive. DinMo will replace spaces by underscores. {% hint style="warning" %} Make sure an attribute with the same name does not already exist. {% endhint %} ### Fields mapping In this section, specify the DinMo field corresponding to the external ID that should be used by Attentive to identify your users. It must correspond to the email or the phone number. ### **Scheduling** In this section, specify how often the list should be updated in Attentive. Every time the list is updated: * Any new user entering your DinMo model or segment will have its attribute updated to `True` in Attentive * Any user leaving your DinMo model or segment will have its attribute updated to `False` in Attentive ### **Warnings** In this section, specify if you want to receive warning for your Attentive activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Synchronize Users ## Overview In this destination service, DinMo will export and update attributes in the Attentive **Subscribers tab.** To achieve this, you will need to follow these three steps: 1. **Creating an Attentive destination:** Refer to the [corresponding section](/integrations/destination-platforms/attentive) for detailed instructions. 2. **Creating a user segment or model:** This should include all profiles and their attributes that will be updated in Attentive. 3. **Activating the model or segment to the Attentive destination:** This initiates the data synchronization. Each time the activation runs: * All attributes with values that have changed since the last activation will be updated in Attentive. * Similarly, if a custom attribute has been added, it will be updated for the entire database. Note: no "contact lists" are created during this activation. To replicate a "list" sync, create an attribute (e.g. Purchased in last 30 days) in DinMo using our [calculated fields](/models/computed-fields), which for your list of customers equals "True". This will allow filtering of your whole contact base to this segmented list in Attentive, which can then serve your use cases. {% hint style="danger" %} Attentive does not support the creation of new contacts. That means that **only those already existing** in Attentive (identified via their email or phone number) will be updated. {% endhint %} ## Destination setup To start synchronizing contacts, you are first required to create a Attentive destination with the corresponding destination service. ## Activation configuration Once the destination has been setup, and your DinMo model created, you can create an activation to start sending data to Attentive right away. Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% hint style="info" %} The first full run may take several hours due to limitations in file size with the Attentive API. Each run following this (subject to a sensible refresh schedule) will be much quicker given only the delta records, those updated or new, are shared via the API. {% endhint %} ## Fields mapping In the **Fields Mapping** section, you must specify the field in your DinMo model corresponding to the email or the phone number. This field is used to match the records in your model to existing profiles in Attentive. Once you have mapped one of these two fields, you can enter the different standards supported by Attentive in this section.
Attentive supports the following fields: `address`, `age`, `city`, `country`, `date of birth`, `email`, `first name`, `language`, `last name`, `latitude`, `longitude`, `organization`, `phone`, `region`, `state`, `time zone`, `title`, `website` and `zip code`. ## Synchronized attributes In this section, you can define the custom attributes you want to create and synchronize. DinMo ensures the values of the mapped attributes are always up to date in Attentive. To map an attribute: * On the left side, select the field in DinMo containing the attribute’s value. * On the right side, enter the name of the field you want to receive in Attentive. {% hint style="info" %} We recommend not using spaces in field names, as they are not supported by the Attentive API.\ We will, of course, carry out our own checks before sending, to normalize fields if necessary. {% endhint %} # Attio Step-by-Step guide to push enriched data from your data warehouse into Attio ## Supported Destination services DinMo supports the following destination services: * [Sync data from any source to People in Attio](/integrations/destination-platforms/attio/synchronize-people) * [Sync data from any source to Users in Attio](/integrations/destination-platforms/attio/synchronize-users) * [Sync data from any source to Companies in Attio](/integrations/destination-platforms/attio/synchronize-companies) * [Sync data from any source to Deals in Attio](/integrations/destination-platforms/attio/synchronize-deals) Please refer to the dedicated documentation page for more information about one specific destination service. In all cases, DinMo will perform upsert operations. ## Authentification to Attio Regardless of the selected destination service, DinMo will always connect to Attio using an API Key Authentification. To connect Attio: * Go the Destinations overview page and click on "New destination" * Connect a new platform and select **Attio** You will be required to enter your Attio API key. You can locate this API key within your Attio account by navigating to Workspace Settings > Developers:
DinMo will need `Read-write` rights on Records and Object Configuration.
# Synchronize People With this destination service, DinMo will update a person's attribute values in the Attio profiles table, and optionally insert new people if they do not already exist. To create such an activation, you will need to go through these three steps: * Creating an Attio destination, with the correct destination service.\ Refer to the [corresponding section](#destination-setup) for more info. * Creating a segment composed of all the records and their attributes that will be updated in Attio.\ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. {% hint style="info" %} Only user segments / models are allowed for this destination service. {% endhint %} * Activating the segment to the Attio destination to start sending data.\ Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation runs: * New people will be created, with mapped attributes * Existing people will be updated, if necessary ## Destination setup To start synchronizing people, you are first required to create an Attio destination with the corresponding destination service.
{% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation Configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Attio right away. {% hint style="warning" %} People need a unique key to be identifiable. If there is no option available in the *Matching attribute* section, that is because you must create or set a `unique` attribute in the People object first.\ The Record ID cannot be used as the matching attribute (as it is an Attio-specific field) {% endhint %} ### Field mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the matching attribute. This field will be used to link the segment's records to existing records in Attio or to create new ones. Once this field is mapped, you can easily map any other field available in Attio.
Existing fields in Attio

Existing fields in Attio for the "People" object that can be mapped in DinMo

{% hint style="info" %} If you want to create new fields, you must first do so in Attio. {% endhint %} **Scheduling** Define how frequently your data is updated in Attio. With each scheduled update: * **(Insert)** DinMo will insert new People, with their custom attributes * **(Update)** All attributes values that have changed since the last activation will be updated in existing People * DinMo will stop updating any person who is no longer in the source model/segment. **Warnings** In this section, specify if you want to receive warning for your Attio activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Synchronize Users With this destination service, DinMo will update a user's attribute values in the Attio User table, and optionally insert new user if they do not already exist. To create such an activation, you will need to go through these three steps: * Creating an Attio destination, with the correct destination service.\ Refer to the [corresponding section](#destination-setup) for more info. * Creating a segment composed of all the records and their attributes that will be updated in Attio.\ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. {% hint style="info" %} Only user segments / models are allowed for this destination service. {% endhint %} * Activating the segment to the Attio destination to start sending data.\ Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation runs: * New User will be created, with mapped attributes * Existing User will be updated, if necessary ## Destination setup To start synchronizing User, you are first required to create an Attio destination with the corresponding destination service.
{% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation Configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Attio right away.
{% hint style="warning" %} User need a unique key to be identifiable. If there is no option available in the *Matching attribute* section, that is because you must create or set a `unique` attribute in the User object first.\ The Record ID cannot be used as the matching attribute (as it is an Attio-specific field) {% endhint %} ### Field mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the matching attribute. This field will be used to link the segment's records to existing records in Attio or to create new ones. Once this field is mapped, you can easily map any other field available in Attio. {% hint style="info" %} If you want to create new fields, you must first do so in Attio. {% endhint %} **Scheduling** Define how frequently your data is updated in Attio. With each scheduled update: * **(Insert)** DinMo will insert new Users, with their custom attributes * **(Update)** All attributes values that have changed since the last activation will be updated in existing Users * DinMo will stop updating any person who is no longer in the source model/segment. **Warnings** In this section, specify if you want to receive warning for your Attio activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Synchronize Companies Learn how to synchronize companies with DinMo With this destination service, DinMo will update company attribute values in the Attio Companies table, and optionally insert new companies if they do not already exist. To create such an activation, you will need to go through these three steps: * Creating an Attio destination, with the correct destination service.\ Refer to the [corresponding section](#destination-setup) for more info. * Creating a segment composed of all the records and their attributes that will be updated in Attio.\ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. {% hint style="info" %} Both user and custom segment can be activated in the Company destination {% endhint %} * Activating the segment to the Attio destination to start sending data.\ Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation runs: * New companies will be created * Existing companies will be updated, if necessary ## Destination setup To start synchronizing companies, you are first required to create an Attio destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation Configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Attio right away.
{% hint style="warning" %} Companies need a unique key to be identifiable. If there is no option available in the *Matching attribute* section, that is because you must create or set a `unique` attribute in the Companies object first.\ The Record ID cannot be used as the matching atribute. {% endhint %} ### Field mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the matching attribute. This field will be used to link the segment's records to existing records in Attio or to create new ones. Once this field is mapped, you can easily map any other field available in Attio.
{% hint style="info" %} If you want to create new fields, you must first do so in Attio. {% endhint %} **Scheduling** Define how frequently your data is updated in Attio. With each scheduled update: * **(Insert)** DinMo will insert new Companies, with their custom attributes * **(Update)** All attributes values that have changed since the last activation will be updated in existing Companies * DinMo will stop updating any Company who is no longer in the source model/segment. **Warnings** In this section, specify if you want to receive warning for your Attio activation. Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). # Synchronize Deals Learn how to synchronize deals with DinMo With this destination service, DinMo will update deal attribute values in the Attio Deals table, and optionally insert new deals if they do not already exist. To create such an activation, you will need to go through these three steps: * Creating an Attio destination, with the correct destination service.\ Refer to the [corresponding section](#destination-setup) for more info. * Creating a segment composed of all the records and their attributes that will be updated in Attio.\ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. {% hint style="info" %} Both user and custom segment can be activated in the Deal destination {% endhint %} * Activating the segment to the Attio destination to start sending data.\ Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation runs: * New deals will be created * Existing deals will be updated, if necessary ## Destination setup To start synchronizing deals, you are first required to create an Attio destination with the corresponding destination service.
{% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation Configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Attio right away. {% hint style="warning" %} **The deal object must be activated in your Attio Account.** {% endhint %}
{% hint style="warning" %} Deals need a unique key to be identifiable. If there is no option available in the *Matching attribute* section, that is because you must create or set a `unique` attribute in the Deals object first.\ The Record ID cannot be used as the matching atribute. {% endhint %} ### Field mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to several information in Attio: * **The name of the deal** * **The stage of the deal**, for instance *Lead*, *In* *Progress*, *Won*, etc.\ :warning: You must use exactly the same wording as in Attio to match a specific deal. You can't create new status directly from DinMo * **The deal owner**, who must be an active Users in Attio * The matching attribute chosen at the step 1 These fields will be used to link the segment's records to existing records in Attio or to create new ones.
Once these 4 fields are mapped, you can easily map any other field available in Attio. {% hint style="info" %} If you want to create new fields, you must first do so in Attio. {% endhint %} **Scheduling** Define how frequently your data is updated in Attio. With each scheduled update: * **(Insert)** DinMo will insert new Deals, with their custom attributes * **(Update)** All attributes values that have changed since the last activation will be updated in existing Deals * DinMo will stop updating any Deal who is no longer in the source model/segment. **Warnings** In this section, specify if you want to receive warning for your Attio activation. Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). # AWS S3 Transfer data at scale from your data warehouse to your apps through AWS using DinMo DinMo allows you to export your data models and segments to an Amazon S3 bucket. Generated files (Parquet, CSV, JSON, XML, etc.) are uploaded directly to your bucket. This guide walks you through the setup of an S3 connection using either **Cross-Account Role** or **Access Key** authentication. > 💡 For more information on destination types, see our [Core Concepts page](/core-concepts). ## Prerequisites Ensure you have access to the AWS account hosting the S3 bucket and the required permissions: * To use **Cross-Account Role**, you must be able to create IAM roles and policies. * To use **Access Key**, you need valid AWS credentials with appropriate S3 permissions. *** ## Add AWS S3 as a Platform in DinMo 1. In DinMo, go to **Destinations**. 2. Click **Add a new destination**. 3. Select **Connect a new platform** and choose **AWS S3**. 4. Enter: * A **Platform Name** (for identification). * The **S3 Bucket Name** where files will be sent. 5. Choose an **Authentication Method**: * **Cross-Account** * **Access Key** DinMo will adapt the form based on your selection. *** ## Cross-Account Role Authentication In this setup, DinMo AWS account assumes a role in your AWS account to upload files securely. ### DinMo Role Information * **DinMo Role ARN**:\ `arn:aws:iam::724998534403:role/DinmoS3AccessorRole-dinmo-prod` * **External ID**:\ A unique string generated by DinMo during setup (e.g., `40cef540-b3b4-4e86-b343-2fde3a6f0396`) ### Create an IAM Role in Your AWS Account **Step 1 – Trust Policy** Create a new IAM Role with this trust relationship (replace `EXTERNAL_ID`): ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::724998534403:role/DinmoS3AccessorRole-dinmo-prod" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "EXTERNAL_ID" } } } ] } ``` **Step 2 – Permissions Policy** Attach this policy to grant S3 access (replace `${bucketName}`): ```json { "Version": "2025-10-17", "Statement": [ { "Sid": "AllowDinMoS3Write", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts", "s3:ListBucketMultipartUploads" ], "Resource": [ "arn:aws:s3:::${bucketName}", "arn:aws:s3:::${bucketName}/*" ] } ] } ``` *** ## Access Key Authentication If you don’t want to create IAM roles, you can connect using AWS credentials. ### Required Fields * **AWS Access Key ID** * **AWS Secret Access Key** * **AWS Region** * **S3 Bucket Name** > 🔐 These credentials must allow write access to your specified bucket. ### Sample IAM Policy The user associated with these credentials should have at least: ```json { "Version": "2025-10-17", "Statement": [ { "Sid": "AllowDinMoAccessKeyWrite", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts", "s3:ListBucketMultipartUploads" ], "Resource": [ "arn:aws:s3:::${bucketName}", "arn:aws:s3:::${bucketName}/*" ] } ] } ``` *** ## Validate & Test Connection Once all required fields are filled: * Click **Connect** in DinMo. * DinMo will test access by attempting a write operation. * If it fails, verify: * IAM Role ARN and External ID (for cross-account) * Access Key credentials and region * Bucket permissions and policies # Export your data models and segments to AWS S3 Sync your model profiles and attributes into an AWS S3 bucket to enable personalization and rapid data retrieval in your apps and websites. ## Overview This destination service allows DinMo to insert new files or update existing ones in an AWS S3 bucket, based on your DinMo models or segments. To use this service, follow these three steps: 1. **Create an AWS S3 destination**. Follow the step-by-step guide above to establish this connection using either Access Key or Cross-Account Role. 2. **Create your DinMo model or segment** representing the data you want to send to your S3 bucket. 3. **Activate your model or segment** with the S3 destination to start synchronization. Every time the activation runs: * If the file does **not yet exist**: DinMo will create it with all the rows in the query results. * If the file **already exists**: DinMo will **overwrite it**, with only the rows added since the last sync. * If you don't want to overwrite existing files, we recommend using a **timestamp in your file name**. ## Activation Setup Once the AWS S3 destination is configured, create an activation to begin syncing your data. To do so: 1. Go to the **Activations** tab. 2. Click on **New activation**. 3. Select the **model or segment** you want to export. 4. Choose your **AWS S3 destination** from the list. You’ll then configure the activation: * **S3 Folder Path**: Specify the folder (key prefix) where you want to store the file. By default, files are stored at the root of the bucket. * **Indicate the name you wish to give to your file.** If you don't want to override existing files, we recommend including timestamp variables in the filename. To do so, you just need to surround each variable with `{}`. DinMo supports these timestamp variables: * **`{YYYY}`**: Full year (e.g., 2025) * **`{YY}`**: Last two digits of the year (e.g., 25) * **`{MM}`**: Month (01-12) * **`{DD}`**: Day of the month (01-31) * **`{HH}`**: Hour (00-23) * **`{mm}`**: Minute (00-59) * **`{ss}`**: Second (00-59) * **`{ms}`**: Millisecond (000-999) * **`{X}`**: Unix timestamp in seconds * **`{x}`**: Unix timestamp in milliseconds For example: `{YY}-{MM}-{DD}_export` will be `25-04-14_export.csv` for the upload of April 14th 2025. * **File Format**: Choose between CSV, JSON, XML, or Apache Parquet. * For CSV: select a delimiter and whether to include headers. * **Attribute Mapping**: Map any fields from your model/segment to custom column names in the destination file. You can rename fields freely.
The example above shows how to export the `age`, `name`, `phone_number` and boolean `is_active`. These columns are mapped to new fields in the destination file as `age`, `last name` , `phone` and `is_active`. DinMo exports these fields to the new fields in the file and ignores all other columns from your model/segment. ### Run Types and Sync Modes When configuring your sync, you will be asked to choose the Run Type and the Sync Mode. For AWS S3 activations, here are the available options:
Run TypeDescriptionUse CaseBehavior
FULL ONLYEvery sync processes all records from the source and exports a complete file (or several, if size limit is reached).When the exported file must always contain a full extract, and incremental updates are not required.
  • No delta logic
  • Every sync rebuilds the full export
  • Recommended for Snapshot mode
FULL THEN DELTAThe first sync exports all records. All following syncs export only changed records, based on DinMo’s delta detection logic.When exporting large datasets frequently and wanting to reduce file size or processing time.
  • Sync 1 → Full export
  • Next syncs → Only changed records (new, updated).
  • Compatible with INSERT and UPSERT modes
Sync modes determine how data is synchronized between your data source and destination. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the AWS S3 destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
SNAPSHOTExports a complete snapshot of all records at the time of sync. Each sync can generate a new file with a timestamped name.Useful for backups or systems expecting full “point-in-time” extracts.
  • Always exports the full segment / model
  • Creates a new file with timestamp
  • No incremental logic
UPSERTWrites all updated or new records into the exported file.Keeps files up-to-date with the latest source data.
  • New records → included in the exported file
  • Existing records → included if, and only if, there are updated values
  • Deleted records → simply not present in the file
INSERTAdds only new records to the exported file. Existing records are never modified.Useful for append-only files, such as historical logs or event tracking.
  • New records → added to file
  • Existing records → ignored
  • Missing records → no action
### **Scheduling** Define how frequently your data is exported to your S3 bucket. Each scheduled execution performs a **delta operation**: DinMo inserts only the rows added since the last sync. This helps optimize bandwidth and storage costs while keeping your exports fresh and relevant. {% hint style="warning" %} The user needs to have access to the target directory and file with **write privileges**. A `permission denied` error message during a sync indicates the user may not have write permissions for both the directory or the file. {% endhint %} # Azure Storage Transfer data at scale from your data warehouse to your apps through Azure Storage using DinMo DinMo allows you to export your data models and segments to an Azure Blob Storage. Generated files (Parquet, CSV, JSON, XML, etc.) are uploaded directly to your blob. This guide walks you through the setup of an Azure Storage connection: * [Export data to Azure Blob Storage](/integrations/destination-platforms/azure-storage/export-data-to-azure-blob-storage) ## Authentification In all cases, DinMo will connect to Azure storage using a SAS token. {% hint style="info" %} If you want to learn more about Azure SAS token, refer to their [official documentation](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview). {% endhint %} To connect Azure Storage in DinMo, follow these steps: 1. In DinMo, go to **Destinations** 2. Click **Add a new destination**. 3. Select **Connect a new platform** and choose **Azure Storage**. 4. Enter: * A **Platform Name** (for identification). * Your **Azure Account** * Your **Azure SAS Token** # Export data to Azure Blob Storage Sync your model profiles and attributes into an Azure Blob Storage container to enable personalization and rapid data retrieval in your apps and websites. ## Overview This destination service allows DinMo to insert new files or update existing ones in an **Azure Blob Storage Container**, based on your DinMo models or segments. To use this service, follow these three steps: 1. **Create an Azure Storage destination**. Follow the [step-by-step guide](/integrations/destination-platforms/azure-storage) above to establish this connection using a SAS Token. 2. **Create your DinMo model or segment** representing the data you want to send to your Azure Blob Storage container. 3. **Activate your model or segment** with the Azure Storage destination to start synchronization. Every time the activation runs: * If the file does **not yet exist**: DinMo will create it with all the rows in the query results. * If the file **already exists**: DinMo will **overwrite it**, with all the rows in the query results. {% hint style="info" %} If you don't want to overwrite existing files, we recommend using a **timestamp in your file name**. {% endhint %} ## Activation Setup Once the Azure Storage destination is configured, create an activation to begin syncing your data. {% hint style="info" %} In the destination configuration, we ask you to specify the target container where you want to receive the data. {% endhint %} To do so: 1. Go to the **Activations** tab. 2. Click on **New activation**. 3. Select the **model or segment** you want to export. 4. Choose your **Azure Storage destination** from the list. You’ll then configure the activation: * **File Name**: Indicate the desired name for your file. If you don't want to override existing files, we recommend including timestamp variables in the filename. To do so, you just need to surround each variable with `{}`. DinMo supports these timestamp variables: * **`{YYYY}`**: Full year (e.g., 2025) * **`{YY}`**: Last two digits of the year (e.g., 25) * **`{MM}`**: Month (01-12) * **`{DD}`**: Day of the month (01-31) * **`{HH}`**: Hour (00-23) * **`{mm}`**: Minute (00-59) * **`{ss}`**: Second (00-59) * **`{ms}`**: Millisecond (000-999) * **`{X}`**: Unix timestamp in seconds * **`{x}`**: Unix timestamp in milliseconds For example: `{YY}-{MM}-{DD}_export` will be `25-04-14_export.csv` for the upload of April 14th 2025. {% hint style="warning" %} All placeholder values are set on **Coordinated Universal Time** (UTC) {% endhint %} * **File Format**: Choose between CSV, JSON, XML, or Apache Parquet. * For CSV only: select a delimiter and whether to include headers.
* **Indicate the type of run you would like to do**, based on the result you would like to see in your file. {% hint style="info" %} Check [this section](#run-types-and-sync-modes) if you want to learn more about the Run Types and the Sync Modes {% endhint %} * **Attribute Mapping**: Map any fields from your model/segment to custom column names in the destination file. You can rename fields freely.
The example above shows how to export the `age`, `name`, `phone_number` and boolean `is_active`. These columns are mapped to new fields in the destination file as `age`, `last name` , `phone` and `is_active`. {% hint style="warning" %} DinMo ignores all other columns from your model/segment. {% endhint %} ### **Run Types and Sync Modes** When configuring your sync, you will be asked to choose the Run Type and the Sync Mode.\ For Azure activations, here are the available options:
Run typeDescriptionUse CaseBehavior
FULL ONLYEvery sync processes all records from the source and exports a complete file (or several, if size limit is reached).When the exported file must always contain a full extract, and incremental updates are not required.

​

  • No delta logic
  • Every sync rebuilds the full export
  • Recommended for Snapshot mode
FULL THEN DELTAThe first sync exports all records. All following syncs export only changed records, based on DinMo’s delta detection logic.When exporting large datasets frequently and wanting to reduce file size or processing time.

​

  • Sync 1 → Full export
  • Next syncs → Only changed records (new, updated).
  • Compatible with INSERT, UPSERT, and DIFFERENCE modes
Sync modes determine how data is synchronized between your data source and destination. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Azure destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
SNAPSHOTExports a complete snapshot of all records at the time of sync. Each sync can generate a new file with a timestamped name.Useful for backups or systems expecting full “point-in-time” extracts.

​

  • Always exports the full segment / model
  • Creates a new file with timestamp
  • No incremental logic
UPSERTWrites all updated or new records into the exported file.Keeps files up-to-date with the latest source data.

​​

  • New records → included in the exported file
  • Existing records → included if, and only if, there are updated values
  • Deleted records → simply not present in the file
INSERTAdds only new records to the exported file. Existing records are never modified.Useful for append-only files, such as historical logs or event tracking.

​

  • New records → added to file
  • Existing records → ignored
  • Missing records → no action
DIFFERENCEGenerates separate files for added, updated, and removed records between syncs.For audit trails, incremental processing, or systems needing change-specific files.

​

  • Creates _added.csv, _updated.csv, _removed.csv (or other extensions)
  • Each file contains only the relevant change type
### Large exports and file names DinMo processes large runs in chunks. In Snapshot, Insert, and Difference modes, these chunks are published as separate files. By default, processing is split when the estimated in-memory size of an operation reaches 200 MB. This is a processing threshold, not the final encoded file size, and the effective limit can vary by run. In these modes, Azure Blob Storage output is also split so that each file contains at most 10,000,000 rows. The number of files can therefore vary between runs depending on the data volume and row size. When Snapshot or Insert produces one file, DinMo keeps the configured file name. Difference mode keeps its change suffixes, such as `customers_added.csv`, `customers_updated.csv`, and `customers_removed.csv`. When an export is split, DinMo appends one-based numeric indexes before the file extension: * **Snapshot and Insert:** `customers_1.csv`, `customers_2.csv`, and so on. * **Difference:** `customers_added_1.csv`, `customers_updated_1.csv`, or `customers_removed_1.csv`. Each change type is indexed independently when it contains multiple chunks. * **Second-level split:** if an already indexed processing chunk is split again because it exceeds 10,000,000 rows, a second index identifies its files, for example `customers_2_1.csv` and `customers_2_2.csv`. A local split on its own uses one index. * **Upsert:** DinMo combines the processed chunks and publishes one final file with the configured name, such as `customers.csv`. The indexes are inserted before the complete extension, including for compressed Parquet files such as `customers_1.parquet.zstd`. Timestamp variables are resolved once per run, so every file produced by that run shares the same timestamped base name. Files in a multi-file export are published independently and may become visible before the activation completes. Downstream consumers should wait for the activation to finish successfully before reading the complete set. {% hint style="warning" %} DinMo does not remove files from an earlier run that are no longer part of the current output set. This can leave an unsuffixed file after a single-to-multi transition or extra numbered files after a smaller run. Include a sufficiently precise timestamp, such as `{x}`, to give each run a distinct base name, and configure downstream consumers to select only files for that run. {% endhint %} ### **Scheduling** Define how frequently your data is exported to your Azure Blob Storage Container. For each run, DinMo performs a **full run**, meaning that 100% of the people in the model/segment will be present in the file (even if they were already in the previous one). ### Warnings In this section, specify if you want to receive warning for your Azure Storage activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Batch Sending data to Batch: Step-by-Step guide DinMo supports both the sending of data to the two Batch product suites: * **Batch Mobile Engagement Platform** (MEP) * **Batch Customer Engagement Platform** (CEP) ## Supported Destination Services DinMo supports the following destination services: * **Batch MEP** * [Synchronize contacts](/integrations/destination-platforms/batch/synchronize-contacts-mep), to update attributes in the contact table * [Delete profiles](/integrations/destination-platforms/batch/delete-profiles-cep-and-mep), to remove a person from Batch (for example, for GDPR purposes) * **Batch CEP** * [Export contact lists](/integrations/destination-platforms/batch/export-contact-lists-cep), to create audiences in the Batch dashboard * [Delete profiles](/integrations/destination-platforms/batch/delete-profiles-cep-and-mep), to remove a person from Batch (for example, for GDPR purposes) * [Synchronize profiles](/integrations/destination-platforms/batch/synchronize-profiles-cep), to update contact attributes in the CEP project * [Send events](/integrations/destination-platforms/batch/send-events-cep), to create and update event linked to a Batch profile * [Synchronize product attributes](/integrations/destination-platforms/batch/synchronize-catalog-attributes), to update product catalog Please refer to the dedicated documentation page for more information. ## Authentication to Batch Regardless of the selected destination service, DinMo will always connect to Batch using REST API keys. You will find their values in the General tab of your Batch settings:
### Informations needed * **For Batch MEP**: API key & REST API keys & Project API Key (only for GDPR purposes) * **For Batch CEP**: REST API Key & Project API Key Note that the keys will be different for Android and iOS apps. To target both apps, please create two separate Batch platforms. # Delete profiles (CEP & MEP) ## Overview In this destination, DinMo will delete profiles from your **Batch dashboard**. {% hint style="danger" %} **This operation is irreversible**.\ You can always recreate a profile via another Batch destination service, but you will lose the historical data for that profile in Batch. {% endhint %} To do so, you will need to go through these three steps: * Creating a Batch destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment (or model) composed of all the users that have to be deleted from Batch. * Activating the segment to the Batch destination to delete profiles. Each time the activation will be running, profiles will be deleted from your Batch dashboard. ## Destination setup To start deleting profiles, you are first required to create a Batch destination with the corresponding destination service. To get your API and project key, navigate to settings (in Batch) and copy your **REST API Key** and **Project Key** into DinMo. You'll also need a **Batch Live API Key**. This key is either your Live, Dev or SDK Batch API key from the settings page of your app within the Batch dashboard.
## Activation setup Once the destination has been setup, and your DinMo segment created, you can create an activation to start deleting profiles in Batch right away. First, you must select the segment/model that contains the data to be deleted in Batch, then the correct destination service. A few additional configurations are then necessary: ### Run type To indicate how the data should be deleted, configure the run type: * **Full only:** DinMo deletes the entire segment/model at each run. * **Full then Delta:** DinMo deletes the entire segment/model on the first run. After that, DinMo only deletes new people (compared to the historical runs). {% hint style="info" %} For example, if a person has been deleted, then is back in Batch (e.g., because they have made another purchase from your company) and finds themselves back in the deletion segment * **Full only** will effectively delete this person a second time * **Full then Delta** will not delete this person because they have already been deleted in the future. {% endhint %} ### Fields mapping It is necessary to map the **person's unique identifier** in the Batch dashboard.
### Scheduling options In this section, specify how often the list should be deleted in Batch. Every time the activation runs: * **Full only**: Any user in your segment/model will be deleted in Batch * **Full then Delta**: Any new user entering your DinMo model or segment will be deleted in Batch # Export contact lists (CEP) ## Overview In this destination service, DinMo will create *audiences* and keep them up to date in Batch. To do so, you will need to go through these three steps: * Creating an Batch destination. Refer to the [corresponding section](/integrations/destination-platforms/batch) for more info. * Creating a user segment composed of all the users that will populate your Batch contact list. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Batch destination to start sending data. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Batch audience * Any user leaving your DinMo segment will be removed from your Batch audience {% hint style="warning" %} In this service, DinMo will not create new contacts in Batch. If you need to do so, please refer to [this destination service](/integrations/destination-platforms/batch/synchronize-profiles-cep). {% endhint %} ### Destination setup To start exporting audiences, you are first required to create a Batch destination with the corresponding destination service. {% hint style="info" %} Refer to [this step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) to learn more about it {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Batch right away. The segment will be exported as an audience in Batch. ### Activation Name For each audience, Batch distinguishes between the **name** (usable via API) and the “**display name**.” It is therefore necessary to enter both information in DinMo. By default, the name of the activated segment will be used for the display name. You must enter the Audience API Name, which corresponds to the “Name” column in Batch. {% hint style="warning" %} The Audience API Name can only have alphanumeric characters, hyphen or underscore. {% endhint %} ### **Fields mapping** In the Fields mapping section, you are asked to specify which field corresponds to the Batch external ID in DinMo. This field is used to identify customers. ### **Scheduling** In this section, specify how often the list should be updated in Batch. Every time the list is updated: * Any new user entering your DinMo model or segment will enter the Audience in Batch * Any user leaving your DinMo model or segment will leave the Audience in Batch ### **Warnings** In this section, specify if you want to receive warning for your Batch activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings) {% endhint %} # Send events (CEP) ## Overview In this destination service, DinMo will export events in the profiles of your **Customer Engagement Platform**. To do so, you will need to go through these three steps: * Creating a Batch destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the events and their attributes that will be sent in Batch. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Batch destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Any records added to your model or segment are treated as new events and are sent to Batch when your sync runs. ## Destination setup To start sending events, you are first required to create a Batch destination with the corresponding destination service. To connect DinMo to Batch, you will need an API Key. To get your API and project key, navigate to settings (in Batch) and copy your REST API Key and Project Key into DinMo.
{% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo event segment (or model) created, you can create an activation to start sending data to Batch right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment that Batch will use to link each segment's records to a Batch contact (Custom Profile ID). Depending on your Batch configuration, it may be the email address of the user, or another external ID. You are also asked to specify the event name. {% hint style="warning" %} Event name values must be lowercase alphanumeric with underscores.\ It must be under 30 characters. {% endhint %} You can also map standard attributes linked to your event, especially the time of occurence and the event label. ### Custom Attributes In this section, any field you select will be exported as a custom attribute (of the event) in Batch. The associated field will have the same name in Batch and DinMo. These values of the attributes selected here will then be updated at each activation. {% hint style="warning" %} Attribute names should be made of letters, numbers or underscores (\[a-z0-9\_]). They cannot be longer than 30 characters and cannot contain uppercase characters. {% endhint %} # Synchronize catalog attributes ## Overview This destination allows you to synchronize items from DinMo to a catalog in Batch. Catalogs in Batch store structured collections of items such as products, offers, locations, or any other objects that can be used for personalization and messaging. Using this destination, DinMo can: * Create catalog items * Update existing items * Remove items from a catalog * Keep the catalog synchronized with your data warehouse Data is synchronized using the [Batch Catalog API](https://doc.batch.com/developer/api/cep/catalogs/create). ## Destination Setup Before activating a synchronization, you must configure the Batch platform in DinMo. To configure the destination, you will need the following information from your Batch project: | Field | Description | | ------------------ | -------------------------------------------------------------------------------------------------------------------- | | Project Key | Your Batch project identifier | | REST API Key | The API key used to authenticate API calls | | Batch Live API Key | This key is either your Live, Dev or SDK Batch API key from the settings page of your app within the Batch dashboard |
A **catalog** **destination in DinMo corresponds to a catalog in Batch**. You can therefore: * connect DinMo to an **existing catalog**, or * create a **new catalog** in Batch and synchronize data into it.
If the catalog does not already exist, DinMo will create it automatically when the first synchronization is executed. ## Activation configuration Once the destination has been setup, and your DinMo segment (or model) created, you can create an activation to start sending data to Batch right away. When activating the destination, you must choose how items should be synchronized between DinMo and Batch. Several synchronization modes are supported. ### Full then Delta This mode performs: 1. An initial **full export** of all items 2. Then **incremental updates** on subsequent runs Two operations are available: * **Upsert** Items included in the synchronization are: * created if they do not exist * updated if they already exist Existing items that are not part of the synchronization remain unchanged. * **Mirror** The catalog in Batch will **mirror the dataset exported by DinMo**. This means: * Items present in the synchronization are created or updated * Items that are no longer present in the dataset are **deleted from the catalog** This ensures that the catalog always reflects the exact state of the source dataset. ### Full Only In this mode, every execution performs a **full export**. Two operations are available. * **Upsert** All exported items are created or updated in the catalog. Items not present in the export remain unchanged in Batch. * **Delete Only** Items included in the synchronization are **deleted from the catalog**. This mode can be used to remove items based on a segment or dataset defined in DinMo. ## **Fields mapping** In the Fields mapping section, you are asked to specify the field contained in your DinMo segment that Batch will use to link each segment's records to a Batch product (Product ID). You can also map other attributes that already exist in your catalog. **Custom Attributes** In this section, any field you select will be exported as a new custom attribute in Batch. The associated field will have the same name in Batch and DinMo. These values of the attributes selected here will then be updated at each activation. {% hint style="warning" %} Attribute names should be made of letters, numbers or underscores (\[a-z0-9\_]). They cannot be longer than 30 characters and cannot contain uppercase characters. {% endhint %} ## Schedule You can configure when the synchronization should run. Typical schedules include: * hourly updates * daily updates * custom schedules depending on catalog update frequency # Synchronize contacts (MEP) ## Performs a full load on the first run, then processes **only new or changed records** on subsequent runs using DinMo’s delta detection logic.Overview In this destination service, DinMo will export and update custom attributes values in the contacts table. To do so, you will need to go through these three steps: * Creating a Batch destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users and their attributes that will be updated in Batch. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Batch destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * All attributes values that have changed since the last activation will be updated in Batch Note that only users of the segment who have an identifier (email address or external ID) linked to a Batch contact will be updated. Batch API does not support contact creation, so DinMo will only update existing contacts without creating new ones. ## Destination setup To start updating attributes, you are first required to create a Batch destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Batch right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Run types and Sync Modes When configuring your sync, you will be asked to choose the Run Type and the Sync Mode. For Batch MEP activations, here are the available options:
Run TypeDescriptionUse CaseBehavior
FULL ONLYProcesses all data from the source and applies the selected sync mode to all records.
  • Initial load when setting up a new source or destination
  • Full rebuild after major data model changes (schema, business logic, identifiers)
  • Recovery after data corruption or desynchronization
  • Every run reprocesses the entire dataset
  • No delta detection is applied
  • Can be resource-intensive and time-consuming on large datasets
  • Guarantees full consistency with the source at each run
FULL THEN DELTAThe first sync processes all records. All following syncs applies the selected sync mode only to changed records, based on DinMo’s delta detection logic.
  • Standard production setup for most pipelines
  • Regular synchronization with large datasets
  • Use cases requiring freshness while optimizing performance and costs
  • First run performs a full load
  • Subsequent runs process only created, updated, or deleted records
  • Relies on DinMo’s internal delta detection logic
  • Faster execution and reduced compute usage compared to FULL ONLY
Sync modes determine how data is synchronized between your data source and your Batch dashboard. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Batch destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
UPSERT (full only)Processes all records from the source at every run and applies upsert logic to each record. No change detection is performed.
  • Initial data loads
  • Small datasets
  • One-off reprocessing or data recovery
  • Connectors or sources without reliable delta keys
  • Every record is sent to the connector on each run
  • Connector decides whether to insert or update each record
  • No deletions are handled
  • Highest consistency, lowest efficiency
UPSERT (full then delta)Performs a full load on the first run, then processes only new or changed records on subsequent runs using DinMo’s delta detection logic.
  • Standard production setup
  • Large datasets with limited changes
  • Frequent syncs requiring good performance
  • First run processes all records
  • Subsequent runs process only inserted or updated records
  • Connector inserts new records and updates existing ones
  • No deletions are handled
  • Much faster and more cost-efficient than FULL ONLY
MIRROR (full then delta)Performs a full load on the first run, then keeps the destination fully aligned with the source, including deletions, using delta detection.
  • Maintaining an exact replica of the source
  • Datasets with frequent updates and deletions
  • Use cases requiring strict data consistency
  • First run processes all records
  • Subsequent runs insert new records, update changed records, and delete records missing from the source
  • Requires connector support for delete operations
  • More processing than Upsert (delta) but ensures full synchronization
{% hint style="info" %} * **Upsert mode never deletes records** from the destination, even if they are removed from the source. * **Mirror mode ensures full alignment** between source and destination, including deletions. * **FULL THEN DELTA is the recommended default** for most production pipelines. * **Choosing FULL ONLY** should be intentional and limited to specific operational needs. {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment that Batch will use to link each segment's records to a Batch contact. Depending on your Batch configuration, it may be the email address of the user, or another external ID. ### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Batch. The associated field will have the same name in Batch and DinMo. These values of the attributes selected here will then be updated at each activation. # Synchronize profiles (CEP) ## Overview In this destination service, DinMo will export and update custom attributes values in the contacts table of your **Customer Engagement Platform**. To do so, you will need to go through these three steps: * Creating a Batch destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users and their attributes that will be updated in Batch. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Batch destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * All customers previously unknown to Batch will be created in the CEP, with the associated attributes * All attributes values that have changed since the last activation will be updated in Batch ## Destination setup To start updating attributes, you are first required to create a Batch destination with the corresponding destination service. To connect DinMo to Batch, you will need an API Key. To get your API and project key, navigate to settings (in Batch) and copy your REST API Key and Project Key into DinMo.
{% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment (or model) created, you can create an activation to start sending data to Batch right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Run types and Sync Modes When configuring your sync, you will be asked to choose the Run Type and the Sync Mode. For Batch CEP activations, here are the available options:
Run TypeDescriptionUse CaseBehavior
FULL ONLYProcesses all data from the source and applies the selected sync mode to all records.
  • Initial load when setting up a new source or destination
  • Full rebuild after major data model changes (schema, business logic, identifiers)
  • Recovery after data corruption or desynchronization
  • Every run reprocesses the entire dataset
  • No delta detection is applied
  • Can be resource-intensive and time-consuming on large datasets
  • Guarantees full consistency with the source at each run
FULL THEN DELTAThe first sync processes all records. All following syncs applies the selected sync mode only to changed records, based on DinMo’s delta detection logic.
  • Standard production setup for most pipelines
  • Regular synchronization with large datasets
  • Use cases requiring freshness while optimizing performance and costs
  • First run performs a full load
  • Subsequent runs process only created, updated, or deleted records
  • Relies on DinMo’s internal delta detection logic
  • Faster execution and reduced compute usage compared to FULL ONLY
Sync modes determine how data is synchronized between your data source and your Batch dashboard. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Batch destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
UPSERT (full only)Processes all records from the source at every run and applies upsert logic to each record. No change detection is performed.
  • Initial data loads
  • Small datasets
  • One-off reprocessing or data recovery
  • Connectors or sources without reliable delta keys
  • Every record is sent to the connector on each run
  • Connector decides whether to insert or update each record
  • No deletions are handled
  • Highest consistency, lowest efficiency
UPSERT (full then delta)Performs a full load on the first run, then processes only new or changed records on subsequent runs using DinMo’s delta detection logic.
  • Standard production setup
  • Large datasets with limited changes
  • Frequent syncs requiring good performance
  • First run processes all records
  • Subsequent runs process only inserted or updated records
  • Connector inserts new records and updates existing ones
  • No deletions are handled
  • Much faster and more cost-efficient than FULL ONLY
MIRROR (full then delta)Performs a full load on the first run, then keeps the destination fully aligned with the source, including deletions, using delta detection.
  • Maintaining an exact replica of the source
  • Datasets with frequent updates and deletions
  • Use cases requiring strict data consistency
  • First run processes all records
  • Subsequent runs insert new records, update changed records, and delete records missing from the source
  • Requires connector support for delete operations
  • More processing than Upsert (delta) but ensures full synchronization
{% hint style="info" %} * **Upsert mode never deletes records** from the destination, even if they are removed from the source. * **Mirror mode ensures full alignment** between source and destination, including deletions. :warning: This irreversibly deletes the profile from the Batch dashboard. * **FULL THEN DELTA is the recommended default** for most production pipelines. * **Choosing FULL ONLY** should be intentional and limited to specific operational needs. {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment that Batch will use to link each segment's records to a Batch contact (Custom Profile ID). Depending on your Batch configuration, it may be the email address of the user, or another external ID. You can also map other standard attributes in Batch: email, phone, language, region, timezone, email or SMS subscriptions, and **Email Open Tracking consent**. ### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Batch. The associated field will have the same name in Batch and DinMo. {% hint style="info" %} If you want to map First Name and Last Name, you can name it "firstname" and "lastname", that the Batch API recognizes the fields and uses them as identifiers in the customer view. {% endhint %} These values of the attributes selected here will then be updated at each activation. {% hint style="warning" %} Attribute names should be made of letters, numbers or underscores (\[a-z0-9\_]). They cannot be longer than 30 characters and cannot contain uppercase characters. {% endhint %} # Braze Sending data to Braze: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination services: * [Synchronize users attributes](/integrations/destination-platforms/braze/synchronize-users-attributes) * [Send track events](/integrations/destination-platforms/braze/send-track-events) * [Synchronize subscription statuses](/integrations/destination-platforms/braze/synchronize-subscription-statuses) * [Export user lists](/integrations/destination-platforms/braze/export-user-lists) Please refer to the dedicated documentation page for more information. ## Authentication to Braze DinMo can push your segments and data models directly into Braze via its REST API. This guide shows you how to create the necessary API key in Braze and configure the connection in DinMo. *** ### 1. Prerequisites * **DinMo access** with permission to create Destinations. * **Braze account** with Developer-level access (to create API keys). * **Braze REST API Endpoint** and **Dashboard URL** for your instance: * US instance example: * REST API: `https://rest.iad-01.braze.com` * Dashboard: `https://dashboard.iad-01.braze.com` * EU instance example: * REST API: `https://rest.eu-01.braze.com` * Dashboard: `https://dashboard.eu-01.braze.com` ### 2. Create an API Key in Braze 1. Log into your Braze dashboard. 2. Navigate to **Developer Console** → **API Settings**. 3. Click **Create API Key**. 4. In the modal: * **Name**: e.g. `DinMo Integration` * **Key Type**: REST API * **Permissions**: grant the following scopes as needed: | **Permission Scope** | **Description** | | ------------------------- | ----------------------------------------------------------------------- | | `users.track` | Create or update user profiles and track custom events | | `users.export.ids` | Export user IDs for bulk operations | | `users.delete` | Delete user profiles *(optional if you handle deletions via Hightouch)* | | `users.alias.update` | Update existing user aliases | | `subscription.status.set` | Set or update subscription status on user profiles | 5. Click **Save**, then **Copy** the generated **API Key**. ### 3. Configure the Braze Destination in DinMo 1. In DinMo, go to **Destinations** in the side nav. 2. Click **Add a new destination** → **Connect a new platform** → **Braze**. 3. Fill out the form: * **Platform Name**: e.g. `Braze – Your Company` * **REST API URL**: your instance’s endpoint (e.g. `https://rest.eu-01.braze.com`) * **Dashboard URL**: your instance’s dashboard (e.g. `https://dashboard.eu-01.braze.com`) * **API Key**: paste the key you copied from Braze 4. Click **Connect** to validate your credentials.
{% hint style="info" %} You must as well specify the dashboard URL. Refer to this [documentation](https://www.braze.com/docs/user_guide/administrative/access_braze/sdk_endpoints) for more information. {% endhint %} *** ### 4. Verify & Test * After saving, DinMo will perform a test call (e.g. `users.track`) to ensure your key and endpoint work. * On failure, double-check: * REST API URL (no trailing slash) * API Key correctness and scopes * That your Braze IP allow-list (if enabled) includes DinMo’s IPs # Export user lists ## Overview In this destination service, DinMo will create lists of user and keep them up to date in Braze. To do so, you will need to go through these three steps: * Creating a Braze destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user model or segment composed of all the users that will populate your list in Braze. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Braze destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info.\ \ Due to a Braze limitation, DinMo will not directly create a list in Braze. Instead, it will create and update an attribute in the users table, which will be set to `True` for all the users who are part of the list.
* To finalize the list creation, navigating to the Braze interface, then creating a new list by filtering all the users where the attribute value is `True`. Each time the activation will be running: * Any new user entering your DinMo model or segment will have its attribute updated to `True` in Braze * Any user leaving your DinMo model or segment will have its attribute updated to `False` in Braze Note that only users who have an external ID linked to an existing Braze user will be considered by DinMo. In this destination service, DinMo will not create new user. ## Destination setup To start exporting lists, you are first required to create a Braze destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your contacts lists to Braze will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your activations if you wish to. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration Once the destination has been setup, and your DinMo model or segment created, you can create an activation to start sending data to Braze right away. The model or segment will be exported as an attribute value in Braze. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Audience Name The audience name will be the name of the attribute that will be created in the users table in Braze. DinMo will replace spaces by underscores. Make sure an attribute with the same name does not already exist. ### Fields mapping In this section, specify the DinMo field corresponding to the external ID that should be used by Braze to identify your users. This is the id that is defined in Braze in [UUIDs and GUIDs](https://en.wikipedia.org/wiki/Universally_unique_identifier) format.\ \ Refer to [this documentation](https://www.braze.com/docs/developer_guide/platform_integration_guides/web/analytics/setting_user_ids/) if you want to learn more about Braze external user IDs. # Send track events ## Overview With this destination service, DinMo will send track events (purchases events, conversions, or any custom event) to Braze. To do so, you will need to go through these three steps: * Creating a Braze destination. Refer to the [corresponding section](#destination-setup) for more info. {% hint style="warning" %} In the destination options, we have chosen to **separate custom events from purchases** because the APIs used by Braze are different. The documentation below remains valid for both destination services. {% endhint %} * Creating an event or custom model (or segment) composed of all the events you wish to send to Braze. All records of the segment correspond to **a unique event type** (for instance, purchase).
* Activating the model to the Braze destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. DinMo will only be inserting the newest events each time the activation will be running, without updating the previously inserted events. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start sending track events, you are first required to create a Braze destination with the corresponding destination service. ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo model containing all your events created, you can create an activation to start sending data to Braze right away. ### Event name When setting up a activation, you need to specify the related event name. All records of the model will be considered as events of this specific type (for instance, 'Drive to store', 'Purchase', etc.). Make sure your segment only contains conversions of the specified type. You must type the exact event type name, as it appears in Braze. Note that if no event type does with the specified name exists in Braze, DinMo will be creating it. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Meta. Braze will use the fields you send to identify the conversions and their values, and recognize each user behind the conversions. You must map the following field: * **Event time** (Required): The timestamp when the conversion took place * **External ID** (Required): The external ID of the user at the origin of the event Refer to [this documentation](https://www.braze.com/docs/developer_guide/platform_integration_guides/web/analytics/setting_user_ids/) if you want to learn more about Braze external user IDs. ### Synchronized attributes In this section, you can add as many attributes mapping as you would like. These attributes are meant to characterize with more details the events you are sending (for instance, what was the purchase price). To map an attribute, please select in the left side the DinMo field containing the attribute's value, and in the right side, please type the exact name of the attribute as it appears in Braze. Note that if the attribute you type does not exist in Braze, DinMo will create it. ### Scheduling In this section, specify how often the events should be sent to Braze. All new events will be sent in batch to Braze at the specified time interval. # Synchronize users attributes ## Overview In this destination service, DinMo will export and update attributes in the users table, and, optionally, insert new users. To do so, you will need to go through these three steps: * Creating a Braze destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment or user model composed of all the users and their attributes that will be updated in Braze. * Activating the model or segment to the Braze destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new users in the model will be inserted as a user in Braze (UPSERT) * All attributes values that have changed since the last activation will be updated in Braze If you chose not to insert new users, only users of the model who have an external id linked to an existing Braze user will be updated (UPDATE). ## Destination setup To start synchronizing contacts, you are first required to create a Braze destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo model created, you can create an activation to start sending data to Braze right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo model corresponding to the external ID or the Braze ID. This field will be used to link the model's records to existing users. Refer to [this documentation](https://www.braze.com/docs/developer_guide/platform_integration_guides/web/analytics/setting_user_ids/) if you want to learn more about Braze external user IDs. ### Sync modes Sync modes determine how data is synchronized between your data source and your Braze application. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Braze destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
UPDATEProcesses only changed records detected since the last sync and updates existing records in the destination. New records are ignored.
  • Enriching or correcting existing datasets
  • Attribute updates without data growth
  • Systems where record creation is handled elsewhere
  • Detects modified records using delta keys
  • Updates existing records only
  • Does not insert or delete records
  • Assumes records already exist in the destination
UPSERTProcesses new and changed records, inserting new records and updating existing ones as needed.
  • Standard synchronization use cases
  • Incremental data refresh
  • Large datasets with moderate change rates
  • Detects new and updated records
  • Inserts missing records
  • Updates existing records
  • Does not delete records
  • Balances data freshness and performance
MIRRORKeeps the destination fully synchronized with the source by applying inserts, updates, and deletions detected since the last sync.
  • Maintaining an exact replica of the source
  • Operational systems requiring strict consistency
  • Data pipelines with frequent deletes
  • Detects all changes using delta logic
  • Inserts new records
  • Updates changed records
  • Deletes records missing from the source
  • Requires connector support for delete operations
{% hint style="danger" %} **Warning — Use Mirror Mode with Caution** **Mirror sync mode permanently deletes records from the destination when they are no longer present in the source.**\ This includes contacts and related data. Once deleted, these records **cannot be recovered** unless they are reintroduced from the source in a future sync. Mirror mode should therefore be used **only when the source is the single source of truth** and when permanent deletions are an intended and fully controlled behavior.\ Always validate deletion rules and run Mirror syncs carefully, especially on production environments. {% endhint %} ### Synchronized attributes In this section, you can add as many attributes mapping as you would like. DinMo will keep the values of all the attributes mapped here up to date. To map an attribute, please select in the left side the DinMo field containing the attribute's value, and in the right side, please type the exact name of the attribute as it appears in Braze. Note that if the attribute you type does not exist in Braze, DinMo will create it. # Synchronize subscription statuses ## Overview In this destination service, DinMo will synchronize subscription status groups. To do so, you will need to go through these three steps: * On Braze, creating a subscription group (SMS or email) * On DinMo, creating a Braze destination. Refer to the [corresponding section](#destination-setup) for more info. * On DinMo, creating a user model or segment composed of all the users which are part of a given subscription group. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * On DinMo, activating the model or segment to the Braze destination to start sending data, specifying the target subscription group. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo model or segment will be marked as subscribed to the target subscription group * Any user leaving your DinMo model or segment will be unsubscribed from the subscription group Note that users who have never been part of the DinMo model or segment will not be modified by DinMo. Also, DinMo will only update the status of existing users in Braze. If some users who are part of the segment or model do not exist in Braze, they will be ignored. ## Destination setup To start synchronizing statuses, you are first required to create a Braze destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo model or segment created, you can create an activation to start sending data to Braze right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Subscription group In this section, you must enter the exact name of the subscription group ID. This group must already exist in Braze. Make sure the model or segment you are activating corresponds to the users of this target subscription group. If you wish to synchronize the subscription status of multiple groups, please create one activation per target subscription group. ### Fields mapping In the Fields mapping section, you are asked to specify which field corresponds to the external ID of the users. This is the field Braze will use to match the users' data sent by DinMo with their own users' data. ### Scheduling In this section, specify how often the list should be updated in Braze. Every time the list is updated: * Any new user having entered your DinMo segment since the last update will be marked as subscribed to the target subscription group, if and only if this user is already an existing Braze user * Any user having left your DinMo segment since the last update will be marked as unsubscribed from the subscription group # Brevo Sending data to Brevo: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination services: * [Synchronize contacts](/integrations/destination-platforms/brevo/synchronize-contacts) * [Export contact lists](/integrations/destination-platforms/brevo/export-contact-lists) Please refer to the dedicated documentation page for more information. ## Authentication to Brevo Regardless of the selected destination service, DinMo will always connect to Brevo using an API key. **Before** generating the API key, configure your Brevo account to establish a connection with DinMo. You can do this by either: * **Recommended:** Whitelisting [DinMo's IP addresses](/security-and-privacy/networking) by following Option 2 presented in [the Brevo documentation](https://help.brevo.com/hc/en-us/articles/5740111683858-Authorize-IP-addresses-for-API-calls-to-improve-security). * Disabling the Brevo IP address detection and authorization feature by following Option 3 in [the Brevo documentation](https://help.brevo.com/hc/en-us/articles/5740111683858-Authorize-IP-addresses-for-API-calls-to-improve-security). Once done, generate an API key in Brevo by clicking SMTP & API here:
Then, click the 'API Keys' tab:
And finally, generate a new API Key from there. Copy its value and paste it in the corresponding field when creating the Brevo destination in DinMo. # Synchronize contacts ## Overview In this destination service, DinMo will export and update attributes in the contacts table, and, optionally, insert new contacts. To do so, you will need to go through these three steps: * Creating a Brevo destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users and their attributes that will be updated in Brevo. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Brevo destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new contacts in the segment will be inserted as a contact in Brevo * All attributes values that have changed since the last activation will be updated in Brevo If you chose not to insert new contacts, only users of the segment who have an email address linked to a Brevo contact will be updated. If you chose to insert new contacts, they will be created in the list *DinMo*, located in the folder *DinMo*. Already existing contacts can be located anywhere. ## Destination setup To start synchronizing contacts, you are first required to create a Brevo destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Brevo right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the email address of the user (it must be in clear text). This field will be used to link the segment's records to existing contacts. You can then map any other attribute existing in Brevo. These attributes will then be updated by DinMo during each activation. ### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Brevo. The associated field will have the same name in Brevo and DinMo. The values of the attributes selected here will then also be updated at each activation. # Export contact lists ## Overview In this destination service, DinMo will create lists of contacts and keep them up to date in Brevo. To do so, you will need to go through these three steps: * Creating a Brevo destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users that will populate your Brevo list. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Brevo destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Brevo list * Any user leaving your DinMo segment will be removed from your Brevo list Note that only users who have an email linked to a Brevo contact will be present in your Brevo list. In this service, DinMo will not create new contacts in Brevo. ## Destination setup To start exporting lists, you are first required to create a Brevo destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} You will need to specify the folder in which your list will be created. ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your contacts lists to Brevo will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your audiences if you wish to. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Brevo right away. The segment will be exported as a list in Brevo. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Activation Name and Description In this section, the name you enter will be the name given to the list created in Brevo. By default, and if you activate your segment using the default activation settings, the name of the list will be the DinMo segment name. ### Fields mapping In the Fields mapping section, you are asked to specify which field corresponds to the email address of the users of the segment. ### Scheduling In this section, specify how often the list should be updated in Brevo. Every time the list is updated: * Any new user having entered your DinMo segment since the last update will be added to your list, if and only if this user is already an existing Brevo contact * Any user having left your DinMo segment since the last update will be removed from your list # Crisp Sending data to Crisp: Step-by-Step guide DinMo supports the sending of data to Crisp to keep people’s data up to date from your data warehouse. ## Supported Destination Services DinMo supports the following destination service: * [**Synchronize people’s data**](/integrations/destination-platforms/crisp/synchronize-peoples-data), to update people’s attributes values in Crisp Please refer to the dedicated documentation page for more information. ## Authentication to Crisp To connect DinMo to Crisp, you first need to install the DinMo plugin on your Crisp workspace. You can install it from the following link: `https://app.crisp.chat/initiate/plugin/b0a2fff3-21e7-4b94-8ef0-d69a8fd4d87d/` **Information needed** To create a Crisp destination in DinMo, you will need: * **Website ID**
Once the DinMo plugin has been installed on your Crisp workspace, copy your Crisp Website ID into DinMo to finalize the connection. # Synchronize people’s data ## Overview In this destination service, DinMo will export and update people’s attributes values in Crisp. To do so, you will need to go through these three steps: * [Creating a Crisp destination](/integrations/destination-platforms/crisp). Refer to the corresponding section for more info. * Creating a user segment composed of all the people and their attributes that will be updated in Crisp. Refer to this [step-by-step tutorial to learn how to build segments without SQL](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo) in DinMo. * Activating the segment to the Crisp destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * *(Upsert or Mirror mode only)* All people previously unknown to Crisp will be created in Crisp, with the associated attributes * All attributes values that have changed since the last activation will be updated in Crisp ## Activation configuration Once the destination has been set up, and your DinMo segment or model created, you can create an activation to start sending data to Crisp right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo) {% endhint %} ### **Sync Modes** When configuring your sync, you will be asked to choose the **Sync Mode**. Sync modes determine how data is synchronized between your data source and Crisp. They control whether to insert new records, update existing ones, or keep the destination aligned with the source. For the Crisp destination, here are the available options: | Sync Mode | Description | Use Case | Behavior | | --------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **UPSERT** | Inserts new people and updates existing people in Crisp. | Initial data loads. Standard synchronization when new people can be created in Crisp. | New people are created in Crisp. Existing people are updated with the latest attributes values. No deletions are handled. | | **UPDATE ONLY** | Updates existing people in Crisp without creating new ones. | Keeping Crisp data up to date only for people already known in Crisp. Avoiding the creation of new people in Crisp. | Existing people are updated with the latest attributes values. Unknown people are ignored and not created in Crisp. No deletions are handled. | | **MIRROR** | Keeps Crisp aligned with the source dataset. | Maintaining an exact replica of the source. Use cases requiring strict consistency between DinMo and Crisp. | New people are created. Existing people are updated. People missing from the source are removed or no longer synchronized, depending on the connector behavior. | **TLDR;** * **Upsert mode** never deletes records from the destination, even if they are removed from the source. * **Update only mode** never creates new records in the destination. * **Mirror mode** ensures full alignment between the source and the destination.\ ⚠️ This irreversibly deletes the profile from Crisp. {% hint style="danger" %} **Warning — Use Mirror Mode with Caution** **Mirror sync mode permanently deletes records from the destination when they are no longer present in the source.** This includes contacts and related data. Once deleted, these records **cannot be recovered** unless they are reintroduced from the source in a future sync. Mirror mode should therefore be used **only when the source is the single source of truth** and when permanent deletions are an intended and fully controlled behavior. Always validate deletion rules and run Mirror syncs carefully, especially on production environments. {% endhint %} ### **Fields mapping** In the Fields mapping section, you are asked to specify the field contained in your DinMo segment that Crisp will use to link each segment’s records to a Crisp person. Depending on your Crisp configuration, it may be the email address of the person, or another external identifier. You can also map the standard fields required to identify and update people in Crisp. ### **Synchronized attributes** In this section, any field you select will be exported as a people attribute in Crisp. If the attribute does not already exist in Crisp, DinMo will create it. The associated field will have the same name in Crisp and DinMo. These values of the attributes selected here will then be updated at each activation. ### Scheduling In this section, specify how often the attributes should be updated in Crisp. Every time the audience is updated: * **Mirror and upsert:** Any new user having entered your DinMo segment since the last update will be added to your Crisp website * **All modes**: For all existing profiles, the attributes will be updated * **Mirror:** Any user having left your DinMo segment since the last update will be deleted from your Crisp account # Criteo Sending data to Criteo: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination service: * [Export audiences](/integrations/destination-platforms/criteo/export-contact-lists) Please refer to the dedicated documentation page for more information. ## Authentication to Criteo Regardless of the selected destination service, DinMo will always connect to Criteo using OAuth2 authentication. Please make sure the user who connects Criteo on DinMo has the right permissions on the target ad accounts. # Export contact lists ## Overview In this destination service, DinMo will create audience segments and keep them up to date in Criteo. To do so, you will need to go through these three steps: * Creating a Criteo destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users that will populate your Criteo audience segment. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Criteo destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Criteo audience segment * Any user leaving your DinMo segment will be removed from your Criteo audience segment ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start exporting audiences, you are first required to create a Criteo destination with the corresponding destination service. You will need to specify the ad account in which your audience will be created. *Note: If the ad account you seek is not listed, it means that the user who connected DinMo to Criteo does not have the permissions for this account.* ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your audiences to Criteo will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your audiences if you wish to. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Criteo right away. The segment will be exported as a new audience in Criteo. ### Activation Name and Description In this section, the name you enter will be the name given to the audience segment created in Criteo. You may also optionally enter a description, that will be attached to the audience segment in Criteo. By default, and if you activate your segment using the default activation settings, the name of the audience segment will be the DinMo segment name, and the name of the description will be the DinMo segment description. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Criteo. Any non mapped fields in your segment will not be sent to Criteo. Criteo will use the fields you send to recognize each user of your segment. You need to map at least one of the following fields: * **Email**: The email addresses of the users in clear text, or hashed (SHA-256) * **Customer Id**: only for Retail Media Customer Lists * **LiveRamp identity link** * **Mobile Ad identifier** The higher the number of identifiers you send, the highest the match rate will be. ### Scheduling In this section, specify how often the audience segment should be updated in Criteo. Every time the audience segment is updated: * Any new user having entered your DinMo segment since the last update will be added to your Criteo audience segment * Any user having left your DinMo segment since the last update will be removed from your Criteo audience segment # Dialog Insight ## **Supported Destination Services** DinMo supports the following destination service: * [Synchronise contacts](/integrations/destination-platforms/dialog-insight/synchronise-contacts) Please refer to the dedicated documentation page for more information. ## **Authentication to Dialog Insight** Regardless of the selected destination service, DinMo will always connect to Dialog Insight via an SFTP repository. You will need this Dialog Insight information to log in: * Authentication Key Identifier * Authentication Key {% hint style="info" %} If you haven’t configured Web Services Access yet, you can consult the [official documentation](https://support.dialoginsight.com/en/support/solutions/articles/1000256347-configuring-web-services-access?utm_source=chatgpt.com) to learn more about Authentication Key Identifier and Key. {% endhint %} You will also need some information directly related to your SFTP repository * SFTP user * SFTP password * SFTP host * SFTP port *(usually 22, which is filled by default)* Please make sure the user who connects Dialog Insight on DinMo has **the right permissions to create new imports** directly in the destination. # Synchronise Contacts ## Overview In this destination service, DinMo will update the contacts fields value in a given contact list, and optionally insert new contacts. To do so, you will need to go through these three steps: * Creating a Dialog Insight destination. Refer to the corresponding section for more info. * Configuring an automated import on the Dialog Insight side * Creating a user segment composed of all the users that will populate your Dialog Insight account and that you want to keep up to date. * Activating the segment to the Dialog Insight destination to start sending data. Every time the activation runs: * DinMo performs an **upsert** operation: * **Insertion:** If a contact doesn’t exist in the target list, DinMo will create it using the mapped attributes. * **Update:** If a contact exists, DinMo updates only the mapped attribute values. {% hint style="warning" %} DinMo cannot create new attributes. You'll need to create them in Dialog Insigth first before you can map them in DinMo. {% endhint %} DinMo will not delete existing contacts even if the profile no longer exists in the model or segment. It will simply stop updating their attributes. ## **Destination setup** ### Dialog Insight setup {% hint style="danger" %} You will need to create an automated import in your Dialog Insight account before sending data with DinMo {% endhint %} To do so, in Dialog Insight: * Go in Projects, and then “Data Management” * In the “Imports/Exports” tab, click on “Import Automation” * Create a new import automation with this information: * **Import name**: The import name you choose * **Import type**: Select the type of import you want, between: * **Normal**: Existing records will be updated, and new records added. * **Add only**: New records will be added, and existing records ignored. * **Update only**: Existing records will be updated, and new records ignored. * **Complete replacement**:This import will first perform a **normal import**. Once migration is completed, all contacts who have not been affected by the import will be **deactivated**. As a result, only contacts who were in the imported file will remain as active contacts. * Choose the SFTP Server from which data will be imported * Enter the name of the CSV file to be used for DinMo activations. You can choose any name you like, but it must remain the same thereafter.
* Don't change anything else in the default settings, except “Schedule Launch”, which should be set to **“Remote Launch”**. ## DinMo setup {% hint style="info" %} Learn how to create such a destination in our [step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start exporting audiences, you are first required to create a Dialog Insight destination with the corresponding destination service. During configuration, we'll ask you for the Project ID and Import ID, available in your Dialog Insight account: * **Project ID**: On the top bar, click on your project's parameter icon, then “All projects”. This will list all your existing projects and their associated IDs.
* **Import ID**: Go the “Automatic Import” you’ve just created. In the URL, you will find your Import ID. ## **Activation configuration** {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Dialog Insight right away. * Specify the file name to store your synchronized data {% hint style="warning" %} The name must be similar to the one you entered when configuring your automated import {% endhint %} * Define the mapping between your data warehouse and Dialog Insight attributes. ### **Fields mapping** In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Dialog Insight. Any mapped field in your segment will be sent to Dialog Insight. {% hint style="warning" %} You can only map fields that already exist in your Dialog Insight account. If you need to create new fiels, you have to do it directly in Dialog Insight. {% endhint %} The field used as the **unique Dialog Insight identifier** must be mapped in order to match the various contacts. This field could be the email address, for example. ### **Scheduling** In this section, specify how often the audience should be updated in Dialog Insight. Every time the audience is updated: * DinMo will perform an upsert operation, inserting new contacts or updating existing ones. * Existing contacts not found in the current DinMo data segment or model will remain in Dialog Insight but will not be updated further. # Dotdigital DinMo's Dotdigital integration enables marketing teams to effortlessly achieve their business objectives using data from their data warehouse. DinMo supports the following destination services: * [Synchronize contacts](/integrations/destination-platforms/dotdigital/synchronize-contacts): Update existing Dotdigital contacts with the latest field values and optionally insert new contacts. * [Synchronize Insight Data Collections](/integrations/destination-platforms/dotdigital/synchronize-insight-data-collections): Insert and update records in a Dotdigital Insight Data collection using data from your warehouse. * [Export Contact Lists](/integrations/destination-platforms/dotdigital/export-contact-lists): Create and maintain Dotdigital contact lists based on audience membership in DinMo. * [Customer program enrolment](/integrations/destination-platforms/dotdigital/customer-program-enrolment): Enroll contacts into an existing Dotdigital program when they enter a DinMo audience. Each destination service covers a specific use case, from keeping contact data up to date to enrolling customers into Dotdigital programs. Please refer to the dedicated documentation page for more information. ## Authentification to Dotdigital Regardless of the selected destination service, DinMo will always connect to Dotdigital using an API key. ### 🔐 Steps to Create an API User in Dotdigital 1. **Log in to Dotdigital**: Access your Dotdigital account with your regular credentials. 2. **Navigate to Settings**: In the bottom-left corner, expand the **User menu** and select **Settings**. 3. **Access API Users**: Go to **Access** > **API users**. 4. **Create a New API User**: * Click on **New User**. * A username (email address) will be automatically generated for you and cannot be edited. * Optionally, add a description to identify the purpose of this API user. * Enter and confirm a password. The password must be at least eight characters long and include at least one digit or non-alphanumeric character. * For rate limiting, select **Tiered**. * Set the status to **Enabled**. * Click **Save** to create the API user.

How to: Create an API User in Dotdigital

# Synchronize contacts Sync your models profiles and attributes into your Dotdigital account to build customer connections with personalized campaigns ## Overview In this destination service, DinMo will export and update attributes in the contacts table, and, optionally, insert new contacts. To do so, you will need to go through these three steps: * Creating a Dotdigital destination. Refer to the [corresponding section](/integrations/destination-platforms/dotdigital) for more info. * Creating a user segment composed of all the users and their attributes that will be updated in Dotdigital. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Dotdigital destination to start sending data. Each time the activation will be running: * All new contacts in the segment will be inserted as a new contact in Dotdigital (if they don't exist in your account yet) * Please note: **any new contacts** that are created during an activation are automatically subscribed to the email channel, so please ensure this is considered during setup. Existing contacts subscription status will be unchanged. * All attributes values that have changed since the last activation will be updated in Dotdigital. * Custom attributes not present in Dotdigital will be created upon the first synchronization and regularly updated afterward. {% hint style="info" %} DinMo will not delete existing contacts even if the profile no longer exists in the model or segment. It will simply stop updating the attributes. {% endhint %} ## Destination Setup To start synchronizing contacts, you are first required to create a Dotdigital destination with the corresponding destination service (*Synchronize contacts*). {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation Setup Once the destination has been setup, and your DinMo segment created, you can create an activation to start synchronizing data to Dotdigital right away. In the Activation page, click on "New activation" and select the segment or model you wish to use to update your contacts' attributes in Dotdigital. Then, select your Dotdigital destination you've just created. ### Matching Identifier First, you need to fill in the matching identifier. This must be the contact ID, phone number or email address. This field is used to match the data in your data warehouse with the contacts already in your Dotdigital account. {% hint style="warning" %} If Contact ID is available in your data warehouse, it must be selected as matching identifier. This is the **preferred matching identifier**. {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the matching identifier. You can then map any other attribute existing in Dotdigital. These attributes will then be updated by DinMo during each activation. ### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Dotdigital. You can choose the name of the associated field that will be used in Dotdigital. The values of the attributes selected here will then also be updated at each activation.

The 3 mapping steps in DinMo

### Scheduling Define how frequently your data is updated in Dotdigital. With each scheduled update: * DinMo will perform an upsert operation, inserting new contacts or updating existing ones. * Existing contacts not found in the current DinMo data segment or model will remain in Dotdigital but will not be updated further. ### Warnings In this section, specify if you want to receive warning for your Dotdigital activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %}
# Synchronize Insight Data collections Insight data is made up of collections of of structured data related to your customers’ purchasing histories, browsing habits, or product reviews. ## Overview In this destination service, DinMo will export records and update attributes for collections of data associated to your contacts. A collection can take a predefined structure, or custom collections can be created for more bespoke use cases. To begin setup, you will need to go through these three steps: * Creating a Dotdigital destination. Refer to the [corresponding section](/integrations/destination-platforms/dotdigital) for more info. * Creating a segment or model composed of all the insight data records and attributes that will be inserted and updated in Dotdigital. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment / model to the Dotdigital destination to start sending data. Each time the activation is running: * All new insight data records will be added as part of the collection and attached to the relevant contact or account * All attribute values that have changed for a particular insight data record since the last activation will be updated in Dotdigital. * Custom (new) attributes not present in Dotdigital will be created upon the first synchronization and regularly updated afterward. Note: * Insight data records will not be deleted from Dotdigital. If a record drops out of the segment / model you are using, the record will simply stop being updated. * Any Insight Data record shared in this activation **MUST** have an associated contact (and matching identifier) that already exists in Dotdigital. {% hint style="info" %} **Data Retention:** the retention policy of an insight data collection is available for you to edit based on the kind of data within the collection. Please see Dotdigital documentation [found here](https://support.dotdigital.com/en/articles/8199279-the-non-developers-guide-to-insight-data) (scroll part way down to 'Edit insight data properties') for more details on how to set this for each of your collections. {% endhint %} ## Destination setup To start exporting Insight data records, you are first required to create a Dotdigital destination with the corresponding destination service. When selecting 'Synchronize Insight Data Records', you must choose a collection for the Insight data records to be associated to. Here you can choose: * Use existing collection * Create a new collection It is not recommended to have more than one activation managing a single collection, therefore it is likely you will choose create new collection here. Next you must choose the collection scope; whether the collection will be at the contact level or account level. For new collections, you then have two options for collection types: * using one of the predefined collection types from the list, all containing a naming convention and predefined structure * or creating a custom collection which allows you to create a custom defined schema. Note: the collections that you have access to can vary depending on the account type. Documentation can be found [here](https://support.dotdigital.com/en/articles/8199279-the-non-developers-guide-to-insight-data) for collection types. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo model or segment created, you can configure an activation to start sending data to Dotdigital right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Matching Identifier Here you are asked to choose the matching identifier, which is the field used to match the Insight data records in your data warehouse to an existing contact in Dotdigital, and takes one of the following: * Contact ID (internal Dotdigital ID created upon creation of a contact in Dotdigital) * Email address * Phone number Note: it is recommended that a consistent identifier is used across all Dotdigital activations within DinMo. If Contact ID exists in your data warehouse, this should be the identifier you chose. ### Fields mapping In the Fields mapping section, you are asked to specify the fields you would like to include as part of the Insight data collection activation. This should include all the attributes associated to your insight data record, which can be used in Dotdigital as part of the Insight data feature. The following mappings are mandatory: * Record Key - this refers to the unique identifier associated to each of the individual Insight data records (such as a transaction ID, or other "child" ID). * Matching Identifier - this is the mapping for the matching identifier selected above, to allow Dotdigital to match each of the insight data records to a contact or account. After this, you can add as many mappings as you like to include all necessary attributes associated to the insight data records. Any new attributes that do not exist in Dotdigital can be added as new attributes to the schema in the next section. Note: any new attribute names must be lowercase, and only contain alphanumeric characters, hyphens, or underscores. Any existing attributes that are removed from the mappings will also be removed from the Insight data records during the sync. Therefore, please ensure there are no dependencies on certain attributes before removing a mapping from an active sync. ### Scheduling In this section, specify how often the list should be updated in Dotdigital. Every time the list is updated: * Any new Insight data record having entered your DinMo model or segment since the last update will be added, if and only if this user is already an existing Dotdigital contact * Any new mapping added to the Insight data record activation, or any updated value for existing attributes, will be updated during the next activation run ### Warnings In this section, specify if you want to receive warnings for your Dotdigital activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Export contact lists ## Overview In this destination service, DinMo will create lists of contacts and keep this list up to date in Dotdigital. To do so, you will need to go through these three steps: * Creating a Dotdigital destination. Refer to the [corresponding section](/integrations/destination-platforms/dotdigital) for more info. * Creating a user model or segment composed of all the users that will populate your Dotdigital list. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the model or segment to the Dotdigital destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Dotdigital list * Any user leaving your DinMo segment will be removed from your Dotdigital list Note: * If a contact does not already exist in Dotdigital that is part of your list, a new contact will be created. The contact will however be created with only a single identifier ([one of the below mappings](#fields-mapping)), so it is recommended that any contact used in a list is included in your 'Synchronize contacts' activation, and that a consistent identifier is used across all Dotdigital activations. * DinMo will not delete contacts in your Dotdigital database, contacts will only be removed from the chosen list. ## Destination setup To start exporting lists, you are first required to create a Dotdigital destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your contact lists to Dotdigital will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your audiences if you wish. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration Once the destination has been setup, and your DinMo model or segment created, you can configure an activation to start sending data to Dotdigital right away. The segment will be exported as a contact list in Dotdigital. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Activation Name and Description In this section, the name you enter will be the name given to the list created in Dotdigital. By default, and if you activate a segment using the default activation settings, the name of the list will be the DinMo segment name. ### List Visibility This gives you the flexibility to chose whether the contacts in a list are either private or public. This depends on your preference for having the list visible in your organisations preference centre within Dotdigital. ### Fields mapping In the Fields mapping section, you are asked to specify the field that corresponds to one of three identifiers for each of the users of the segment. This is the field that Dotdigital will use to recognize the contacts sent by DinMo from your data warehouse, and takes one of the following: * Contact ID (internal Dotdigital ID created upon creation of a contact in Dotdigital) * Email address * Phone number Note: please bare in mind that any new contacts created through a list activation will be created with the single identifier mapped above. It is recommended to use a consistent identifier across all Dotdigital activations, and to include all contacts in lists within your synchronize contacts activation. If Contact ID exists in your data warehouse, this should be the identifier you chose. ### Scheduling In this section, specify how often the list should be updated in Dotdigital. Every time the list is updated: * Any new user having entered your DinMo model or segment since the last update will be added to your list, if and only if this user is already an existing Dotdigital contact * Any user having left your DinMo model or segment since the last update will be removed from your list # Customer program enrolment Enroll DinMo Profiles programmatically to your Dotdigital programs ## Overview In this destination service, DinMo will enroll customers to the selected program in Dotdigital. Use this destination service when you want DinMo to enroll contacts into a program that is already built in Dotdigital. This is the right option when membership in a DinMo audience should trigger entry into a Dotdigital journey. To do so, you will need to go through these three steps: * Creating a Dotdigital destination. Refer to the corresponding section for more info. * Creating a user model or segment composed of all the users that should be enrolled into the program. * Activating the model or segment to the Dotdigital destination to start sending data. Each time the activation runs: * Any new user entering your DinMo audience will be enrolled into the selected Dotdigital program. * Users who were already enrolled by a previous run will not be enrolled again unless your Dotdigital program allows re-enrolment. * DinMo will not remove contacts from the program if they later leave the audience. {% hint style="info" %} **Note:** * The target program must already exist in Dotdigital. * Contacts must already exist in Dotdigital before enrolment occurs. * It is therefore recommended to keep all eligible contacts synced to Dotdigital through a **Synchronize contacts** activation before using this destination service. {% endhint %} ## Destination setup To start enrolling customers into a Dotdigital program, you are first required to create a Dotdigital destination with the corresponding destination service. * Go To Destinations * Click on "New Destination" * Choose your Dot Digital Platform * On the next page choose the Destination Option: **Customer Program Enrolment** * Give it a name * Save Your destination is now ready and you can start firing actions.
### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to set up Default Activation Settings. This step is optional, but highly recommended to facilitate the activation process. By configuring default settings, enrolling new audiences into the same Dotdigital program will take just one click. Without default settings, you will be required to go through the configuration each time you activate a new audience. Note that even if you set up default settings, you will still be able to adjust activation settings for each audience if you wish. Refer to the Activation configuration section for more information about the default settings configuration process. ## Activation configuration Once the destination has been set up, and your DinMo model or segment created, you can configure an activation to start sending data to Dotdigital right away. ### Program selection When setting up an activation, you need to specify the Dotdigital program that contacts should be enrolled into. The selected program must already exist in Dotdigital and be configured to accept API-based enrolments. Make sure your audience only contains contacts that should enter this specific program.
## Fields mapping In the **Fields mapping** section, you are asked to specify the field that corresponds to one identifier for each of the users in your audience. This is the field that Dotdigital will use to recognize the contacts sent by DinMo from your data warehouse. Supported identifiers are: * Contact ID (internal Dotdigital ID created upon creation of a contact in Dotdigital) * Email address * Phone number At least one identifier must be mapped. Note: * Contacts must already exist in Dotdigital before they can be enrolled into a program. * It is recommended to use a consistent identifier across all Dotdigital activations. * If Contact ID exists in your data warehouse, this should be the identifier you choose. ### Activation behavior This destination service behaves like an event-style enrollment flow. DinMo will only enroll the newest contacts entering the audience each time the activation runs. Previously enrolled contacts are not updated by this destination service, and leaving the audience does not remove a contact from the Dotdigital program. ## Important notes ### Contacts must already exist in Dotdigital This destination service only enrolls contacts into an existing Dotdigital program. It does not create the contacts themselves. If a contact does not already exist in Dotdigital, the enrolment will fail. For this reason, we recommend synchronizing contacts to Dotdigital first. ### Enrolment is asynchronous Dotdigital processes program enrolments asynchronously. As a result, contacts may not appear in the program instantly after DinMo sends them. ### Program start behavior When contacts are enrolled into a program through the Dotdigital API, they start the journey immediately rather than waiting for the program’s next scheduled execution. ### Re-enrolment behavior Whether a contact can enter the same program again depends on the enrolment limits configured in Dotdigital. If the program is configured to allow contacts to enter only once, DinMo will not be able to re-enroll previously exited contacts into that same program. If the program allows re-enrolment after exit or after a delay, DinMo can enroll them again when they re-enter the audience. ### This destination service does not remove contacts from programs Customer program enrolment is a one-way action from DinMo to Dotdigital. If a contact leaves your DinMo audience after being enrolled, DinMo will not remove them from the Dotdigital program. Program exits and removals must be handled inside Dotdigital itself. ## Recommended use cases Use **Customer program enrolment** when you want DinMo to control who should enter a Dotdigital program based on warehouse data. Typical examples include: * enroll contacts into a welcome or onboarding program * enroll customers into a retention or win-back program * enroll users into a post-purchase or post-signup journey * enroll contacts into a reminder or lifecycle program based on audience entry ## When not to use this destination service Do not use this destination service if your goal is to: * create or update contacts in Dotdigital * sync attributes to Dotdigital contacts * create and manage contact lists in Dotdigital For those use cases, use the corresponding Dotdigital destination services instead. # Emarsys Sending data to Emarsys: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination services: * [Export contact lists](/integrations/destination-platforms/emarsys/export-contact-lists) * [Synchronize contacts data](/integrations/destination-platforms/emarsys/synchronize-contacts-data) * [Synchronize custom table's data (RDS)](/integrations/destination-platforms/emarsys/synchronize-custom-tables-data-rds) Please refer to the dedicated documentation page for more information. ## Authentication to Emarsys Regardless of the selected destination service, DinMo will always connect to Emarsys with an API user. **Setup:** You will need your username, typically in the format of "account\_name00X" (X representing a digit), and the API secret. For an API secret, you need to create a new API user for DinMo under *Admin > Security Settings*. **API Endpoint Configuration:** During the API key creation, you will need to enable the necessary endpoints. DinMo requires the following collection of endpoints: **contacts**, **fields**, and **contact lists**. Please refer to the [Emarsys documentation](https://dev.emarsys.com/docs/core-api-reference/b3c3a1eba8515-authentication#creating-api-users) to learn more about permissions and API users. {% hint style="warning" %} Note that only account owners (and not admins) can create API users in Emarsys. {% endhint %} # Export contact lists ## Overview In this destination service, DinMo will create lists of contacts and keep them up to date in Emarsys. To do so, you will need to go through these three steps: * Creating an Emarsys destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user model or segment composed of all the users that will populate your Emarsys list. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the model or segment to the Emarsys destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Emarsys list * Any user leaving your DinMo segment will be removed from your Emarsys list Note that only users who have an email linked to an existing Emarsys contact will be present in your list. In this service, DinMo will not create new contacts in Emarsys. Also note that DinMo will not delete contacts in your Emarsys database. ## ## Destination setup To start exporting lists, you are first required to create an Emarsys destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your contacts lists to Emarsys will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your audiences if you wish to. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration Once the destination has been setup, and your DinMo model or segment created, you can configure an activation to start sending data to Emarsys right away. The segment will be exported as a contact list in Emarsys. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Activation Name and Description In this section, the name you enter will be the name given to the list created in Emarsys. By default, and if you activate a segment using the default activation settings, the name of the list will be the DinMo segment name. ### Fields mapping In the Fields mapping section, you are asked to specify which field corresponds to the email address of the users of the segment. This is the field that Emarsys will use to recognize the contacts sent by DinMo. ### Scheduling In this section, specify how often the list should be updated in Emarsys. Every time the list is updated: * Any new user having entered your DinMo model or segment since the last update will be added to your list, if and only if this user is already an existing Emarsys contact * Any user having left your DinMo model or segment since the last update will be removed from your list # Synchronize contacts data ## Overview In this destination service, DinMo will export and update attributes in the contacts table, and, optionally, insert new contacts. To do so, you will need to go through these three steps: * Creating an Emarsys destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user model or segment composed of all the users and their attributes that will be updated in Emarsys. * Activating the model or segment to the Emarsys destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new contacts in the model or segment will be inserted as a contact in Emarsys * All attributes values that have changed since the last activation will be updated in Emarsys If you chose not to insert new contacts, only users of the model who have an email address linked to an existing contact in Emarsys will be updated. If you chose to insert new contacts, they will be created in the list you define in the setup of the destination. Already existing contacts can be located anywhere. Note that you might have to wait a bit before you see the contacts being creating in the Emarsys interface. ## Destination setup To start synchronizing contacts data, you are first required to create an Emarsys destination with the corresponding destination service. In this process, specify in which contacts list new contacts will be created. This is because Emarsys requires each contact to be part of at least one list. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo model or segment created, you can create an activation to start sending data to Emarsys right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo model corresponding to the email address of the user (it must be in clear text). This field will be used to link the model's records to existing contacts. You can then map any other attribute existing in Emarsys. These attributes will then be updated by DinMo during each activation. ### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Emarsys. The associated field will have the same name in Emarsys and DinMo. The values of the attributes selected here will then also be updated at each activation. # Synchronize custom table's data (RDS) ## Overview This destination service is only relevant for Emarsys accounts with Relational Data Service (RDS) enabled. In this destination service, DinMo will export and update rows of a pre-defined custom table located in Emarsys Relational Data Service (RDS), and optionally, insert new rows into this table. {% hint style="warning" %} The custom table should already exist in Emarsys RDS, with its schema configured, and, one of its column corresponding to the primary key should be exactly named 'id'. {% endhint %} To create such an activation, you will need to go through these three steps: * Creating an Emarsys destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a **custom** segment or **custom** model composed of all the records and their attributes that will be updated in Emarsys. * Activating the model to the Emarsys destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new records in the model will be inserted in the Emarsys custom table * All rows values that have changed since the last activation will be updated in the Emarsys custom table If you chose not to insert new records, only records of the model which are already present in Emarsys will be updated. ## Destination setup To start synchronizing custom tables' data, you are first required to create an Emarsys destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} In this process, you must enter the connection name in which your target table is contained. The connection name can be found under the *Connections* tab of the *Relational Data* add-on in Emarsys:
Next, enter the name of the target custom table that DinMo will update. The table must have been prievously created on Emarsys side. The table must already contain all relevant columns that DinMo will be updating, and, it must have a column exactly named `id`, that will be used to match records between DinMo and Emarsys. ## Activation configuration Once the destination has been setup, and your DinMo model created, you can create an activation to start sending data to Emarsys right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo model corresponding to the identifier column of the target custom table. This field will be used to link the model's records to existing rows in Emarsys. You can then map any other column existing in your Emarsys custom table. These attributes will then be updated by DinMo during each activation. #### Notes {% hint style="warning" %} Due to a limitation in Emarsys, Boolean values must be sent in 0/1 format. A Boolean True/False is always interpreted as False in the Emarsys RDS API. {% endhint %} # Fincome Sending data to Fincome: Step-by-Step guide DinMo supports the sending of data to Fincome to keep customer’s data up to date from your data warehouse. ## Supported Destination Services DinMo supports the following destination service: * [**Synchronize customers’s data**](/integrations/destination-platforms/fincome/synchronize-customers-data), to update customers’s attributes values in Fincome Please refer to the dedicated documentation page for more information. ## Authentication to Fincome To connect DinMo to Fincome, you first need to create an API key in your Fincome platform. Go to Settings, then to Developers and Create a secret key.
**Information needed** To create a Fincome destination in DinMo, you will need: * **API\_KEY** # Synchronize customers' data ## Overview In this destination service, DinMo will export and update people’s attributes values in Fincome. To do so, you will need to go through these three steps: * [Creating a Fincome destination](/integrations/destination-platforms/fincome). Refer to the corresponding section for more info. * Creating a user segment composed of all the people and their attributes that will be synchronized with Fincome. Refer to this [step-by-step tutorial to learn how to build segments without SQL](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo) in DinMo. * Activating the segment to the Fincome destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation runs: * *(Insert Only mode only)* All people previously unknown to Fincome will be created in Fincome with the associated attributes * *(Update Only mode only)* Existing people already available in Fincome will have their attributes updated * Existing attributes values that have changed since the last activation will be synchronized according to the selected sync mode ## Activation configuration Once the destination has been set up, and your DinMo segment or model created, you can create an activation to start sending data to Fincome right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo) {% endhint %} ### **Sync Modes** When configuring your sync, you will be asked to choose the **Sync Mode**. Sync modes determine how data is synchronized between your data source and Fincome. They define whether new records should be created, existing records updated, or both. For the Fincome destination, here are the available options: | Sync Mode | Description | Use Case | Behavior | | --------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **INSERT ONLY** | Inserts new people into Fincome without updating existing records. | Initial imports or use cases where only new people should be added without modifying existing Fincome profiles. | New people are created in Fincome. Existing people already present in Fincome are ignored and remain unchanged. | | **UPDATE ONLY** | Updates existing people in Fincome without creating new records. | Keeping existing Fincome profiles synchronized while preventing the creation of additional people. | Existing people are updated with the latest attributes values. Unknown people are ignored and not created in Fincome. | **TLDR;** * **Insert only mode** creates new records but never updates existing ones. * **Update only mode** updates existing records but never creates new ones. * Neither mode deletes records from Fincome. {% hint style="info" %} **Note** No profile deletions are performed by the Fincome connector. People removed from the source segment will remain in Fincome unless deleted directly within Fincome. {% endhint %} ### **Fields mapping** In the Fields mapping section, you are asked to configure how the columns in your segment data should be mapped to fields in your destination. Some of the fields are marked as required by the destination platform to better map your data. At the moment, the only required field is customer\_id. ### **Create new custom attributes in Fincome** The selected fields will be exported as new attributes to the destination if they don't already exist. In all cases, DinMo will ensure they are kept up to date. ### Scheduling In this section, specify how often the attributes should be updated in Fincome. Every time the audience is refreshed: * **Insert only:** Any new user entering your DinMo segment since the last update will be added to Fincome * **Update only:** Existing users already present in Fincome will have their attributes updated * **All modes:** Attribute values already synchronized can be refreshed according to the selected synchronization behavior # Firestore DinMo's Firestore integration enables marketing teams to effortlessly activate real-time warehouse data, improving personalization and boosting customer engagement. ## Supported destination services {% hint style="info" %} Learn more about all of our Destination service types on our [Core Concepts page](/core-concepts). {% endhint %} DinMo supports syncing User models (or segments) and associated fields to **Firestore Documents**. Refer to these two documentation pages for detailed guidance on setting up an activation with your connected Firestore platform: * [Export Audiences](/integrations/destination-platforms/firestore/export-audiences) * [Create and update Collection Documents](/integrations/destination-platforms/firestore/create-and-update-collection-documents) ## Connect Firestore to DinMo There are two ways to connect your Firestore integration to DinMo: **Option 1: Direct Firestore Access** * Recommended for teams already using Firebase or Firestore directly. * Requires generating and uploading a JSON service account key directly from your Google Cloud Console. * The service account must have the **Cloud Datastore User** role.
**Option 2: Access via Google Cloud Platform (GCP)** * Suitable for teams managing Firestore through a broader GCP setup. * Requires generating and uploading a JSON service account key from your GCP console. * The service account must have the **Cloud Datastore User** role. Follow these steps to successfully connect your Firestore platform to DinMo: **1. Prerequisites** Ensure you have appropriate permissions in your Google Cloud Platform (GCP) project. * Log in to your [Google Cloud Console](https://console.cloud.google.com/). * Navigate to **IAM & Admin > Service Accounts**. * Verify you have permission to create or manage service accounts with the role **Cloud Datastore User**. * If you lack the required permissions, contact your GCP admin. **2. Set Up Firestore and Generate Credentials** * In your GCP console, navigate to **Firestore** and ensure your database is running in **Native mode**. * Collect the **database name** and the **documents collection** that you want DinMo to use for your activations. * ```
``` * Navigate to **IAM & Admin > Service Accounts**. * Select an existing service account or create a new one with Firestore permissions. * Click on the service account, navigate to the **Keys** tab, and generate a new JSON key. * Download the generated JSON key file and store it securely. **3. Connect Firestore as a Platform in DinMo** * In DinMo, navigate to the **Destinations** section from the navigation bar. * Click "Add a new destination". * Select "Connect a new platform" and choose **Firestore**. * Enter a recognizable name for your platform connection. * Upload the JSON key file you downloaded from your GCP account. * Enter your Firestore Project ID and (optionally) specify the database name if not using the default. * Save the connection. Your Firestore platform is now connected to DinMo! To proceed, refer to the dedicated destination options to initiate your first Firestore activation. # Create and update Collection Documents Sync your models profiles and attributes into a Firestore collection document to enable real-time personalization and rapid data retrieval in your apps and websites. ## **Overview** This destination service allows DinMo to insert new documents or update existing ones in your Firestore collections based on your DinMo profiles or segments. To use this service, follow these three steps: 1. **Create a Firestore destination**. Follow our step-by-step guide to establish this connection. 2. **Create your DinMo user segment or data model** representing the data you want to sync to Firestore. 3. **Activate your segment or model** with the Firestore destination to start synchronization. Every time the activation runs: * DinMo performs an **upsert** operation: * **Insertion:** If a Firestore document matching the provided Document ID does not exist, DinMo will create it using the mapped attributes and document id value. * **Update:** If a document exists, DinMo updates only the mapped attribute values. * Attributes that exist will have their values updated. * Attributes not present in the document will be created upon the first synchronization and regularly updated afterward. * DinMo will not delete existing documents even if the profile no longer exists in the model or segment. It will simply stop updating these documents. ## **Destination Setup** Before beginning data synchronization, set up your Firestore destination: * Go to destinations > Add a destination. * Choose your Firestore Platform. * Click on **Create and update Collection Documents** option. * Give it a name and save the destination. ## **Activation Configuration** Once the Firestore destination is configured, create an activation to begin syncing your data: * Choose your attribute **write mode**: * **Merge**: will only update the provided fields in the [fields mapping](#field-mapping) * **Overwrite**: will replace the entire document with the provided fields, meaning that existing fields could be deleted * Specify the **Firestore collection name** to store your synchronized data. * Optionally, add a "Last a updated at" timestamp or a "Time to live" to each document: * **Last updated at**: DinMo will add this field to each document of the collection. The value will be the timestamp of the last update for this document. * **Time to live**: DinMo will add the "Time to live" value to this field in each document. If you want to automatically delete expired documents, this needs to be the same value as the TTL policy set on your firestore database.
### **Sync mode** Sync modes determine **how data is synchronized between your data source and your** **Firestore**. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Firestore destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
UPSERTPerforms a full load on the first run, then processes only new or changed records on subsequent runs using DinMo’s delta detection logic.
  • Standard production setup
  • Large datasets with limited changes
  • Frequent syncs requiring good performance
  • First run processes all records
  • Subsequent runs process only inserted or updated records
  • Connector inserts new records and updates existing ones
  • No deletions are handled
MIRROR (full then delta)Performs a full load on the first run, then keeps the destination fully aligned with the source, including deletions, using delta detection.
  • Maintaining an exact replica of the source
  • Datasets with frequent updates and deletions
  • Use cases requiring strict data consistency
  • First run processes all records
  • Subsequent runs insert new records, update changed records, and delete records missing from the source
  • More processing than Upsert (delta) but ensures full synchronization
{% hint style="info" %} * **Upsert mode never deletes records** from the destination, even if they are removed from the source. * **Mirror mode ensures full alignment** between source and destination, including deletions. :warning: This irreversibly deletes the document from your Firestore collection. Be careful if this document is supposed to be updated via other activations. {% endhint %} ### **Field Mapping** During activation setup, you need to define the mapping between your data warehouse attributes and Firestore document fields. * **Document ID Mapping**: Choose the unique DinMo profile field used as the Firestore Document ID. * **Collection Name**: Enter the name of your Firestore collection. * **Custom Attributes**: Add custom attributes by mapping model fields and typing in custom names that will be used as document field names.
### **Scheduling** Define how frequently your data is updated in Firestore. With each scheduled update: * DinMo will perform an upsert operation, inserting new documents or updating existing ones. * Existing documents not found in the current DinMo data segment or model will remain in Firestore but will not be updated further. # Export Audiences Sync dynamically DinMo User segments with your website or app users for personalization use cases. ## **Overview** In this destination service, DinMo will export and continuously update audience or user segments membership directly in Firestore documents. This allows you to indicate clearly and efficiently which segments each user profile belongs to. To implement this, follow these three steps: 1. **Create a Firestore destination**. Refer to the Firestore platform connection guide for detailed instructions. 2. **Create a DinMo user segment** representing the audience you wish to export. 3. **Activate the segment** with the Firestore destination to begin synchronization. Each time the activation runs: * DinMo will update the Firestore collection specified by the user. * Any profile entering your DinMo segment will have the segment name added to the `dinmo_segments` field within the corresponding Firestore document.
* Any profile exiting your DinMo segment will have the segment name removed from the `dinmo_segments` field. * If the profile doesn't already exist in Firestore (no matching document ID), DinMo will create a new document. ## **Destination Setup** Before exporting segments, you need to configure your Firestore destination of type **Export audiences.** * Go to destinations > Add a destination. * Choose your Firestore Platform. * Click on **Export audiences** option. * Give it a name and save the destination. * In the Default activation settings, Define the **Firestore collection name** where DinMo will sync segment membership data. ## **Activation Configuration** Once your Firestore destination and DinMo segment are configured, create an activation to begin exporting your audience data: * By using One Click Activation directly from the User Segment Overview * Or from the activation tab if you want to use a specific user model to sync or have more control on the name that will be shown in the dinmo\_segments field in Firestore documents **Field Mapping** During activation, specify: * **Document ID Mapping**: Choose the DinMo user profile field that corresponds to the Firestore document ID. DinMo uses this mapping to match profiles in Firestore. * **Collection Name**: Define the name of the Firestore collection that will store your audience membership data. **Scheduling** Specify the frequency of audience updates in Firestore. With each scheduled update: * New profiles entering the DinMo segment will have the audience name added to their `dinmo_segments` array. * Profiles leaving the DinMo segment will have the audience name removed from their `dinmo_segments` array. * Updates ensure your audience data remains current, enabling accurate personalization. # FTP Transfer data at scale from your data warehouse to your apps through FTP using DinMo ## Supported destinations services {% hint style="info" %} Learn more about all of our Destination service types on our [Core Concepts page](/core-concepts). {% endhint %} DinMo supports exporting your data models and segments to an FTP server. DinMo will upload a file (CSV, JSON, XML, etc.) containing the selected attributes to the FTP server. Refer to this documentation page for detailed guidance on setting up an activation with your connected FTP server: * [Export your data models and segments to FTP](/integrations/destination-platforms/ftp/export-your-data-models-and-segments) ## Connect your FTP Server to DinMo * In DinMo, navigate to the **Destinations** section from the navigation bar. * Click "Add a new destination". * Select "Connect a new platform" and choose **FTP**. * Enter a recognizable name for your platform connection. * Fill out the connection details: * The authentication method: **Username** + **Password** * The **hostname** * The **port**, which is most likely `21` * Save the connection. {% hint style="info" %} Unlike SFTP, FTP does not rely on SSH authentication. If your environment uses a secured FTP endpoint, make sure the host and port you provide are the ones intended for your FTP/FTPS access. {% endhint %} # Export your data models and segments to FTP Sync your model profiles and attributes into an FTP server to enable personalization and rapid data retrieval in your apps and websites. ## Overview This destination service allows DinMo to insert new files or update existing ones in an FTP server, based on your DinMo models or segments. To use this service, follow these three steps: 1. **Create an FTP destination**. Follow our [step-by-step guide](/integrations/destination-platforms/ftp) to establish this connection. 2. **Create your DinMo model or segment** representing the data you want to send to your FTP server. 3. **Activate your model or segment** with the FTP destination to start synchronization. Every time the activation runs: * If the file does not yet exist: DinMo will create it with all the rows in the query results * If the file already exists: DinMo will overwrite it, with only the lines added since the last sync If you don't want to overwrite existing files, we recommend using the timestamp in your file names. ## Activation Setup Once the FTP destination is configured, create an activation to begin syncing your data. To do so, go to the *Activations* tab and click on "New activation". You will be asked to choose the model or segment you want to send to your FTP server and select your FTP destination you've just created Then, you can configure your activation: * **Indicate the folder where you wish to store your file**. By default, the file will be sent to the login directory of the FTP server. {% hint style="info" %} Learn more about absolute or relative path [here](#troubleshootings) {% endhint %} {% hint style="warning" %} The user needs to have access to the target directory and file with **write privileges**. A `permission denied` error message during a sync indicates the user may not have write permissions for both the directory or the file. {% endhint %} * **Indicate the name you wish to give to your file.** If you don't want to override existing files, we recommend including timestamp variables in the filename. To do so, you just need to surround each variable with `{}`. DinMo supports these timestamp variables: * **`{YYYY}`**: Full year (e.g., 2025) * **`{YY}`**: Last two digits of the year (e.g., 25) * **`{MM}`**: Month (01-12) * **`{DD}`**: Day of the month (01-31) * **`{HH}`**: Hour (00-23) * **`{mm}`**: Minute (00-59) * **`{ss}`**: Second (00-59) * **`{ms}`**: Millisecond (000-999) * **`{X}`**: Unix timestamp in seconds * **`{x}`**: Unix timestamp in milliseconds For example: `{YY}-{MM}-{DD}_export` will be `25-04-14_export.csv` for the upload of April 14th 2025. * **Select file format**. DinMo supports CSV, JSON (and new delimited JSON), XML and Apache Parquet. * For the CSV option, you'll be asked to choose the CSV delimiter and if you want to include the CSV headers. * **Indicate the type of run you would like to do**, based on the result you would like to see in your file. {% hint style="info" %} Check [this section](#run-types-and-sync-modes) if you want to learn more about the Run Types and the Sync Modes {% endhint %} * **Map all the DinMo attributes** that you want to include in your file. You can of course rename any column you're syncing by choosing your *"custom attribute name"*.
The example above shows how to export the `age`, `name`, `phone_number` and boolean `is_active`. These columns are mapped to new fields in the destination file as `age`, `last name`, `phone` and `is_active`. DinMo exports these fields to the new fields in the file and ignores all other columns from your model or segment. ### Run Types and Sync Modes When configuring your sync, you will be asked to choose the Run Type and the Sync Mode. For FTP activations, here are the available options:
Run TypeDescriptionUse CaseBehavior
FULL ONLYEvery sync processes all records from the source and exports a complete file (or several, if size limit is reached).When the exported file must always contain a full extract, and incremental updates are not required.
  • No delta logic
  • Every sync rebuilds the full export
  • Recommended for Snapshot mode
FULL THEN DELTAThe first sync exports all records. All following syncs export only changed records, based on DinMo’s delta detection logic.When exporting large datasets frequently and wanting to reduce file size or processing time.
  • Sync 1 → Full export
  • Next syncs → Only changed records (new, updated).
  • Compatible with INSERT, UPSERT, and DIFFERENCE modes
Sync modes determine how data is synchronized between your data source and destination. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the FTP destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
SNAPSHOTExports a complete snapshot of all records at the time of sync. Each sync can generate a new file with a timestamped name.Useful for backups or systems expecting full “point-in-time” extracts.
  • Always exports the full segment / model
  • Creates a new file with timestamp
  • No incremental logic
UPSERTWrites all updated or new records into the exported file.Keeps FTP files up-to-date with the latest source data.
  • New records → included in the exported file
  • Existing records → included if, and only if, there are updated values
  • Deleted records → simply not present in the file
INSERTAdds only new records to the exported file. Existing records are never modified.Useful for append-only files, such as historical logs or event tracking.
  • New records → added to file
  • Existing records → ignored
  • Missing records → no action
DIFFERENCEGenerates separate files for added, updated, and removed records between syncs.For audit trails, incremental processing, or systems needing change-specific files.
  • Creates _added.csv, _updated.csv, _removed.csv

    (or other extensions)
  • Each file contains only the relevant change type
### Scheduling Define how frequently your data is sent to your FTP server. Each scheduled operation performs a delta operation, inserting the rows that were added since the last sync. This helps optimize **bandwidth and storage costs** while keeping your exports fresh and relevant. ## Troubleshootings * **How do I know where to send my file?** You can either input an absolute path (starting with `/`) or a relative one. Relative paths start from the login directory of the user connected. To target directly this directory, input `.` For example, consider the following directory: ``` / ├── foo ├── home │ └── alex │ └── baz ``` We are logged as user `alex`. * To target the `foo` folder, use an absolute path: `/foo`. * To target the `baz` folder, an absolute path is: `/home/alex/baz`. You can also use a relative path. Relative paths start from the login directory of the `alex` user, and do not start with `/`. If the login directory is the `alex` folder, just input `baz`. {% hint style="warning" %} Keep in mind that relative notation depends on the user logged in, so if you change the FTP user used in the platform, the files may end up in a different location on the server. {% endhint %} To target directly the login directory in relative notation, you can input `.`, which means "here" in Unix pathing. To go back to the upper folder, use `..` ``` folder absolute path relative path ───────────────────────────────────────────────────────────────── / / ../.. ├── foo /foo ../foo ├── home /home .. │ └── alex /home/alex . │ └── baz /home/alex/baz baz ``` # Google Ad Manager Sending data to Google Ad Manager: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination services: * [Export Segments (GAM Key/Values) via Firestore](/integrations/destination-platforms/google-ad-manager/export-segments-via-firestore) * [Export Segments (GAM Audiences) via Batch Upload](/integrations/destination-platforms/google-ad-manager/export-segments-via-batch-upload) Please select the corresponding option when setuping the destination, and refer to their dedicated documentation page for more information. ## Authentication to Google Ad Manager Regardless of the selected destination service, DinMo will always connect to Google Ad Manager using OAuth2 authentication. Please ensure that the user who connects Google Ad Manager on DinMo has the required permissions on the target Google Ad Manager account. You will need to specify the Network Code of your Google Ad Manager account. *Note: If the Network Code you seek is not listed, it means that the user who connected DinMo to Google Ad Manager does not have the permissions for this account. Refer to this* [*Google Documentation*](https://support.google.com/admanager/answer/7674889?hl=en) *for more information about Network Code* ## Destination Configuration Once authenticated, select the option that matches the service you want to use. Detailed configuration steps are provided in the links listed above. # Export Segments (GAM Key/Values) via Firestore ## Overview In this destination service, DinMo will create a custom targeting Key and keep its Values up to date in Google Ad Manager through Firestore. To do so, you will need to go through these three steps: 1. **Create a GAM via Firestore destination**. * You may need to create a new [Firestore destination](/integrations/destination-platforms/firestore) if this has not already been done. * Then refer to the [Google Ad Manager (GAM) connection guide](/integrations/destination-platforms/google-ad-manager) for detailed instructions on how to authenticate. * Finally, use the documentation below (Destination Setup) to complete the setup. 2. **Create a DinMo user segment** representing the audience you wish to export. 3. **Activate the segment** with the GAM via Firestore destination to begin synchronization. Each time the activation runs: * DinMo will find or create a custom targeting key named `dinmo_segments` in GAM under Inventory > Key-values tab * DinMo will add the activated DinMo segment UUID as the targeting value Name in GAM (or a custom ID if defined in DinMo) * DinMo will add the activated DinMo segment name as the targeting value Display Name in GAM (or a custom name if defined in DinMo) * DinMo will update the Firestore collection specified by the user. * Any profile entering your DinMo segment will have the Targeting Value Name (default to segment UUID) added to the `gam_segments` field within the corresponding Firestore document. This field is an array of segment UUIDs and will be automatically created by DinMo if it does not already exist. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our [step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start exporting segments, you are first required to create a Google Ad Manager destination with the corresponding destination service. You will need to create or choose an existing Firestore platform and collection. If you choose to create a new one, you will be prompted in a new tab and after creating it you can come back to this step and the Firestore platform will show up in the list. ### Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been set up, and your DinMo segment created, you can create an activation to start sending data to Google Ad Manager and Firestore right away. ### Activation core parameters The `Targeting Value Name` is by default the DinMo segment UUID and can be modified. This value will be the segment name in Google Ad Manager and the value in the `gam_segments` array in each Firestore document belonging to a profile present in the DinMo segment. The `Display Name` is the human-readable display name for this segment in Google Ad Manager. It can be modified as well and has the DinMo segment friendly name by default. ### Fields mapping During activation, specify: * **Document ID Mapping**: Choose the DinMo user profile field that corresponds to the Firestore document ID. DinMo uses this mapping to match profiles in Firestore. ### Scheduling Specify the frequency of audience updates in Firestore. With each scheduled update: * New profiles entering the DinMo segment will have the audience name added to their `gam_segments` array. * Profiles leaving the DinMo segment will have the audience name removed from their `gam_segments` array. * Updates ensure your audience data remains current, enabling accurate personalization. ### Adding to the Google Ad Manager tag Once the data is available in Firestore, your technical teams need to configure your tag manager to retrieve the values of the `gam_segments` key from the Firestore document corresponding to the user, and inject it as values of the `dinmo_segments` key in your Google Ad Manager tag (Google Publisher Tag). See Google documentation here. # Export Segments (GAM Audiences) via Batch Upload ## Overview In this destination, DinMo creates an audience in GAM and populates it with user IDs via server-side Batch Uploads. To set this up, you will need to complete the following steps: 1. **Obtain the prerequisites from your Google account manager**, as outlined in this [Google documentation](https://support.google.com/admanager/answer/4349785?hl=en): * Retrieve your GAM Network Code. * Obtain access to a Google Cloud Storage (GCS) bucket associated with your GAM account. * Create a Google Group with permission to view and upload files to the GCS bucket above, and add the user who will configure the GCS destination in DinMo to that group. 2. **Create a GCS destination**, linked to the bucket provided by your Google account manager. 3. **Create a Google Ad Manager destination** of type “Export Segments via Batch Upload” and select the GCS destination created in the previous step. 4. **Create a DinMo user segment** representing the audience you want to export. 5. **Activate the segment** using the Google Ad Manager destination created to start the synchronization. Each time the activation runs: * DinMo will look up or create a “Publisher Managed” audience in GAM (Inventory > Audiences). * DinMo will populate this audience with the identifiers defined when the destination was created and keep it continuously up to date. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our [step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start exporting segments, you must first create a Google Ad Manager destination using the corresponding service (“Export Segments (GAM Audiences) via Batch Upload”). You will need to select an existing Google Cloud Storage (GCS) destination in DinMo that is linked to your dedicated GAM bucket. Please ensure this GCS destination is configured before setting up your Google Ad Manager destination. ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our step-by-step tutorial {% endhint %} Once the destination and your DinMo segment are set up, you can create an activation to start sending data to Google Ad Manager. ## Activation core parameters `Audience Name` and `Audience Description` define how the audience’s name and description will appear in the Inventory > Audiences section of Google Ad Manager. Fields mapping During activation, specify which ID(s) to send to Google Ad Manager and which corresponding DinMo ID(s) to use (PPID, GAID, IDFA, etc.). ## Fields mapping During activation, specify which ID(s) to send to Google Ad Manager and which corresponding DinMo ID(s) to use (PPID, GAID, IDFA, etc.). ## Scheduling Specify the frequency of audience updates in GCS. With each scheduled update: * New profiles entering the DinMo segment are added to the GCS export files, with a list\_id corresponding to the audience in GAM. * Profiles leaving the DinMo segment are flagged in the GCS export files for the corresponding list\_id, with a dedicated column set to 1. * These updates ensure your audience data remains up to date, enabling accurate targeting and personalization. # Google Ads Sending data to Google Ads: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination services: * [Export audiences](/integrations/destination-platforms/google-ads/export-audiences) * [Send online conversions](/integrations/destination-platforms/google-ads/enhanced-conversions-for-web) * [Send offline conversions](/integrations/destination-platforms/google-ads/upload-click-or-offline-conversions) * [Adjust conversion events](/integrations/destination-platforms/google-ads/adjust-conversion-events) * [Retract conversion events](/integrations/destination-platforms/google-ads/retract-conversion-events) Please refer to their dedicated documentation page for more information. ## Authentication to Google Ads Regardless of the selected destination service, DinMo will always connect to Google Ads using OAuth2 authentication. Please make sure the user who connects Google Ads on DinMo has the right permissions either on the target ad accounts, or on the MCC. # Export audiences ## Overview In this destination service, DinMo will create audiences and keep them up to date in Google Ads. To do so, you will need to go through these three steps: * Creating a Google Ads destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users that will populate your Google Ads audience. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Google Ads destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Google Ads audience * Any user leaving your DinMo segment will be removed from your Google Ads audience Note that only users who have an identifier (phone number or email address) linked to a Google account will be present in your Google Ads audience. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start exporting audiences, you are first required to create a Google Ads destination with the corresponding destination service. You will need to specify the ad account in which your audience will be created, and the data type to be sent to Google Ads. `contact_info` is the most popular choice and is used for managing contacts identified by emails or phone numbers. *Note: If the ad account you seek is not listed, it means that the user who connected DinMo to Google Ads does not have the permissions for this account.* ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your audiences to Google Ads will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your audiences if you wish to. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Google Ads right away. The segment will be exported as a new audience in Google Ads. ### Activation Name and Description In this section, the name you enter will be the name given to the audience created in Google Ads. You may also optionally enter a description, that will be attached to the audience in Google Ads. By default, and if you activate your segment using the default activation settings, the name of the audience will be the DinMo segment name, and the description will be the DinMo segment description. ### User consent Since early 2024, it is mandatory to send user consent modes to Google Ads for: * Ad user data * Ad Personalization Failure to comply will result in Google stopping the processing of the data you send. Google Ads only enable to apply consent modes to the entire customer list you send, and not at a user granularity. You must fill in the two consent fields. Make sure the segment you are synchronizing to Google Ads respect the user consent policy. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Google Ads. Any non mapped fields in your segment will not be sent to Google Ads. Google Ads will use the fields you send to recognize each user of your segment. **The higher the number of fields you send, the most likely Google will be able to identify the users.** You can map the following fields: * **Email** (Required): The email addresses of the users. It can be in clear text, or hashed (SHA-256) * **Phone**: The phone numbers of the users. E164 format is preferred ('+49xxxxxxxx'). It can be in clear text, or hashed (SHA-256) * **First Name:** It can be in clear text, or hashed (SHA-256) * **Last Name:** It can be in clear text, or hashed (SHA-256) * **Postal Code:** It can be in clear text, or hashed (SHA-256) * **Country Code:** 2-letter country code in ISO-3166-1 alpha-2 of the user’s address. It can be in clear text, or hashed (SHA-256) * **State:** It can be in clear text, or hashed (SHA-256) * **City:** It can be in clear text, or hashed (SHA-256) Tips to improve matching: If your user list contains an invalid email, Google Ads will require additional attributes to identify the user, otherwise this record will be rejected. In this instance, you have two options for giving Google Ads the minimum required information, by adding one of the following: * Phone * A combination of first name, last name, and address (minimum postcode/zip code and country code) Of course, the more attributes you add the better the matching. However, adding one of these two gives Google Ads sufficient information to identify these users, and means the records will not be rejected during the activation. ### Scheduling In this section, specify how often the audience should be updated in Google Ads. Every time the audience is updated: * Any new user having entered your DinMo segment since the last update will be added to your Google Ads audience * Any user having left your DinMo segment since the last update will be removed from your Google Ads audience # Enhanced Conversions for Web This destination is used to improve your web conversions measurement by sending hashed first-party data up until 24 hours after the conversion. ## Overview With this destination service, DinMo will send web conversion events to optimize web conversions measurement by sending hashed first-party data. (clicks, add to carts, purchase, etc.). {% hint style="info" %} This destination corresponds to the Google API Enhanced Conversions for web. Check out the [official documentation](https://support.google.com/google-ads/answer/13261987?hl=en\&sjid=11588977402760492996-EU) to learn more about this service. {% endhint %} To do so, you will need to go through these three steps: * Creating a Google Ads destination. Refer to the [corresponding section](#destination-setup) for more info.
* Creating an event segment composed of all the events you wish to send to Google Ads. All records of the segment correspond to **a unique conversion action** (for instance, purchase) that has taken place in the last 24 hours, that was previously created in Google Ads.\ \ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo.
* Activating the segment to the Google Ads destination to start sending first-party data. Refer to the [corresponding section](#activation-configuration) for more info. DinMo will be sending all the new conversion events each time the activation is running. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start sending conversion events, you are first required to create a Google Ads destination with the corresponding destination service. You will need to specify the ad account (also named Customer Id) to which your events will be sent. *Note: If the ad account you seek is not listed, it means that the user who connected DinMo to Google Ads does not have the permissions for this account.* ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment containing all your conversion events created, you can create an activation to start sending data to Google Ads right away. ### Conversion Action When setting up a activation, you need to specify the related conversion action. All records of the segment will be considered as conversion events of the selected action (for instance, 'Drive to store', 'Purchase', etc.). {% hint style="danger" %} Make sure your segment only contains conversions of the selected type and that they took place within the last 24 hours. {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Google Ads. Any non mapped fields in your segment will not be sent to Google Ads. Google Ads will use the fields you send to identify the conversions and their values, and recognize each user behind the conversions. You must map the following fields: * **Email** (Required): The email addresses of the user at the origin of the conversion. It can be in clear text, or hashed (SHA-256) * **Order Id** (Required): The identifier of the conversion * **Conversion time** (Required): The timestamp when the conversion took place If the conversion is transactional (i.e referring to a purchase), you must also map the two following fields: * **Value**: The price spent by the customer during the transaction * **Currency code:** The currency of the transaction. Consult Google's chart of [supported currency codes](https://developers.google.com/adsense/management/appendix/currencies) to ensure your data meets their specifications. To increase the chance of identifying the user behind the conversion, you can also map the following fields: * **Phone**: The phone numbers of the users. E164 format is preferred ('+49xxxxxxxx'). It can be in clear text, or hashed (SHA-256) * **First Name:** It can be in clear text, or hashed (SHA-256) * **Last Name:** It can be in clear text, or hashed (SHA-256) * **Postal Code:** It can be in clear text, or hashed (SHA-256) * **Country Code:** 2-letter country code in ISO-3166-1 alpha-2 of the user’s address. It can be in clear text, or hashed (SHA-256) * **State:** It can be in clear text, or hashed (SHA-256 ) * **City:** It can be in clear text, or hashed (SHA-256) **The higher the number of fields you send, the most likely Google will be able to identify the users.** ### Scheduling In this section, specify how often the conversions should be sent to Google Ads. All new conversions will be sent in batch to Google Ads at the specified time interval. We highly recommend setting up at least a daily schedule frequency. Google Ads might indeed reject old conversions (over 24 hours). # Upload click or offline conversions This destination allows you to upload offline or custom conversions using Google Click Id (Gclid) or hashed first-party data. ## Overview With this destination service, DinMo will upload custom or offline conversion events (drive to store, offline purchase, etc.) to optimize targeting. {% hint style="info" %} If you send conversions with first-party data, this refers to the Google API Enhanced Conversions for Leads. Check out the [official documentation](https://support.google.com/google-ads/answer/9888656#leads) to learn more about this service. In addition, take a look at our article if you'd like to learn more about the importance of s[ending conversions to Google Ads](https://www.dinmo.com/third-party-cookies/solutions/conversions-api/google-ads/). {% endhint %} To do so, you will need to go through these three steps: * Creating a Google Ads destination. Refer to the [corresponding section](#destination-setup) for more info.
* Creating an event segment composed of all the events you wish to send to Google Ads. All records of the segment correspond to **a unique conversion action** (for instance, purchase), that was previously created in Google Ads.\ \ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo.
* Activating the segment to the Google Ads destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. DinMo will be sending all the new conversion events each time the activation is running. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start sending conversion events, you are first required to create a Google Ads destination with the corresponding destination service. You will need to specify the ad account (also named Customer Id) to which your events will be sent. *Note: If the ad account you seek is not listed, it means that the user who connected DinMo to Google Ads does not have the permissions for this account.* {% hint style="warning" %} Sending offline or custom conversions to Google Ads requires pre-configuration in your Google Ads account and tag manager. Refer to the [dedicated page](/integrations/destination-platforms/google-ads/upload-click-or-offline-conversions/prerequisites-and-walkthrough) if you need guidance on your Google Ads and Google Tag Manager accounts. {% endhint %} ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment containing all your conversion events created, you can create an activation to start sending data to Google Ads right away. ### User consent Since early 2024, it is mandatory to send user consent modes to Google Ads. Failure to comply will result in Google stopping the processing of the data you send. You can either define the consent mode for all events of the segment, or, at a per-event granularity, if the consent mode is contained in one field of your segment. To define the consent mode at a per-event granularity, select 'Custom mapping' in the user data consent dropdown. Then, please click on 'Add a Mapping' to map the 'User consent field'.
The corresponding field should be a boolean: it can either be 'True' (when the user did grant consent), or 'False', otherwise. Any other value (for instance, empty value) will be considered as 'Unspecified consent'. ### Conversion Action When setting up a activation, you need to specify the related conversion action. All records of the segment will be considered as conversion events of the selected action (for instance, 'Add to cart', 'Purchase', 'Click', etc.). Make sure your segment only contains conversions of the selected type. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Google Ads. Any non mapped fields in your segment will not be sent to Google Ads. Google Ads will use the fields you send to identify the conversions and their values, and recognize each user behind the conversions. You must map the following fields: * **Email** (Required): The email addresses of the user at the origin of the conversion. It can be in clear text, or hashed (SHA-256) * **Order Id** (Required): The identifier of the conversion * **Conversion time** (Required): The timestamp when the conversion took place
If the conversion is transactional (i.e referring to a purchase), you must also map the two following fields: * **Value**: The price spent by the customer during the transaction * **Currency code:** The currency of the transaction To increase the chance of identifying the user behind the conversion, you can also map the following fields: * **Phone**: The phone numbers of the users. E164 format is preferred ('+49xxxxxxxx'). It can be in clear text, or hashed (SHA-256) * **First Name:** It can be in clear text, or hashed (SHA-256) * **Last Name:** It can be in clear text, or hashed (SHA-256) * **Postal Code:** It can be in clear text, or hashed (SHA-256) * **Country Code:** 2-letter country code in ISO-3166-1 alpha-2 of the user’s address. It can be in clear text, or hashed (SHA-256) * **State:** It can be in clear text, or hashed (SHA-256 ) * **City:** It can be in clear text, or hashed (SHA-256) **The higher the number of fields you send, the most likely Google will be able to identify the users.** ### Scheduling In this section, specify how often the conversions should be sent to Google Ads. All new conversions will be sent in batch to Google Ads at the specified time interval. We highly recommend setting up at least a daily schedule frequency. Google Ads might indeed reject old conversions. # Prerequisites and walkthrough With **DinMo**, businesses can seamlessly sync offline conversions with Google Ads, ensuring that every valuable action down the funnel is accounted for. DinMo supports two primary methods for matching conversions: 1. **First-party customer data matching**: Leverages [**Enhanced Conversions for Leads**](https://support.google.com/google-ads/answer/9888656?sjid=17129196395069717744-EU), requiring that the customer’s email or phone number was shared with Google Ads during the initial online interaction along with the GCLID. 2. **Google Click Identifier (GCLID) Matching**: Uses GCLIDs captured during online interactions to link with offline conversions. {% hint style="info" %} This page presents the step-by-step instructions for sending custom or offline conversions to Google Ads, both before DinMo (on Google Ads and GTM) and from DinMo. {% endhint %} ## Google Ads prerequisites ### **Step 1: Set Up Conversion Actions in Google Ads** Before syncing offline conversions using DinMo, you need to define the conversion actions in Google Ads. To do so, navigate to the *Goals Menu* on the left and within the summary section click on “**+ Create conversion action**” button. Then, you'll need to create a **New Conversion Action**: {% hint style="info" %} *NB: All screenshots are taken at MCC level. If you look at the sub-account level, the interface may not be the same. However, the flow remains strictly identical.* {% endhint %} * Choose **Conversions Offline** as the conversion type.
* Click **Add data source**, then choose **Skip this step and set up a data source later**, and click **Done**.
* Select the **conversion category** relevant to your use case (e.g., "Qualified Leads," "Valid Subscriptions," or "Repeat Purchases").
* Click **Save and continue** * Under the selected **Conversion Action Category**, click **Add an event to this category**. Then choose the option Offline data sources as shown below:
* Click **Settings**. * On the side panel: * provide a **descriptive name** for the conversion (e.g., "Closed Deals - Phone Sales"). * Choose whether this action is **Primary (for bidding)** or **Secondary (for reporting only)**. * Configure additional settings such as attribution model and conversion window.
* Click **Save** to finalize the conversion action. ### Step 2: Implement Enhanced Conversions For Leads (optionnal) This step is mandatory only and only if you want to upload conversions using first-party customer data matching. {% hint style="info" %} Enhanced Conversions for Leads enable **more accurate offline conversion tracking** by sending **first-party customer data** (e.g., email or phone number) along with the **Google Click Identifier (GCLID)** when a user submits a form (e.g., sign-up, lead form, or purchase). This ensures that later, when the offline conversion occurs, Google Ads can match it back to the original user. {% endhint %} **Set Up the Google Tag** * Follow [Google's setup guide](https://support.google.com/tagmanager/answer/12002338) to install the Google tag on your website. * Ensure the tag collects **GCLIDs** whenever a user submits a lead form, sign-up, or purchase. **Enable Enhanced Conversions in Google Ads** * Go to **Goals, then** **Settings** in Google Ads. * In the **Enhanced conversions for leads** section: * Check the box “Turn on enhanced conversions for leads” * Choose the implementation method: Google Tag or Google Tag Manager * Clik Save
* **Accept Customer Data terms**: When you select Turn on enhanced conversions for leads, you’ll need to accept the customer data terms. * Setup Enhanced conversions for leads with Google Tag Manager or Google Tag * Please refer to this [documentation](https://support.google.com/google-ads/answer/11347292?sjid=6825191360258545968-EU) for guidance on how to setup with Google Tag Manager * Please refer to this [documentation](https://support.google.com/google-ads/answer/11347292?sjid=6825191360258545968-EU) for guidance on how to setup with the Google tag {% hint style="warning" %} You need to be able to specify a data source for leads conversions that would enable to share hashed PII (Email or Phone number) with Google Ads each time a form conversion is sent to GoogleAds. {% endhint %} ## **Step 3: Configure DinMo for Data Syncing** With conversion actions set up, configure DinMo to sync your offline conversion data: 1. **Prepare Your Data**: * Organize your offline conversion data to include the following fields: * **Conversion ID**: The identifier of the conversion to avoid counting duplicate conversions * **Conversion Time**: Timestamp of the offline conversion. * **Conversion Value**: (Optional) Monetary value of the conversion. * **Currency Code**: (Optional) Currency of the conversion value. * A matching Key: * **Email or Phone**: For 1st party customer data matching, ensure emails or phone numbers are hashed using SHA-256. Otherwise DinMo will hash them during the process of the sync * **GCLID**: For GCLID matching, ensure GCLIDs are accurately captured. 2. **Create an event Model that contains the data you prepared for this task** 3. Refer to this [documentation page](/integrations/destination-platforms/google-ads/sync-offline-store-conversions) for a step by step guidance on how to create an activation that will sync your conversion events regularly with the conversion action specified in Google. # Adjust conversion events ## Overview With this destination service, DinMo will adjust the value of conversion events which were already sent to Google Ads. To do so, you will need to go through these three steps: * Creating a Google Ads destination. Refer to the [corresponding section](#destination-setup) for more info.
* Creating an event segment composed of all the events you wish to adjust in Google Ads.\ \ The segment should contain the restatement value for each events. All records of the segment should also correspond to **a unique conversion action** (for instance, purchase).\ \ Google Ads will reject any attempt to adjust events that happened less than 24h ago. Thus, make sure the segment only contains events which are at least 24h old.\ \ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo.
* Activating the segment to the Google Ads destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. DinMo will be adjusting all the new conversion events each time the activation is running. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start adjusting conversion events, you are first required to create a Google Ads destination with the corresponding destination service. You will need to specify the ad account (also named Customer Id) to which the events to be adjusted are sent. *Note: If the ad account you seek is not listed, it means that the user who connected DinMo to Google Ads does not have the permissions for this account.* ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment containing all your events with their adjustment values created, you can create an activation to start sending data to Google Ads right away. ### Conversion Action When setting up a activation, you need to specify the related conversion action. All records of the segment will be considered as conversion events of the selected action (for instance, 'Drive to store', 'Purchase', etc.). Make sure your segment only contains conversions of the selected type. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Google Ads. Any non mapped fields in your segment will not be sent to Google Ads. Google Ads will use the fields you send to find the conversion to adjust, and the restatement value which will replace the current value. You must map the following fields: * **Order Id or GCLID** (One required): The identifier of the conversion you wish to adjust * **Restatement value** (Required): The new conversion value which will replace the current one
If you mapped the GCLID field, you must then map the following field as well: * **Conversion time**: The timestamp when the conversion to be adjusted took place Please not that if the type of the conversion is equal to `WEBPAGE`, then, the Order Id must be specified. ### Scheduling In this section, specify how often the conversions adjustments should be sent to Google Ads. All new conversions will be adjusted in batch to Google Ads at the specified time interval. # Retract conversion events ## Overview With this destination service, DinMo will retract conversion events which were already sent to Google Ads. To do so, you will need to go through these three steps: * Creating a Google Ads destination. Refer to the [corresponding section](#destination-setup) for more info.
* Creating an event segment composed of all the events you wish to delete in Google Ads.\ \ All records of the segment should also correspond to **a unique conversion action** (for instance, purchase).\ \ Google Ads will reject any attempt to retract events that happened less than 24h ago. Thus, make sure the segment only contains events which are at least 24h old.\ \ Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo.
* Activating the segment to the Google Ads destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. DinMo will be retracting all the new conversion events each time the activation is running. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start retracting conversion events, you are first required to create a Google Ads destination with the corresponding destination service. You will need to specify the ad account (also named Customer Id) to which the events to be retracted are sent. *Note: If the ad account you seek is not listed, it means that the user who connected DinMo to Google Ads does not have the permissions for this account.* ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment containing all your events, you can create an activation to start sending data to Google Ads right away. ### Conversion Action When setting up a activation, you need to specify the related conversion action. All records of the segment will be considered as conversion events of the selected action (for instance, 'Drive to store', 'Purchase', etc.). Make sure your segment only contains conversions of the selected type. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Google Ads. Any non mapped fields in your segment will not be sent to Google Ads. Google Ads will use the fields you send to find the conversion to retract. You must map the following fields: * **Order Id or GCLID** (One required): The identifier of the conversion you wish to retract If you mapped the GCLID field, you must then map the following field as well: * **Conversion time**: The timestamp when the conversion to be retracted took place Please not that if the type of the conversion is equal to `WEBPAGE`, then, the Order Id must be specified. ### Scheduling In this section, specify how often the conversions retractions should be sent to Google Ads. All new conversions will be retracted in batch to Google Ads at the specified time interval. # Sync offline store conversions Store sales conversions focus specifically on importing in-store or offline purchase data, often aggregated and matched using customer information rather than individual click IDs. ## Overview This destination service allows you to **import offline store sales conversions**, enabling you to bring offline transactions into Google Ads. By matching transaction data from your point-of-sale system or customer database, you can measure how your ads drive offline purchases. {% hint style="info" %} Offline Store Conversions are not [offline click conversions](/integrations/destination-platforms/google-ads/upload-click-or-offline-conversions) In short, offline click conversions track specific clicks leading to offline actions, while store sales conversions measure overall offline sales influenced by ads. {% endhint %} :point\_right: Check the [official documentation](https://developers.google.com/google-ads/api/docs/conversions/upload-store-sales-transactions) to learn more about this service To send Offline Store Sales Conversions, you will need to go through these three steps: * **Creating a Google Ads destination**. Refer to the [corresponding section](#destination-setup) for more info * Creating an **event segment** composed of all the events you wish to send to Google Ads. {% hint style="warning" %} All records of the segment must correspond to **a unique conversion action** (for instance, purchase), that was previously created in Google Ads. {% endhint %} * **Activating the segment to the Google Ads destination** to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. DinMo will send all the new Offline Store Sales Conversions each time the activation runs. ## Destination Setup To start sending offline conversion events, you are first required to create a Google Ads destination with the corresponding destination service: *Import Store Sales Conversion*. You will need to specify the ad account (also named *Customer Id*) to which your events will be sent. {% hint style="info" %} If the ad account you are looking for does not appear in the list, it means that the user who connected DinMo to Google Ads does not have the necessary permissions for that account. {% endhint %} ### User Consent Since early 2024, it is mandatory to send user consent modes to Google Ads. Failure to comply will result in Google stopping the processing of the data you send. You can either define the consent mode for all events of the segment, or, at a per-event granularity, if the consent mode is contained in one field of your segment.
## Activation Configuration Once the destination has been setup, and your DinMo segment containing all your Offline Conversion events created, you can create an activation to start sending data to Google Ads right away. ### Conversion Action Select the conversion action you previously set up in your Google Ads account. The dropdown menu displays the conversion action present in your Google Ads account. {% hint style="warning" %} As a reminder, the segment you send must contain only one type of conversion. If you want to send multiple action conversions to Google Ads, you need to create multiple segments and activations. {% endhint %} ### Optional settings: Custom Key You may optionally include a custom key to segment store sales conversions. If you fill this field, you must map the "Custom Variable" field in the mapping section. ### User Consent If you chose to define the consent mode for all events of the segment, you must enter the value of the two consents in the dedicated section.
Otherwise, it is necessary to map the column corresponding to the consent in the Fields Mapping. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Google Ads. Any non mapped fields in your segment will not be sent to Google Ads. Google Ads will use the fields you send to identify the conversions and their values, and recognize each user behind the conversions. You must map the following fields: * **Transaction time** (Required): The timestamp when the conversion took place * **Transaction amount** (Required): The monetary value of the transaction * **Currency Code** (Required): The currency of the transaction *(e.g. EUR for conversions in euros)* * **At least one first-party user identifier:** * **Email** (Required): The email addresses of the user at the origin of the conversion. It can be in clear text, or hashed (SHA-256) * **Phone**: The phone numbers of the users. E164 format is preferred ('+49xxxxxxxx'). It can be in clear text, or hashed (SHA-256) To increase the chance of identifying the user behind the conversion, you can also map other first-party identifiers. The higher the number of fields you send, the most likely Google will be able to identify the users. {% hint style="warning" %} By default, the Google API expects transaction values in micros (e.g. 200€ = 200000000 micros €).\ **DinMo performs the conversion automatically so that you do not have to change the conversion value.** {% endhint %} ### Scheduling In this section, specify how often the conversions should be sent to Google Ads. All new conversions will be sent in batch to Google Ads at the specified time interval. We highly recommend setting up at least a daily schedule frequency. Google Ads might indeed reject old conversions. **Warnings** In this section, specify if you want to receive warning for your Google Ads activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Google Cloud Storage Transfer data at scale from your data warehouse to your apps through Google Cloud Storage using DinMo DinMo allows you to export your data models and segments to a Google Cloud Storage bucket. Generated files (Parquet, CSV, JSON, XML, etc.) are uploaded directly to your bucket. This guide walks you through the setup of a Google Cloud Storage connection: * [Export your data models and segments to Google Cloud Storage](/integrations/destination-platforms/google-cloud-storage/export-your-data-models-and-segments-to-google-cloud-storage) ## Authentication In all cases, DinMo connects to Google Cloud Storage using a **JSON key from a Google Cloud service account**. The service account can be the same one you already use for your data warehouse, as long as it has the permissions required for DinMo to upload files to the target bucket. ## Prerequisites Before connecting Google Cloud Storage to DinMo, make sure you have: * A Google Cloud Storage bucket where DinMo will upload the exported files * A service account JSON key * The required permissions for this service account to write files to the target bucket ## Add Google Cloud Storage as a Platform in DinMo 1. In DinMo, go to **Destinations**. 2. Click **Add a new destination**. 3. Select **Connect a new platform** and choose **Google Cloud Storage**. 4. Enter: * A **Platform Name** for identification * The **Google Cloud Storage Bucket Name** * The **JSON key** of the service account used to upload files 5. Save the connection. ## Validate & Test Connection Once all required fields are filled: * Click **Connect** in DinMo * DinMo will test access by attempting an upload operation * If it fails, verify: * the bucket name * the service account JSON key * the service account permissions on the target bucket # Export your data models and segments to Google Cloud Storage Sync your model profiles and attributes into a Google Cloud Storage bucket to enable personalization and rapid data retrieval in your apps and websites. ## Overview This destination service allows DinMo to insert new files or update existing ones in a Google Cloud Storage bucket, based on your DinMo models or segments. To use this service, follow these three steps: 1. **Create a Google Cloud Storage destination**. Follow the step-by-step guide above to establish this connection using a service account JSON key. 2. **Create your DinMo model or segment** representing the data you want to send to your Google Cloud Storage bucket. 3. **Activate your model or segment** with the Google Cloud Storage destination to start synchronization. The exact export behavior depends on the **Run Type** and **Sync Mode** selected for the activation. For example, some configurations generate a full file on each run, while others export only new or changed records. If you don't want to overwrite existing files, we recommend using a **timestamp in your file name**. ## Activation Setup Once the Google Cloud Storage destination is configured, create an activation to begin syncing your data. To do so: 1. Go to the **Activations** tab. 2. Click on **New activation**. 3. Select the **model or segment** you want to export. 4. Choose your **Google Cloud Storage destination** from the list. You’ll then configure the activation: * **Folder Path**: Specify the folder path inside the bucket where you want to store the file. By default, files are stored at the root of the bucket. * **Indicate the name you wish to give to your file.** If you don't want to override existing files, we recommend including timestamp variables in the filename. To do so, you just need to surround each variable with `{}`. DinMo supports these timestamp variables: * **`{YYYY}`**: Full year (e.g., 2025) * **`{YY}`**: Last two digits of the year (e.g., 25) * **`{MM}`**: Month (01-12) * **`{DD}`**: Day of the month (01-31) * **`{HH}`**: Hour (00-23) * **`{mm}`**: Minute (00-59) * **`{ss}`**: Second (00-59) * **`{ms}`**: Millisecond (000-999) * **`{X}`**: Unix timestamp in seconds * **`{x}`**: Unix timestamp in milliseconds For example: `{YY}-{MM}-{DD}_export` will be `25-04-14_export.csv` for the upload of April 14th 2025. * **File Format**: Choose between CSV, JSON, XML, or Apache Parquet. * For CSV: select a delimiter and whether to include headers. * **Attribute Mapping**: Map any fields from your model or segment to custom column names in the destination file. You can rename fields freely. ### Run Types and Sync Modes When configuring your sync, you will be asked to choose the Run Type and the Sync Mode. For Google Cloud Storage activations, here are the available options:
Run TypeDescriptionUse CaseBehavior
FULL ONLYEvery sync processes all records from the source and exports a complete file (or several, if size limit is reached).When the exported file must always contain a full extract, and incremental updates are not required.
  • No delta logic
  • Every sync rebuilds the full export
  • Recommended for Snapshot mode
FULL THEN DELTAThe first sync exports all records. All following syncs export only changed records, based on DinMo’s delta detection logic.When exporting large datasets frequently and wanting to reduce file size or processing time.
  • Sync 1 → Full export
  • Next syncs → Only changed records (new, updated).
  • Compatible with INSERT, UPSERT, and DIFFERENCE modes
Sync modes determine how data is synchronized between your data source and destination. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the Google Cloud Storage destination, here are the available options:
Sync ModeDescriptionUse CaseBehavior
SNAPSHOTExports a complete snapshot of all records at the time of sync. Each sync can generate a new file with a timestamped name.Useful for backups or systems expecting full “point-in-time” extracts.
  • Always exports the full segment / model
  • Creates a new file with timestamp
  • No incremental logic
UPSERTWrites all updated or new records into the exported file.Keeps files up-to-date with the latest source data.
  • New records → included in the exported file
  • Existing records → included if, and only if, there are updated values
  • Deleted records → simply not present in the file
INSERTAdds only new records to the exported file. Existing records are never modified.Useful for append-only files, such as historical logs or event tracking.
  • New records → added to file
  • Existing records → ignored
  • Missing records → no action
DIFFERENCEGenerates separate files for added, updated, and removed records between syncs.For audit trails, incremental processing, or systems needing change-specific files.
  • Creates _added.csv, _updated.csv, _removed.csv (or other extensions)
  • Each file contains only the relevant change type
### Large exports and file names DinMo processes large runs in chunks. In Snapshot, Insert, and Difference modes, these chunks are published as separate files. By default, processing is split when the estimated in-memory size of an operation reaches 200 MB. This is a processing threshold, not the final encoded file size, and the effective limit can vary by run. In these modes, Google Cloud Storage output is also split so that each file contains at most 10,000,000 rows. The number of files can therefore vary between runs depending on the data volume and row size. When Snapshot or Insert produces one file, DinMo keeps the configured file name. Difference mode keeps its change suffixes, such as `customers_added.csv`, `customers_updated.csv`, and `customers_removed.csv`. When an export is split, DinMo appends one-based numeric indexes before the file extension: * **Snapshot and Insert:** `customers_1.csv`, `customers_2.csv`, and so on. * **Difference:** `customers_added_1.csv`, `customers_updated_1.csv`, or `customers_removed_1.csv`. Each change type is indexed independently when it contains multiple chunks. * **Second-level split:** if an already indexed processing chunk is split again because it exceeds 10,000,000 rows, a second index identifies its files, for example `customers_2_1.csv` and `customers_2_2.csv`. A local split on its own uses one index. * **Upsert:** DinMo combines the processed chunks and publishes one final file with the configured name, such as `customers.csv`. The indexes are inserted before the complete extension, including for compressed Parquet files such as `customers_1.parquet.zstd`. Timestamp variables are resolved once per run, so every file produced by that run shares the same timestamped base name. Files in a multi-file export are published independently and may become visible before the activation completes. Downstream consumers should wait for the activation to finish successfully before reading the complete set. {% hint style="warning" %} DinMo does not remove files from an earlier run that are no longer part of the current output set. This can leave an unsuffixed file after a single-to-multi transition or extra numbered files after a smaller run. Include a sufficiently precise timestamp, such as `{x}`, to give each run a distinct base name, and configure downstream consumers to select only files for that run. {% endhint %} ### Scheduling Define how frequently your data is exported to your Google Cloud Storage bucket. Each scheduled execution performs a delta operation, inserting the rows that were added since the last sync. This helps optimize bandwidth and storage costs while keeping your exports fresh and relevant. {% hint style="warning" %} The service account used by DinMo must have write access to the target bucket and folder path. If a sync fails, verify both the bucket permissions and the configured folder path. {% endhint %} # Google Display & Video 360 Sending data to Google Display & Video 360: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination services: * [Export audiences](/integrations/destination-platforms/google-display-and-video-360/export-audiences) Please refer to their dedicated documentation page for more information. ## Authentication to Google Display & Video 360 Regardless of the selected destination service, DinMo will always connect to Google Ads using OAuth2 authentication. # Export audiences ## Overview In this destination service, DinMo will create audiences and keep them up to date in Google Display & Video 360. To do so, you will need to go through these three steps: * Creating a Google Display & Video 360 destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users that will populate your Google Display & Video 360 audience. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Google Display & Video 360 destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * Any new user entering your DinMo segment will be added to your Google Display & Video 360 audience Note that only users who have an identifier (phone number or email address) linked to a Google account will be present in your Google Display & Video 360 audience. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} To start exporting audiences, you are first required to create a Google Display & Video 360 destination with the corresponding destination service. You will need to specify the ad account in which your audience will be created, and the data type to be sent to Google Display & Video 360. * `contact_info` is the most popular choice and is used for managing contacts identified by emails or phone numbers. * `mobile_id` will recognize each of the users you send with their mobile identifier *Note: If the ad account you seek is not listed, it means that the user who connected DinMo to Google Display & Video 360 does not have the permissions for this account.* ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your audiences to Google Display & Video 360 will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your audiences if you wish to. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Google Display & Video 360 right away. The segment will be exported as a new audience in Google Display & Video 360. ### Activation Name and Description In this section, the name you enter will be the name given to the audience created in Google Display & Video 360. You may also optionally enter a description, that will be attached to the audience in Google Display & Video 360. By default, and if you activate your segment using the default activation settings, the name of the audience will be the DinMo segment name, and the description will be the DinMo segment description. ### User consent Since early 2024, it is mandatory to send user consent modes to Google for: * Ad user data * Ad Personalization Failure to comply will result in Google stopping the processing of the data you send. Google only enable to apply consent modes to the entire customer list you send, and not at a user granularity. You must fill in the two consent fields. Make sure the segment you are synchronizing to Google respect the user consent policy. ### Fields mapping In the Fields mapping section, you are asked to specify the meaning of the fields of your segment that you wish to send to Google Display & Video 360. Any non mapped fields in your segment will not be sent to Google Ads. Google Display & Video 360 will use the fields you send to recognize each user of your segment. **The higher the number of fields you send, the most likely Google will be able to identify the users.** ### Scheduling In this section, specify how often the audience should be updated in Google Display & Video 360. Every time the audience is updated: * Any new user having entered your DinMo segment since the last update will be added to your Google Display & Video 360 audience * Any user having left your DinMo segment since the last update will be removed from your Google Display & Video 360 audience # Google Drive ## Supported Destination Services DinMo supports the following destination service: * [Export your data models and segments to Google Sheets](/integrations/destination-platforms/google-drive/export-data-to-google-sheet) ## Authentification to Google Drive Regardless of the selected destination service, DinMo will always connect to Google Drive using OAuth2 authentication. Please make sure the user who connects Google Drive on DinMo has the right permissions on target objects. # Export data to Google Sheet Sync your model profiles and attributes into a Google Sheet to enable personalization and rapid data retrieval in your apps and websites. ## Overview This destination service allows DinMo to update existing sheets in a Google Sheet, based on your DinMo models or segments. To use this service, follow these three steps: 1. **Create a Google Drive destination**. Follow our [step-by-step guide](/integrations/destination-platforms/google-drive) to establish this connection. 2. **Create your DinMo model or segment** representing the data you want to send to your Google Sheet. 3. **Activate your model or segment** with the Google Drive destination to start synchronization. Every time the activation runs, DinMo will overwrite the sheet and populate it with all the rows in the query results. {% hint style="danger" %} Google spreadsheets are limited to **10 million cells**. As a consequence, activations will fail if the limit is reached. {% endhint %} ## Activation Setup Once the Google Drive destination is configured, create an activation to begin syncing your data. To do so, go to the *Activations* tab and click on "New activation". You will be asked to choose the model or segment you want to send to your Google Sheet and select the destination you've just created The, you can configure your activation: * **Specify the sheet in which you want to save your file**, either by selecting the sheet from the drop-down list or by entering the URL. {% hint style="info" %} DinMo does not currently support the creation of a new sheet in a Google Sheet. {% endhint %} {% hint style="warning" %} The name of your selected sheet cannot contain a colon ":", as it may create a bug in Google Sheet API calls. {% endhint %} * **Indicate the type of run you would like to do**, based on the result you would like to see in your sheet. {% hint style="info" %} Refer to [this section](#run-types-and-sync-modes) to learn more about Run Types and Sync Modes {% endhint %} * **Map all the DinMo attributes** that you want to include in your file. You can of course rename any column you're syncing by specifying your *"custom attribute name"*.
The example above shows how to export the `age`, `name`, `phone_number` and boolean `is_active`. These columns are mapped as `age`, `last name` , `phone` and `is_active` , which will correspond to the headers in the Google Sheet. {% hint style="warning" %} DinMo will ignore all other columns from your model/segment. {% endhint %} ### Run Types and Sync Modes When configuring your sync, you will be asked to choose the Run Type and the Sync Mode. For Google Sheet activations, here are the available options:
Run TypeDescriptionUse CaseBehavior
FULL ONLYEvery sync processes all records from the source and exports a complete file.When Google Drive must always contain a full extract, and incremental updates are not required.
  • No delta logic
  • Every sync rebuilds the full export
FULL THEN DELTAThe first sync exports all records. All following syncs export only changed records, based on DinMo’s delta detection logic.When exporting large datasets frequently and wanting to reduce file size or processing time.
  • Sync 1 → Full export
  • Next syncs → Only changed records (new, updated).
  • ⚠️ Deleted records are not highlighted
Sync modes determine how data is synchronized between your data source and destination. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For Google Drive, here are the available options:
Sync ModeDescriptionUse CaseBehavior
SNAPSHOTGenerates a full snapshot file containing all records at each sync.Useful for backups or systems expecting full “point-in-time” extracts.
  • Always exports the full segment / model
  • No incremental logic
UPSERTWrites all incoming (updated or new) records into the exported file.Ideal when you want Google Drive to always contain an up-to-date extract of the latest data, without managing incremental files.
  • New records → included in the exported file
  • Existing records → included if, and only if, there are updated values
  • Deleted records → simply not present in the file
In a nutshell: * **Full Only + Snapshot** will overwrite the whole sheet every time with every row in the segment. * **Full then Delta + Upsert** will do a first full run, then every next run will clear and re-write the modified rows, potentially inserting new rows. ### Scheduling Define how frequently your data is exported to your Google Sheet. Each time activation is launched, the sheet will be updated to contain only the people from the model or segment, with only the attributes that have been mapped. ### Warnings In this section, specify if you want to receive warning for your Google Sheet activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Google Search Ads 360 Sending data to Google Search Ads 360: Step-by-Step Guide ## Supported destination services {% hint style="info" %} Learn more about all of our Destination service types on our [Core Concepts page](/core-concepts). {% endhint %}
Destination serviceSupported?Type
Destination serviceSupported?Type
Conversions✅Events
## Destination Setup Please do the following steps to add Google Search Ads 360 as a destination in DinMo: 1. Go to the Destinations section in the navigation bar. 2. Click "Add a new destination". 3. Select "Google Search Ads 360". 4. Click "Connect" to activate the connection. You will be redirected to Google, where you will be asked to grant the necessary permissions to DinMo.\
5. Click continue once the connection is done. 6. Give a name to your destination. 7. Click Connect. ## Syncing Floodlight Conversions ### Sync Setup Here are the necessary steps involved in the creation of a new sync to Floodlight Conversions: 1. Navigate to the Activations tab, and click "New Activation" in the upper-right corner of the screen.
2. Select "Event Segment", then click "Continue".
3. Choose your Google Search Ads 360 platform in the dropdown, then click “Continue.”\ \
4. Fill in the agency ID, advertiser ID and account ID.
5. Select "Floodlight" as the Segmentation Type.
6. Select the device type corresponding to the events data to be synced. Floodlight supports the following devices:
| Devices Types | | --------------- | | Desktop | | High End Mobile | | Tablet | | Other Device | 7. Choose the type of conversions to be synced. It can either be transactions or actions.
8. Fill in the Fields Mapping section. Google requires the following information:\
| Required Fields Mapping | | ----------------------- | | `Google Click ID` | | `Conversion ID` | | `Event Timestamp` | | `Event Name` | 9. Under the Scheduling options, choose the time interval at which you want your segment to be synced to Google Ads. A daily sync is sufficient for most use cases.
10. Click “Continue,” then “Create” to finish. # Hubspot Sending data to Hubspot: Step-by-Step guide ## Supported Destination Services DinMo supports the following destination service: * [Synchronize Objects](/integrations/destination-platforms/hubspot/synchronize-objects) (Contacts, Deals, Products, etc.) * [Synchronize Custom Objects](/integrations/destination-platforms/hubspot/synchronize-custom-crm-objects) Please refer to the dedicated documentation page for more information. ## Authentication to Hubspot Regardless of the selected destination service, DinMo will always connect to Hubspot using OAuth2 authentication. # Synchronize objects ## Overview In this destination service, DinMo will export and update attributes of specific objects: * Contacts * Deals * Products * Companies Optionally, new records can be as well imported in this destination service. To create such an activation, you will need to go through these three steps: * Creating a Hubspot destination. Refer to the [corresponding section](#destination-setup) for more info. {% hint style="info" %} If you update contacts, you can choose to use an external attribute to match contacts between DinMo and Hubspot. In this case, you must select the option when configuring the destination. {% endhint %}
* Creating a segment composed of all the records and their attributes that will be updated in Hubspot. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Hubspot destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new records in the segment will be inserted in Hubspot * All attributes values that have changed since the last activation will be updated in Hubspot If you chose not to insert new records, only records of the segment which are already present in Hubspot will be updated. ## Destination setup To start synchronizing objects, you are first required to create a Hubspot destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Hubspot right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Sync Mode Sync modes determine how data is synchronized between your data source and destination. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the all Hubspot destination, here are the available options: | Sync Mode | Description | Use Case | Behavior | | ---------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **INSERT** | Creates new records in HubSpot. Existing records are never modified. | When you want to add contacts, companies, or deals without risking any overwrite. |
  • New records → created in HubSpot
  • Existing records → ignored
  • Missing records → no action
| | **UPDATE** | Updates existing HubSpot records only. No new records are created. | When enriching existing data (e.g., adding computed attributes) without creating new CRM objects. |
  • New records → ignored (HubSpot entries must already exist)
  • Existing records → updated
  • Missing records → no action
| | **UPSERT** | Creates new records if they don’t exist, or updates them if they already exist in HubSpot. | Best for keeping HubSpot CRM objects fully up to date with both new and updated information. |
  • New records → created
  • Existing records → updated
  • Missing records → no action
| #### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the ID of the target object. This field will be used to link the segment's records to existing records in Hubspot. For instance, for contacts, you might want to map the email address (in clear text). You can then map any other attribute existing in Hubspot. These attributes will then be updated by DinMo during each activation. #### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Hubspot. The associated field will have the same name in Hubspot and DinMo. The values of the attributes selected here will then also be updated at each activation. **Scheduling** Define how frequently your data is updated in Hubspot. With each scheduled update: * **(Insert)** DinMo will insert new Objects, with their custom attributes * **(Update)** All attributes values that have changed since the last activation will be updated * DinMo will stop updating any Object who is no longer in the source model/segment. **Warnings** In this section, specify if you want to receive warning for your Hubspot activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Synchronize custom CRM objects ## Overview In this destination service, DinMo will export and update attributes of your custom objects. Optionally, new records can be as well imported in this destination service. To create such an activation, you will need to go through these three steps: * Creating a Hubspot destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a segment composed of all the records and their attributes that will be updated in Hubspot. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Hubspot destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new records in the segment will be inserted in Hubspot * All attributes values that have changed since the last activation will be updated in Hubspot If you chose not to insert new records, only records of the segment which are already present in Hubspot will be updated. ## Destination setup To start synchronizing objects, you are first required to create a Hubspot destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ### Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Hubspot right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} #### Sync Mode Sync modes determine how data is synchronized between your data source and destination. They control whether to insert new records, update existing ones, or both, and how to handle the synchronization process. For the all Hubspot destination, here are the available options: | Sync Mode | Description | Use Case | Behavior | | ---------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **INSERT** | Creates new records in HubSpot. Existing records are never modified. | When you want to add contacts, companies, or deals without risking any overwrite. |
  • New records → created in HubSpot
  • Existing records → ignored
  • Missing records → no action
| | **UPDATE** | Updates existing HubSpot records only. No new records are created. | When enriching existing data (e.g., adding computed attributes) without creating new CRM objects. |
  • New records → ignored (HubSpot entries must already exist)
  • Existing records → updated
  • Missing records → no action
| | **UPSERT** | Creates new records if they don’t exist, or updates them if they already exist in HubSpot. | Best for keeping HubSpot CRM objects fully up to date with both new and updated information. |
  • New records → created
  • Existing records → updated
  • Missing records → no action
| #### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the ID of the target object. This field will be used to link the segment's records to existing records in Hubspot. You can then map any other attribute existing in Hubspot. These attributes will then be updated by DinMo during each activation. **Scheduling** Define how frequently your data is updated in Hubspot. With each scheduled update: * **(Insert)** DinMo will insert new Custom Objects, with their custom attributes * **(Update)** All attributes values that have changed since the last activation will be updated * DinMo will stop updating any Custom Object who is no longer in the source model/segment. **Warnings** In this section, specify if you want to receive warning for your Hubspot activation. {% hint style="info" %} Consult the specific section to [learn more about sync warnings](/activations/troubleshooting-syncs/sync-warnings). {% endhint %} # Intercom Sending data to Intercom: Step-by-Step Guide ## Supported Destination Services DinMo supports the following destination service: * [Export segments](/integrations/destination-platforms/intercom/export-segments) * [Synchronize contacts](/integrations/destination-platforms/intercom/synchronize-contacts) * [Synchronize companies](/integrations/destination-platforms/intercom/synchronize-companies) Please refer to the dedicated documentation page for more information. ## Authentication to Intercom Regardless of the selected destination service, DinMo will always connect to Intercom using OAuth2 authentication. # Export segments ## Overview In this destination service, DinMo will set and update tags to Intercom users. The tags can then be used in Intercom to create segments. To do so, you will need to go through these three steps: * Creating an Intercom destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment composed of all the users that will populate your Intercom segment. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment to the Intercom destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. This will create a tag with the value of the DinMo's segment name, and all users who are part of the DinMo's segment will be assigned the tag. * On Intercom, creating a segment with by filtering all users who have been assigned this tag Each time the activation will be running: * Any new user entering your DinMo segment will be assigned the tag you configured * Any user leaving your DinMo segment will have this tag removed Note that only users who have an email linked to an existing Intercom user will be edited by DinMo. In this service, DinMo will not create any new users in your Intercom account. ## Destination setup {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} You are first required to create an Intercom destination with the corresponding destination service. ### Optional: Setup default activation settings At the end of the destination creation, you will be proposed to setup Default Activation Settings. This step is optional, but is highly recommended to facilitate the activation process. By configuring default settings, synchronizing all your contacts lists to Intercom will just take one click. Without default settings, you will be required to go through the [configuration](#activation-configuration) each time you activate a new audience. Note that even if you setup default settings, you will still be able to adjust activation settings for each of your segment if you wish to. Refer to the [Activation configuration section](#activation-configuration) for more info about the default settings configuration process. ## Activation configuration {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Intercom right away. ### Activation Name and Description In this section, the name you enter will be the name given to the tag created in Intercom. By default, and if you activate your segment using the default activation settings, the name of the tag will be the DinMo segment name. ### Fields mapping In the Fields mapping section, you are asked to specify which field corresponds to the email address of the users of the segment, or, the User ID. ### Scheduling In this section, specify how often the segment should be updated in Intercom. # Synchronize contacts ## Overview In this destination service, DinMo will export and update attributes in the contacts table, and, optionally, insert new contacts. To do so, you will need to go through these three steps: * Creating an Intercom destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a user segment or model composed of all the users and their attributes that will be updated in Intercom. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment or model to the Intercom destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new contacts in the segment or model will be inserted as a contact in Intercom * All attributes values that have changed since the last activation will be updated in Intercom If you chose not to insert new contacts, only users of the segment or model who have an email address linked to an Intercom contact will be updated. ## Destination setup To start synchronizing contacts, you are first required to create an Intercom destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Intercom right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to the email address of the user (it must be in clear text), or, an external ID. This field will be used to link the segment's records to existing contacts in Intercom. You can then map any other attribute existing in Intercom. These attributes will then be updated by DinMo during each activation. Non mapped attributes will not be modified by DinMo. ### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Intercom. The associated field will have the same name in Intercom and DinMo. The values of the attributes selected here will then also be updated at each activation. # Synchronize companies ## Overview In this destination service, DinMo will export and update attributes in the companies table, and, optionally, insert new company records. To do so, you will need to go through these three steps: * Creating an Intercom destination. Refer to the [corresponding section](#destination-setup) for more info. * Creating a custom segment or custom model composed of all the companies records and their attributes that will be updated in Intercom. Refer to this [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/create-your-first-segment) to learn how to build segments without SQL in DinMo. * Activating the segment or model to the Intercom destination to start sending data. Refer to the [corresponding section](#activation-configuration) for more info. Each time the activation will be running: * If you ticked the insert mode option, all new companies records in the segment or model will be inserted as a new company in Intercom * All attributes values that have changed since the last activation will be updated in Intercom If you chose not to insert new companies, only records of the segment or model who have an identifier linked to an Intercom company will be updated. **Note:** Only company records which are linked to existing Intercom contacts will be displayed in the Intercom interface. ## Destination setup To start synchronizing companies, you are first required to create an Intercom destination with the corresponding destination service. {% hint style="info" %} Learn how to create such a destination in our[ step-by-step tutorial](/guides/get-started-with-dinmo/initial-configuration-of-dinmo/create-a-destination) {% endhint %} ## Activation configuration Once the destination has been setup, and your DinMo segment created, you can create an activation to start sending data to Intercom right away. {% hint style="info" %} Learn how to activate a segment in our [step-by-step tutorial](/guides/get-started-with-dinmo/create-and-activate-segments-on-dinmo/activate-your-first-segment) {% endhint %} ### Fields mapping In the Fields mapping section, you are asked to specify the field contained in your DinMo segment corresponding to company ID. This field will be used to link the segment's records to existing company records in Intercom. You can then map any other attribute existing in Intercom. These attributes will then be updated by DinMo during each activation. Non mapped attributes will not be modified by DinMo. ### Custom Attributes In this section, any field you select will be exported as a new custom attribute in Intercom. The associated field will have the same name in Intercom and DinMo. The values of the attributes selected here will then also be updated at each activation. --- [Next Page](/llms-full.txt/1)