Description -
While conducting our first real-life implementation case for data collection via the AEP Web SDK and the Edge Network, we wanted to rely on the out-of-the-box customer consent preferences:
https://experienceleague.adobe.com/docs/experience-platform/edge/consent/supporting-consent.html?lan...
However, while experimenting with the different options available, we were facing major limitations with regards to the flexibility of handling the consent - in particular with the current consent object:
consent: [{
standard: "Adobe",
version: "2.0",
value: {
collect: {
val: "y"
},
metadata: {
time: "2021-03-17T15:48:42-07:00"
}
}
}]
Mainly, I'm referring to these two limitations stated in the official documentation:
#1 No granular consent handling:
"Currently, the SDK supports only a single all or nothing purpose."
#2 No overwriting of the collected consent:
"After a user has opted out, the SDK will not allow you to set the users collect consent to y."
Why is this feature important to you -
RE#1: Modern consent management solutions such as OneTrust offer great flexibility and granularity for the user to decide which type of cookies and tracking solutions he/she is opting-in or not (e.g., first- vs. third-party). However, this can't be reflected with the current AEP consent object as it only takes binary inputs. This can result in fewer opt-in rates and/or data coverage because few users decide to go "all-in" and respectively the consent object has to be set to "n" which prevents any tracking to happen. Since data is key to the measurement of all kinds of marketing activities, the amount of data points captured is key, less coverage means less meaningful insights which ultimately can make client-side tracking solutions redundant.
RE#2: As the user can opt-out this value of "n" will be irreversible written onto the AMCV, meaning in reality, for this particular user we will never ever be able to track any kind of data (unless they empty the browser's cache, switch devices etc.). This is even more severe as it drastically limits the potentially tracked users and can even have a disastrous impact when for instance, the value has been set to "n" by mistake.
How would you like the feature to work -
RE#1: Instead of just offering "y" or "n", give the flexibility to set different tracking categories within the consent object which correspond to different cookies/technologies (e.g., functional, first-party, third-party):
consent: [{
standard: "Adobe",
version: "2.0",
value: {
collect: {
functional: "y",
tracking: "y",
marketing: "y"
},
metadata: {
time: "2021-03-17T15:48:42-07:00"
}
}
}]
RE #2: Just add the capability to either reset and/or update the value that has been previously submitted as the consent object would tremendously help in overcoming the initially described limitation.
Current Behaviour -
As explained above.
