Consent management in Adobe Experience Platform Web SDK with Launch

Introduction

Let's get right into it. You need to manage a user's consent in order to collect data about them for analytics or marketing purposes. This is especially true if your visitors are outside the United States. The AEP Web SDK provides mechanisms to handle this at the configuration level. This means you can queue events until the consent status is known and send data only when explicitly allowed by the user or send nothing if not allowed. This also means that if you are using the AEP Web SDK with Launch, you do not need to do consent checks in individual rule firing conditions.

This video demonstrates the functionality outlined in the post:

Cookie Consent Managers

If you are reading this you are probably familiar with Cookie Consent Managers (CCMs). The popular ones in our world being OneTrust and TrustArc. CCMs allow a user to opt in or out of cookies and other technologies on a website. They do a little more than that, but that's the basic gist. This consent status is then used to determine whether or not sending data to a third party such as a marketing pixel or analytics tool is allowed.

The AEP Web SDK does not have a built in CCM, nor can its consent settings control your outgoing requests to marketing pixels; you still need to manage that in rule conditions. It can, however, control outgoing data to your datastream using the defaultConsent settings in your AEP configuration settings and the setConsent action. This means that you can control whether or not to send data to your datastream based solely on the user's consent settings and not to check for it in each rule condition that sends AEP data.

On this site I actually have a fake CCM where you can accept or reject cookies. You can see it by adding consent=true to the query string. This will set a cookie called cookieConsent to accepted or rejected. I will use this to set the consent status in my AEP Web SDK.

Let's wire this cookie up to the AEP Web SDK.

Data Elements

The first thing to do is store the cookie value in a data element. Later, I will set up a Launch rule to react to the cookieConsent cookie changing or coming into existence.

To convert the cookie to a value that the Web SDK can use, either in, out, or pending, I will use my favorite extension: Mapping Table. This data element which I'll call Consent Status will default to pending. This means if the data element cookieConsent is undefined (ie cookie does not exist) or is something other than accepted or rejected, the default consent status will be set to pending and the Web SDK will wait for the consent status to be known before determining whether to send data.

That's all the data elements I need. I could probably do this in one, but I find this more clear. I like to use out of the box tooling whenever possible.

Default Consent

Inside the configuration settings of your AEP Extension in Launch there is a section called Consent. Behind the scenes, this is the defaultConsent setting. This is telling the Web SDK what to do when the consent status is unknown. You set it to in to send data to your datastream by default, out to not send data to your datastream by default, and pending to queue events until the consent status is known.

For most people reading this, default consent status will be known when the page loads and the CCM cookie is read or the CCM loads (possibly via Launch itself), but may not be known when the AEP Web SDK loads.

Loading your CCM with Launch

Quick aside here: I think your consent manager is a mission critical tool and should be loaded by the application itself, not in Launch. I say this because more and more these days, consent is a legal requirement and should be considered part of a sites critical infrastructure. In my opinion, this disqualifies it from being loaded by a tag manager. The site itself loading the CCM also allows you to load it before the need for consent decisions are made (ie when Launch or GTM loads and needs to know the consent status before doing stuff.)

I am going to set Default Consent to my Consent Status data element. This will do 2 things:

• When the Web SDK loads and the consent status cookie is already present, the default consent status will reflect the cookie value. A return visitor will likely have an Adobe consent cookie as well so default consent settings won't really mean anything.
• If the cookie is not present meaning the CCM hasn't loaded or the user hasn't selected a setting, the default consent status will be pending. The user will then make a selection in the CCM modal setting up the Set Consent action.

A note on country based default consents

Somewhat outside the scope of this little blog post is setting default consent based on a user's country. If you have the means to do this, you could also use this to set default consent based on that country's GDPR status. However, I still think its a better approach to wait and queue events until the consent status is known. That way, things are absolute.

Default Consent Complete

This setting just represents what the Web SDK should do when it is initially configured. The user's consent will be updated and more robust cookies set by Adobe when the Set Consent Action is called.

Set Consent

We now shift gears to the Set Consent action. Once the Web SDK loads and its default consent is set, there are a few scenarios to account for:

• The CCM cookie is present and default consent is set to in or out
• The CCM cookie is not present or undefined and default consent is set to pending

In the first case, I don't need to do anything. The consent settings can remain as is because the user, by nature of their actions or their geographic location has expressed their consent desires. They almost certainly have a consent cookie from Adobe as well. More on that in a second. I can set consent again, but I will just be telling the Web SDK something it already knows.

The second scenario is where things are interesting. I do not yet know the user's consent status. Likely because they are a new visitor. The CCM cookie is not present or undefined; the default consent is set to pending and awaiting an update via the Set Consent action. I need to flip pending to in or out as soon as I am able to. Enter the data element change and set consent action.

Data Element Change

Because my consent cookie is a data element, I can use the data element change action to trigger the Set Consent action. This will cover a user setting their consent status for the first time or a user changing their consent status at any point.

Except condition

I want prevent this rule from firing if the consent status is pending. Set Consent (this version I am using) only accepts in or out as a value. I'm sure there are some weird scenarios this rule won't cover, but this example should cover most normal cases. I can use an except condition to prevent the rule from firing if the consent status is pending which is its default setting when there is no CCM consent cookie.

The Set Consent Action

The Web SDK extension comes prepackaged with Set Consent action. There are a lot of options and parameters you can fill in and I'm sure there will be more by the time you read this. I'm not going to get into the specifics of each one, and there is a whole other layer to consent in AEP where you use this action to set device level consent for individual CDP profiles. However, my simple example is representative of what the Set Consent action does and how it can be used to update the consent status of the Web SDK regardless of the specific settings you employ. I encourage you to read the official documentation for setConsent as it goes quite deep.

When the cookie pops into existence, the data element change action will fire and update the consent status of the Web SDK. This will cause the Web SDK to send data to your datastream if the consent status is in or not send data if the consent status is out. Also, when you flip from pending to in, the Web SDK will fire any queued events that were sent while the consent status was pending

Adobe's Consent Cookies

When you use these consent actions the Web SDK will set its own cookies to keep track of your consent status in addition to its various visitor identification cookies. The consent one is called kndctr_orgid_consent and will contain a value like general=in or general=out. The Web SDK will then use this cookie as its reference when determining whether or not to send data to your datastream. This cookie is device specific and has a lifetime of 180 days.

Putting it all together...

1. New user visits website, Web SDK loads with default consent set to pending. CCM loads consent modal.

2. Rules will fire but their sendEvent actual outgoing requests will be queued, waiting for setConsent

3. User accepts cookies, setConsent action fires and updates consent status of Web SDK, and queued events, if any, fire

4. The process is the same if the user rejects cookies, except the Web SDK will not fire any queued events and will not send any future events to the datastream

Video Demo

This is much easier to see in action (same video as above)