Expand my Community achievements bar.

Join us on September 25th for a must-attend webinar featuring Adobe Experience Maker winner Anish Raul. Discover how leading enterprises are adopting AI into their workflows securely, responsibly, and at scale.
SOLVED

Implementing OneTrust with Web SDK

Avatar

Level 3

We recently implemented Web SDK. We have Analytics, Target and AAM. We will be implementing RTCDP soon.

 

We also recently got OneTrust. We did a OneTrust scan of our website and came up with a list of cookies. In OT, cookies are categorized as Essential, Functional, Targeting, etc. Visitor preferences for each category are stored in a data layer variable. Therefore, we can inspect the variable to see that was opted in and out for each visitor; e.g. Essential opted in, Functional opted in, Targeting opted out, etc. We can have a script that either allows cookies to be created or not based on the category preferences (opted in or out).

 

In Launch, we have a Page View rule. Based on my research, Web SDK creates multiple cookies such as-

kndctr_<ORG_ID>_identity - Functional cookie
kndctr_<ORG_ID>_consent - Targeting cookie
kndctr_<ORG_ID>_cluster - Functional cookie
mbox - Targeting cookie
mboxEdgeCluster - Targeting cookie
AMCV_###@AdobeOrg - Targeting cookie

 

OT deals with cookie preferences in a granular way, using categories. In Launch, the Page View rule creates cookies that belong to multiple categories. Therefore, I cannot set a condition in the Page View rule to fire or not based on individual categories of the cookies that are created. For instance, if a visitor opts in to Functional cookies but opts out of Targeting cookies and I create a condition to not fire Page View when the visitor opted out of Targeting cookies, it will stop the Page View rule from firing even though Functional cookies are opted it. The rule either fires or not as a whole. It isn't granular and can't be made to fire part of it that sets Functional cookies but not the part of it that sets Targeting cookies. This leads me to believe this approach will not work.

 

In Web SDK, how can I allow cookies to be set or not based on Product; e.g. allow or disallow all cookies created for Analytics (assuming they are all categorized as Performance cookies), allow or disallow all cookies created for Target (assuming they are all categorized as Targeting cookies), etc.

 

Any advice on how to handle this would be appreciated.  

 

 

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @m_alcantara 

this is a good one.

 

Adobe does not differentiate by cookie categories and the cookies you see are used by the Edge Network to identify a visitor. There is no differentiation in the Edge Network which tool shall fire based upon set cookies nor what is sent in "set-consent" call.

This is only done based on the XDM payload you send in your Web SDK requests (see guided events further down)

 

Remember, the new Web SDK / alloy library is replacing the legacy libraries for analytics, target, audience manager and visitor id service. Hence, there is no dedicated cookie for tool X anymore as it used to be.


So, there is also no real point (imho) splitting the three cookies in different consent categories since you cannot really control them individually either.

 

Now, there are a couple of options and best practices I try to adhere to.

  • make sure Web SDK condent is set to "pending" and release the consent in a dedicated rule that sends a "set-consent" event to the Edge network.
  • in the "set-consent" call, there is one category that must be set for any cookie to be set, and that is "collect", which I typically recommend mapping the to your performance/analytics category of your consent tool.
  • without "collect.val" set to "y", no cookies will be set and any Web SDK sendEvent will fail.
  • use use the "guided actions" checkbox in your send event settings to make sure analytics calls are ending up only on analytics side, same with target 

But bottom line "collect" consent category setting controls everything that you want to send to the experience platform. Without this enabled, you won't get any of the Adobe tools connected to your datastream to work.

But: this does not mean that the Web SDK cookies shall be a classified as mandatory. 

Bottom line, even if Adobe does not allow to apply the consent per tool, you are still in control on Launch side which tool fires and how consent is handled. 

P.S. I have asked Adobe many times whether this will become baked into the platform at some point, and they always said it may come one day 😅 

 

 

Cheers from Switzerland!


View solution in original post

1 Reply

Avatar

Correct answer by
Community Advisor

Hi @m_alcantara 

this is a good one.

 

Adobe does not differentiate by cookie categories and the cookies you see are used by the Edge Network to identify a visitor. There is no differentiation in the Edge Network which tool shall fire based upon set cookies nor what is sent in "set-consent" call.

This is only done based on the XDM payload you send in your Web SDK requests (see guided events further down)

 

Remember, the new Web SDK / alloy library is replacing the legacy libraries for analytics, target, audience manager and visitor id service. Hence, there is no dedicated cookie for tool X anymore as it used to be.


So, there is also no real point (imho) splitting the three cookies in different consent categories since you cannot really control them individually either.

 

Now, there are a couple of options and best practices I try to adhere to.

  • make sure Web SDK condent is set to "pending" and release the consent in a dedicated rule that sends a "set-consent" event to the Edge network.
  • in the "set-consent" call, there is one category that must be set for any cookie to be set, and that is "collect", which I typically recommend mapping the to your performance/analytics category of your consent tool.
  • without "collect.val" set to "y", no cookies will be set and any Web SDK sendEvent will fail.
  • use use the "guided actions" checkbox in your send event settings to make sure analytics calls are ending up only on analytics side, same with target 

But bottom line "collect" consent category setting controls everything that you want to send to the experience platform. Without this enabled, you won't get any of the Adobe tools connected to your datastream to work.

But: this does not mean that the Web SDK cookies shall be a classified as mandatory. 

Bottom line, even if Adobe does not allow to apply the consent per tool, you are still in control on Launch side which tool fires and how consent is handled. 

P.S. I have asked Adobe many times whether this will become baked into the platform at some point, and they always said it may come one day 😅 

 

 

Cheers from Switzerland!