Stape
Search
Try for free

How to set up consent management using GTM and Didomi

Published
Nov 13, 2024

Managing user consent is more important than ever, especially with privacy laws like GDPR and CCPA. It’s essential to make sure you're collecting and using data based on what users agree to. Server-side consent management helps you do this more securely and with better tracking accuracy.

Didomi is a leading Consent Management Platform that helps businesses ensure they comply with data privacy regulations. Both Didomi and Stape are committed to data security and privacy. With this shared focus, we teamed up to write this article, aiming to simplify the process of implementing server-side consent management and ensure your business stays compliant with evolving privacy standards.

In this article, we’ll show you how to set up server-side consent management using Google Tag Manager (GTM) and Didomi. By the end, you’ll know how to collect and manage user consent easily and keep your data practices clear and compliant with regulations.

Many people mistakenly believe that consent management is optional with server-side tagging, but this is not true. Just like with web tracking, consent management is essential for server-side tagging.

Here’s how consent works in server GTM:

  • The consent banner on your website gathers the user's consent preferences and passes them to the tag responsible for transmitting consent status from the web to server GTM, such as Google Tag.
  • This tag sends a parameter containing the consent status to the server GTM.
  • Inside the server, tag behavior is adjusted based on the value of the consent status parameter.

Implementing consent management provides several key advantages, making it an increasingly popular solution for businesses managing user data across websites and mobile apps. Here are the main benefits:

BenefitDescription
1. Improved data privacy compliance- Enhanced control: manage consent at the server level to comply with regulations like GDPR, CCPA, and ePrivacy, ensuring no personal data is collected without explicit user consent.- Fewer data leaks: reduces unauthorized third-party access to data, enhancing security and protecting user information.
2. Increased data security- Server-side data handling: data processed in a secure server environment minimizes risks of tampering or interception compared to client-side tracking.- Lower exposure to ad blockers: bypasses ad blockers, ensuring critical tracking and analytics function without compromising user privacy.
3. Unified consent across platforms- Cross-platform consistency: apply user consent across multiple platforms (websites, mobile apps), ensuring uniform data handling and preventing discrepancies.- Centralized consent management: simplifies consent management by applying the same settings across various tools and platforms.
4. Better site performance- Reduced browser load: offloading tracking to the server lessens the load on the client’s browser, improving page load times and user experience.- Faster tag execution: server-side tags execute independently of the user's browser, enhancing the reliability and speed of data collection.
5. More accurate data collection- Minimized data loss: less likelihood of data collection being blocked or disrupted by browser restrictions or tracking protection measures, leading to greater accuracy.- Anonymized tracking for non-consent: collect anonymized data in advanced consent mode, allowing for machine learning and informed decisions based on aggregated data.

What’s needed for the setup

To effectively manage consent within server-side GTM, you'll need several components in place:

  1. Consent management platform (CMP): e.g. Didomi.
  2. Web and server Google Tag Manager containers: both must be set up for seamless data flow.
  3. Server-side Google Analytics 4: server-side GA4 will forward the user’s consent status from the web container. Other tags can also be used to transmit consent status, which will be covered in an upcoming blog post.

There are two consent behavior modes in Google Tags, and each affects the implementation of server-side consent differently:

Consent behaviorDescriptionImpact on implementation
Basic consent modeGoogle tags are blocked from loading until the user consents. No pings are sent to Google, meaning ssGA4 cannot transmit user consent status.-
Advanced consent modeGoogle tags send anonymized pings even without user consent, which helps Google use machine learning to model user behavior without consent.GA4 pings can be used to track consent status on the server, and Google will use consented data to model the behavior of non-consented users.

Here is a list of our articles about consent, as we have covered this topic extensively in the past:

1.1. Activate Didomi GTM integration

Enable the GTM integration in the Integrations tab of your consent notice by selecting this option:

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 (1.2 - Create the variables in GTM).

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.

1.2. Set up 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 set up a data layer variable that maps to the didomiVendorsEnabled variable, for instance, that will be pushed by the SDK onto the data layer.

1, Go to the "Folders" section of your Google Tag Manager workspace.

2. Make a new folder named "Didomi."

3. Click on “add new variable.”

4. Create new user-defined variables, using the following settings:

  • Name: Didomi Vendors Consent
  • Variable type: Data Layer Variable
  • Data layer variable name: didomiVendorsEnabled
Note: We recommend keeping Didomi's variables and triggers in a corresponding "Didomi" folder but you are welcome to structure resources differently.

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

1.3. Set up triggers

