NOTE: This documentation references many concepts addressed in the glossary of terms. Please visit this page before you continue.
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.
There are five methods available to pass consent into the DMP:
- Inside the DMP
Plan to pass a consent signal for every user you see for every consent flag that exists. Otherwise, product functionality may be unnecessarily gated.
We recommend this method for passing consent signals to the DMP. Please reference the technical documentation for technical details on using the API.
Below is an example of the JavaScrip Consent Tag format.
Krux('ns:NAMESPACE', 'consent:ROUTE', parameters, callback)
Inside the DMP
You can use DMP controls to define consent for a user. We recommended this option only for one-off cases when managing consumer objections and change requests.
Follow these steps to set consent for a user.
- Navigate to the Consumer Rights Management tile in Consent Management
- Click Raise a new request and select Update consent request
- Choose a user identification type
- Specify bridge key or device type
- Enter the applicable user identifiers
- Enter an ID for each user
- Enter IDs for multiple users one at a time
- Enter your consent settings values
- Select the value for each consent flag
- Specify a policy regime
- Click Submit
If you choose not to integrate via other supported methods, you can pass consent signals via file. All consent collected through files process daily, so the system will not register the request until after daily jobs have processed.
Important: If you are passing through consent for devices that are included in a corresponding first party import file, you must drop the consent file one day prior to dropping the first party import file on S3. This way we can guarantee that the consent for the devices will be ingested prior to ingesting records from the import file, and that we can correctly gate data collection and other data activities accordingly.
Please upload files to the following location.
Bridge Key Format:
Note: Policy regime (pr) and timestamp (ts) are optional. Flags are required if the action is
set. For more detail on the consent flags format, please refer to Consent Flags section of the DMP Consumer Rights Management Concepts and Glossary document.
Examples of valid records:
Regardless of whether or not you submit data for the optional timestamp or policy regime, include all of the delimiters. Data will not process without all delimiters.
The DMP supports gzip and lzo compression types, but recommends lzo with an lzo index file. If you choose to use gzip, the maximum supported size is 1GB per file submitted. Alternatively, the DMP does support plain text files.
After you have started providing consent information to the DMP, it is important to understand how the DMP processes this information and assigns all devices in the account with a set of consent values.
As noted in the glossary, there are many different sources of consent. Additionally, it is important to recognize that not every device seen in an organization will have provided consent directly. Some devices may provide indirect consent or some combination of multiple types of consent. Finally, consent is not static. It can change over time, and this must be reflected for each user.
Given this complexity, the DMP resolves consent for each device based on the most recent signal based on the prioritization below:
- Direct consent (first-party)
- Indirect consent (second-party)
- Indirect third-party data provider consent (third-party)
- DMP Default Consent
For example, if Device 1 provides consent on your website on day 1 and is exposed to an ad impression on day 3, the consent signal from the most recent direct consent event is still respected. This setting remains the same even though the most recent consent event was an ad impression. On day 5, the consumer provides consent again through a direct source, such as API or file. We respect the settings from day 5, as they are the most recent.
In addition to consent signals provided by you, the DMP has obligations to other 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.
You can get information on the most recent consent signal for a given ID Value (device or bridge key). The DMP supports five methods to check consent.
In addition to passing consent, the same API supports your request for the latest consent signals. For more information on this API, review the API technical documentation.
Consent Audit Logs and Dissent Lists
Consent audit logs are available at the locations listed below. Dissent lists are available and part of the regular data feeds going forward.
Audit Logs Location
Audit Logs Format
Note: if the request comes in at the device level such as a cookie or MAID, then the first two fields will be '-' as no bridge key lookup is required.
Dissent List Location
Dissent List Format
Note that the Flag will match the folder name.
Aggregate Consent Report
Within the admin console in the DMP UI, you can check the population sizes for each consent flag. For more information, visit documentation on the UI configuration settings.
All consent provided for the organization, or set of linked organizations (depending on the configuration), is respected based on the most recent signal for a device. For example, a user provided content to targeting on Monday but changed to non-consent on Tuesday. In this case, the DMP removes that user from all outbound segments until that user provides consent again. The DMP Customer is expected to properly define and record consent so that the DMP may respect those consent signals.
DMP restricts data collection based on this consent signal. If the DMP observes a device that doesn't include consent for data collection, the DMP does not fire the following data collection tags.
Additionally, the DMP will not fire any tags via SuperTag that have a data collection designation.
Please note, this only applies to events where the Salesforce DMP Control Tag is loaded on the page. We do not restrict collection for all file based data collection methods and any beacon (e.g. heartbeat.gif) that is not managed directly through the control tag. In these cases, the DMP Customer is expected to ensure consent exists to fire this infrastructure or send personal data via file.
Managing Data Collection Tags In Supertag
All tags that fire via SuperTag include a data collection designation. This simply denotes whether or not a tag collect data. All tags that are designated as data collection tags are restricted when a user does not consent to data collection via the Consent Management Framework. This designation allows you to use SuperTag to fire tags that do not collect data, but simply render content on your page.
To update the data collection designation for a tag, perform these steps.
- Navigate to SuperTag within the DMP UI
- Edit Tag
- Set the “Data Collection Tag” checkbox as desired
- Click Save
The DMP removes all users that have provided negative consent for targeting from segments sent to any third-party system. Because targeting requires analytical jobs via segment processing to run, consent for analytics is a pre-requisite for targeting.
DMP removes all users that have provided negative consent for analytics from analytical jobs that run within the DMP. This is inclusive of but not limited to reports like Journey Insights, Einstein Segmentation, Marketing Performance, and Lookalikes.
Additionally, all segments that are processed only include users that have provided consent for analytics. Within the segment builder the rule populations reflect analytics consented populations based on when the segment was last processed. The total segment size number also reflects all users who meet the segment criteria that have consented to analytics. This number is updated daily regardless of segment processing schedules.
DMP removes all users that provide negative consent for cross-device from all predictive and declared user match tables for the organization in question.
All segments that are shared through Data Studio or through DMP Partner Management via a Shared Partner configuration will be filtered based on data sharing consent.
DMP removes all users that have not provided consent for data sharing from any segments or events being shared via Data Studio. After filtering users based on the source organization, the consent restrictions on usage of that data are based on the receiving organization.
For example, Device 1 is in a the “sports lovers” segment shared from Organization 1 to Organization 2. In Organization 1, the user consented to data sharing and targeting. However, the user did not consent to targeting in Organization 2. In this case, the user would not be targetable in Organization 2.
In Partner Management, DMP customers may now distinguish between their own account or a sharable account for each activation partner. Sharable accounts should be used to send data to endpoints not owned or operated by the customer, and segments sent to sharable accounts will be filtered based on data sharing consent. When requesting new activation partners, customers are responsible for indicating if a sharable account is required for each unique account setup. Customers may have multiple accounts to the same partner. For example, they may set up one account to DBM using their own ClientID, and segments sent to that ClientID will be filtered on targeting. Then they may set up a second account to DBM Sharable using a 3P ClientID, and then segments sent to that accocunt will be filtered on both targeting and data sharing.
DMP removes all users that provided negative consent for re-identification from segments sent to Email Studio or any other internal reidentification platform.
One challenging aspect of introducing consent requirements for all devices is what to do with historical devices and the data associated with them. You may not start collecting consent until May, which could mean that you have many devices for which you have not received consent. Similarly, you may have data associated with devices that have churned and can never be seen again, making consent collection impossible.In either of these cases, the result may be that you have a lack of consent for many devices in your account, potentially leading to segment population declines.
To address this day zero implementation issue, we have introduced a one time use feature which will enable you to backfill consent for all historical devices. This allows you to define the consent you have with each user per your contracts, and have that associated with all devices in your account. This consent will be applied to all devices in your account just before May 25th, and can never again be set. Ultimately, it allows you to slowly ramp up your consent management collection without enduring through population declines.
For more information on how to set your backfill defaults, please click here.