Configure the Didomi / GTM integration
To avoid overriding our variables in the dataLayer in the case where Didomi is loaded before the dataLayer initialization, we recommend to instantiate it with this syntax : window.dataLayer=window.dataLayer || []; instead of window.dataLayer=[];
This section describes how to control what tags are embedded on your website when using Google Tag Manager for managing tags.
The key idea of the integration is that Didomi pushes GDPR consent information into Google Tag Manager as variables of the data layer. You should then configure GTM to only fire tags after consent has been collected for every vendor.
The integration relies on adding a trigger 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 Google Tag Manager only loads the tags matching the user consent.
For instance, if the user gives consent to the vendor didomi:google, the SDK will push the event didomi-consent and the variable didomiVendorsConsent with the value didomi:google,. The tags setup in Google Tag Manager and with a trigger "didomiVendorsConsent" contains "didomi:google," will then be loaded by Google Tag Manager and other tags with triggers for a different vendor ID will not be loaded.
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.

Step 1 - Enable our GTM integration

Option 1: Didomi Console

If you are configuring Didomi through the Console, enable the GTM integration in the Integrations tab of your consent notice by selecting this box:
GTM integration in the Didomi Console
By default, Didomi uses the name “dataLayer” as the variable name for your GTM data layer.
If you are using another name for your data layer, you can instruct Didomi to use this name instead, by typing it in the “DATA LAYER NAME” field.
If you are configuring Didomi through the Console, you can now go to the next step (2 - Create the variables in GTM).

OR Option 2: Tag

If you are configuring Didomi through a didomiConfig tag, you need to update your tag configuration to enable our GTM integration in the SDK. The events and variables pushed by Didomi to the dataLayer will not be available until the integration is enabled.
Add the tagManager.provider key in your didomiConfig object:
1
<script type="text/javascript">
2
window.didomiConfig = {
3
[...Your existing tag],
4
5
tagManager: {
6
provider: 'gtm'
7
}
8
};
9
</script>
Copied!
By default, Didomi uses window.dataLayer as the variable name for your GTM data layer. If you have renamed your data layer name (https://developers.google.com/tag-manager/devguide#renaming), you can instruct Didomi to use another variable name:
1
<script type="text/javascript">
2
window.didomiConfig = {
3
[...Your existing tag],
4
5
tagManager: {
6
provider: 'gtm',
7
dataLayerName: 'customDataLayer' // Custom data layer name (optional ; default to dataLayer)
8
}
9
};
10
</script>
Copied!
Embedding the Didomi SDK through GTM
We recommend not embedding the Didomi SDK through GTM. 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 GTM will result in fewer consents being passed to vendors and a lower consent rate from their perspective.

Step 2 - Create the variables in GTM

The Didomi SDK will automatically push variables and events to GTM that contain the user consent status. You can then use these custom variables and events to decide when to load a vendor tag on your website.
First, you need to create a data layer variable that maps to the didomiVendorsConsent variable for example, that will be pushed by the SDK onto the data layer.
1) Go to the "Folders" section of your Google Tag Manager workspace:
GTM folders
2) Create a new folder named "Didomi"
3) Click on “add new variable”
4) Create new user-defined variables, using the following configuration:
    Name: Didomi Vendors Consent
    Variable type: Data Layer Variable
    Data layer variable name: didomiVendorsConsent
GTM Didomi variable
Note: We recommend keeping Didomi's variables and triggers in a dedicated "Didomi" folder but you are free to structure resources differently.

Step 3 - Create triggers

You need to create triggers that will be used to decide when to load each tag in Google Tag Manager.
For every vendor tag that you need to control, in the "Folders" section of the manager, add a new trigger to the Didomi folder:
New trigger
And use the following configuration:
    Trigger name: "{name of the Vendor} – {id of the vendor}" for example (see “how to find your vendor ID” further down in the article)
    Trigger type: Custom event
    Event name: one of the events pushed by Didomi (didomi-consent, didomi-ready or didomi-consent-changed). We recommend using didomi-consent, because this event is merging didomi-consent-changed and didomi-ready. As a result, it will take care of a change of consent and a simple page load.
    “This trigger fires on “: Some Custom Events
    “Fire this trigger when an Event occurs and all of these conditions are true” :Didomi Vendors Consent contains {id of the vendor}
    Save.
