Consumer Rights Management - Concepts & Glossary of Terms

Overview

Salesforce DMP 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 the DMP, 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

The DMP 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. The Salesforce DMP provides multiple methods for you to record and manage consent from your consumer. Based on consent signals that you provide, DMP 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 the Salesforce DMP. 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 DMP 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. DMP 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 the DMP 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 the DMP through a third-party data provider.

Consent Flag Conflict Resolution

Because targeting, cross-device, data sharing, and re-identification all require segment processing (analytics), the DMP does not support a user consenting to any of these things without also consenting to analytics. In the case where you provide the DMP with an affirmative consent for these consent categories, but a negative consent for analytics, the DMP 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 Salesforce DMP Infrastructure is fired via the Control Tag or SDK, then the user consent signals will be checked before any data is sent back into the DMP.  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 the Salesforce DMP, 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 the DMP 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 into the DMP 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 the DMP.

The DMP 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 the DMP 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, the DMP 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, the DMP has obligations to regulatory bodies such as the NAI and DAA. As part of these obligations, the DMP respects generic opt-out from the NAI, DAA, and the DMP opt-out page across ALL organizations.

The DMP references the following industry opt out consent sources:

  1. NAI Opt Out (nai) - Opt out that comes from the DMP integration with NAI.
  2. DAA Opt Out (daa) - Opt out that comes from the DMP integration with DAA.
  3. DMP Opt Out (dmp) - Opt out that comes from the DMP privacy settings page. For more information please refer to the DMP 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 the DMP.

Indirect Consent - DMP Default

In certain conditions the DMP has no consent for a user.

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

In these cases the DMP 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

DMP 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 the DMP recognizes the users to which those actions apply.

Overview

The DMP collects the vast majority of its data against devices. While the DMP 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 DMP Customers provide relationships between device identifiers and their proprietary customer identifier, also known as bridge keys. These identifiers power deterministic identity features in the DMP. You can utilize this same deterministic mapping for all Consumer Rights actions on consumer data, such as consent and delete requests.

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

GDPRoverview1.png

While the DMP 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 the DMP to map people to their respective devices. Bridge keys are always DMP Customer defined and are frequently proprietary customer identifiers representing authenticated accounts in the customer system. In order to make requests to the DMP using bridge keys, you must have deterministic identity setup with the bridge key in question.

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

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 the DMP 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 the DMP
Bridge Key (bk) If ID Type (idt) is Bridge Key, this field is used to define which bridge key is being used. Any DMP 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 DMP 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, the DMP 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 the DMP, it is required to specify your organization ID (uuid). To obtain your organization ID, contact your CSG team lead.

Organization Links

Some DMP 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, the DMP 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 DMP 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, the DMP 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. The DMP associates a policy regime with every single device that is observed in each account.

The DMP 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, the DMP does not collect the data. However, for users not governed under the GDPR policy regime, the DMP collects the data unless the user has opted out through NAI, DAA, or some other regulatory body that the DMP complies with.

Association Method

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

Organization Level

If a DMP 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 a DMP Customer sets policy regime at the user level, for all events within the organization or set of organizations, the DMP 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, the DMP 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 DMP Customer can set their own policy regime when passing the DMP Consumer Rights signals. The DMP respects that definition over any other that the DMP makes about the device in question.

In rare cases where the DMP cannot make a declaration about the policy regime for a given device, the DMP 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 the DMP provides multiple options to define the policy regime, the policy regime source (prsrc) is always referenced when information about consent is being provided from the DMP.

  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 DMP 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.
DMP Opt Out dmp A valid source for consent. Indicates consent came from a generic opt out through the DMP consumer privacy page.
DMP 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 DMP 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
Have more questions? Submit a request

0 Comments

Article is closed for comments.