Level 2

Question

Capture reject consent with WebSdk extension

Forum|Forum|1 year ago
October 14, 2024
3 replies
1590 views

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/accessing-the-ecid 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

Experience Platform

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

SSampsa

Level 4

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:

I have not tried this myself
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.

I

ish2488Author

Level 2

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

Community Advisor and Adobe Champion

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

create a custom CNAME for consent tracking e.g., consent.mydomain.com, that is a proxy that strips all outgoing and incoming cookies
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.

Cheers from Switzerland!

bjoern__koth

Community Advisor and Adobe Champion

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

Cheers from Switzerland!

I

ish2488Author

Level 2

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...

kautuk_sahni

Community Manager

@ish2488 Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

Kautuk Sahni

I

ishanchopra

Level 2

@kautuk_sahni... No, I am still looking for the right answer. The use-case is to capture tracking when user rejects the cookies via WebSdk approach but to capture limited set of KPI's.

Along with that, we don't want to send ECID for that server call if someone rejects and wanted to check how can we approach since we don't have FID in WebSdk method.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded