Adobe Launch/DTM

This section describe how to control what tags are embedded on your website when using Adobe Launch or DTM for managing tags.
The key idea of the integration is that Didomi pushes GDPR consent information into Adobe as variables of the data layer (_satellite.setVar) and fires events/direct calls (_satellite.track) to indicate when tags that require consent can be loaded. You should then configure Adobe to only fire tags after consent has been collected for each vendor.
On your side, the integration relies on adding rules, events and conditions to all the tags from vendors that do not support the IAB framework to make them fire on a custom event from the data layer. The Didomi SDK will then fire an event with the list of vendors that the user has given consent to, which will ensure that Adobe only loads the tags matching the user consent.
For instance, after a user gives consent to the vendor google, the SDK will push the direct call didomi-consent-changed and the variable didomiVendorsConsent with the value google,. The tags setup in Adobe can then be fired through a rule on the event didomi-consent-changed.
Make sure that our SDK is setup
Before continuing, please read our section on setting up our SDK to learn how to do the initial setup of your tag. It is particularly important that our tag gets embedded before all the other tags on your page.
Configure the Didomi / Adobe integration
Step 1 - Enable the Adobe integration
Didomi Console
If you are configuring Didomi through the Console, enable the Adobe DTM and Launch integration in the Integrations tab of your consent notice:
Adobe DTM and Launch integration in the Didomi Console
Make sure to publish your notice after enabling the integration.
Tag
If you are configuring Didomi through a didomiConfig tag, you need to update your tag configuration to enable our Adobe integration in the SDK. The events and variables pushed by Didomi will not be available until the integration is enabled.
Add the tagManager.provider key in your didomiConfig object:
<script type="text/javascript">
window.didomiConfig = {
  [...Your existing tag],
  
  tagManager: {
    provider: 'adobe'
  }
};
</script>
Embedding the Didomi SDK through Adobe
We recommend not embedding the Didomi SDK through Adobe. By being directly on your pages, the Didomi SDK can load faster and also ensures that IAB vendors can detect a CMP on the page as soon as possible.
Embedding the Didomi SDK through Adobe will result in less consents being passed to vendors and a lower consent rate from their perspective.
Step 2 - Create rules
You need to create rules that will be used to decide when to load each tag in Adobe DTM or Launch. Vendors that do not require consent need not be updated. IAB vendors do not need to be conditioned either as they will automatically collect the consent status from Didomi through the IAB TCF API.
For every vendor tag that you need to condition on the user consent status, create or update a rule with the following configuration:
Events
Configure an event of type Direct Call with identifier didomi-ready:
Didomi ready event configuration
With this event configured, your tag will be fired when the page loads AND consent has been given on a previous page. If you also want the tag to fire when consent is given on the current page, also add an event with identifier didomi-consent-changed:
Didomi consent changed event
You should end up with one or two events configured:
Conditions
Add a condition to your rule so that it only triggers if consent has been given to the vendor.
The condition should be created on the didomiVendorsConsent data element (noted as %didomiVendorsConsent%) to validate that it contains the ID of the vendor that the tags belongs to.
See Variables / Vendors for more information on didomiVendorsConsent and other variables available to condition your tags.
How to find your vendor ID?
To find your vendor ID, go to the Vendors and Purposes section of your Didomi account and copy the SDK ID:
Copy the SDK ID to get your vendor ID
Variables
The Didomi SDK pushes variables to Adobe to allow you to control when tags are loaded and to share the consent information with non-IAB vendors or IAB vendors with non-JavaScript pixels (usually image tags).
Here are the variables that the SDK pushes:
Vendors
These variables contain the consent status of the user for every vendor that you have defined in your configuration.
The consent status reported for vendors automatically includes the status for their required purposes. You usually do not have to create a trigger that uses both vendors AND purposes variables and a rule on vendors is enough.
Example: didomi:google is only included in the list of vendors that the user has given consent to if the user has given consent to didomi:google and to every purpose required by that vendor.
Vendor IDs reported in dataLayer variables are prefixed
iab: for IAB vendors (ex: iab:1)
didomi: for Didomi vendors (ex: didomi:google)
c: for custom vendors (ex: c:vendor-id)
Make sure to include the prefix in your Adobe condition.
Variable
Description
didomiVendorsConsent
A comma-separated list of vendors that the user has given consent to. We use the list of purposes declared for the vendor to make sure that it has consent for all of them.
didomiVendorsConsentUnknown
A comma-separated list of vendors that the user has not yet given/denied consent to.
didomiVendorsConsentDenied
A comma-separated list of vendors that the user has denied consent to.
didomiVendorsRawConsent
A comma-separated list of vendors that the user has given consent to.
This list includes the raw consent status to vendors and does not take into account the required purposes per vendor. Only use this value if you are sure of what you are doing. Most likely, didomiVendorsConsent is the one you are looking for.
didomiVendorsRawConsentUnknown
A comma-separated list of vendors that the user has not yet given/denied consent to.
This list includes the raw consent status and does not take into account the required purposes per vendor. Only use this value if you are sure of what you are doing. Most likely, didomiVendorsConsentUnknown is the one you are looking for.
didomiVendorsRawConsentDenied
A comma-separated list of vendors that the user has denied consent to.
This list includes the raw consent status to vendors and does not take into account the required purposes per vendor. Only use this value if you are sure of what you are doing. Most likely, didomiVendorsConsentDenied is the one you are looking for.
Values
All variables have the same format: a comma-separated list of vendor IDs.
The list includes prefixes (iab: for IAB vendors, didomi: for Didomi vendors and c: for custom vendors) and is terminated by a final comma. Triggers on this variable should check if the variable contains prefix:ID, to guarantee that there is an exact and avoid a confusion between vendor prefix:1 and vendor prefix:10.

