Consumer Rights Management - Concepts & Glossary of Terms

Overview

Salesforce Audience Studio provides several methods to assist you in maintaining compliance with applicable data protection and privacy regulations. Regardless of the regulations and policies with which you’re complying, we give you tools and information via the Consumer Rights content hub within Zendesk to help you evaluate the best way to meet your requirements.

Within Audience Studio, Consumer Rights Management refers to all functionality that supports compliance with privacy policy regulations globally. This is inclusive of, but not limited to:

1. GDPR
1. Consent Management
2. Right to be Forgotten
3. Data Portability
2. Industry Opt Out
1. NAI / DAA Opt Out
2. DNT

This page specifically addresses important details that apply globally to Consumer Rights Management settings.

Consumer Rights Actions

Audience Studio currently supports four main activities as it relates to Consumer Rights.

1. Consent Management (set) - Used to set consent information for a given user input.
2. Consent Management (get) - Used to get consent information for a given user input.
3. Delete User Data (remove) - Used to request data deletion for a user.
4. Get all User Data (portability) - Used to request all data for a given user.

Managing Consent

Many data protection and privacy regulations require you and your company to obtain consent from users before collecting data about them, and to honor users' requests for how you use their data. Audience Studio provides multiple methods for you to record and manage consent from your consumer. Based on consent signals that you provide, Audience Studio functionality is restricted to only the users who provided consent.

For more information about managing consent, click here.

Data Deletion / Right to be Forgotten

In accordance with users' right to be forgotten (RTBF), you can delete users’ personal data when it’s necessary to comply with various data protection and privacy regulations. We give you the tools to request data deletion via API or directly through the admin UI within Audience Studio. That way, you can determine a plan of action for complying with the regulations that apply to you.

For more information about requesting data deletion, click here.

Data Portability

Many data protection and privacy regulations can require you to export consumers’ personal data when consumers request it. For more information about requesting data portability feeds, click here.

Consent Flags

Consent Flag Definition and Format

Use these consent flags to indicate specific types of consent from a given user.

Item	Abbreviation	Description
Data Collection	dc	Collecting and storing events.
Analytics	al	Any processing of data.
Targeting	tg	Sending a device to a 3rd party for campaign execution or other uses.
Cross Device	cd	Using data to link one device to another.
Sharing Data	sh	Sharing data or linkages with 3rd parties.
Reidentification	re	Taking data collected with a “pseudonymous” or “anonymous” key and merging it to a “PII” key.

Value	Definition
1	True - consumer consents
0	False - consumer dissents

When passing consent flags, a value of 1 or true indicates consumer consent, and a value of 0 or false indicates consumer dissent. If no value is passed for an item then the default flag will be set to 0 (false). For example, if you submit a request that only includes one flag, the rest of the flags default to 0 (false). Therefore, it is highly recommended that you submit a full request including all six flags for each user.

Below is an example of a full request, including all six flags. For detailed information based on the consent method, please refer to the appropriate technical documentation for that method.

 dc=1&tg=1&al=1&cd=1&sh=0&re=1

Consent Flag Use Cases

Following is information on the consent flags required for typical use cases.  Future use cases may be linked to one or many of these consent flags, such as reidentification, so it is advised that you explicitly send a full request to allow for future capabilities.

Use Case	Data Collection	Analytics	Targeting	Cross Device	Sharing	Reidentification
DATA INGESTION
Collect data from site, apps, OTT devices	X
First party import via First Party ID*	X			X
Onboarding first party data via onboarding partner**	X
AUDIENCE ANALYTICS AND SEGMENTATION
Build audience segment with 1st party data	X	X
Utilize Determinstic CDIM to power people number in segment summary screen	X	X		X
Extend segment via predictive CDIM	X	X		X
Extend segment via look-a-like 1st party data	X	X
Extend segment via other data	X	X
AUDIENCE TARGETING
Target users through on site activation with 1st party data	X	X	X
Target users on partner DSP with 1st party data	X	X	X
Target users on partner DSP shared seat with 1st party data	X	X	X		X
Target users through on site activation with 3rd or 2nd party data		X	X
Target users on partner DSP with 3rd or 2nd party data		X	X
Send 1st party data to Ad Studio for activation	X	X	X
Send 1st party data to Email Studio for activation	X	X	X			X
DATA STUDIO
Buy data via Data Studio for analytics		X
Buy data via Data Studio for targeting		X	X
Sell 1st party data via Data Studio	X	X	X		X

 Notes:

