Adobe Experience Platform

Danny-Miller · 3/13/23

Authors: @Aimee-Gregg @Ben-Maloney @Danny-Miller

Data Governance, honoring consent preferences, and data access control are three foundational pillars for building customer trust and are critical pieces to get right during your Adobe Experience Platform implementation and ongoing use of the platform. According to Adobe’s 2022 Trust Report, 79% of consumers stated that they were concerned about how companies are using their data.

We are starting a blog series that will cover how different tools within AEP can support each of these pillars. Today, we’ll focus on Data Governance and AEP’s DULE (Data Usage Label Enforcement) framework.

First off, let’s talk about what we mean we say “data governance”. In this context we are referring to restricting the usage of data outside of platform due to organizational needs or contractual obligations. With so much first party data available in the tool and cross-channel activation opportunities that bring many different teams’ campaign activities together in a single platform, ensuring that data are used properly when activated is crucial to protect sensitive customer information. With a little forethought and labelling, we can do just that in AEP with the DULE framework.

If you’re about to start an implementation of AEP and RTCDP, you might be wondering when you should start thinking about data governance.

From our perspective, the sooner, the better but don’t do it in a vacuum!

Let's unpack both of those pieces of advice.

Timing for starting to talk about data governance or DULE is best done while you consider your first core use-cases and before data is ingested. We find that our customers with best-in-class data governance have a clear idea of how and where each dataset and dataset fields ingested into AEP will be consumed outside of platform. It doesn’t mean that you must have every tiny detail figured out, but it is best to have thought about this as an organization before you ingest data.

Before we get ahead of ourselves, though, we should note that these data governance policies should be done in close consideration with a data steward, compliance, legal and privacy teams, as they're the ones who can plan out a strategy for your company to consider from a legal or contractual perspective.

Where to start?

During these early conversations, some questions you’ll want to consider as a team are:

Do I have any core use-cases around wanting to restrict the export or usage of my data?

For instance, do you not want email addresses to be exported for paid ad targeting? Is that a critical use-case to list and build an export restriction into the design for your email field and paid media destinations?

Do we have contractual obligations regarding the data we collect and how can it be used?

For instance, if your health app for your sportswear brand contractually states that you will only use this data in the app and not for targeting ads or offers, you will want to plan to build rules around the usage of your health app data. What about sharing across brands or business units?

What types of sensitive data do we have that we need to be careful about?

You may want to store specific data within AEP but not have that sensitive data be used in marketing efforts. For example, if geographic information is not something you want to use to target ads or other information, you can easily restrict the usage of that data.

Where do we intend to activate our segments?

A key consideration to help inform your data governance strategy will be around what destinations you intend to send your segments to. For example, an email-based destination where the file you send contains PII may have different data governance considerations than an advertising-based destination which uses hashed email as an identifier. I.e., do some fields have different policies depending on where and how we need to use them? The destination is where you will enforce your policy, so scoping these out early is key.

DULE Components

DULE (Data Usage Label Enforcement) is a very simple but powerful framework that has four components:

1.) Data Governance Labels

There are four types of labels that come out-of-the-box in AEP:

Identity (e.g., Directly Identifiable information)
Sensitive (e.g., Precise Geo)
Contract (e.g., No Onsite Ad Targeting)
Custom (Create your own)

You can apply these labels to an entire dataset or a field within that dataset or schema.

One example of using a Governance Label might be applying the “Directly Identifiable Information” to the clear email address, phone number, and physical street address fields in all datasets where they are present.

2.) Marketing Actions

Marketing Actions are a different type of label that can be applied to destinations or journeys that describe the marketing use-case of the data export or communications. There are many Marketing Actions that come out-of-the-box (ex: Email Targeting, Export to third party), but custom Marketing Actions can also be created.

The goal of the Marketing Action is simply to label a destination or a journey with what that destination or journey is doing. One example of this would be applying the “Email Marketing” Marketing Action as well as the “SMS Marketing” Marketing Action to your email service provider that can also send SMS.

Tip: We have seen a customer apply every single Marketing Action to a destination—and while some destinations might have multiple applicable Marketing Actions, you should really only apply a Marketing Action when you know it will be used in a policy.

3.) Policies

Both Data Governance Labels and Marketing Actions themselves do not restrict the usage or export of data. They must be referenced in a Data Usage Policy that is enabled for restriction to start happening. These policies are very simple. You select your data label(s) and then choose which marketing action(s) you want to either allow or restrict data export with.

For example, you could create a policy that said where the data label “No Onsite Ad Targeting” exists, don’t allow the export to the Target destination where you have the label “Onsite Ad Targeting” present.

4.) Enforcement

Your policy will be invoked in two different scenarios:

Segments Contains Labelled Field

Your segment will inherit the data labels that apply to the attributes, events, or datasets that make up your segment. If you try to export a segment with a restricted field included in its logic, then your policy will be invoked, and you will receive an error message that will stop you from finalizing your destination mapping.

Best Practice: If you label an entire dataset, and that dataset is used in a merge policy or any field that your segment uses, then that segment will also inherit the label and be restricted at activation. For this reason, we recommend labelling individual fields instead of entire datasets.

For example, if you have labelled and restricted “Precise Geo” fields where the Marketing Action “Email Marketing” is present, you won’t be able to send any segments to your Email Service Provider (assuming you labelled it with your “Email Marketing” Marketing Action) where they derive any segment logic from labelled data such as precise location coordinates.

Profile Export Fields Contain Labelled Field

Another time your policy will be invoked is if you try to export a restricted field in a Destination as the chosen identity or in a profile export as one of the fields chosen.

