Data Steward
Imagine you are a data steward. The legal department has recently decided that, due to privacy concerns, you cannot use the attribute 'age' for customisation on your company website.
As data steward, you are responsible for configuring AEP to comply with the new policy. AEP provides a number of tools to centrally manage what data can be used and for what purpose.
Marketing actions, (also called marketing use cases) in the context of the data governance framework, are actions that an Experience Platform data consumer can take, for which your organization wants to restrict data usage. In the current scenario the marketing action is the desire to export AEP audiences to personalisation tool.
Now, have a look at what marketing actions are available.
- Click on Policies on the left rail menu;
- Click on Marketing Actions.
This is the list of marketing actions defined by AEP by default. There is already an action called 'Onsite Personalisation', which exactly meets the requirements of the legal requirement.
AEP already includes a number of marketing actions that cover the main use cases. However, it is also possible to create custom marketing actions for specific needs.
Each destinaion needs to be associated with a marketing action. In our technology stack, the personalisation tool is Adobe Target. We want to make sure that the destination has been linked to the correct marketing action.
- Click on Destinations to see the list of already configured destinations;
- click on Adobe Target.
The right hand menu shows information about the destination, including the marketing action Onsite Personalisation. The destination is correctly configured.
Data usage labels allow you to categorize datasets and fields according to governance policies that apply to that data. Labels can be applied at any time, providing flexibility in how you choose to govern data.
For the current use case, we need a label to identify fields that "cannot be used for on-site personalisation".
- Click on Policies on the left rail menu;
- click on the Labels button to access the list of labels that have already been defined;
- in the list we find C7, which already meets our requirements.
AEP already includes a number of labels that cover the main use cases. However, it is also possible to create custom labels for specific needs.
The next step is to create a policy that will automatically block anyone who tries to activate a segment with fields labelled C7 on a destination with the marketing action Onsite Personalisation.
- Click Browse to access the list of policies already defined.
- At the bottom of the list is a policy called Restrict Onsite Personalisation, which blocks any segment containing attributes labelled C4 and C7.
- The policy status column shows that the policy is already active.
No further action needed.
AEP already includes a number of policies that cover the main use cases. However, it is also possible to create custom policies for specific needs.
The last step is to apply the label C7 to the field called age.
The field is already associated to the right label. Follow the next steps to understand how to do it, but don't click Save at the end of the process.
- Click on Schemas on the left rail menu;
- click on the Apply Access and Data Governance Labels button on the top right of the window;
- in the search field type "crm";
- select Demo System - Profile Schema for CRM (Global v1.1);
- click Next on the top right corner of the window.
Now you can see the list of all the fields of the schema.
- In the search field type "age";
- select the Age field;
- click on the Apply access and data governance labels button on the right menu;
In the pop-up you can see the list of all the labels available.
- Scroll down to find C7
In this case it already selected, in order to avoid concurrences issue, since all the participants are working on the same instance and same field.
- Click on Cancel
Now the Age field is labeled with the C7 label.
Each field belongs to a fieldgroup; as the fieldgroup is shared by several schemas, once the label is applied it will be reflected in all schemas.
The configuration is complete. As the data steward, you can now rest assured that the Age field will not be used for on-site personalisation.