How I got OneTrust to Work with Adobe Launch

Disclaimer: I’m not a lawyer. Please don’t take any of this post as legal advice. I claim no responsibility for how the information in this post is used. Each organization needs to work with their lawyers to ensure their setup is compliant. Please test thoroughly and often to make sure your OneTrust set up is working as expected.

You’ll note I’m not calling this “The Best Way to set up OneTrust in Launch”, because I don’t know if this IS the best way; it’s just the only way I could get it all to work in my particular situation. If folks have found other potentially better ways I’d love to exchange knowledge! I will be updating this post if and/or when I learn new things.

To be honest, this is one of the scarier posts I’ve written (and not just for legal reasons)- I fully expect someone to say “this is a really weird way of doing it” (heaven knows I’ve said to myself “there must be a better way”). And I do know there are probably a few places where I could simplify/optimize. But I’ve talked to a lot of different people trying to set up OneTrust, and no one has ever been able to give me a different/better way yet, and I’m getting asked weekly how I’ve managed to get it to work, so here goes!

While this post is very specific to Adobe Launch*, a lot of the script and logic could apply to any TMS/Adobe Analytics setup. Some of it could even apply to other Consent Management Platforms (CMPs).

This post is long, and while the topic is complicated, much of what I’ve included is just for reference, so please don’t feel overwhelmed. We’ve got this.

Also, don’t be evil. I primarily work with first-party analytics (ie, Adobe Analytics), and I have no ethical compunctions about doing so. The only impact we have on the user is we improve website experiences (and I don’t mean that in a “we show better ads” way… I mean our focus is the actual site user experience). That said, I don’t want to “trick” the user into allowing it, and I want them to be informed about it. But consent management (and tag management) also applies to stuff that can be very ethically (not to mention legally) questionable. Prioritize your user’s privacy. Keep them informed. Remember most regulations don’t care specifically about cookies, they care about what you are doing with user’s data (which often includes but is not limited to cookies). There is no “getting around” requests for privacy. (That goes for server-side tracking, too, by the way.)

My Goals With This Setup (Opt-In and Opt-Out)

I’ve worked with OneTrust*** and Launch a fair amount, but for one project in particular, I had nearly complete ownership of it- this is the project I’m basing this post off.

Their set up had to work for a Launch property that has users throughout the US, as well as in a few EU countries, meaning we need to account for situations where we can track only if the user has opted in (GDPR), AND situations where we can track until the user has opted out (most non-GDPR regulations, like California’s CCPA**).

We’ve set up two OneTrust templates and two Geolocation rules. Fortunately, OneTrust uses geolocation to tell which banner they need to show the user, and whether they should be considered opted-in or opted-out by default. Unfortunately, on the very first page view, if OneTrust hasn’t had a full chance to run its script and define those categories, you can have timing issues, so we’ll have to work around that in this solution.

Some organizations choose to just treat EVERYONE as opt-in-only, including in the US where that is not legally necessary. This definitely is the legally safest choice but given that most orgs get opt-in rates of 30-50%, you may end up losing 50-70% of your data. I’ve seen one site in the UK that only had 11% of users opt in, though if you optimize your banner and really think through how you present information to your users, you should be able to get it much much higher. Either way, our goal here was to opt-in as many people as we legally/ethically could.

OneTrust Setup

I’m not going to get too into too much detail here about the actual configuration in OneTrust; OneTrust’s documentation is pretty thorough (though guilty of the atrocity of requiring you to login to access it***) and this post is more than long enough already. This whole post assumes you have an entirely correct and compliant set up in OneTrust including that you’ve correctly created your “Categorizations”, you’ve created banners (though I do have tips for working with their CSS- ping me on twitter or slack if it’s giving you trouble), and you’ve made sure your Geolocation rules are set up correctly (make sure you check the “Do Not Track” and “Global Privacy Control” options!)

Don’t use Autoblock if you can help it

As you publish a script in OneTrust, it gives you an option to toggle on Automatic Blocking of Cookies, also known as Autoblock:

Autoblock basically allows itself to become a middle man between your user and anything your site is trying to load. Everything gets routed through it and it gets to choose which requests to block or allow, based on what the user has consented to. This may be tempting… in theory, you could leave all of your tags and cookies in OneTrust’s hands and not have to worry about setting up conditions in your TMS. (I’ve heard a few people mention how much this feels like when TMSes were touted as “one simple line of code that does all the work for you!”)

