Block cookies automatically dropped by Launch

[atarian2049]

Greetings.

I'm having a dickens of a time trying to stop cookies like "mbox", "s_sq", "s_plt", "s_pltp", and others from dropping upon the loading of Adobe Launch in a website before the user selects whether they wish to use cookies through OneTrust. It looks like the cookies are created and dropped when the minified Launch JS file is loaded from adobedtm. The Launch JS is necessary for the page to run properly from the outset, so I just need to stop the cookies from dropping. If anyone has any recommendations, I'd love to hear them.

[Amruthesh_AG]

@atarian2049  are you implemented analytics tracking websdk or AppMeasurement.js? 

you can use below code 

adobe.optIn.denyAll();
var consentlist= window.OnetrustActiveGroups;

if(consentlist){
if (consentlist.indexOf(",C0002,") > -1 ) {
adobe.optIn.approve(adobe.OptInCategories.ANALYTICS,true);
adobe.optIn.approve(adobe.OptInCategories.TARGET,true);
adobe.optIn.approve(adobe.OptInCategories.ECID,true);
adobe.optIn.complete();
}
}

[atarian2049]

I'm using AppMeasurement.js (along with VisitorAPI and MediaSDK). Is the OT Check a custom code block as well? I don't see that as a standard condition type. I'm guessing the custom code in the actions is where you implemented the written code above the images, correct?

[atarian2049]

Also, wouldn't the cookies have already dropped just from using the Launch JS file by the time it gets to the rules in the code?

[bjoern__koth]

@atarian2049 , the Visitor ID Service comes with an opt-in API that can be used to control which of the legacy Adobe libraries (Target, Analytics and Audience Manager) are alloed to fire.

Internally, it uses a queue that, once consent is granted, is released, so that you do not lose tracking calls on the same page.

Check out this - slightly old but still valid - blog post by Jan Exner: https://webanalyticsfordevelopers.com/2021/02/16/consent-and-launch/ which explains step by step which settings to apply on the Visitor ID extension. As @Amruthesh_AG mentioned above, it is crucial to have a data element in place that picks up the (if applicable) previously given consent.

One word of notice: I would omit using the 

window.OnetrustActiveGroups

which I have seen running into race conditions where a given consent was not written into that window scoped variable by the time Launch executed and led to missed tracking calls.

Instead, I would always read out the cookie yourself, in that case checking for the category followed by a ":1" e.g., "C0002:1" for the standard performance/analytics category.

More documentation on the opt in service can be found here

https://experienceleague.adobe.com/en/docs/id-service/using/implementation/opt-in-service/optin-over... 

[atarian2049]

This is definitely a step in the right direction. So I should implement the ECID Service Extension, and set it so that Opt-In is set to Yes. Since these cookies are dependent on whether a user clicks to consent through a separate OneTrust banner, should I use the "OneTrust Consent Management for Cookies" extension as well, or would reading the cookie itself as you recommended suffice?

I have the following as a custom code rule with an order of 1 to get it running right away:

adobe.optIn.denyAll();
var OTCookie= _satellite.cookie.get('OptanonConsent') || '';
console.log(`--- COOKIE BLOCK: current optanon cookie: ${OTCookie}`)

if(OTCookie.includes(',4:1')){
  console.log('--- COOKIE BLOCK: Cookie level 4 now approved.')
  adobe.optIn.approve(adobe.OptInCategories.ANALYTICS,true);
  adobe.optIn.approve(adobe.OptInCategories.TARGET,true);
  adobe.optIn.approve(adobe.OptInCategories.ECID,true);
  adobe.optIn.complete();
} else {
  console.log('--- COOKIE BLOCK: Cookie level 4 denied.')
}

I have placed the library containing this new rule into development, but I'm still seeing cookies being placed in Development; the OneTrust cookie definitely shows that the consent has not been granted just yet.

[atarian2049]

I'm also seeing that even with a rule running at order 1, cookies like mbox, s_gpv, s_ivc, etc. are still dropping in before the rule even runs because they're still a part of the existing extensions being placed into the Launch js file. I cannot take those extensions out because I didn't install them, and I don't know what sort of downstream effects they may have if I do remove them.