GTM Didomi trigger
Repeat this process for every non-IAB vendor that you have. You need to create one trigger per non-IAB vendor.
Then, if your existing trigger is a custom trigger, you will need to create a Trigger group, so that the tag triggers when condition 1 (already existing condition) AND condition 2 (related to consent) are both met.
Otherwise, if you just add another firing trigger related to consent to a tag with an already existing condition, the tag will trigger when condition 1 OR condition 2 are met. But not necessarily both at the same time, and this will not be compliant.
In the "Folders" section of the manager, add a new trigger to the Didomi folder, using the following configuration :
    Trigger group name : Trigger Group - Consent + {other condition} - {name of the Vendor} – {id of the vendor}
    Trigger type: “Trigger Group”.
    Select the existing trigger of your tag.
    Also select the Didomi trigger for this vendor, that you created in step 3.
    Save
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 in the last column of the list of vendors:
Copy the SDK ID to get your vendor ID
Be careful, there is a particular case for 4 vendors.
For Facebook, Google Advertising Products, Amazon and Twitter, you will have to add the prefix “didomi:” before the ID given in the last column.
So the IDs that you need to use in your GTM are:
    Facebook (Connect, Social Plugins, etc.): “didomi:facebook”
    Google Advertising Products (DFP / Ad Manager etc.): “didomi:google”
    Amazon: “didomi:amazon”
    Twitter (Widgets, Analytics, Advertising, etc.): “didomi:twitter”
This trigger (or trigger group) can now be used to define tags that fire only when the user has given consent for that vendor.

Step 4 - Classify your tags

You now need to classify your tags and define what user consent is required for firing each of them. This last step is very important.
In the "Tags" section of your Google Tag Manager, edit EACH of your existing tag concerning non-IAB vendors and add the trigger or the trigger group (created at step 3) corresponding to the vendor that owns the tag instead of what was previously used.
Remember to condition the tags of all your containers.
GTM didomi tag
Moving forward, every time you add a new tag that does not implement the IAB specification and that requires GDPR consent, you must categorize it by adding the adequate trigger.

Variables

The Didomi SDK pushes variables to the GTM dataLayer 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 trigger 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 GTM trigger.
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 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 the GTM dataLayer to allow you to use triggers 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-consent
This event is pushed once when the page is loaded and then every time the consent status changes as the result of a user interacting with the Didomi consent notices or preferences.
Because this event does not distinguish between a page load and a subsequent status change, it can be fired multiple times on the page and is not suited for tags that must be fired at most once. You will usually want to use a combination of the didomi-ready and didomi-consent-changed events instead for these cases.
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.
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.
A deprecated didomi-cookies-consent event is also sent by the Didomi SDK. This event was used for a deprecated feature that is not supported anymore. You must ignore this event and not rely on it.
If you have your own custom events that you use as triggers 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:
1
window.didomiOnReady = window.didomiOnReady || [];
2
window.didomiOnReady.push(function (Didomi) {
3
// Fire your custom event(s)
4
dataLayer.push({'event': 'custom_event'});
5
});
Copied!
You can use as many didomiOnReady functions and put them anywhere in your code. Custom events that are not used as triggers 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 events triggers.

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 GTM 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.
1
function fireCustomEvents(consentStatus) {
2
if (consentStatus === true) {
3
// Fire your custom event(s) because the user has given consent
4
dataLayer.push({'event': 'custom_event'});
5
}
6
}
7
8
window.didomiOnReady = window.didomiOnReady || [];
9
window.didomiOnReady.push(function (Didomi) {
10
// The SDK is done loading, check the consent status of the user
11
const consentStatus = Didomi.getUserConsentStatusForVendor('vendor-id');
12
13
if (consentStatus === true) {
14
// The user has given consent for that vendor, fire the custom events
15
fireCustomEvents(consentStatus);
16
} else if(consentStatus === undefined) {
17
// The consent status of the user is not known yet
18
// Subscribe to the consent.changed event to get notified when it does
19
Didomi.on('consent.changed', function () {
20
// The consent status of the user has changed
21
fireCustomEvents(Didomi.getUserConsentStatusForVendor('vendor-id'));
22
});
23
}
24
});
Copied!
Last modified 1mo ago