* Customer is expected to only send data where they have obtained consent for data collection. Audience Studio will not gate 1P file ingestion based on this flag.  

** Customer should ensure that consent is obtained for all use cases. If you wish for Audience Studio to gate any functionality based on individual consent signals, customer is responsible for having the onboarding partner send a supplementary file with those explicit consent signals.

*** Customer is responsible for obtaining consent from the consumer for targeting, analytics and sharing if data is uploaded into Audience Studio through a third-party data provider.

Consent Flag Conflict Resolution

Because targeting, cross-device, data sharing, and re-identification all require segment processing (analytics), Audience Studio does not support a user consenting to any of these things without also consenting to analytics. In the case where you provide Audience Studio with an affirmative consent for these consent categories, but a negative consent for analytics, Audience Studio references a default configuration to resolve the consent conflict.

• True - This option sets all consent flags to true to resolve the conflict.
• False - This option sets all consent flags false to resolve the conflict.

Learn more about managing settings for consent conflict resolution, click here.

Deleting Erroneous Second Party Sourced Data

When Audience Studio infrastructure is fired via the Control Tag or SDK, then the user consent signals will be checked before any data is sent back into it.  For example, if the consumer has dissented from data collection, then the Control Tag will not fire pixel.gif for that consumer.  There is the possibility that other tags such as ad_impression pixels are firing outside of the Control Tag or SDK.  In those instances, the ad_impression.gif will fire and data will be logged in Audience Studio, however that data will not be used if the consumer has dissented from data collection.  If you would like to ensure that any rogue data that may be logged into Audience Studio gets deleted, please check the second toggle under the Conflict Resolution section of the Consumer Rights Management Configuration UI.  When checked, all raw data will be deleted on a daily bases for consumers who have dissented to data collection.

Consent Sources

Consent can come intoAudience Studio from many different sources, each of which have varying levels of signal quality. This section describes the various sources that exist, and what they represent.

For more information on how each of the consent sources fit together, please refer to the section on consent management.

Direct Consent - First Party

Direct first party consent is consent collected through a direct engagement with a consumer. This is considered the most meaningful signal of consent in Audience Studio.

Audience Studio references the following first party consent sources:

1. API (api) - All consent signals that come from an API. This includes SDK, API (both UI and direct calls), and JavaScript Tag.
2. File (file) - All consent signals that come from a file upload.

Indirect Consent - Second Party

Some events captured by Audience Studio present a unique challenge as it relates to obtaining consent. For example, ad impressions from marketing campaigns happen where most of the users reached by an ad do not directly visit a web property owned by the marketing entity. As such, you cannot obtain direct consent.

To address this, Audience Studio enables you to define the consent you believe you obtain from second party consent events, like ad impressions. All users that are reached with these types of events that do not directly consent to your brand inherit the consent defaults that you choose.

These event types take on the default settings in absence of first-party direct consent.

1. ad_impression.gif
2. event.gif
3. heartbeat.gif
4. media_analytics.gif
5. Data Transfer 2.0 and other ad impression log files

All second party consent is referenced throughout the API, JavaScript Tag, and Files as “indir”.

Learn more about setting your second party consent defaults here.

Indirect Consent - Industry Opt Out

In addition to consumer-specific consent, Audience Studio has obligations to regulatory bodies such as the NAI and DAA. As part of these obligations, Audience Studio respects generic opt-out from the NAI, DAA, and the Audience Studio opt-out page across ALL organizations.

Audience Studio references the following industry opt out consent sources:

1. NAI Opt Out (nai) - Opt out that comes from the Audience Studio integration with NAI.
2. DAA Opt Out (daa) - Opt out that comes from the Audience Studio integration with DAA.
3. Audience Studio Opt Out (dmp) - Opt out that comes from the Audience Studio privacy settings page. For more information please refer to the Privacy Policy and Opt Out Guide.

Indirect Consent - Third-Party

Third-party data providers are legally contracted to provide data which can be used for targeting and analytics, and they are responsible for obtaining that consent from the consumer. No data provider that has not contractually committed to this will be enabled in Audience Studio.

Indirect Consent - Audience Studio Default

In certain conditions Audience Studio has no consent for a user.

1. Audience Studio has never seen the user
2. Audience Studio Customer did not obtain consent directly or indirectly, or consent signals were not passed correctly

In these cases Audience Studio sets default consent based on the applicable policy regime as follows:

