DMP Implementation Best Practices for GDPR

Getting Started

The Salesforce DMP has provided multiple methods and settings to enable your compliance with various privacy regulations, but there is still work required of the DMP Customer to define your company's approach to obtaining and setting consumer consent, building the UX consent interface for your consumers, and connecting that consent experience to the Salesforce DMP. The purpose of this document is to outline the pre-work that you will need to undertake to ensure that your DMP instance is properly configured and that you are set up to utilize all the consent mechanisms offered by the Salesforce DMP Consumer Rights Management system.

As you get started, you should be aware of the six consent flags and which flags are required to drive different use cases within the DMP.  These are outlined in the Consent Flags Use Case section of the Concepts & Glossary of Terms document.  Please refer to this document for detailed information on the concepts referred throughout this guide such as: Actions, Consent Sources, Consent Flags, Conflict Resolution, User Identification, Organization Links, Policy Regime, and Return Action Timetable and SLAs.   

General Checklist:

Initial activities (prior to May 25, 2018)

  • Define company approach to GDPR
  • Setup and confirm organization configuration settings in the Salesforce DMP
    • Review organization linking
    • Select Policy Regime Association
    • Review Conflict Override settings and erroneous data deletion
    • Review 2nd Party Consent Default settings
    • Determine Back-filling Consent for assigning consent for historical data (by April 15th)
  • Select and implement UX for consent
    • Train DMP Administrator on using UI settings for manually passing consent signals
  • Connect consent experience to the Salesforce DMP
  • Review SuperTag and mark applicable tags for data collection

Post-launch activities (daily/weekly for first quarter)

  • View Consent Reports to understand consent distribution and populations
  • Monitor populations within the DMP (Audience analytics, Marketing performance, Segment populations) for population drop-offs
  • Adjust configuration settings based on risk profile and population sizes

Ad-hoc activities (as needed based on changes in business)

  • Link any new organizations during the DMP implementation phase
  • Change Policy Regime Association based on new regulations
  • Ensure SuperTags are marked correctly for data collection where applicable

Define Company Approach to GDPR

Owners: Legal and internal stakeholders
Result: Company definition of the entity's obligation for GDPR compliance including but not limited to compliance defaults, the handling of new consumers, policy regime, and consent granularity settings.

You, our Customer, are responsible for obtaining consent from consumers and recording that consent within the Salesforce DMP.

Some questions that you should consider:

  • What consent do you want to obtain from your consumers?
    • What level of granularity do you want to expose to the consumer?
      • The Salesforce DMP allows you to record consent for each consumer based on the following granular types of processing: data collection, analytics, targeting, cross device identification, data sharing, and reidentification (ability to tie pseudonymous data within the DMP to a known person in Marketing Cloud or external systems)
    • How flexible do you want to be when obtaining consent from the consumer?
  • If you have multiple Salesforce DMP instances, should they all be treated alike?
  • How much of your traffic comes from different regions? Does this differ by instance?
  • What obligations do you feel you have to your consumer?
    • How conservative should you be when setting default consent?
    • How conservative should you be when resolving conflicts?

Setup Organization Configuration Settings

Owners: Legal and Salesforce DMP Admin Users
Result: Confirmation that the organization configuration settings are aligned with your corporate policy.

Initial Setup

Every DMP account will be pre-configured with with the following settings:

  • Policy Regime Association = User Level, GDPR
  • Conflict Overrides = Consent flags set to false to avoid conflicts
  • Erroneous data deletion = delete any erroneous second party sourced data
  • 2nd Party Consent Defaults = data collection, analytics, targeting, cross device are true, data sharing and reidentification are false (same as Global Standard Policy Regime defaults)

You should review each setup with your legal department and decide if any adjustments need to be made given your company's approach to GDPR. Below is more detail on each of the configurations. 

Setting/Confirming Configuration

Linking Organizations

