Capture reject consent with WebSdk extension

[ish2488]

Hi everyone,

We are currently in process of migrating the analytics implementation to Websdk approach and there is one use-case which we are trying to implement.

Currently, we are not tracking users who rejected the cookies from OneTrust banner and we need to gather this details and implement via WebSdk approach but to capture limited set of KPI's.

I wanted to know if it is feasible or not.

Generally with ECID service extension, we used to get ECID and if we don't use that extension by default we get the Fallback ID (FID). However, in our case we are using WebSdk extension and to capture ECID we followed data prep method https://experienceleague.adobe.com/en/docs/experience-platform/tags/extensions/client/web-sdk/access... when user accepts the cookies. We need to capture the scenario when users doesn't provide the consent/reject the cookies but still want to capture with limited set/OOTB KPI's (Not with ECID but with any other ID).

Is there any method that can suffice this use-case ?

Thank you

[SSampsa]

Let me get started by saying that it doesn't differ too much for FID or ECID as such, it's more in what you tie into them. Instead of using different ID's, one could possibly create a different ruleset in Tags, or a custom method of running only limited set or rules, variables and events for those that do not consent, so that baseline information required e.g. for developing website or shop are still gathered.

In case this is still a no-go, here is something else.

AEP and therefore Web SDK is built around utilizing the ECID, so my first thought would be to use FPID to override the default method when there is no consent. Before going any further, I want to make absolutely clear two things:

1. I have not tried this myself
2. This is not what FPID is meant for and there may be other issues with this method

Now that the disclaimer is out of the way, these are the generic instructions on how to use FPID:

First-party device IDs in Web SDK | Adobe Data Collection

In short: Before Web SDK sends anything, you gather consent. When consent is rejected, FPID is set (via e.g. the cookie method) and Web SDK is then triggered, using the FPID based identifier. You could use the same data for FPID as Adobe uses for FID (User Agent and IP address), so it's lifetime expectancy would be about the same.

[ish2488]

I am not sure if this is the right way to capture this use-case. However, I learned there are different cookies within WebSdk like "kndctr". Any idea, if we can utilize them to capture this use-case ?

[bjoern__koth]

Hi @SSampsa 

the kndctr ("konductor") cookies are placed by the Adobe Experience Edge Network and contain amon others information about the user consent status e.g., "general=in", but not really anything that would be useful in your case I think.

If you have not done that in the past, maybe there was a (legal) reason for that?

Again, I don't think it is wise to try to track opt outs in any way. 

The only legally compliant way to track cookie opt-outs no matter which consent category, would be without cookies. And Adobe cannot do that, at least not by itself.

Well, you actually can, but it will require a bit of technical setup and know-how. I implemented a custom AA consent tracking for a client that roughly looked like this

1. create a custom CNAME for consent tracking e.g., consent.mydomain.com, that is a proxy that strips all outgoing and incoming cookies
2. write custom code that captures the display of and interaction with the consent banner, sending "forged" AA requests to a dedicated report suite. Forged meaning you fabricate a tracking call with all needed query parameters (your consent categories as props, individual events for banner shown, accepted, declined...)
   Important is to not use any Adobe Library for this to make sure no cookies are set. Add more payload as needed (e.g., user agent)

The beauty of this is that you are flexible enough to do your own bot detection and analysis, since many consent providers like OneTrust aren't able to filter any traffic.

But yeah, nerdy it is.

[SSampsa]

There is nothing illegal about using cookies per say, but there needs to be a justification for it. This is of course also down to local and per company interpretations, which I will not go into.

As you said this is really easy to do with AppMeasurement, as you can do a scenario like you did, or simply force it to use a fallback model without much trouble, but I was going for a Web SDK based solution and I don't see these running side-by-side as a long term solution.

If we're going to get down and dirty with AEP, doing a server-side HTTP API based data collection allow data collection utilizing e.g. a server generation session or device identifier. This would only be activated if consent is not given and data would be separated from standard tracking due to them not being compatible. When it gets down to this, I also think about the ROI of the whole thing and is it worth it?

[SSampsa]

A major difference with Web SDK and the old library is that Web SDK is built around using only ECID. There are likely other ways to do this, perhaps even using Data Prep, but the way I see it there are no direct ways to avoid using ECID unlike before. I am working with cases who do what you're aiming for as well with AppMeasurement and I'll surely face this challenge when the time comes.

The cookies utilized by Web SDK (starting with kndctr) provide the ECID, consent details and edge cluster used in their base form, so they won't help with maintaining an identity other than the ECID. Web SDK has some configuration options, such as the ability to modify XDM before it's sent, perhaps one could use it to modify request details or by simply manipulating the cookie value, I can't say that for sure, as the key for me here is reliability and making sure the ID works and behaves as expected. Check out: onBeforeEventSend | Adobe Data Collection on how to manipulate XDM before sending data (there is another function for link-events).

[bjoern__koth]

OneTrust has built-in dashboards that show you consent rates per category (shown/accepted/rejected), so I would rather look at those 

[ish2488]

Totally agree, OneTrust can categorized the details based on the categories but we wanted to see this detail in analytics how many users did reject the cookies and we can somehow track limited information for them...