Introduction to Consent Managment

05 Nov 2023 » Platform

One of the reasons why some people start a blog is to document what they have recently learned. In my case, I have mainly written about things that I feel confident enough about. Today is going to be different, I will write about something I have recently come across: how Adobe Journey Optimizer (AJO) manages consent. In general, most people will never need to dive into it, as it is a bit internal to AJO, but I am in a project where I have to manipulate profiles’ consent. This post will be an introduction to this topic, where I will document what I learned so far.

Let’s start with some definitions. I do not claim to be an expert in this field, but I think we all intuitively understand what consent means. Google’s preferred definition is:

Permission for something to happen or agreement to do something

Good definition but too general. It can be applied to many aspects of life.

However, if you are reading this, you probably are interested in consent applied to marketing or consent-based marketing. The idea is that people should be in control of what marketing communications they want to receive. A good definition that I have liked (What Is Consent-Based Marketing?) states:

Consent-based marketing is the practice of only contacting consumers who have given their prior express written consent to be contacted. The objective is to ensure that only ‘active prospects’, or those who have actively expressed interest in hearing from you, make it into your funnel.

Since AJO is all about marketing automation, it has to provide a solution to manage consent. This solution revolves around the schema AJO Consent Service Schema:

AJO Consent Service Schema

You will also notice that there is a dataset named AJO Consent Service Dataset (ajo_consent_service_dataset), which conforms to the previous schema. This is where AJO will send any updates to a profile’s consent. For example, if you use in your emails from AJO a one-click unsubscribe link hosted by AJO (more on this below), clicking on this link will write into this dataset. I do not know why, but this dataset does not generate any batches, which means that it has no data in the data lake.

It goes without saying that both schema and dataset must be enabled for profile.

One final comment. I have understood that using this schema and dataset is not mandatory. You can add to your profile schema the field group Consent and Preference Details, but I have not tried it and I am not sure how I would use it.

Channel vs identity

AJO has, at least, two levels to manage consent: channel and identity. There may be more but I have not come across them.

Channel

This is the case when you want to prevent the full profile from receiving marketing communications through a particular channel. The consent data is stored in the XDM tree under consents.marketing:

Consent Marketing Schema Path

As an example, in the screenshot above I have expanded the email object. If I set consents.marketing.email.val to n, the profile will stop receiving emails. You can also set consents.marketing.email.time to the timestamp when consent was last changed.

Identity

Channel-level consent is simple and useful, but it does not cover all use cases. For example, if your profile can have multiple email addresses. Such is the case of my current customer, where a profile is expected to have multiple email addresses, and the consent should be managed per email address. In other words, it should be possible to have an email address opted in and another opted out, and with the solution just explained above this is not possible.

Here is where identity-level consent comes into play. Some people also call it contact-level consent, but I will use Adobe’s nomenclature. The idea is that each identity or contact should have its own set of consent parameters.

The way that AJO manages identity-level consent is through the consents.idSpecific map. This map was designed to hold information from multiple channels and identities. Unfortunately, the documentation about this map is quite sparse. From what I have been gathering, and thanks to the help of Adobe’s fantastic AJO consultants, the part of this map that I am interested in, in terms of marketing consent, follows this structure:

consents.idSpecific.{Namespace}.{Identity}.marketing.{Channel}.val

With:

  • Namespace: one of the namespaces supported by AEP; for example, ECID, Email, Phone.
  • Identity: the value of the identity under the previous namespace.
  • Channel: this can be, at least, email, push, or sms.
  • val: value of opt-in.

For example, [email protected] = 'y' means that the email address [email protected] is opted in to receive marketing emails. If you add more email addresses to the map, you get the desired identity-specific consent.

You will also notice that the help for the idSpecific map shows more data, which does not follow the structure above. This is expected. As I said, I am only interested in marketing consent, but it can also store collection or online advertising consent.

Before I move on, let me clarify how namespaces and identities are used in this context. You do not have to set any field as an identity with the previous namespace at AEP level for this system to work. For example, you do not need to set an email address field as an identity in any XDM schema, even if you want to capture email address consent. In fact, it may be better this way if your profiles can share email addresses, to avoid profile collapse.

Landing page

If you configure a one-click unsubscribe landing page within AJO, you can set which type of consent you want to use when configuring a checkbox:

One Click Unsubscribe

There is also an option for subscriptions, but I will not explain them today.

Accepted values for val

You will have noticed that, in all cases, the consent itself is captured under a profile attribute, whose path ends with val. You can see it in both channel- and identity-level consent, but also the field group I mentioned earlier and other places.

In this post, I have shown two sample values, y and n, but there are many more. I will not explain them, but they are worth reviewing, in case you have advanced use cases: accepted values for val.

Last-mile check

To wrap up, I want to explain how consent is enforced in AJO. Do you have to create a segment based on the val parameter to include only opt-ins? Do you have to create a branch in a journey to exclude opt-outs?

The answer is that AJO will always look into the consent profile attributes before sending any communication.

  • It will start with channel-level consent (consents.marketing). If the profile is opted out, it will not send the communication.
  • If the channel-level consent is not present or the profile is opted in, it will then check the identity-level consent (consents.idSpecific).

In other words, channel-level consent takes precedence over identity-level consent.

This is what we can call a last-mile check: even if you forget to exclude the profiles, AJO will make sure consent is honored.

 

Photo by Masjid MABA on Unsplash

Related Posts