1. GDPR
1. Data Collection = 0
2. Targeting = 0
3. Analytics = 0
4. Cross Device = 0
5. Data Sharing = 0
6. Reidentification = 0
2. Global Standard
1. Data Collection = 1
2. Targeting = 1
3. Analytics = 1
4. Cross Device = 1
5. Data Sharing = 0
6. Reidentification = 0

Audience Studio default consent is referenced throughout the API, JavaScript Tag, and Files as “unk”.

For more information on how consent sources work together, click here.

User Identifiers

Having described what things can be done in context of Consumer Rights Management, it is important to understand how Audience Studio recognizes the users to which those actions apply.

Overview

Audience Studio collects the vast majority of its data against devices. While Audience Studio does have an identity solution which resolves devices as belonging to the same individual, information is stored against device identifiers like cookies and mobile ad identifiers. As a result, we track and enforce all signals collected as part of Consumer Rights Management against individual devices.

Leveraging Deterministic Identity

Some Audience Studio customers provide relationships between device identifiers and their proprietary customer identifier, also known as bridge keys. These identifiers power deterministic identity features in Audience Studio. You can utilize this same deterministic mapping for all Consumer Rights actions on consumer data, such as consent and delete requests.

If a customer chooses to submit a request to Audience Studio based on a valid deterministic identifier for the account,Audience Studio automatically associates the activity to all related devices.

While Audience Studio also predicts the relationships between devices with varying degrees of certainty, we do not use this functionality in conjunction with Consumer Rights activities. In other words, unlike deterministic matching, which associates activity related to known related devices, matches that are not deterministic will not be associated for purposes of a consent, delete or GDPR request.

User Identifier Definition

Broadly speaking there are two main ID types: devices and bridge keys. Devices represent the actual identifier against which an action (consent, delete, etc.) is stored. A device could be a cookie, a mobile ad identifier, or something more exotic like a Roku ID.

Bridge keys are pseudonymous identifiers that are frequently used in Audience Studio to map people to their respective devices. Bridge keys are always Audience Studio customer defined and are frequently proprietary customer identifiers representing authenticated accounts in the customer system. In order to make requests to Audience Studio using bridge keys, you must have deterministic identity setup with the bridge key in question.

Below is a description of all user identification fields Audience Studio uses to manage Consumer Rights activities. Names included in parentheses are the official system recognized names used when interacting with Audience Studio.

Name	Description	Values
ID Type (idt)	The type of identifier that will be used	Device (device) - An actual device, as opposed to a bridge key
		Bridge Key (bk) - Pseudonymous identifiers that are frequently used in Audience Studio to map people to their respective devices
Device Type (dt)	If ID Type (idt) is device, this field is used to define which type of device is being used	Krux Cookie (kxcookie) - The Krux 3rd party cookie observed on a website
		IDFA (idfa) - Apples advertising identifier
		AAID (aaid) - Googles Android advertising identifier
		Other (other) - Any device which has not been formally categorized but is recognized as a device in Audience Studio Example - OTT Devices
Bridge Key (bk)	If ID Type (idt) is Bridge Key, this field is used to define which bridge key is being used. Any Audience Studio user attribute that is setup as a user identifier can be referenced here, but it must match exactly the user attribute code that already exists	Any Audience Studio user attribute that is setup as a user identifier can be referenced here, but it must match exactly the user attribute code that already exists
ID Value (idv)	The value of the ID defined regardless of whether or not a bridge key or device is being passed	The value of the ID defined regardless of whether or not a bridge key or device is being passed

When passing consent, you must choose to pass data keyed either off of a device or a bridge key. You cannot pass both device values and bridge key values. Additionally, if the desired key is a Krux Cookie (kxcookie) and the event is happening online, Audience Studio will automatically read the Krux Cookie and assign it to the ID Value.

User identifier examples

Below are a few examples of valid user identifier configurations which could be used with the Consumer Rights API, JavaScript Tag, or files.

First, the order of the fields should always follow the format defined below:

For Devices:
idt^dt^idv

For Bridge Key:
idt^bk^idv

For Krux cookie where the value of the cookie is already known:

device^kxcookie^abcdef123

For submissions against an android advertising ID:

device^aaid^38400000-8cf0-11bd-b23e-10b96e40000d

For submissions against a bridge key that is a SHA256 hashed email:

bk^email_sha256^f660ab912ec121d1b1e928a0bb4bc61b15f5ad44d5efdc4e1c92a25e99b8e44a

Scope Of Organizational Impact