Example: iab:1,iab:2,didomi:google,c:custom,
How to find your vendor ID?
To find your vendor ID, go to the Vendors and Purposes section of your Didomi account and copy the SDK ID:
Copy the SDK ID to have your vendor ID
Purposes
These variables contain the consent status of the user for every purpose that consent is collected for. You usually do not need to use these variables directly and want to use the Vendors variables instead.
Variable
Description
Values / Example
didomiPurposesConsent
A comma-separated list of purposes that the user has given consent to.
cookies,analytics,
didomiPurposesConsentUnknown
A comma-separated list of purposes that the user has not yet given/denied consent to.
cookies,analytics,
didomiPurposesConsentDenied
A comma-separated list of purposes that the user has denied consent to.
cookies,analytics,
GDPR & IAB
Variable
Description
Values / Example
didomiGDPRApplies
Define whether the GDPR applies to the current user (ie the user is located in the EU or your website is configured to enforce GDPR for all users).
0 (GDPR does not apply) and 1 (GDPR does apply)
didomiIABConsent
The IAB consent string as defined in the Consent String and Vendor List Format specification. It encodes the consent information for every vendor and purpose as well as few other pieces of information on the CMP that created the string.
BOMi0lyOMi0lyAHABBENAC-AAAAB4AQABaA
AB tests
We expose variables that the contain the status of the AB test running (if any). That allows you to track your AB tests results through your own analytics solution.
Variable
Description
Values / Example
didomiExperimentId
ID of the AB test running.
The value of the experiment.id property in your SDK configuration. An empty string is provided if there is no test configured.
didomiExperimentUserGroup
The group that the user is a part of. 
control if the user is part of the control group
test if the user is part of the user group
An empty string is provided if the user is not part of the control or test group.
Events
The Didomi SDK pushes different events to Adobe to allow you to use rules to decide when to embed tags from your vendors. All the variables listed above are pushed with every event.
Here are the events that the SDK pushes:
Event
Description
didomi-ready
This event is pushed exactly once when the page is loaded and can be used for any tag that you want to fire exactly once on the page. The consent status of the user at the time of this event might be unknown. It can be used as an alternative to a page view/load event.
didomi-consent-changed
This event is pushed every time the consent status changes as the result of a user interacting with the Didomi consent notices or preferences.
Custom events and consent
If you have your own custom events that you use as rules for tags and also want to add an additional condition on the consent status of the user, you need to make sure that your custom events only fire after the Didomi event that you are using (so that the Didomi variables have already been populated). You have two options to do so.
Wrap your custom events
In your JavaScript code that is pushing your custom events onto the data layer, wrap all your custom events to only fire them after the Didomi SDK has initialized and the didomi-ready event has been sent:
window.didomiOnReady = window.didomiOnReady || [];
window.didomiOnReady.push(function (Didomi) {
  // Fire your custom event(s)
  _satellite.track('custom_event');
});
You can use as many didomiOnReady functions and put them anywhere in your code. Custom events that are not used as rules for a tag that you want to condition on consent do not need to be wrapped.
If you do not wait until the Didomi SDK is ready before firing your custom events, the order of the events will end up being random and you have no guarantee that the consent is correctly enforced for the tags using custom rules.
Condition your custom events
The second option is to only fire your custom events when you have consent. In that case, you do not need to add a consent condition in Adobe and the mere fact that the event gets fired implies that consent was given
It is not ideal because is pushes the consent condition into your JavaScript code but can be useful sometimes.
function fireCustomEvents(consentStatus) {  
  if (consentStatus === true) {
    // Fire your custom event(s) because the user has given consent
    _satellite.track('custom_event');
  }
}
​
window.didomiOnReady = window.didomiOnReady || [];
window.didomiOnReady.push(function (Didomi) {
  // The SDK is done loading, check the consent status of the user
  const consentStatus = Didomi.getUserStatus().vendors.consent.enabled.includes('vendor-id');
  const vendorsWithKnownConsentStatus = Object.values(Didomi.getUserStatus().vendors.consent).flat();
  
  if (consentStatus === true) {
    // The user has given consent for that vendor, fire the custom events
    fireCustomEvents(consentStatus);
  } else if(!vendorsWithKnownConsentStatus.includes('vendor-id')) {
    // The consent status of the user is not known yet
    // Subscribe to the consent.changed event to get notified when it does
    Didomi.on('consent.changed', function () {
      // The consent status of the user has changed
      fireCustomEvents(Didomi.getUserStatus().vendors.consent.enabled.includes('vendor-id'));
    });
  }
});

