Data Governance overview

In this video, I’ll give you an overview of the governance features in Adobe Experience Platform. Let’s first look at the data governance challenges facing enterprises today. On one hand, you want to provide personalized customer experiences by leveraging customer data, data science, analytics, segmentation and activation. On the other hand, you also want to ensure that all data usage complies with policies based on legal, contractual and privacy obligations. Complying with such policies becomes hard when data usage is siloed from data stewardship. The governance features on Adobe Experience Platform allows you to address these challenges and break down such enterprise silos. Adobe Experience Platform provides an easily extensible governance framework that is deeply embedded in data usage workflows. We call this the data usage and labeling enforcement framework, or DUEL, and it provides features for you to take complete control over governing your data, from the point it’s collected at data sources to when it’s syndicated to destinations outside platform. The framework is built on three key aspects, labels, policies, and enforcement. First, you can classify data using governance labels. Second, you can alter governance policies to define usage restrictions. Third, policies can be enforced when the data is used. With these three pillars, you can be assured that all data usage is in compliance and does not violate any policies.

Now let’s take a look at each of these aspects, starting with data classification using labels.

In an increasingly privacy conscious landscape, you want to ensure that your data is appropriately tagged and classified to reflect corporate policies, contractual obligations, compliance requirements and regional regulations. Governance labels enable you to do this and are critical to differentiating known and unknown data about your customers. Once labeled, the classifications are propagated as data flows through the system. Labels are also building blocks to other usage policies and enable services to identify and restrict data usage. Different types of governance labels are offered in Adobe Experience Platform to capture a rich and complex set of restrictions you want to apply on the data. Three categories of labels are provided out of the box. Contract labels can be used to categorize data, indicating contractual obligations. For example, you can use C6 Contract Label on data that is contractually restricted from use an onsite targeting. Identity labels can be used to categorize data that can be used to identify or contact a specific person. For example, you can use I1 identity label on data from your CRM system that directly identifies an individual, like the email address or phone number. Sensitive labels can be used to categorize sensitive data like geolocation. Additionally, you can also create custom labels based on your business needs.

Data classification is designed to be a convenient experience that minimizes repetitive tasks. You can apply the governance labels at the source level on datasets. Granularity to apply labels at the dataset field level is also provided. This means that when you want to use the data, restrictions relevant for individual fields can be honored while fields without restrictions can continue to be used. Any segments or profiles that are created from source datasets will automatically inherited the labels. Not only does this reduce the chance of making mistakes, but any updated restrictions are propagated and reflected in data assets downstream in real-time.

Now that we’ve covered data classification, let’s look at policy management, the second aspect of the governance framework. Adobe Experience Platform provides data stewards with the ability to define data usage policies based on their corporate, legal and privacy guidelines. A governance policy describes what kinds of data usage actions are not allowed based on the classifications applicable on data. Two features are provided that act as building blocks to define a governance policy, governance labels and marketing actions. Let’s look at an example. You may want to define a policy that states, directly identifiable data should not be used for onsite targeting. To enable this, you can use a marketing action identifying onsite advertising and the governance label I1 to create a policy rule.

The policy engine offers flexibility to use a Boolean expression of labels when altering the rule. This can be a combination of one or more Boolean and/or expressions involving labels. You can define your own marketing actions and also enable or disable policies to have complete control over policy definitions. Governance policies come in two flavors. Core policies are provided out of the box, and use predefined labels and marketing actions in their definition. These are defined in coordination with privacy and legal guidelines, and help you get started with common restrictions to be applied for customer experience use cases. You can see some of the core policies on the right side. For example, a policy to restrict email targeting is based off label C4 and C5, and prevents data with that classification from use for email targeting. Custom policies provide flexibility to define your own restrictions using the policy engine tailored to your specific use cases.

The third aspect of the governance framework is policy enforcement. Once policies are defined and enabled, applications using data can enforce these policies at the point where data is used for specific marketing actions. The applications should go through the following steps to enable governance enforcement. First, all the classifications for data requested for usage needs to be retrieved. Next, all the marketing actions for which data is requested for is retrieved. Once the labels and actions are retrieved, any violations against active governance policies can be checked, if any policies are violated, data usage can be controlled to honor the policies. Policy enforcement is built into Adobe Experience Platform with both simplicity and extensibility as key considerations. All four steps to enable enforcement can be performed using governance APIs. This means that any custom applications built on top of Platform can restrict data usage, and do it in a way that allows those applications to define the enforcement experience to provide to their users. Platform services and applications will provide an enforcement experience out of the box. This automates the steps for enforcement under the hood and is embedded in the usage flow of the applications. Platform’s approach to governance is not just about restricting usage, but also to help you make informed choices on what you can do to mitigate the violation and continue delivering customer experiences. Whenever a policy violation happens, enough context is provided about why this happened. This includes a list of violated policies, as well as a comprehensive lineage analysis. By analyzing this lineage, you can identify how the activation you are trying to perform caused a policy violation. Based on this analysis, you can decide on the course of action and subsequently remediate violations by making appropriate updates to data relationships. That’s an overview of the governance features in Adobe Experience Platform.

