Implementing OneTrust via Google Tag Manager
In recent years and months, more and more states have adopted data privacy regulations, to such a degree that keeping up with the compliance landscape has practically become a full-time job.
And if you haven’t heard already, these regulations aren’t toothless. In fact, a wave of cookie consent-related lawsuits have swept across the nation, as some enterprising lawyers have recognized the opportunity to profit from the gap between the expectations of privacy regulations such as California’s CIPA law, and the unaware or slow to respond tendencies of website operators.
Even if the judgements in these cases may not be astronomical, the headache of responding to such a complaint is something you’ll definitely want to avoid. You’ve got enough on your plate as is.
In our opinion, the best way to deal with ever-changing privacy regulations is to bring on a consent management platform (CMP) that will stay on top of the latest requirements for you.
With that in mind, today we’re continuing our series on GTM-based consent implementations with an eye on one of the biggest consent management platforms in the game: OneTrust. OneTrust offers a few different methods of implementation, but we prefer their GTM-based implementation. Implementing OneTrust via GTM will reduce the dev support required, help avoid data layer timing conflicts, is easier to update in the future, and in general provides a more transparent implementation and testing process.
While you can find basic implementation instructions from Google, a few key pieces are missing, particularly if you use server-side GTM to manage your CAPI implementations.
The Basics
We won’t waste your time re-writing instructions that are found elsewhere, so if you haven’t clicked the link above, do so now. Here, we’ll even make it easy for you: Set up OneTrust to obtain user consent. Follow everything that guide tells you, including:
Scanning your site for cookies, categorizing them, setting up geolocation rules, and building your banners inside OneTrust
Installing the OneTrust CMP tag template from the GTM Community Gallery
Configuring the OneTrust CMP tag and any region-specific defaults inside GTM
As a friendly reminder, don’t forget a couple of basic steps the guide assumes you’ve already done:
Enable consent overview inside your GTM container settings (Admin > Container Settings)
Configure the consent checks required on all 3rd-party tags, such as Meta Ads conversions, Pinterest Ads conversions, Hotjar or similar analytics platforms, and more
Google-related tags (GA4, Google Ads, etc.) can be configured with “No additional consent required”. While this technically isn’t necessary, it will prevent GTM from flagging these tags as having consent issues when you go to publish your container.
The Edge Cases
Even if you’ve followed the above instructions to the letter, you may still encounter a few common issues.
Pageview-Based Tag Errors
The problem: If you’re defaulting your users' consent state to “Denied”, keep in mind that certain key actions, such as pixel initialization or pageview events, may fire before a user has had a chance to opt-in to tracking. This can be a problem, as a pixel initialization tag failing to fire (because of blocked consent) may result in data issues for later events, even if a user opts into tracking.
The solution: Ensure that any tags blocked by the default consent state will still fire once consent is granted by the user. To do so, follow the below steps.
Create a new trigger, called “Event - OneTrustGroupsUpdated”
Type: Custom Event
Event Name: OneTrustGroupsUpdated
Fires on: All Custom Events
Add the new trigger to all page-view based tags.
Update the “Tag firing options” to “Once per page” for all impacted tags.
Servers-Side Data Collection
The problem: If you’re using server-side GTM for your CAPI events, you need to communicate the user’s consent state along with any events, to ensure that your tags don’t inadvertently violate the consent preferences selected.
Assuming you’re using GA4 tags to pass data to the tagging server, please keep in mind that the following is not required for server-side GA4 tags. Google’s built-in tags are able to read the consent state encoded in GA4 tags.
The solution: Attach consent parameters to all tagging-server bound events, and use these signals to prevents tags from firing unless consent has been granted. Follow these instructions:
Create a new variable in the client-side container called “OptanonConsent”
Type: 1st Party Cookie
Cookie Name: OptanonConsent
URI-decode cookie: enabled
Create a new variable in the client-side container for each type of consent you need to pass. For example, you might create a variable called “OneTrust Consent Status - Targeting Cookies Status” to govern all tags that require ad_storage consent.
Type: Custom Javascript
Custom JavaScript: see below
Notes:
The below code assumes that consent is denied by default. If this is not the case, you’ll need to update the script accordingly.
The below code assumes that the consent group C0004 is used to store the user’s ad storage consent state. Update this according to the consent groups configured in your OneTrust setup.
function() {
var cookie = {{OptanonConsent}};
if (!cookie) return "denied";
var match = cookie.match(/groups=([^&]*)/);
if (!match) return "denied";
var groups = match[1].split(',');
for (var i = 0; i < groups.length; i++) {
var parts = groups[i].split(':');
if (parts[0] === 'C0004') {
return parts[1] === '1' ? "granted" : "denied";
}
}
return "denied";
}
Update your GA4 event settings variable to pass a parameter for each type of consent you need to communicate to the tagging server. For example, you might create a parameter called “ad_storage” with a value of “{{OneTrust Consent Status - Targeting Cookies Status}}”.
In your server-side GTM container, create a new variable for each type of consent signal you’re passing your GA4 tags. For example:
Type: Event Data
Key Path: targeting_cookie_status
Set Default Value: enabled
Default Value: denied
Notes:
Update the key path according to whatever you’ve set the parameter name as in the previous step.
It’s a good idea to set the default value, in case the parameter is not included for any reason.
For each type of consent passed, create a new trigger in your server-side GTM container checking for whether the value is “denied”. For example:
Type: Custom
Fires on: Some Events
Conditions: {{Targeting Cookies Status}} equals denied
Notes:
The variable name in the condition should match whatever you named it in the previous step
Add your new triggers as trigger exceptions to all relevant tags in the server-side GTM container.
(Optional) If you’re passing data to GA4 via your server-side GTM container, remove the consent status parameters via a transformation.
Type: Exclude parameters:
Parameter to exclude: targeting_cookie_status (or whatever you named the parameters in your GA4 event settings variable)
Affected Tag Types: Some
Included Tag Types: GA4
We’re taking this approach because it can apply to all your GA4 tags no matter how many you have set up, and because it can be extended to other destinations, as needed.
Conclusion
As with all things consent: make sure you test, test, and test again. Clear your cookies between each test, and use GTM’s consent overview to ensure that GTM is recording the default and selected consent state appropriately. OneTrust even offers a handy way to simulate the experience users from different geographic regions will receive, a key element of testing.
If you need additional help, Avatria has extensive experience implementing consent solutions for clients. Don’t hesitate to reach out via the form below!