But please consider it only as a last resort! Yes, turning off Autoblock and instead using conditions to decide which tags to fire looks like a lot more work, but it’s more flexible, and gives you more control and visibility. (And, to be honest, getting Autoblock to work the way you want may end up being more work than you expect, anyways.) I had a whole section of this post devoted to Autoblock, but it was enough it merited a post of its own. So please, before deciding to use Autoblock, get enough information to make an informed decision.

Why not use OneTrust to block Launch altogether?

This is another kind of lazy (or overzealous) solution I’ve seen folks try: just don’t load your TMS library at all until the user has consented to some tracking. Certainly, it is a fairly safe approach (assuming you don’t have anything on your site, outside of your TMS, that needs consent). It really limits your flexibility, though. Especially if you have different categories for consent, you may want to fire analytics (performance category) but not Doubleclick (marketing/targeting category). Or you may have script in your TMS that doesn’t require consent… for instance, I know of one site that uses Launch to deploy some ADA compliance updates (hardly a best practice, but it happens). Or your TMS may have code in it that helps keep you compliant by managing cookies, etc.

In an opt-out scenario, such an approach seems a bit silly- by the time they opt out, your TMS has already loaded and may continue tracking link clicks, etc.

In an opt-in/GDPR scenario, there is a key reason I don’t like this approach: the ECID Opt-In Service, when set up properly, is very good at holding on to tracking until there is consent.

So if my page loads, and we don’t have consent, but my Page Load rule normally would have set variables and fire a beacon… those actions get queued up, so to speak, for once the user DOES consent. Once they click the “allow all” button, my Page Load rule doesn’t re-run, but the things it would have done initially, like sending page view data to Adobe, finally get to fire. That way, you don’t have to either fire a new rule after acceptance, or wait until the next page view, to get information about that first critical page view (which often includes things like Campaign tracking codes or session referrer information).

Why not use the OneTrust Launch Extension?

I hate to say it, but the OneTrust extension doesn’t offer many advantages***. There is still enough you have to set up and tweak outside of it that in the end, you may as well just skip using it. Not using it keeps everything transparent, too, which I like.

Global “True” Page Top Rule

The setup we used needed a rule that runs before anything else possibly even starts. This is particularly important if you are firing your OneTrust library from within Launch, but you may want it either way, to set up compliance logic before anything else fires.

We didn’t even use “Page Top” as the trigger; rather we used a little trick that ensures it really is the first thing to run: we create an Custom Code Event that just contains one line of code:

trigger();

And we set the order on that to -1 (or 0 or 1… just make sure it’s a lower number than anything else):

That may all seem overkill (and it may very well be) but it gives us some peace of mind, without negative side effects.

Inserting the OneTrust library (from within Launch, if you must)

Ideally you would have your devs insert the OneTrust library directly on the page, as high on the page as possible. This will give you the best chance to not have timing issues. To be clear: this is my recommendation. If you’re going that route, skip to the “Set up consent data elements” section.

But we live in the real world, where sometimes we have to work with what’s available. In this particular client case, a hard-coded reference to OneTrust wasn’t a practical option at the time, so we needed to add our OneTrust libraries into the Page Top rule we just created.

We put a single Custom Code Action in this rule, which calls on our OneTrust library. You can get these code snippets from within OneTrust- the important part is the data-domain-script. Note, you can get both a test script and a production script snippet from OneTrust, similar to how Launch has a dev environment to test your changes before you go to prod. Just make sure you’re using the right one for the stage you’re at.

We’ll also use this rule and code block to fire our Adobe/ECID consent, but we’ll come back to that later.

Set up consent data elements

I tend to have one master “Onetrust Consent Groups” data element, then data elements for each category:

For the master consent groups data element, we have a few things we need to consider. OneTrust provides two places to see what groups your user is in:

1. The most supported-by-OneTrust approach is to use a Javascript object, window.OnetrustActiveGroups, which returns a value like this:
‘,C0001,C0003,C0007,C0004,C0002,’
These codes correspond to the Categories you set up in OneTrust. You can view YOUR Categories by going to Categorizations>Categories.