By linking organizations, you can ensure that all consent settings are applied universally to all linked organizations within your company's umbrella, so as to reduce administrative burden for managing each organization's settings. However, just because you administer multiple organizations doesn't mean you should default to linking all organizations. If your different organizations encompass brands that are delineated based on some criteria that your consumer would believe is immaterial to their choice of interaction with your company (eg: Org1 is for Region1 and Org2 is for Region2), then it might make sense to link organizations. However, if you are managing separate organizations that are delineated by something more substantive, like brand, business unit, market (eg: Org1 is for Gaming site and Org2 is for ConsumerGoods site), then your company should probably not assume consent across the different organizations.

Considerations and recommendations:

  • How are the different organizations delineated? Is it just by an arbitrary construct or is each organization materially different, and do consumers interact with each organization differently?
  • Do all organizations have similar traffic, or are some primarily US-based traffic and others primarily EU-based traffic?
  • Are all organizations centrally managed or are they operated independently?
  • Do you want to assume the same default policies and risk aversion across all organizations?
  • Are you going to have a potentially high number of unknown devices, or will you be getting 1P consent across all of your organizations in a consistent manner?
Link Organizations Separate Organizations
Organizations are fairly homogenous Organizations are materially different
Traffic across all organizations originates from similar regions Each organization has different traffic patterns based on geography and market
Centrally managed operational teams Disparate operational teams
Many organizations Few organizations
Same risk profile across organizations Markets have unique interpretation of GDPR compliance
1P consent framework consistently implemented across organizations Organizations will manage whether or not they implement a 1P consent framework

Example Company 1: EU brand managing 5 DMP organizations, one per business unit
Company 1 is based in the EU, and has traffic mostly from the EU local markets. Though they have 5 organizations, they are centrally managed by one team, and will be implementing a universal consent management framework to encompass all brands. Consider linking the 5 organizations.

Example Company 2: Global brand managing 20 DMP organizations, one per market
Company 2 has a separate DMP organization per market. Markets spread across the globe, and are managed locally. Since each market will be assuming responsibility for GDPR compliance based on their local standards, consider keeping the organizations separate.

Example Company 3: US brand managing 10 DMP organizations based on market and business unit
Company 3 is based in the US, and has most properties which are US-centric, but does have 3 properties with a high level of international traffic. Because the US-centric properties are all managed in the US, consider linking these 7 organizations, but keeping the 3 organizations with a high percentage of EU traffic managed separately so that they can be managed to respect a more conservative risk profile.

Policy Regime Association

The Policy Regime settings are instrumental for defining how unknown users will be handled as they are recorded by the DMP. Unknown users are devices in which there is no information from any consent source; first party consent (via the page from which you are collecting consents from users), second party consent (specified via the defaults), third party consent, or industry optout.

There are two levers to set when setting the Policy Regime: The association level (organization or user level) and the default policy (GDPR or Global Standard).

  • GDPR: all consent flags are set to false
  • Global Standard: data collection, analytics, targeting, cross device are true, data sharing and reidentification are false

The association level determines how granularly you can manage the settings. 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. 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.

  Organization Level User Level
GDPR Every unknown device will have all consent flags set to zero to be compliant with the GDPR policy regime. Unknown devices will be associated to the policy regime based on their geoIP.  In the rare case where geoIP cannot be resolved, the user will be associated to the GDPR policy regime.
Global Standard Every unknown device will have all consent flags set to the Global Standard. Unknown devices will be associated to the policy regime based on their geoIP.  In the rare case where geoIP cannot be resolved, the user will be associated to the Global Standard policy regime.

It is important to note that since the policy regime is intended to handle unknown devices, the impact of these settings is correlated to how big the unknown device pool is for your organization. In other words, if and how you implement a consent experience for 1st party (”1P”) consent, the defaults you select for 2nd party (“2P”) consent, the number of devices that you see from 3rd party (“3P”) sources all affect the pool of unknowns.

Considerations and recommendations:

  • Will you be implementing consent management on your web properties? If not, then more of your devices are likely to be unknown. Consider User Level settings.
  • Do you have significant traffic from 2P and 3P sources? If not, then more of your devices are likely to be unknown. Consider User Level settings.
  • Do you have linked organizations that are located in multiple regions? If so, then consider User Level settings.
  • Do you expect that you will have a very small number of unknown devices, but want to treat those devices conservatively until you are able to obtain 1P consent via your company's policy page? Are you in the EU? Are you a single organization and have no linked organizations? Are you prepared to see a decrease in DMP populations until those unknown devices are able to explicitly or implicitly pass consent via 1P, 2P, or 3P sources? Consider Organization Level settings.

