OneTrust Implementation in Adobe Launch

OneTrust offers a comprehensive platform to help businesses achieve and maintain compliance with the California Consumer Privacy Act (CCPA), General Data Protection Regulation (GDPR) and other privacy related regulations across the world.

This is my first collaboration piece, working with Andrew to explore OneTrust. 
Post from andrew can be found here.

In this post, I have shared my experience of OneTrust integration with tag management solution adobe launch, but conceptually this would work similarly on other TMS like Google Tag Manager(GTM) etc. During the implementation of oneTrust we faced a few problems and this post shares technical details about how we overcame those problems. Any suggestions or feedback, please comment below.

Problem statement 1 : When different pages of a website are maintained by the different dev teams, there have been a few cases where oneTrust library is not present on some of the pages. As a result, we can’t fully rely on JavaScript variable OnetrustActiveGroups to determine the consent status.

Solution 1: Check for OptanonConsent cookie if JavaScript variable OnetrustActiveGroups is not available.

Problem statement 2 : On some pages, OptanonConsent cookie is set at a particular path ( such as /abcd/def ) instead of all path ( / ). Let’s say the user lander on www.site.com/path1 and denies the consent, then the user goes to page www.site/com/path2 which doesn’t have oneTrust library. Now we don’t have JavaScript variable OnetrustActiveGroups as well and we can’t access OptanonConsent cookie as the cookie path is different.

Solution 2: Clone OptanonConsent cookie to ck_OptanonConsent_fallback cookie and set path as all path (./)

Problem statement 3 : OptanonConsent cookie is set at the subdomain level instead of the parent domain level. Let’s say the user lander on www.site.com/path1 and denies the consent which sets the OptanonConsent cookie at domain .www.site.com , then the user goes to www.subdomain.site.com which doesn’t have oneTrust library. Now we don’t have JavaScript variable OnetrustActiveGroups as well and we can’t access OptanonConsent cookie as the cookie subdomain is different.

Solution 3: Clone OptanonConsent cookie to ck_OptanonConsent_fallback cookie and set domain as dot parent domain (.site.com)

While discussing with Andrew, he suggested that there is also an option available in oneTrust admin configuration to set the cookie at the subdomain level instead of the parent domain. However, by default, this is turned off. Isn’t it strange why oneTrust has kept this off by default, and it’s not easy to locate this setting?

Problem statement 4 : Intermittently oneTrust sets JavaScript value of OnetrustActiveGroups as an empty string with just commas (‘,,’) for a few milliseconds before it populated with actual group value (such as ‘,C0001,C0002,C0003,C0004,CADNS’). Empty groups give false positive results of consent status.

Solution 4: Skip JavaScript OnetrustActiveGroups if it contains an empty string with commas, and validate the next check i.e OptanonConsent cookie.

Problem statement 5 : User lands on the first page which doesn’t have oneTrust library. Now we don’t have JavaScript variable OnetrustActiveGroups, nor cookie OptanonConsent to determine consent status.

Solution 5 : Have fallback hardcoded default consent status based on CCPA/GDPR etc privacy laws.

Problem statement 6 : OneTrust loads on a site with delay as a result OptonWrapper is not fully reliable for tracking changes in consent and triggering Adobe launch rule or Google tag manager tags.

Solution 6 : Attach a listener to page load event, that would have DirectCall trigger in adobe launch when OptonWrapper function is not available on the page.

The site I used had both Adobe Launch for Adobe Analytics, and Google Tag Manager for Google Analytics as well as Media Analytics (Third party tracking)

List of business and technical requirements when consent is denied.

1) Block Adobe Analytics { CADNS value or OptIn status used to block }
2) Block Google Analytics { CADNS value or OptIn status used to block }
3) Block Media Analytics { CADNS value or OptIn status used to block }
4) Implement consent V2 in GTM {not converted in this article}
5) Implement ECID optIn service at runtime {not converted in this article}
6) Delete ECID and other adobe cookies

Implementation Details

1. Create a DataElement name ‘OnetrustActiveGroups’
   - first check for JavaScript variable OnetrustActiveGroups
   - second check for cookie OptanonConsent and extract groups information
   - third check for fallback cookie ck_OptanonConsent_fallback and extract groups information
   - forth default fallback hardcoded consent

Note: This code be optimized by creating a function to extract groups from cookie

2) Create a dataElement ‘cc_OneTrust_Consent_status’ to return OptIn/OptOut status, so it can be used for props/evar or any other variable etc

3) Create a pageTop rule in launch that would during optOut
- delete the adobe cookies
- update cookie ck_oneTrustGTMconsent for the GTM consent V2 purpose
- triggers the GTM datalayer event launch_optonWrapper
- attach listener at load event that triggers DirectCall when optonWrapper is not available.

We intentionally created cookieListDoDelete as an object having key (CADNS) from the consent groups. So if in future, if we have to delete different sets of cookies based on each consent group, and then we just have to update cookieListDoDelete variable. This is added complexity and not required as per current requirement, but we kept it to make it future-proof.

4) Create a DirectCall rule in launch that would do exactly same as pageTop rule, when optonWrapper function is not available due to the delay or any other reason.

Note: this rule is very similar to previous rule, with few minor difference. They can be merged to optimize the code.