You need to create triggers that will be utilized 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:

Use the following configuration:

  • Trigger name: "{name of the Vendor} – {id of the vendor}", for instance, 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 Enabled contains {id of the vendor},. Use the full ID of the vendor with an additional comma (,) at the end.
  • Save.

When matching vendors by IDs in variables, use the full ID of the vendor with an additional comma (,) at the end to ensure IDs do not get mixed and matched. For instance: Use google, to match the vendor with ID google and not the vendor with ID googleana-4TXnJigR.

Repeat this process for every non-IAB vendor that you have. You need to create one trigger per non-IAB vendor.

Then, if your current 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 section 1.3.
  • Save.
Note: Please note that trigger groups are triggered once per page only, which can be an issue when using dynamic websites. In that case, you can use our functions and events. And in the specific context of a SPA, you can refer to our dedicated GitHub page.  

How to find your vendor ID?

To find your vendor ID, in your Didomi account, go to Consent notices -> Open your notice -> Regulation -> Edit vendors and Purposes: copy the API ID. Learn more about variables in this documentation.

This trigger (or trigger group) can now be used to define tags that fire only when the user has given consent for that vendor.

Following these directions while also enabling Google Consent Mode, will result in negatively impacting the Consent Mode functionality by blocking the Google tags from firing until consent is granted.

If enabling Google Consent Mode via our GCM direct integration, make sure that no consent-aware tags are configured for Google tags (vendors google , googleana-4TXnJigR).

To make sure Google Consent Mode is active, you will have to remove any consent-aware event and only use the didomi-ready event.

1.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 1.3) corresponding to the vendor that owns the tag instead of what was previously used.

Remember to condition the tags of all your containers.

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.

If you’d like to set up advanced consent mode, please choose a preferable option: the Didomi console or the GTM template.

You can read more about how to configure Google Consent Mode with Didomi in their official documentation.

2.1. Using Didomi Console

  • Go to the Consent notices section and click on the Edit icon corresponding to your notice
  • Proceed to step 2. Customization, then to the Integrations section.
  • Click on the Advertising tab.
  • Enable the integration (check the box at the top right)
  • You can activate the integration and select either the Google Analytics products vendor, or Google Advertising Products, or both vendors

Check the item "Set the default status" to be able to make a specific choice on each of the associated sub-options. Checked sub-options indicate that the status will be set to granted when the page initially loads.

For example, if you enable "Enable ad_storage before user gives consent", on your website, the initial page load for ad_storage will be set to granted

2.2. Using the Didomi GTM template

Follow these instructions to configure GCM with the Didomi GTM template.

Set the default status to GCM granted for the desired permission(s).

2.3. Set up Google Tags

Google tags (Ad Words, Analytics, Conversion Linker and Floodlight) should be loaded as soon as the SDK is ready.

The tags will then send data based on the default status.

In advanced mode, it is therefore important to define the default status that you want Didomi to expose.

To configure Advanced Mode with Google Tag Manager, use the didomi-ready event to ensure that Google tags are loaded once the Didomi SDK is ready and Consent mode is set (or a trigger group if necessary).

You can refer to this documentation.

3. Configure server GTM container

If you don’t have a server container, check out our guide on how to set it up using server Google Tag Manager

3.1. Configure a custom domain for your server GTM container on Stape. Once the custom domain is added, you need to configure the DNS setting you see on the screen. Domain verification can take up to 72 hours.

3.2. Go to the server Google Tag Manager container settings and add a custom domain or the default tagging server URL (not recommended) inside server GTM.

3.3. Update the web GTM script on your website with the Custom Loader.

4. Setting up server-side GA4

There can be two options:

4.1. If you’ve already configured Google Analytics 4 inside your web GTM container, all you need to do is:

4.1.1. Add your server container URL to Google Tag settings. In the configuration settings, add the configuration parameter server_container_url and add your tagging server URL as a value.

4.1.2. Set up Google Analytics 4 client in server GTM container. To do it, open the clients’ section → Create New client → Select client type Google Analytics: GA4 (Web) → Add client name and click Save.

4.1.3. In the server GTM container make a new tag with the tag type Google Analytics: GA4.

4.1.4. Add Measurement ID and Event Name.

Measurement ID -  Follow this guide to find GA4 ID. You can add it as a variable or if the event came from a GA4 web tag, you can leave this field blank to inherit the measurement ID of the event.

Event Name - the event name to send to Google. See the recommended events for more information. If this field is empty, the value of the event_name parameter will be sent.