Example Company 1: EU Company with some global traffic
Company 1 might want to be very conservative in how unknown devices are handled. Company 1 has implemented consent management on their web properties, so doesn't expect a high number of unknown devices to pass through, and so sets the Policy Regime to Organization Level: GDPR. This means that any unknown users from non-EU locations will be treated with the stringent GDPR standards, meaning that all consent flags will be set to false. Population numbers may drop significantly depending on the number of unknown, non-EU traffic.

Example Company 2: US Company with some global traffic
Company 1 may be delayed in implementing consent management on their web properties. Since much of their traffic is from 2P sources and within the US, Company 2 sets the Policy Regime to User Level: Global Standard. Unknown users with EU geoIP will be treated under GDPR policy regime, but in the highly unlikely event that geoIP cannot be resolved, record from the device will be captured and allowed for analytics, targeting, and cross device.

Example Company 3: US Company with near 100% US traffic
Since Company 3 has nearly all traffic originating from the US, they might not want to invest resources to implement any consent management on their web properties at this time. Devices known to Company 3 from 3P data or via 2P sources such as ad impressions will have those respective consent signals sent (based on the defaults defined by you, as described below). Company 3 may wish to set the Policy Regime to Organization Level: Global Standard to allow for the collection and use of as many data signals as possible.

Conflict Overrides

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 consent categories 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, you must set a default configuration, which the DMP will reference to resolve the consent conflict.

  • True - This option sets the analytics consent flags to true to avoid the conflict.
  • False - This option sets targeting, cross-device, data sharing, and re-identification consent flags false to avoid the conflict.

Considerations and recommendations:
Setting the conflict resolution to resolve all flags to false is the most conservative approach, but could have implications on the populations you see within the DMP. One approach is to try to avoid conflicts in the first place. For instance, if your consumer privacy page allows your consumers to select each flag individually, then there is a high likelihood that the API will return conflicting flags. However, if you provide a few pre-configured options and not expose each unique flag, then the chance for conflict is greatly reduced.

Setting the conflict resolution to true will maintain data collection and populations in the DMP, however this may not be the best approach for your company given your location and risk profile. You should decide which approach is best for you. Some questions you should consider before determining how to resolve conflicts are below.

  • Minimize conflicts:
    • How much traffic do you see from 1P sources?
    • Are you implementing consent management on your sites?
    • Is your company's privacy page clearly defined and consent management eloquently implemented, reducing the likelihood of conflict?
  • Assess risk:
    • How risk averse are you?
    • How concerned are you with the potential for decreased populations in the DMP?

Deleting Erroneous Data Collection

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.

Considerations and recommendations:
For clients who do not have any data ingested from second party sources (eg: ad_impression.gif, event.gif, heartbeat.gif, etc), then there should be no data being ingested into the system outside of the Control Tag or SDK.  Therefore this setting is superfluous.  However, if you have provided HTML pixels to other entities and cannot control when they are fired, then this setting will ensure that any erroneous data getting sent will be deleted on a daily basis. 

2nd Party Consent Defaults

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

Considerations and recommendations:

These consent flags contain default values based on the global standard policy regime. This may not represent the risk profile for your company. We recommend you review and adjust these defaults based on the following considerations:

  • What is the risk profile of your company?
  • How much of your traffic comes predominantly via 2P sources and not ever via 1P sources?

If your company is more risk adverse or is operating under GDPR, then you should consider modifying these defaults. However, keep in mind that if your traffic is predominantly via 2P sources and you don't have the opportunity to obtain explicit consent via 1P traffic via your website's consent UX, then DMP populations will suffer. Remember that you, the Customer, are responsible for obtaining consent from consumers. If you believe no consent is passed to you from 2P events, you should define the defaults accordingly.

