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.
Solved! Go to Solution.
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.
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 😅
Views
Replies
Total Likes
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.
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 😅
Views
Replies
Total Likes
Views
Like
Replies