Most device identifiers remain the same across customer organizations. For example, Google's Ad ID (AAID) uses the same value across every customer organization. As a result, Consumer Rights activities are managed specifically for each identifier within each organization.

For example, if AAID-1 consents to targeted advertisements from Brand 1, we do not assume that is true for all other organizations. Instead, we require each other organization to get consent separately.

As a result, when interacting with Audience Studio, it is required to specify your organization ID (uuid). To obtain your organization ID, contact your CSG team lead.

Organization Links

Some Audience Studio customers use multi-organization configurations and want to link all related organizations for every Consumer Rights action instead of managing each organization independently. If a customer chooses to link organizations, Audience Studio propagates all signals received across all linked organizations. Similarly, all other Consumer Rights activities, such as delete or request data, address consumer data from all linked organizations.

For example, if a Audience Studio customer chooses to link Organization 1 and Organization 2, and consent is specified for Device 1 within Organization 1, that same consent applies to Organization 2, even though the user did not provide direct consent within that organization. Consent for Organization 1 is direct, and consent for Organization 2 is derived. This will be reflected in the contentSource field of the Consent Audit Logs as described here.

To link organizations, contact your CSG lead for this managed service. If your organization is already linked, you will see that within your configuration settings. Learn more here.

Policy Regime

Consumer Rights can be established and enforced by many different entities. There are nationally enforced consumer rights which differ region by region, and there are industry enforced consumer rights from regulators like the DAA and NAI.

Because each individual may be governed under a different set of policies, Audience Studio introduces the construct of Policy Regime. Policy regime is a specific set of privacy policy regulations that apply for a specific user. For example, a user that lives in the EU is governed by the GDPR, but a user that lives in the United States is not. Therefore, the restrictions that apply to the user in the US do not apply to the EU resident and vice versa. Audience Studio associates a policy regime with every single device that is observed in each account.

Audience Studio currently recognizes two policy regimes.

1. GDPR (gdpr) - We manage devices set with this policy regime in accordance with the GDPR.
2. Global Standard (global) - We manage devices set with this policy regime in accordance with industry regulations, such as IAB, NAI, and DAA. This setting does not include GDPR regulations.

For example, Device 1 shows up on Site 1 and does not have any consent settings. If that user is governed under the GDPR policy regime, Audience Studio does not collect the data. However, for users not governed under the GDPR policy regime, Audience Studio collects the data unless the user has opted out through NAI, DAA, or some other regulatory body that Audience Studio complies with.

Association Method

Every device must have an associated policy regime. Audience Studio can associate a policy regime to a device at the organization level or the user level..

Organization Level

If an Audience Studio customer sets policy regime at the organization level, all events within the organization or set of organizations (based on organization linking), use a single policy regime for all devices. This policy regime applies regardless of whether that device or user is in the region associated with the default policy regime.

For example, if a customer selects the organization level and sets the policy regime for their organization to GDPR, all devices would be treated under the GDPR, even if the users are from the United States.

User Level

If an Audience Studio customer sets policy regime at the user level, for all events within the organization or set of organizations,Audience Studio evaluates the geographic region associated with the device and applies the appropriate policy regime. For example, consumers in the US are not managed by the GDPR rules, but EU consumers are.

If you elect to define the policy regime at the user level, you can specify the policy regime directly when passing Consumer Rights requests. In absence of a consumer-provided policy regime signal, Audience Studio will rely on geo location data to associate the user to the appropriate policy regime.

To learn more about setting up policy regime configurations, click here.

Default Policy Regime

Regardless of which association method is used, each account must define the default policy regime. When the policy regime association is done at the organization level, the default policy regime applies to all users in the organization. If the association is done at the user level, the default policy regime is only used in rare cases when the system cannot detect the location of the user from either the consumer-provided signal or geo location data. 

Self Set Policy Regime

The Audience Studio customer can set their own policy regime when passing the Audience Studio Consumer Rights signals. Audience Studio respects that definition over any other made about the device in question.

In rare cases where Audience Studio cannot make a declaration about the policy regime for a given device, it uses the default policy regime settings. You can learn more about setting your own policy regime in the following documentation portals:

1. Consent management
2. Right to be forgotten
3. Data portability

Policy Regime Source

Because Audience Studio provides multiple options to define the policy regime, the policy regime source (prsrc) is always referenced when information about consent is being provided.