Back-filling Consent for Historical Activity

On May 25, 2018, the DMP starts to enforce consent. However, you likely have a lot of historical data against devices that you did not yet collect consent for. In order to transition into the new model, the DMP enables you to define the consent settings for every historical user before May 25, 2018.

On May 24, all devices will receive the consent settings based on the configuration you define in the UI. This measure gives you the option to ensure you do not experience a dramatic reduction in population sizes while you ramp up your consent collecting process. Starting on May 25, you must manage all consent through the API or DMP user interface. We plan to disable the ability to toggle this setting on May 21, 2018, to ensure that no last-minute changes occur to the historical data.

You do not have to set historical defaults values. If you choose not to define historical consent, we treat all devices in your account as if they have no consent, and the no consent rules take place based on each devices policy regime. The impact of this will vary based on your policy regime as well as how frequently you see return devices. If user visits occur with high frequency, then you will soon have the opportunity to obtain explicit or implicit consent (whichever you determine is appropriate, and as defined by you in default settings) via 1P/2P/3P sources. However, if return visits are infrequent, than the impact of not setting historical values will be greater.

Considerations and recommendations:

  • How long have you had the DMP active?
  • What is your segment lookback window?
  • How frequently do visitors return to your site or get exposed to other data collection events (like ad impressions or event pixels that inherit 2P consent rules)?
  • Have you previously had a privacy page where you have tracked some form of consent?

If your DMP has been active for a long time, meaning that you have a lot of historical data, your segment lookback window is long, and visitors don't frequently return, then you may choose to set historical defaults based on any previous policy or consent relationship you have with your consumers. This will minimize any impact to the bulk of devices being evaluated as 'unknown devices' until the population ramps up. If your DMP implementation is fairly new or you have a high number of devices only coming from 2P and 3P sources, than the back-fill settings will have less impact.

Implement Consent Management Processes

Owners: Legal and internal stakeholders, UX team, technical team, DMP Administrator
Result: Methods and processes for passing consent signals are in place

Regardless of which method you use for passing consent, you will need to do some pre-work so that you have the mapping between any consumer inputs and the consent signals you send into the DMP. This may mean designing any consent pages that will be available on your website, setting up processes to pass files to the DMP, training the DMP Administrator on the Consent Management Console, and specifying your company policy on areas such as SLAs and audit protocols.

This section discusses the main tasks to consider for each of the consent methods. The following section provides more detail on options for your company's consent UX and how it should be connected to this Consent Management Framework. As noted in previous sections, thoughtful implementation on your company's consent UX will minimize consumer confusion and also reduce or eliminate conflicts in the consent flags.

API-based consent

The recommended approach to ensure that you’re passing consent in a timely manner and minimizing any ongoing human interruption or error is to utilize the API, SDK, or JavaScript Tag. With each of these, your technical team will need to make sure that the appropriate calls are made when your consumer indicates any action or preference on your Company's Consent page or form. However once this development work is done, there should be no ongoing work by your team.

  • API can be called programmatically from any page. For instance, if you have a consent section of your website or a consent landing page, you can call the API based on the user’s inputs. Similar with the SDK.
  • The JavaScript Tag is essentially a JS wrapper around the API. The advantage of using the JavaScript Tag is that since this can be used where the DMP control tag is placed, you will not have to pass any cookie identifiers; the JavaScript tag can read the Krux cookie that was set by the DMP Control Tag. For any of you using the AJAX method of calling the Control Tag, this is a similar implementation.

For managing consent via API:

  • Determine which method(s) you plan to use, and communicate the changes to your technical development team so that they can schedule the work to implement the new code.
  • Determine the consent model you wish to use (examples are provided in the section below)
  • Create the UX for the customer facing consent page and the app experience
  • Document the mapping between the consumer-facing screen and the consent actions and flags you'll be sending to the DMP
  • Implement the API/JavaScript Tag/SDK based on your documented consent mapping

File-based consent

You may wish to pass consent signals via a file. This can be done as often as daily or as infrequently as you wish. Note that it is your responsibility to ensure that the file is in the proper format, as we will only process valid records.