Using our “Precise Geo” example from above, if you created a segment of profiles who purchased in the last 90 days, but then tried to export their precise location coordinates in your destination flow for a personalized email, you would also receive an error message.

See below for what the error message looks like. It will show the policy which was violated as well as the data lineage of the data that was restricted from being shared.

Bringing it all together with a Real-Life Example

Let’s walk through a clear real-life example of an end-to-end DULE policy.

In this case let’s say that you want to ensure that a clear email address cannot be exported to paid media destinations. A few of our customers have this use case because they want to programmatically ensure that marketers or agencies that have not had access to sensitive data in the past aren’t able to accidentally export that data outbound. At the same time, many of our customers are also activating to email as a channel and do want to export email address for those activations. Let’s dive into how we can architect a policy to restrict a field export for only certain use-cases.

Label your data

The first step to bring this use-case to life is to simply label the clear "Email Address” field in the dataset with a governance label. One pre-made label you can use here is the I1 Identity Label which denotes a Directly identifiable data that can identify or contact a specific person, rather than a device.

Tip: We’ve seen a few successful strategies with labels. We see some customers only utilize the pre-made labels while others only create custom ones. For customers who create custom labels, one best practice we recommend is creating a naming convention for that label to ensure it isn’t misused. Perhaps the most effective use of labels we see are customers who use a mix of both. They use pre-built labels for large organizational governance policies (e.g., labelling all data with PII as “sensitive” and restricting export of all those fields) and they create custom labels when a policy requires just one label and one marketing action for a very specific purpose.

Assign a Marketing Action to your Paid Media Destinations

When setting up your paid media destinations, you can select the “Cross-Site Targeting” marketing action to apply.

Tip: If you have already set up your destination, you can only add or remove marketing actions via the API.

Define a usage policy

Up until this point, assuming you don’t have any other policies enabled, your label and your marketing action will have no effect on your activities. You need to set up a Governance Policy in order to unite your data label and marketing action for any enforcement to happen.

Creating a policy is a multi-step process where you choose a label and then relate that label to a marketing action. You want to make sure to name, describe, and save your policy. Using our example, you’d create a policy that says “if the I1 label is present, restrict export where the cross-site targeting Marketing Action is present”.

After you’re done, you’ll need to activate the saved policy by hitting the “enable” button.

Enforcement

Once the policy is enabled, your activations will be eligible for enforcement.

Blocking Email Export for Paid Media: If someone on your team tried to export email addresses to paid marketing destinations (assuming the cross-site targeting Marketing Action is applied) or they tried to export a segment which included the email field as part of its logic, they would get stopped from doing so through the UI. A popup would inform them precisely what is causing the block.

Allowing Email Export for Other Channels: If that team-member tried to export the email field or segment containing the email field to a destination that connected to an email service provider which did not have the “Cross-Site Targeting” Marketing Action, then the export would happen without restriction.

Best Practices

Think About Governance Early On

We’ve already discussed when to start thinking about DULE, as early as possible. Timing is crucial because we have seen customers who wait too long to think about data governance and must delay the onboarding of marketing teams onto the platform until they can control the export of data their organization deems sensitive. This ultimately increases time-to-value and decreases tool adoption overall.

Align on the Labelling Approach that is Best for Your Organization

Another point to consider is what strategy you should use for labeling. There are two schools of thought: The “Open” approach where you label only the few fields that are critical or the “Closed” approach where you label everything you can.

Most organizations we work with only have a handful of policies and data fields that they want to restrict. For these organizations, we find the “Open” approach works well meaning that labels are only applied when enforcement is needed, and their Governance Framework can easily be altered or made flexible as new data comes into the platform. Also, it is much easier to thoughtfully add labels later than it is to have to remove or change the labels later when new restrictions are needed.

For organizations with heavy restrictions on many data fields and destination exports, the “Closed” approach may work, but significant planning that would be needed ahead of time in order to do the “Closed” approach with success. Customers who haven’t done the “Closed” approach well have labelled everything in their instance immediately without planning out their policies or considering how they want to restrict data export. Then, when they eventually do create policies, they automatically enforce data usage and actions they didn’t intend. This often results in a rushed cleanup effort and unhappy campaign managers.

Always Label with Purpose

For any organization, our advice is to be purposeful and careful with how you label, create policies, and restrict marketing actions.

Afterall, these policies have real-world effects on your marketing team and on your revenue (if done incorrectly).

Wrap Up

Creating a data usage policy is something that Adobe has made easy in AEP. When creating your data usage policy using DULE, you’ll always want to first consult with your data steward and legal and privacy teams.

We advise that it is best to start DULE conversations early, even before you ingest data. Identify those critical fields where you know governance will be needed because that data will need to be protected in some way. Then, identify the use-cases for those fields and for which types of exports they should be restricted.

You can always label more data and create more policies later, but from what we have seen with the most successful customers using DULE it is best to start slowly and purposely.

The ideal state for AEP in your organization is a platform all your teams can use freely. Your marketing and execution teams can easily use your customer data to segment for fast time to market on campaigns. However, with DULE, your organization has peace of mind that customer data is always being used in adherence to your internal data guidelines.

Furthermore, with the usage of DULE, the relationship and trust you are building with your customers strengthens when customers know and trust you are correctly using their data.

In fact, according to Adobe’s blog Marketing responsibly with consumer data, “Showing consumers that marketers care about their data means understanding and implementing the most critical strategies for protecting information — consumer privacy, data governance, and system security.”

While data usage and labeling enforcement is a powerful tool AEP has several other tools that give you more control over delivering experiences in line with your policies. One of those is Trust Console which we will cover in our next blog.