4.1.5. Click Triggering and set up a trigger with the trigger type Custom that will fire every time when client name equals GA4 (or the name of the GA4 client that you’ve specified on the step 2.b) → Click Save.

4.2. If you do not have GA4 configured, follow the below steps:

4.2.1. Inside the Web container, set up a new tag of the tag type Google Tag. Add your Google Tag ID.

Add trigger to GA4 tag.

You can also create a Google Tag: Configuration Settings variable that will predefine Google Tag settings if you need to use multiple Google Tags on your website and do not want to add settings for each tag manually.

These parameters can, for instance, define whether you want to send a page view event every time a Google Tag triggers, set UTM parameters, set client ID, etc. There is a list of standard Google Tags configuration parameters.

4.2.2. To set up the GA4 event tracking, go to the tags section and make a new tag with the tag type Google Analytics: GA4 Event. Add your GA4 ID and the event name; there is a list of standard event names.

4.2.3. Go to your Google Tag Manager Server container. Click Clients and New.

4.2.4. Choose Google Analytics: GA4 (web) and click Save.

4.2.5. Go to Tags and click New.

4.2.6. Choose Google Analytics: GA4.

4.2.7. Add Measurement ID and Event Name.

Measurement ID -  Follow this guide to find GA4 ID.  You can add it as a variable or if the event came from a GA4 web tag, you can leave this field blank to inherit the measurement ID of the event.

Event Name - the event name to send to Google. See the recommended events for more information. If this field is blank, the value of the event_name parameter will be sent.

4.2.8. Click Triggering.

4.2.9. Create triggers for the tag. Client name should equal GA4. 

4.2.10. Open web and server GTM debuggers and test the setup. 

Open the Server container preview mode and check that you see GA4 requests. Publish updated inside server and web Google Tag Manager containers.

GTM works with consent management platforms like Didomi to modify tag behavior based on user consent. Google Tags, such as GA4, automatically adjust according to the user consent settings configured in the web GTM.

For advanced consent, GA4 will continue to send anonymized pings even if users do not provide consent for analytics cookies. To activate this option, update the Consent Settings in web GTM to No additional consent required. There’s no need for any additional configuration in server GTM for advanced consent.

To limit all GA4 data collection without explicit consent, set the consent settings to Require additional consent in web GTM. Server-side GA4 will comply with the consent rules set in web GTM.

In advanced consent mode, anonymized GA4 requests are sent to server GTM. Facebook Conversion API triggers are based on the GCS parameter value. The CAPI tag should only trigger when ad_storage cookies are allowed (when GCS is 110 or 111).

6.1.1. Create a GCS variable

In server GTM, create a new variable to read the GCS parameter from the GA4 request. Use the Event Data variable type and input x-ga-gcs as the key path.

6.1.2. Update Facebook CAPI tag

Update the Facebook conversion API tag to trigger only when the x-ga-gcs variable equals 110 or 111.

With basic consent mode, GA4 does not send anonymized pings to the server container, so you will need another way to deliver users’ consent state to sGTM. In this example, we will use Data Tag and Data Client to transmit user consent to sGTM.

6.2.1. Add Data tag in web GTM

Add the Data Tag from the community template gallery. Set the event name, transport URL (from step 2.3), and scroll to consent settings. Select Require additional consent for the tag to fire and choose ad_storage.

6.2.2. Trigger Data tag on consent update

Ensure the Data Tag triggers on the custom event didomi-consent.

6.2.3. Add Data client template in server GTM

Download the Data Client Template and add it to your server GTM container. Go to the template section, click New, then click the three dots in the top-right corner and select Import.

6.2.4. Set up data client

Create a new Data Client in the client section of your server GTM container. This client will retrieve consent information sent by the Data Tag.

6.2.5. Update Facebook CAPI trigger

Update the Facebook CAPI tag trigger so that it fires when the Data Client is claimed, and the event’s name is marketing_consent.

To sum up

Implementing server-side consent management with GTM and Didomi provides a robust foundation for privacy compliance while maintaining data accuracy.

This setup ensures proper consent collection before any data processing, supports basic and advanced implementations for Google consent mode, and enables granular control over vendor permissions.

Following the implementation steps listed in the article, organizations can achieve seamless consent synchronization between client and server environments, enhance data security, and improve site performance - while fostering user trust and meeting regulatory standards.

Remember to regularly test your configuration, monitor consent analytics, and stay updated with evolving privacy requirements for optimal results.

If you need guidance on optimizing your consent management implementation, our team is here to help. If you have any questions, feel free to reach out.

Try Stape for all things server-sideright now!