2. An “OptanonConsent” cookie, which I’m pretty sure they don’t particularly want us using, but it can be handy because once it is created, it’s accessible as a page loads, before that window.OnetrustActiveGroups object is. It returns a value like this:

isGpcEnabled=0&datestamp=Tue+Mar+14+2023+12:10:28+GMT-0400+(Eastern+Daylight+Time)&version=202212.1.0&isIABGlobal=false&hosts=&landingPath=NotLandingPage&groups=C0001:1,C0003:1,C0007:1,C0004:1,C0002:1&AwaitingReconsent=false&geolocation=US;GAConsoleNetwork request blockingSearchIssuestop

…which is a bit messy, but potentially useable. I don’t currently use it in my solution but I figured I’d note it because I have seen others use it.

Important: Timing Issues for opt-in land (GDPR)

(To be clear, much of this section is only needed for folks who have timing issues because their OneTrust library is loaded by Launch or isn’t loading before Launch starts trying to do stuff.)

The problem is, if your OneTrust library is not called as high on the page as possible, there is a chance that OnetrustActiveGroups JavaScript object won’t exist when you need it; on each page load, it has to wait for the OneTrust library to create it. And the cookie only exists after the first time the OneTrust library loads… meaning if it’s the user’s first page view, you won’t know whether they count as opted-in or opted-out until after the OneTrust library loads! That’s one reason you should put the OneTrust library as high on your page as possible. But if you can’t, or you just want a failsafe, you can define some default consent groups. This would be simple if you were in a everyone-is-auto-opted-in scenario, or a everyone-is-auto-opted-out scenario. Where it gets fun is when you need to account for both.

Fortunately, my client already has a reliable method to tell me the user’s country (and even continent!) I’ll be honest, I’m not sure what I would have done otherwise, because we have to be able to detect the user’s jurisdiction to decide if they should be auto-opted-in or auto-opted-out. I have some theories of other ways we could do this but I’m glad I already had a reliable way to do it. Here is what I did for my “onetrust consent groups” data element:

try {
  var consentGroups=""
    if(window.OnetrustActiveGroups){
        consentGroups=window.OnetrustActiveGroups //if this exists and is accurate, use it. We often have a timing issue though. So, our back up options:
    }else if( _satellite.cookie.get("OptConsentGroups")){
        consentGroups=_satellite.cookie.get("OptConsentGroups") //if we've previously gotten the consent groups, we don't have to worry about the timing with onetrust, we just grab it from a cookie that we create
    }else if(_satellite.getVar("continentCode")=="eu" || navigator.globalPrivacyControl==1 || navigator.doNotTrack==1){//if no previous permissions, but in the EU or have GPC or DNT enabled, opt OUT of all not-strictly-necessary
        consentGroups=',C0001,'
    }else{ //everyone NOT in the EU who doesn't have GPC or DNT gets auto-opted-in to all categories
        consentGroups=',C0003,C0001,C0007,C0004,C0002,'
    }

    //store groups in a cookie 
    _satellite.cookie.set("OptConsentGroups", consentGroups, {expires: 360, samesite:"lax", secure:true, domain: "example.com"})

    return consentGroups;

} catch (e) {
	_satellite.logger.info("onetrust error:" + e);
}

Basically, if OneTrust has loaded, great, let’s use their JS object. If not, then based on the user’s location or privacy settings, we auto-opt them in or out of all categories (aside from “strictly necessary”). Then we create our OWN cookie, OptConsentGroups, so it’ll be easily accessible early on in the next page load.

NOTE: YOUR CATEGORIES WILL VARY. C0002 is for performance cookies for this particular client, based on how they have their categories set up within OneTrust. You will need to figure out how to identify the categories for your set up.

This data element gets referenced in a few places, meaning it is constantly getting updated, in case preferences change.

Set up data elements for each category

Once that data element exists, I create data elements for each category. My “onetrust consent: marketing” data element looks like this:

var consentGroups=_satellite.getVar("onetrust consent groups")||"" 

if(consentGroups.indexOf("C0007")!=-1){
  return "true"
}else{
  return "false"
}

I’ll use these to create conditions for any of my rules that contain non-Adobe tracking. Adobe rules don’t need conditions, they’re handled by the Experience Cloud Opt-in service.

Set up the ECID Opt-in Service

This is how I configured the Experience Cloud ID Service extension, essentially shifting all the work to my “onetrust consent: adobe” data element:

