All you need to know when it comes to setting up a new integration in the Didomi Marketplace
Step #1 - Settings
Integration settings are a crucial step in gathering the parameters that allow Didomi to establish connections with your chosen 3rd party applications.
The required parameters are different from one integration to another. Learn more about each parameter through our tooltips and in our detailed Developer Documentation.
Step #2 - Options
Enhance your integration with optional parameters:
- Upsert mode: ensure user preferences are pushed for non-identified profiles in the 3rd party app.
- Bidirectional mode: collect user preferences from the 3rd party app to Didomi and ensure both ends sync. This option may not be supported for all integrations.
- Transactional email: request a specific email provider for your transactional emails. Once this option is selected, you will need to make the necessary email configuration as explained in this Developer Documentation.
- Specific options: depending on the 3rd party app you are connecting with, additional options may be requested at this step. Learn more about each parameter through our tooltips and in our detailed Developer Documentation.
Step #3 - Mapping
In this step, you will be asked to set up the mapping between your configuration tree attributes and the 3rd party attributes that will be pushed by the Didomi integration.
As a quick reminder, your configuration tree attributes could be:
- A purpose
- A preference
- A value within a preference
To set up mapping:
- Select your configuration tree attribute: go to the corresponding line.
- Manually enter the name or select the 3rd party attribute from the dropdown (dropdown selection may not be available for 3rd party apps whose APIs do not support this).
- If dropdown selection is possible, you can easily search for the 3rd party attribute by name or ID.
The most appropriate mapping for your needs depends on your requirements and how the 3rd party attributes are built on your end.
We provide our general recommendations for optimal and efficient mapping:
👉 Collecting string (Multi-choice) values:
The end goal here is that, when your user selects a specific value in a given preference (string values), this value is reflected in profile attributes as text:
- In this case, our recommendation is to map your preference with the 3rd party string/text attribute where the selected value will be pushed. <image preference mapped to 3rd party attribute>
👉 Collecting Boolean (Single choice) values:
This may be required in one of the two use cases below:
When your user chooses an option within a purpose (”Yes” or “No” choice), you wish this to be reflected in their boolean profile attribute.
- In this case, you simply need to map the purpose with a 3rd party attribute that has a boolean type. <image purpose mapped to 3rd party attribute>
When choosing a specific value within a preference. Let's look at an example:
- You have a boolean attribute called “OPTIN” in your 3rd party app
- In the Didomi Preference Management platform, you are collecting the “opt-in” status through a preference per below:
- For the value selection: more specifically, when the user selects the value optin we want this to be reflected in the boolean attribute OPTIN . In this case, you can simply map the value optin with the attribute OPTIN. In this way when the user selects the value optin, it will be reflected as “Yes” in the attribute OPTIN <image preference value mapped to 3rd party attribute>
We highly recommend not creating preferences with “Yes” or “No” values, and then only mapping one value ("Yes", for example). Instead, we suggest using the purpose as it is the most suitable object for this mapping option.
- Mapping is not available for the legacy preference centre. Please contact firstname.lastname@example.org if you want to set up the mapping step.
- If you delete or move a preference in your configuration tree, this will break the mapping with the 3rd party tool. Make sure you check your mapping after any updates to the configuration tree.
Please note: for Didomi native integrations (webhook, batch exports, analytics exports) the mapping step is not needed.