Google Consent Mode with OneTrust and Tag Manager

Intro

In one of the previous articles, I provided a general overview of what Google Consent Mode is and the benefits it offers to businesses. In essence, Google Consent Mode is a solution provided by Google that enables website owners to respect users’ privacy rights while still obtaining high-quality depersonalised reporting on website activity.

OneTrust is a Consent Management Platform that empowers users to create and control their consent preferences for different types of cookies. Integrating this tool into a website can be accomplished by a web analyst through Google Tag Manager, or more commonly, it will be configured by a developer. From the visitors’ perspective, it appears as a familiar banner where they can provide consent for tracking.

Once OneTrust is added, we should begin working on Google Consent Mode. Consent Mode is a special tag management mode that serves as a layer allowing Google to determine which cookies a user has accepted or rejected, thus enabling decisions on how to handle the associated tag or event triggered by that user.

Each CMP system and its configurations can vary, which means consent orchestration can differ as well. I’d like to present a case: a website that already has OneTrust configured at the code level. The website includes events and a container where Consent Mode needs to be configured.

Configuration Case

Enable Consent Mode

The first thing to do is to enable “Enable consent overview” in the container settings.

Set up Tags’ Consent Checks

Next, you can proceed with configuring all the tags.

In my case, it’s necessary to set up each tag to check for consent to use cookies for analytics and advertising retargeting. Therefore, only the standard Built-in Consent Checks — ad_storage and analytics_storage are important.

Choose “No additional consent required” and proceed unless your technical requirements exceed the outlined scope.

Initiate Default Consent Status

In the templates, look for “Consent Mode (Google tags)” by Simo Ahava, add it, and create a tag named “Consent Mode — Default.” In the Consent Command field, choose the “Default” option.

Before you start interacting with OneTrust variables, you need to establish default consent settings for the entire website. These settings will be in effect until user-initiated consent is obtained or is detected. It’s essential to have guidance from the business for this step. In my case, until the user gives consent, we assume that the website is not authorised to use Advertising, Analytics, or Functionality cookies. This configuration is being fired using the “Consent Mode Initialization” trigger on all pages.

It’s worth mentioning that you have the option to customize the template and define which cookies you need to manage based on consent.

In a straightforward setup, you will encounter the following situation in Tag Assistant. The Set and Consent events will encompass all the configurations you selected in Consent Mode (Google tags), which you established using the installed template.

Initiate Real User Consent Status

Once we’ve established the default consent values before the website loads, we can proceed to configure consent checks and update the previously defined values to ensure they match visitors real consent.

To accomplish this, within the newly created Consent Mode (Google tags) tag, you should select the “Update” option in the Consent Command field.

Then, we need to specify the values that should be sent based on each type of cookie. There is a point that we begin working with the variable settings sent through OneTrust.

As we can see, each field contains a Custom JavaScript function that acts as an orchestrator for OneTrust variables, enabling the transmission of user consent or non-consent to ensure the proper functioning of Google Consent Mode.

Before delving into the syntax of this function, I suggest taking a look at what a consent variable looks like in an event triggered by OneTrust. In my case, this event was configured by developers.

For instance, when we first visit the website and encounter the OneTrust banner, in Tag Assistant, we observe that the “OneTrustLoaded” event has been triggered, accompanied by the “OnetrustActiveGroups” variable. This variable will have a value of “,1,” signifying the absence of user consent. Consequently, without interacting with the banner, developers have established non-consent as the default value.

When we provide consent for the use of all cookies and click the “Accept Cookies” button on the banner, we receive an update to this variable in the data layer.

In my situation, consent is granted for a group of cookies, where each digit corresponds to consent for a specific category. The ones of utmost importance to us are the ones described and selected at the beginning of this article. Each of these categories is assigned a specific digit within OneTrust, depending on the settings.

By the way, it’s worth noting that we cannot create a trigger to update consent for Google Consent Mode using the “Message” event. Therefore, if you encounter a similar configuration scenario and the developer hasn’t created a custom event for updating values in “OneTrustActiveGroups,” on which you can base a trigger, we can effectively address it ourselves with the following script.

<script>
  setTimeout(function() {
    var isOnetrustActive = false;
    for (var i = 0; i < dataLayer.length; i++) {
      if (typeof dataLayer[i] === 'object' && dataLayer[i].hasOwnProperty('OnetrustActiveGroups') && dataLayer[i]['OnetrustActiveGroups'].indexOf(',1,') !== -1) {
        isOnetrustActive = true;
        break;
      }
    }
    if (isOnetrustActive) {
      dataLayer.push({
        'event': 'isOnetrustActiveCheckingTrue'
      });
    }
  }, 250);
</script>

The script should be fired after clicking the consent banner. It checks, with a small delay, whether the necessary object and corresponding value exist in the data layer.

Orchestrating OneTrust variables

Now, let’s go back to the Consent Mode (Google tags) tag we created for consent updates. In each field, we need to insert a function that retrieves the value from OnetrustActiveGroups and sends either ‘granted’ or ‘denied,’ which are standard for Google Consent Mode.

Therefore, we must create as many functions as the number of cookies we have and link them accordingly to each digit within the OneTrust group.

Before creating these functions, you will need to establish a Data Layer Variable with the value of OnetrustActiveGroups.

function() {  if ({{Data Layer Variable - OnetrustActiveGroups}}.indexOf(',2,') !== -1) {
    return 'granted';  } else {
    return 'denied';  }
}

After all the functions are added, and the tag is set to execute immediately following a click and updating the values of the OneTrust cookie groups, we observe the following scenario in Tag Assistant.

If each event (tag) is configured correctly within the container, when the event is triggered, we will observe the following in Tag Assistant.

In this manner, we can validate the accuracy of the settings and the functionality of the consent mode.

Post Scriptum

You might be wondering if it’s necessary to trigger the Google Tag (Configuration Tag) following successful consent or its update.

The answer is no.

It is adequate to activate configuration tag with a page view once on a page, for example, during the “Container Loaded” event.

It’s highly likely that the initial page view will have consent denied if a user is new. However, once the user grants consent, you will observe a “user_engagement” event with the client_id.

It may not be immediately apparent in standard reports, but Google will process this interaction in a way that, in your property, you will receive a fully viewable “Page View” event the following day or two.

If you add the execution of a new configuration tag, you may end up with a duplicated events.

It’s important to remember that configuring Consent Mode always carries a risk of errors. On one hand, there’s a chance of compromising data integrity and quality if you set up it wrong way. On the other hand, it offers a more comprehensive understanding of what’s happening on the website. In addition to the data modeling feature when we use Blended user identity in the Google Analytics 4 UI property, we’ll have access to all the events in BigQuery, that we can conveniently aggregate and analyse. Although we won’t be able to associate them with specific user identities, we can still perform calculations and estimate the approximate number of potentially missed users.

It’s a trade-off that’s worth considering.

If you find value in this article and it helps your work, I would deeply appreciate your applause.

Such support inspires me to create more valuable content.