That “onetrust consent: adobe” data element looks like this:

var consentGroups=_satellite.getVar("onetrust consent groups")
var consent=false //false by default

//set per adobe category (we're treating all three- analytics, ecid and target- as performance. Your situation may merit a different split)
if(consentGroups.indexOf("C0002")!=-1){ //C0002= performance cookies
	var consent=true
}

//_satellite.logger.info("onetrust consent groups:" + consentGroups) //handy for debugging
return { aa: consent, target: consent, ecid: consent };

It checks if the user has consented to “performance” tracking, and if so, returns an object like this:

{aa: true, target: true, ecid: true}

This is the format that that “previous permission”/pre-opt-in approvals piece of the ECID is looking for. I’d love to say I learned that in the Adobe Documentation, but unless I’m missing something obvious, you have to backwards-engineer their code example to figure it out. Fortunately, this blog post by Abhinav Puri documents it all nicely.

(But wait, shouldn’t Adobe Target be categorized as “Targeting”? You should definitely ask your lawyers, but by my reasoning, the Targeting category is for targeted advertising and retargeting. Adobe Target may be named Target, but it is primarily a user experience/performance tool. It doesn’t chase you around the internet with personally-relevant advertising.)

Setting up the extension with this data element will cover Adobe permissions on page load, before the user interacts with the banner.

(In theory, this ECID extension part is the main thing the OneTrust extension would help with. But I like keeping all of the logic very transparent. And I’m a control freak that doesn’t trust vendor code I haven’t thoroughly tested.)

Updating Permissions (Banner Interaction)

To update permissions when the user has changed their preferences (including their initial reaction to the banner), I added code to my Page Top rule, within the OptanonWrapper() function, which is functionality provided by OneTrust that fires when OneTrust library first loads, as well as whenever there is a change to the user’s permissions:

<script type="text/javascript">
function OptanonWrapper() { //this function runs any time there are changes to one trust
  var consentSettings=_satellite.getVar("onetrust consent: adobe")   
  if(consentSettings.ecid===true){ //experience cloud ID service
      adobe.optIn.approve('ecid',true);
  }else{adobe.optIn.deny('ecid',true);}
  
  if(consentSettings.aa===true){ //analytics
      adobe.optIn.approve('aa',true);
  }else{adobe.optIn.deny('aa',true);}
  
  if(consentSettings.target===true){ //target, obv
      adobe.optIn.approve('target',true);
  }else{adobe.optIn.deny('target',true);}
  
  adobe.optIn.complete();
}
</script>

(In theory I could simplify this a bit since all three categories pretty much always have the same consent, but I wanted this to be flexible for potential changes in the future.) So now that rule looks like this:

(If you’re not deploying your OneTrust Library through Launch, then lines 1-7 don’t apply.)

Set up Rule Conditions

Fortunately, the ECID Opt-in Service will handle everything Adobe-related: you do NOT need to take further action, such as adding Rule Conditions to all rules with Analytics actions, in order for Analytics to not fire when it shouldn’t. The rules will still fire but they will not send anything to Analytics or Target (yet).

Marketing tags, however, need to be explicitly told to pay attention to the user’s consent preferences. This is, unfortunately, still a very manual process. First, you may need to make your rules a little more category-based. In general it’s easiest if for any particular rule event/condition combo, if you have your performance-category actions together in one rule, and your marketing/targeting actions in a separate rule. We were already generally following that, but there were a few rules that had both analytics and marketing tags- for those, I copied the rule and deleted analytics out of one of them and deleted the marketing tags out of the other one, resulting in one analytics-only rule and one marketing-tag-only rule. The analytics-only rule is fine as-is (thanks, ECID!) but the marketing tag rule needs an extra condition.

If your entire rule falls into one consent category, then it’s as simple as adding a condition where “%onetrust consent: marketing%” equals “true”:

If, however, you need to use conditions within your code to decide what fires and what doesn’t (perhaps your rules don’t neatly align with your categories), that might look like this:

if(_satellite.getVar("onetrust consent: marketing")=="true"){
  //insert code for marketing tag here
}

If someone out there has some extra time on their hands and wanted to write a Launch API function that would automatically add such a condition to all rules, that sure would be swell. In the meantime, I tend to take this approach: open my list of rules, and starting at the top, left-click on each rule while holding down cmd (or ctrl for a PC). This will open each rule in a new tab, while leaving your Rule List tab alone so you can keep track of what you’ve done and not done.

