How to handle user consent in Launch Event Forwarding Properties

[b_koth]

Hi all

I am fairly new to event forwarding and have a seemingly trivial question.

So, we have an AEP setup that sends an alloy("setConsent", ...) as soon as the user consented.

Now we have the task to implement the Facebook Conversion API via event forwarding in a Launch Event Forwarding Property.

The raw XDM data ending up there does not contain any signs of the actual user consent since that is also not contained in the actual requests sent to the Edge network.

Also, since there is no access to the user cookies, there seems to be no way to retrieve and respect the consent information.

I mean, technically I could enrich the XDM with the same "Consents and Preferences" field group and send in the same data that I have just sent with the setConsent but that sounds slightly complicated.

Is there at all a built-in way to respect/implement user consent in Event Forwarding Properties if you do not have access to cookies anyway?

Especially since the Facebook CAPI is eager to get any kind of PII, this would put any company in a precarious situtation, trying to explain the judge why exactly the not given user consent that the experience platform  claims to handle so well with its governance framework is then immediatly ignored when it comes to Launch.

Thanks for any ideas / suggestions

Björn

[Anil_Umachigi · Accepted solution]

@b_koth So there are couple of ways to do this 

1. Include the consents and preference xdm fields: Like you mentioned this is probably best way to approach not only for server side tags but also will ensure the profile is enriched with latest consent status. 
2. use custom xdm field: instead of using the consent, create a custom field group just for server side tags and send status ( consented or declined at tag or tool basis) which can be read by event forwarding and either trigger or cease to send tracking. 

either of the approach, i'm assuming the payload will only be created if consented correct? 

Hope that helps

[b_koth]

Hi @Anil_Umachigi 

spoke to Adobe as well and they suggest the same.

They also indicated that it is on the roadmap to bring Profile (and consent) information in the event forwarding in the near future, so this is just a temporary workaround.

BR

Björn

[Anil_Umachigi]

@b_koth Thanks for sharing it here! Good luck with next steps. 

[satyanarayanam1]

The other approach, if you dont want to store conent preferences in event dataset, you can pass them in the data section of the payload and read them on the server side container to ensure you respect consent choice of the user.

Quick question - 

So you were using set consent command to send consent choices to profile store using profile schema enabled with consent prefernece field group.

In addition, do we also need to send in every payload to event dataset as well?

what is the benefit of adding this consent field group to event data set?

If the event data set is enabled for profile - wont that duplicate?