For managing consent via files:

  • Determine who on your team will be responsible for creating the file and uploading to S3
  • Decide the frequency of file uploads, if applicable 

UI-based consent

The DMP Administrator can utilize the DMP UI to send consent for a specific user using the KUID, AAID, IDFA, or Bridge Key. This might be an infrequent option you utilize if you get any request through your support portal or via email request. This is the most manual, the most time consuming, and will likely incur a lot of lag time from the original user’s request to when your Admin can enter in the info. Therefore, if you utilize the other options, you should only need to use this sparingly to catch any requests that might come in from unforeseen sources.

For managing consent via UI:

  • Establish a process for relaying inbound consent requests to the DMP Administrator (eg: inbound request comes via call center and request gets routed to Administrator(s) via internal ticketing system or distribution list)
  • Train DMP Administrator(s) on using DMP UI to enter in consent requests
  • Determine any audit trail (aside from the DMP audit logs) you may want to maintain for inbound requests
  • Consider establishing a SLA for honoring inbound requests across different channels

Connect Consent UX to Salesforce DMP Consumer Rights Framework

Owners: Legal, UX team, technical team
Result: UX design and mapping document for connecting consumer submitted requests via your UI to the DMP Consumer Rights Framework via API/JavaScript Tag/SDK, as defined by you and your legal team.

Mapping Consent

DMP-related activities may only be a subset of the types of processing performed by your company, and thereby the type of consent you and your legal team have decided is necessary to obtain from consumers. Conversely, the DMP consent settings may be too granular for the consent you and your legal team have decided to obtain from your consumers.

Consult your legal team and define the set of permissions to explicitly obtain consent for, then map the DMP flags to one or more of those different permissions. You can determine whether to explicitly ask for each granular item or not. The primary consideration from a DMP integration perspective is that you provide a consent signal for every single flag regardless of whether or not you and your legal team decided it was necessary to explicitly ask for that granular consent. This consent mapping determination is up to you.

One-to-One Consent Models

This example contains 6 different options mapped to the 6 different consent flags available in the DMP.

When the user confirms this series of consent settings, the outcome in the API appears similar to this example.

https://consumer.krxd.net/consent/set/d591743f-c1fd-4241-b202-1f9e17e80d39?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&dc=1&al=1&tg=1&cd=1&sh=1&re=1

One-To-Many Consent Models

In some cases, you may decide that a single question or privacy policy can address your requirements for obtaining consent.

When the user confirms this series of consent settings, the outcome in the API might appear like this example.

https://consumer.krxd.net/consent/set/9c2469be-b2c2-4c7c-af30-ddb88f3b62d3?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&dc=1&al=1&tg=1&cd=1&sh=1&re=1

Hybrid Consent Models

A hybrid model groups some questions together in a single item and calls out other items explicitly. For example, if you decide to collect consent for interest-based advertising, you may define it to include data collection, analytics, and targeting. In this case, when a user consents to interest-based advertising, you may pass positive consent for collection, analytics, and targeting in the DMP.

This example calls out cross-device explicitly, and includes email based product recommendations which do not relate to the DMP flags. 

When the user confirms this series of consent settings, the outcome in the API appears like this example.

https://consumer.krxd.net/consent/set/9c2469be-b2c2-4c7c-af30-ddb88f3b62d3?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&dc=1&al=1&tg=1&cd=0&sh=0&re=0

This example shows cross-device ID management as set to 0, indicating no consent, as defined by the user. Additionally, data sharing and reidentification are set to 0 because they are not encapsulated in interest-based advertising per the example definition.

In the absence of asking the question directly to the consumer, all consent flags still provide the value you have defined.

Integrating Policy Regime

You can choose to allow the user to directly define their country of residence so that you can provide the most accurate policy regime settings.

When the user confirms this series of consent settings, the outcome in the API appears like this example.

https://consumer.krxd.net/consent/set/9c2469be-b2c2-4c7c-af30-ddb88f3b62d3?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&pr=gdpr&dc=1&al=1&tg=1&cd=1&sh=1&re=1