Then work you way through the tabs, adding your condition, saving, then closing that tab. I’ll often open 10-15 at a time, being careful to note where in the rule list I stop. When you’re done, you can use something like Tagtician to export your whole library and make sure you didn’t miss anything.

Side Note: Don’t forget to honor non-banner-based opt-outs!

Part of the California Consumer Privacy Act (CCPA) and others like it, is that sites must have a “Do Not Sell My Personal Info” page where the user can opt out, or view/delete/modify what data you have on them. Lawyers have generally been pretty good about making sure orgs get these pages in place- you probably already have one. Often, these pages are set up to sync up with the org’s CRM… if r.swanson@pawnee.gov fills out a form to opt out of tracking, then the CRM may delete all the info they have for dear R.Swanson, and/or someone may use the Adobe Privacy API or the Adobe Privacy JS to delete/edit/modify/view the Adobe data on that user. That’s all as it should be. The problem is, this process often exists completely separately from the Consent Management Platform. You may have deleted the person for your backend systems, but you’re still setting cookies and collecting data on the site!

Make sure that your Tag Manager knows when these kind of opt-outs occurs and honors them. OneTrust does have a way of tapping into those forms, though I can’t find any public documentation other than this general good advice about CCPA. But within their knowledge base, look up “Do Not Sell for AdTech Vendors”- it has tips and script you can use to help OneTrust know what happens on those forms.

Side note: Cookie Deletion

Note, right now, when you tell the ECID Opt-in Service to opt a user out of tracking, it does not remove any existing cookies. So in an opt-out situation, where everyone gets cookies to begin with, you may have users that have declined tracking and won’t be getting analytics beacons, but still have Adobe-created-cookies in their browser. Legally, this is a bit of a gray area. Even if it is technically legal (I’ll leave that to the lawyers to confirm), unfortunately the general public cares a lot about appearances. I’ve already seen one instance where Adobe cookies that were set but not even used (the site didn’t fire analytics beacons) caused a lawsuit in Spain, where they were accused of being “one of the most invasive types of cookie for user privacy”. This is complete nonsense, but the authorities and all the lawyers involved may not understand that without a bunch of effort. Even if the lawsuit fails, it has consumed a lot of that company’s resources.

At bare minimum, you should consider adding verbage to your banner or privacy policy that instructs users how to delete cookies on their own. The regulations strongly encourage this.

If you want to delete the AMCV and AMCVS cookies on behalf of the user, it can be a little tricky, since most of the time there is a domain mismatch between the www.example.com site you are on and the “.example.com” domain the AMCV cookies are set at, so you can’t just use _satellite.cookie.remove or somesuch. But you can do something like this to delete them:

_satellite.cookie.set("AMCV_21C9EXAMPLE123450101@AdobeOrg", "delete", {domain:'.example.com', expires: -1})

Note, many plugins also create cookies- you might see s_ppv or s_vnum or any number of other “s_” cookies that are the default names of cookies created by Adobe plugins. Generally, these don’t have “personal information” and in theory shouldn’t have to worry too much about (though I am not a lawyer so please don’t base your decisions off of me), you may want to delete them or at least be aware of them.

Depending on your ECID settings, you may also be setting a demdex cookie. Since this is a third-party cookie (and can effect how users are identified on other sites) it’s even more legally dodgy, and unfortunately even more difficult to delete. You can either stop that cookie from being set to begin with ECID’s disableThirdPartyCookies setting, or be very careful in how you inform your users about it and their ability to opt-out and/or delete it.

Validation

Here is a non-comprehensive list of things to check to confirm you have things set up correctly: obviously, you want to validate that your Analytics, Target, ECID, marketing tags, targeting tags, etc all only fire with user consent. Check both for cookies (in the “Applications” tab if you’re in chrome) and beacons/scripts (in the “Network” tab). Double check that your setup honors the Global Privacy Control signal (I’ve found this easiest to do in Firefox). Check that the user experience isn’t hindered. Be careful to check things that may be using third party technology, like video players- both that they work, and that they comply with consent policies. If you have iframes anywhere on your site, make sure the content within them is also being controlled by your CMP. Make sure you test for each of your Geolocation rules in OneTrust.

