ÃÛ¶¹ÊÓƵ

Transcript

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 ÃÛ¶¹ÊÓƵ 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 ÃÛ¶¹ÊÓƵ 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.