Google Tag Manager

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 describe 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-changed 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.

Configure the Didomi / GTM integration

Step 1 - Enable our GTM integration

Didomi Console

If you are configuring Didomi through the Console, enable the GTM integration in the Integrations tab of your consent notice.

GTM integration in the Didomi Console

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:

<script type="text/javascript">
window.didomiConfig = {
[...Your existing tag],
tagManager: {
provider: 'gtm'
}
};
</script>

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:

<script type="text/javascript">
window.didomiConfig = {
[...Your existing tag],
tagManager: {
provider: 'gtm',
dataLayerName: 'customDataLayer' // Custom data layer name (optional ; default to dataLayer)
}
};
</script>

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 less 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 that will be pushed by the SDK onto the data layer.

Go to the "Folders" section of your Google Tag Manager workspace:

GTM folders

Create a new folder named "Didomi" then 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.

Please read below for the list of all variables that are pushed to GTM by the Didomi SDK.

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, using the following configuration:

  • Trigger name: "Vendor - IDXXX"

  • Trigger type: Custom event

  • Event name: one of the events pushed by Didomi (didomi-consent, didomi-ready or didomi-consent-changed)

  • Fire this trigger when: Didomi Vendors Consent contains prefix:vendorID,

GTM didomi trigger

This trigger can now be used to define tags that fire only when the user has given consent for that vendor. Repeat this process for every vendor that you have.

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

Step 4 - Classify your tags

You now need to classify your tags and define what user consent is required for firing each of them.

In the "Tags" section of the manager, edit each tag and add a trigger corresponding to the vendor that owns the tag.

GTM didomi tag

Moving forward, every time you add a new tag that does not implement the IAB specification and that requires a 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 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 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:

window.didomiOnReady = window.didomiOnReady || [];
window.didomiOnReady.push(function (Didomi) {
// Fire your custom event(s)
dataLayer.push({'event': 'custom_event'});
});

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.

function fireCustomEvents(consentStatus) {
if (consentStatus === true) {
// Fire your custom event(s) because the user has given consent
dataLayer.push({'event': '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.getUserConsentStatusForVendor('vendor-id');
if (consentStatus === true) {
// The user has given consent for that vendor, fire the custom events
fireCustomEvents(consentStatus);
} else if(consentStatus === undefined) {
// 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.getUserConsentStatusForVendor('vendor-id'));
});
}
});