This examples includes the policy regime (pr) parameter in the request as the user indicated living in France, an EU member state. The logic to define that France appears under the GDPR policy regime is the responsibility of the customer.

Passive Consent

If you and your legal team determine that you may obtain consent passively instead of having an active opt-in experience, the DMP supports this use case, but still requires you to set consent flags for each user/consumer.

Customer-Facing Webpage and App Experience

Data protection and privacy regulations can require that you provide consumers with the option to change their consent settings whenever they choose. Because consent is mostly stored against a cookie or MAID, a user experience that avoids the consumer having to find their cookie, MAID, or other device ID works best.

In addition to the main consent obtaining experience, we recommend hosting a webpage, mobile app, or combination of both. This implementation integrates with our consent API to enable customers to perform these actions.

  1. View and Update Consent
  2. Request Right-To-Be-Forgotten or Data Deletion Activities
  3. Request Data Portability Data Feeds

In absence of such an experience, you can facilitate changes and requests on behalf of your consumer via the DMP Admin screen or via Data Feeds. In either of these cases, you can ask the consumer to provide their KUID or device IDs if you don't use a bridge key value (such as hashed email address). To provide a better experience, we recommend hosting a management screen instead.

Other Implementation Considerations

Complete Queries and Incremental Queries

The DMP supports a single, complete request for each device. We interpret additive requests where you submit single consent flags one after the other as net-new settings for each call that is made. When you submit a request that only includes one flag, the rest of the flags default to false.

For example, you send positive consent for data collection in one call for a single user ID.

https://consumer.krxd.net/consent/set/9c2469be-b2c2-4c7c-af30-ddb88f3b62d3?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&dc=1

We interpret the URL as these consent flags.

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

One second later, you send positive consent for sharing for the same user.

https://consumer.krxd.net/consent/set/9c2469be-b2c2-4c7c-af30-ddb88f3b62d3?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&sh=1

We interpret the URL as these consent flags.

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

This actions confirms that sharing is enabled for this user, but data collection and all other flags are false. For this reason, ensure you fire a complete request for each user.

https://consumer.krxd.net/consent/set/9c2469be-b2c2-4c7c-af30-ddb88f3b62d3?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&dc=1&al=1&tg=1&cd=1&sh=1&re=1

A more complex example involves dependent flags set in isolation. As documented in the consent management configuration section, some consent flags have dependencies. For example, targeting is dependent on analytics.

Perhaps you set targeting to true in a single flag request, and your configurations resolve conflicts to true.

https://consumer.krxd.net/consent/set/9c2469be-b2c2-4c7c-af30-ddb88f3b62d3?idt=device&dt=aaid&idv=6d0109bb-b7c8-4de9-b554-22c8663bca91&tg=1

We interpret the URL as these consent flags.

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

Analytics defaults to true because of the conflict configurations, and the other non dependent flags are set to false per the established rule.

Review SuperTags for data collection

Owners: DMP SuperTag Administrator
Result: Data collection tags fired through SuperTag are correctly marked

SuperTag provides a complete solution for managing third-party tags, custom tags currently hardcoded on site pages, and JavaScript ad tags through a container-tag model. In addition to the current fine-grained controls of limiting tag firing based on metrics such as throttling, frequency caps, timing and sequencing, and target based on URLs or attributes, SuperTag now respects tag firing based on whether the tag is marked as a Data Collection Tag.

When creating or editing tags in SuperTag, you now have the option to select whether the tag is a Data Collection tag or not. Those tags marked as Data Collection will not fire for any user for whom the data collection consent flag is set to false. These might include analytics or measurement tags. If a tag is not collecting any data via the page, then this checkbox can remain unchecked.

For auditing and managing tags via SuperTag:

  • Train DMP SuperTag Administrator(s) on new SuperTag control
  • Plan a tag audit and review process in advance of the May 25th timeline based on the number of tags your company is firing via SuperTag.
  • Update your tag deployment process to includes data collection reporting and verification
  • Determine any additional audit trail you may want to maintain for inbound tag deployment requests
Have more questions? Submit a request

0 Comments

Article is closed for comments.