Description - the current Web SDK "set-consent" behaves a little unexpected in different situations, leading to unwanted results, whereas a the legacy Visitor ID service behaved differently.
Examples:
A) A new visitor denies cookies. With the Visitor ID service, you would've just denied the consent categories, mapped to the Adobe tools without having any whatsoever cookie written. With the Web SDK however, if you send a general "opt out" through the "set-consent" action, two things happen
- "kndctr" cookies are set (!)
- if the company has a RT-CDP license, a pseudonymous profile is created (correct me if am wrong!) with the consent preferences attached to it
In my opinion, none of the two above make sense, and cookies written lead to potential legal problems.
Now, I am a seasoned Launch developer and have a workaround that involves local storage and some other constructs to make sure the "set-consent" rule only triggers (and writes cookies and creates a profile), when it is needed.
I am wondering what happened to the super simple approach with the old Adobe optIn API.
Why is this feature important to you -
ease of use, legal compliance and cost control. If I don't consent, why does the Edge network return cookies. And when I am a new visitor without consent, why create a profile?
How would you like the feature to work -
Web SDK should send a set-consent call if
- a user previously consented and changed his settings e.g., now opts out.
- a user gives consent to be tracked ("collect")
Web SDK should NOT send a set-consent call if
- the user has never consented and rejected all consent categories, resp. the "collect" category
Current Behaviour - opt out with cookies stored on client side and needed workaround in place to disable Adobe tools and functionalities that were automatically handled through the Visitor ID Service in the past.
