Consents and Preferences data type
The Consent for Privacy, Personalization and Marketing Preferences data type (hereinafter referred to as the “Consents and Preferences data type”) is an Experience Data Model (XDM) data type that is intended to support the collection of customer permissions and preferences generated by Consent Management Platforms (CMPs) and other sources from your data operations.
This document covers the structure and intended use of the fields provided by the Consents and Preferences data type.
Prerequisites prerequisites
This document requires a working understanding of XDM and the use of the schemas in Experience Platform. Please review the following documentation before continuing:
Data type structure structure
The Consents and Preferences data type provides several fields used to capture consent and preference information.
A consent is an option that allows a customer to specify how their data may be used. Most consents have a legal aspect, in that some jurisdictions require obtaining permission before data can be used in a particular way, or require that the customer has an option to stop that use (opt out) if affirmative consent is not required.
A preference is an option that allows the customer to specify how different aspects of their experience with a brand should be handled. These fall within two categories:
- Personalization preferences: Preferences regarding how the brand should personalize experiences delivered to a customer.
- Marketing preferences: Preferences regarding whether a brand is allowed to contact a customer through various channels.
The following screenshot shows how the structure of the data type is represented in the Platform UI:
The following JSON shows an example of the type of data that the Consents and Preferences data type can process. Information on the specific use of each of these fields is provided in the sections that follow.
{
"consents": {
"collect": {
"val": "VI",
},
"adID": {
"idType": "IDFA",
"val": "y"
},
"share": {
"val": "y",
},
"personalize": {
"content": {
"val": "y"
}
},
"marketing": {
"preferred": "email",
"any": {
"val": "u"
},
"push": {
"val": "n",
"reason": "Too Frequent",
"time": "2019-01-01T15:52:25+00:00"
}
},
"metadata": {
"time": "2019-01-01T15:52:25+00:00"
}
}
}
consents
choices
consents
contains several fields that describe a customer’s consents and preferences. These fields are described in further detail in the subsections below.
"consents": {
"collect": {
"val": "VI",
},
"adID": {
"idType": "IDFA",
"val": "y"
},
"share": {
"val": "y",
},
"personalize": {
"content": {
"val": "y"
}
},
"marketing": {
"preferred": "email",
"any": {
"val": "u"
},
"email": {
"val": "n",
"reason": "Too Frequent",
"time": "2019-01-01T15:52:25+00:00"
}
}
}
collect
collect
represents the customer’s consent for having their data collected.
"collect": {
"val": "y"
}
val
adID
adID
represents the customer’s consent for whether an advertiser ID can be used to link the customer across apps on this device.
"adID": {
"idType": "IDFA",
"val": "y"
}
idType
IDFA
for Apple’s ID for Advertisers or GAID
for Google’s Advertiser ID, also known as Android Advertiser ID (AAID).val
share
share
represents the customer’s consent for whether their data can be shared with (or sold to) second or third parties.
"share": {
"val": "y"
}
val
personalize
personalize
personalize
captures customer preferences regarding which ways their data can be used for personalization. Customers can opt out of specific personalization use cases, or opt out of personalization entirely.
personalize
does not cover marketing use cases. For example, if a customer opts out of personalization for all channels, they should not stop receiving communications through those channels. Rather, the messages they receive should be generic and not based on their profile.marketing
, explained in the next section), then that customer should not receive any messages, even if personalization is permitted."personalize": {
"content": {
"val": "y",
}
}
content
val
marketing
marketing
marketing
captures customer preferences regarding what marketing purposes their data can be used for. Customers can opt out of specific marketing use cases, or opt out of direct marketing entirely.
"marketing": {
"preferred": "email",
"any": {
"val": "u"
},
"email": {
"val": "n",
"reason": "Too Frequent"
},
"push": {
"val": "y"
},
"sms": {
"val": "y"
}
}
preferred
any
marketing
. If you plan on using more granular consent options, it is recommended that you exclude this field.If the value is set to
n
, then all more specific personalization settings should be ignored. If the value is set to y
, then all finer-grained personalization options should also be treated as y
, unless explicitly set to n
. If the value is unset, then the values for each personalization option should be honored as specified.email
push
sms
val
time
metadata
, then this field does not to be set for that preference.reason
metadata
metadata
captures general metadata about the customer’s consents and preferences whenever they were last updated.
"metadata": {
"time": "2019-01-01T15:52:25+00:00",
}
time
time
value under an individual preference overrides the metadata
timestamp for that particular preference.Ingesting data using the data type ingest
In order to use the Consents and Preferences data type to ingest consent data from your customers, you must create a dataset based on a schema that contains that data type.
See the tutorial on creating a schema in the UI for steps on how to assign data types to fields. Once you have created a schema containing a field with the Consents and Preferences data type, refer to the section on creating a dataset in the dataset user guide, following the steps to create a dataset with an existing schema.
Handling consent and preference changes
When a customer changes their consents or preferences on your website, these changes should be collected and immediately enforced using the Adobe Experience Platform Web SDK. If a customer opts out of data collection, all data collection must immediately cease. If a customer opts out of personalization, then there should be no personalization present on the next page they visit.
Appendix appendix
The sections below provide additional reference information regarding the Consents and Preferences data type.
Accepted values for val
choice-values
The following table outlines the accepted values for val
:
y
n
p
p
until they select a link in an email to verify that they have provided the correct email address, at which point the consent would be updated to y
.If this consent or preference does not use a two-set verification process, then the
p
choice may instead be used to indicate that the customer has not yet responded to the consent prompt. For example, you can automatically set the value to p
on the first page of a website, before the customer has responded to the consent prompt. In jurisdictions that do not require explicit consent, you may also use it to indicate that the customer has not explicitly opted out (in other words, consent is assumed).u
dy
Note that if laws or changes to your company’s privacy policy result in changes to the defaults of some or all users, you must manually update all profiles containing default values.
dn
Note that if laws or changes to your company’s privacy policy result in changes to the defaults of some or all users, you must manually update all profiles containing default values.
LI
CT
CP
VI
PI
Accepted values for preferred
preferred-values
The following table outlines the accepted values for preferred
. The preferred
values indicate the customer’s preferred channel for receiving communications that would inform them about data collection, privacy policies, and personalization options.
email
push
inApp
sms
phone
phyMail
inVehicle
inHome
iot
social
other
none
unknown
Full Consents and Preferences schema full-schema
To view the full schema for the Consents and Preferences data type, refer to the official XDM repository.