Skip to main content

Filter by idea status

10000+ Ideas

Allow Flexible Consent Management via AEP SDKNew

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?lang=en 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.

GregoryCrNew Participant

Allow Individual Approval Decisions on Joint ProofsNew

Description - Our Creative teams have Projects that require multiple versions of a creative to be rendered with slight differences in size, composition, and messaging within the artwork itself.  The general theme still rolls up to the project itself, but the variances require individual Approvals by the legal team to ensure the offerings, messaging, and overall creative association is allowed from a legal standpoint.  The issue we are running into is trying to create a joint proof for all of these similar (But slightly different) creatives, is that we can only approve or reject all at once.  If only one or two of the creatives get rejected, we have to start the whole proof of all creative assets over again with a version 2.Why is this feature important to you - It will save time and effort on our creative team that is currently spread thin from a resource allocation standpoint.How would you like the feature to work - I would like to be able to submit individual approvals on the combined proof.  The combined proof creates a zip file that acts as the actual reviewed file.  With Individual Approvals enabled, an approval on each separate file would create a nonzipped version of the file to be saved in the documents folder (OR a specified "Approved" Folder if possible).  Anything not approved would have to be changed and iterated in the Proof Version 2.  EX: a combined Proof of 5 files has three approved and 2 Rejected.  The 3 approved files are saved as individual files in an "Approved Folder" in the documents section.  The two rejected will be required to be uploaded as a version 2 combined proof. Current Behavior - The combined proof is created as a zip file for the actual review file, but you must approve or reject all files at the same time.  No individual approval is possible.