Tag managers

Eulerian

Last modified 8mo ago

Variable	Description
`didomiVendorsConsent`	A comma-separated list of vendors that the user has given consent to. We use the list of purposes declared for the vendor to make sure that it has consent for all of them.
`didomiVendorsConsentUnknown`	A comma-separated list of vendors that the user has not yet given/denied consent to.
`didomiVendorsConsentDenied`	A comma-separated list of vendors that the user has denied consent to.
`didomiVendorsRawConsent`	A comma-separated list of vendors that the user has given consent to. This list includes the raw consent status to vendors and does not take into account the required purposes per vendor. Only use this value if you are sure of what you are doing. Most likely, `didomiVendorsConsent` is the one you are looking for.
`didomiVendorsRawConsentUnknown`	A comma-separated list of vendors that the user has not yet given/denied consent to. This list includes the raw consent status and does not take into account the required purposes per vendor. Only use this value if you are sure of what you are doing. Most likely, `didomiVendorsConsentUnknown` is the one you are looking for.
`didomiVendorsRawConsentDenied`	A comma-separated list of vendors that the user has denied consent to. This list includes the raw consent status to vendors and does not take into account the required purposes per vendor. Only use this value if you are sure of what you are doing. Most likely, `didomiVendorsConsentDenied` is the one you are looking for.

Variable	Description	Values / Example
`didomiPurposesConsent`	A comma-separated list of purposes that the user has given consent to.	`cookies,analytics,`
`didomiPurposesConsentUnknown`	A comma-separated list of purposes that the user has not yet given/denied consent to.	`cookies,analytics,`
`didomiPurposesConsentDenied`	A comma-separated list of purposes that the user has denied consent to.	`cookies,analytics,`

Event	Description
`didomi-ready`	This event is pushed exactly once when the page is loaded and can be used for any tag that you want to fire exactly once on the page. The consent status of the user at the time of this event might be unknown. It can be used as an alternative to a page view/load event.
`didomi-consent-changed`	This event is pushed every time the consent status changes as the result of a user interacting with the Didomi consent notices or preferences.