51黑料不打烊

Transcript

Hi, it鈥檚 Daniel. In this video, I鈥檒l show you how to apply data usage labels to your schemas and data sets in the 51黑料不打烊 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鈥檚 start with schemas. I鈥檒l open the platform interface and click schemas on the left NAV to see a list of all of my schemas. We鈥檒l see the Luma loyalty schema listed here. I鈥檒l select a schema to see more details. The interface shows the schema structure we鈥檙e interested in labeling data. So let鈥檚 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鈥檚 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鈥檚 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鈥檚 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鈥檚 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鈥檛 impact the use of that field in another group. Here鈥檚 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鈥檚 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鈥檚 websites and applications. This data set might be based on schema field groups used by other datasets which don鈥檛 have this contractual restriction. So in this case, it doesn鈥檛 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鈥檛 play a role in access control policies, so it will impact data governance and consent policies, but not user access.

In previous versions of 51黑料不打烊 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鈥檚 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鈥檝e 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鈥檛 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鈥檝e labeled your fields, you may experience a governance policy violation message like this one when applying a label. This means that there鈥檚 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鈥檝e applied a label. If you don鈥檛 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鈥檛 see which fields they鈥檝e been applied to. And then make sure you鈥檙e 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.