Hi, it’s Daniel. In this video, I’ll show you how to apply data usage labels to your schemas and data sets in the Adobe Experience platform. Data usage labels enable you to tag and classify data to reflect corporate policies, contractual obligations, compliance requirements, regional regulations, user access policies, and customer consent preferences. This is critical to differentiating known and unknown data about your customers and applying appropriate controls on data usage based on the nature of the data.

You can label data in both schemas and data sets. Let’s start with schemas. I’ll open the platform interface and click schemas on the left NAV to see a list of all of my schemas. We’ll see the Luma loyalty schema listed here. I’ll select a schema to see more details. The interface shows the schema structure we’re interested in labeling data. So let’s click the labels tab at the top. In this view, you can see all of the fields in this schema and which labels they contain. There’s a filter option to help you filter to specific field groups, identity fields and the already applied labels in the Luma Loyalty schema. I have an email address field that can directly identify an individual. Let’s apply an appropriate classification to this field.

Select a checkbox next to the field name and then click the button to edit the governance labels for the field.

In the dialog, you can choose labels from any of the three categories provided out of the box. Contract labels, identity labels, and sensitive labels. You can even create a new label from within. This workflow will apply an AI one label to indicate that email address is directly identified. Label Data. Click Save. To finish. Another workflow you can use is to select a field from the schemas structure view and then select apply labels.

When you label a fields in a schema. That label is inherited across all schemas and platform. Using that same fields group. So that should save you the trouble of having to track down all other locations that use that same field group.

For example, here’s another schema which uses the same personal contact details Fields group as my loyalty schema. If I look at the email address field, you will see it’s already applied. Keep in mind, though, that sometimes several field groups use the same field at the same X path, and labeling the field in just one group won’t impact the use of that field in another group. Here’s an example of that. If I open my Luma context schema and open the personal email address field, which was added by the extreme business person details group. Note that the label has not been applied.

Labels can also be applied at the data set level. In this case, let’s pretend we purchased a data set from a third party and it has a contractual restriction preventing the data from being used for any cross aid targeting outside of the customer’s websites and applications. This data set might be based on schema field groups used by other datasets which don’t have this contractual restriction. So in this case, it doesn’t make sense to apply labels at the schema level, but instead to the data set itself. To do this, click the data governance tab. You might notice labels that were inherited from your schema. You can toggle these in or out of view. Scroll through the list of labels and apply the C five label to indicate the restriction for cross-site targeting. One thing to keep in mind is that labels applied at the data set level don’t play a role in access control policies, so it will impact data governance and consent policies, but not user access.

In previous versions of Adobe Experience, platform labels could be applied on individual data set fields to capture. Are fine grained classifications not applicable to the entire data set that has been discontinued in favor of the more powerful schema field labeling. But here’s an example of what that looked like, and you may still see some individual fields labeled in your data set. We suggest that you remove them over time and replace them with equivalent labels on the schema fields. To remove a label from a data set first, make sure you’ve already labeled the schema field equivalent and then in your data set, just click the X to remove the label from the field. Since the labels are applied on the schema and data set metadata, you can start classification as soon as you have the data sets modeled and platform. You don’t need to wait until the actual data ingestion starts. Once data is classified, data usage can be restricted by defining governance, consent and user access policies. If policies have already been created before, you’ve labeled your fields, you may experience a governance policy violation message like this one when applying a label. This means that there’s already a usage in place which will be violated by the application of this label. So use the data lineage diagram to understand what other configurations you might need to change before being able to add the label. Also, be aware that since the schema labels are also used for access control, a field might disappear from your view after you’ve applied a label. If you don’t have permission to view fields with that label, if that happens to you, I suggest you open the schema and use the filter to see what labels are being used. Even if you can’t see which fields they’ve been applied to. And then make sure you’re in a permissions role that has the same labels. You should now be able to classify data by applying labels on individual fields in this schema and to an entire data set. Thanks for watching.