1. default - Used when the system is unable to reconcile policy regime through all possible methods. This is the last resort setting.
2. client-config - The client specific configuration from the UI. Used for organizations that associate policy regime at the organization level OR when policy regime cannot be derived through either of the below methods.
3. geo-ip - Based on ip lookup for the data subject in question. This is used when the policy regime association is done at the user level and nothing was provided by the consumer with the request.
4. request - This is used when the policy regime association is done at the user level and policy regime was specified by the consumer in the request.

Glossary of Terms

Name	System Code	Description
Action	action	The specific Consumer Rights action that is referenced; get consent, set consent, portability, remove.
Setting Consent	set	Used to set consent information for a given user input.
Getting Consent	get	Used to get consent information for a given user input.
Deleting User Data	remove	Used to request data deletion for a user.
Data Portability Feed	portability	Used to request all data for a given user.
Consent Flags	{flags} OR settings	Points to a complete list of ALL consent flags for a given user.
Data Collection	dc	Collecting and storing events.
Analytics	al	Any processing of data.
Targeting	tg	Sending a device to a 3rd party for campaign execution or other uses.
Cross Device	cd	Using data to link one device to another.
Sharing Data	sh	Sharing data or linkages with 3rd parties.
Reidentification	re	Taking data collected with a “pseudonymous” or “anonymous” key and merging it to a “PII” key.
Consent Source	source	The source from which consent was received. (eg: api, api-derived, file, file-derived)
API	api	A valid source for consent. Indicates consent came from a direct query to the API.
File	file	A valid source for consent. Indicates consent came from a file upload from the Audience Studio customer.
Indirrect Second Party Consent	indir	A valid source for consent. Indicates consent came from an event which inherited the second party consent defaults from the UI configuration.
NAI Opt Out	nai	A valid source for consent. Indicates consent came from a generic opt out through the NAI.
DAA Opt Out	daa	A valid source for consent. Indicates consent came from a generic opt out through the DAA.
Audience Studio Opt Out	dmp	A valid source for consent. Indicates consent came from a generic opt out through the Audience Studio consumer privacy page.
Audience Studio Default Consent	unk	A valid source for consent. Indicates user has not given any direct or indirect consent, and therefore consent is not known.
ID Type	idt	The type of identifier that will be used
Device Type	dt	If ID Type (idt) is device, this field is used to define which type of device is being used
Bridge Key	bk	If ID Type (idt) is Bridge Key, this field is used to define which bridge key is being used. Any Audience Studio user attribute that is setup as a user identifier can be referenced here, but it must match exactly the user attribute code that already exists
ID Value	idv	The value of the ID defined regardless of whether or not a bridge key or device is being passed
KUID	kuid	Used in consent audit logs. Represents the actual device the action took place against.
IP Address	ip	The IP address associated with the request.
Request ID	reqID	Each request to the consent API has a uniqe identifier that can be used for auditing purposes.
Policy Regime	pr	A specific set of privacy policy regulations that apply for a specific user.
GDPR	gpdr	A valid Policy Regime - devices set with this policy regime are managed in accordance with the GDPR.
Global Standard	global	A valid Policy Regime - devices set with this policy regime are managed in accordance with industry regulations such as IAB, NAI, and DAA.
Policy Regime Association Method	n/a	The method by which the policy regime is associated to a user. Can be either organization or user.
Policy Regime Source	prsrc	The source providing policy regime information.
Default Policy Regime	default	A valid policy regime source. Used when the system is unable to reconcile policy regime through all possible methods. This is the last resort setting.
Client Configured Policy Regime	client-config	A valid policy regime source. The client specific configuration from the UI. Used for organizations that associate policy regime at the organization level OR when policy regime cannot be derived through other methods.
Geo Based Policy Regime	geo-ip	A valid policy regime source. Based on ip lookup for the data subject in question. This is used when the policy regime association is done at the user level and nothing was provided by the customer with the request.
Client Provided Policy Regime	request	A valid policy regime source. Used when the policy regime association is done at the user level and policy regime was specified by the customer in the request.
Beacon	n/a	Beacons are the the infrastructure used to collect data. Examples include pixel.gif, ad_impression.gif, heartbeat.gif.

Return Action Timetable and SLA

Action	API	File
Set	Consent flags are updated within 4 hours of API call	Consent flags are updated after nightly batch process
Get	Consent information immediately returned with callback	NA
Remove	RTBF request registered within 4 hours of API call and data deleted within 90 days of request	RTBF request registered after nightly batch process and data deleted within 90 days of request
Portability	Portability request registered within 4 hours of API call and data feeds are available within 14 days of request	Portability request registered after nightly batch process and data feeds are available within 14 days of request