Ideally, before you roll out major OneTrust changes, you’d do a full regression test (the type of QA typically done before a major site release, where you make sure none of your pre-existing stuff is impacted). If you are resorting to using Autoblock for anything, a full regression test is a necessity.

Things I’ve found useful for testing:

OneTrust does provide a preview mode, but the most important thing I got out of that is that you can use query parameters (even in production) to change how OneTrust behaves:

?otreset=true&otpreview=false&otgeo=gb

For example, the above combo resets my preferences so I’ll see the banner again (you can also do this by deleting the OptanonAlertBoxClosed cookie.) The handiest part is the otgeo param- I can have Onetrust treat me like I’m in Great Britain (or any other country code I put there) to test that it works as expected in different jurisdictions.

Another useful thing: you can use this in the console to see what Adobe thinks its current permissions are:

adobe.optIn.permissions

I console.logged the heck out of that when figuring out the timing of things.

Tracking Opt-In/Opt-Out Rates

This is a tricky subject: how do you track that someone said they don’t want to be tracked? It may be worth a chat with your lawyers about. It’s important to remember, most regulations are more about having personal information, such as an ID in a cookie (even anonymous IDs), sent to third parties. Cookies are generally needed for keeping track of a session/visitor from page view to page view (or domain to domain, in some cases). If you are only tracking one user action without context, and there is nothing that ties that action to a particular user in any way, then the user has far less to be concerned about when it comes to their privacy. It’s sensitive and definitely worth discussing with your lawyers, but most regulations do allow for the most basic of tracking if there are no IDs used, the data isn’t shared or sold, it’s stored and processed correctly, the user is informed, etc. The data is useless for journey analysis and attribution, but can actually be used to make sure you are respecting user’s privacy properly. But TALK TO LAWYERS before deciding on any such tracking.

OneTrust does have the option to get high-level reporting on consent rates. I would link to the documentation on it but I’ve never gotten a link to Onetrust documentation to work. Instead, I have to click the ? icon and read any documentation within that panel:

I’ll admit I have not enabled or used their reporting. I’m curious how they get the info they do in cases where the user has consent to zero tracking. I’m assuming that it is free of personal information such as a cookie ID, etc.

We implemented another solution, where for the first 2 weeks after launching OneTrust, we fired hard-coded, identifier-less/cookie-less Adobe Analytics beacons to a Report Suite set up for that purpose, just to get a rough estimate of how it was working. I hope to have a separate blog post about that in the near future.

Adobe Analytics Settings for Privacy

Adobe does offer some admin settings that also help with privacy. You may want to consider these in addition to what you have set up in your TMS:

• Your General Report Suite Settings include a “Replace the last octet of IP addresses with 0” option and an “IP Obfuscation” option. The first happens before any processing on a hit, meaning the IP never gets stored or processed, and everywhere in Adobe, that user’s true IP is not accessible (including Data Warehouse and Data feeds). Accordingly, it has an impact on your reporting, especially geolocation rules. The IP Obfuscation Option, on the other hand, happens after some processing is done, so it has less impact. You can use it to merely obfuscate, or to remove the IP address altogether.
• I only just learned of this back-end setting that respects browser privacy settings (presumably, the older Do Not Track option or the newer Global Privacy Control setting). In theory, if your OneTrust/TMS implementation is configured right, nothing with those flags will ever even make it to Adobe, but there’s no harm in a little redundancy, right?

Conclusion

As I said at the beginning, I would love to learn more and improve my approach where possible. The best solution may end up being a crowd-sourced one. Please let me know what has worked or not worked for you!

* Sorry, Adobe. No one is going to convince me to call it “Data Collection Tags”.

** CCPA: I know there are many laws out there beyond California’s Consumer Privacy Act; however, since CCPA tends to be one the most expansive laws ( for now), I tend to use the phrase “CCPA” as an umbrella stand-in term for US laws. It’s much more complicated than that, but I don’t want to open that can of worms every time I need to reference a opt-out-based regulation.

*** If it wasn’t clear, this post was not done in partnership with OneTrust, and I have no formal relationship with them. I’d be happy to talk to them about anything in this post, though. And for what it is worth, of the 5 CMPs I’ve worked with, OneTrust was the least awful, in my experience.