Because my early Adobe Analytics exposure was primarily in APAC markets, data governance was not a top concern to me. I’m not sure whether there are clear guidelines in APAC markets even now; I’ve never noticed any. My initial encounter with data governance happened years ago while I was preparing for my first Business Practitioner exam. There was a GDPR-related question, and two of the options were Right to Access and Right to be Forgotten. I’m sure I didn’t answer the question correctly (but still passed the exam) since I never had the opportunity to work on data governance at the time. I wanted to explore data governance from an analytics perspective, but I couldn’t recall if Adobe’s documentation supplied that information during the time, and I was sidetracked with other tasks. When I got the opportunity to work with US and EMEA markets, I realized I had to acquire everything I could about the topic and this post covers the fundamentals of data governance I have acquired from my experience in a simple summary.
Why is Data Governance important in Adobe Analytics?
Though organizations won’t gather PII in Adobe Analytics, they can/will still identify the individuals based on the cookie or any custom identifier such as customer id, loyalty id, account id, etc., which can be referred to as identity data. Furthermore, organizations would gather a few sensitive and private data such as geographic data or any data accidentally collected by plugins such as the activity map, which might be a concern. Under GDPR or CCPA regulations, customers can opt-out of data collection utilizing consent management, but that’s only for future data. If the data was already collected, customers do have the right to access and delete the data collected by the organizations. So, Data Governance in Adobe Analytics tackles the second, namely, the Right to Access and Right to be Forgotten.
How do customers gain access to and delete their captured data?
Though the customer data is stored in the Adobe (the data processor) platform, it is the responsibility of the organizations (the data controller) to ensure that customers (the data subjects) can request access to and delete the captured data. Adobe’s Privacy Service enables organizations to assure that data is accessed and deleted upon request. Organizations can develop a simple user interface on their post-login website or mobile application (not limited to) to accept customer requests. A simple user interface might look like the one below.
As a result, customers can request data access and deletions using the portal developed by the organizations.
What happens when a customer requests access or deletion?
When a customer submits a request through an organization’s portal, the request is sent directly to Adobe (in certain circumstances, organizations can intervene) using Privacy Service. Once processed, Adobe dispatches the customer data to the organizations. Organizations can then decide which data to return to customers and respond to them with the final data. Below is a snapshot of the request and response diagram.
How does Adobe identify the customer?
Adobe identifies customers using their Cookie-ID (Analytics ID or ECID) or custom identifiers such as customer id, loyalty id, account id, and so on. Based on the previously stated interface, if customers select the option ‘Browser,’ organizations can read the browser cookie and request Adobe via the Privacy Service to inquire about the customer information. It applies to both access and deletion requests.
If a custom identifier (here, the customer ID) is selected, organizations should provide the customer ID to Adobe in order to obtain customer information. When a custom identification is used, there is a catch that everyone should be aware of. Assume the customer lands at a pre-login page before moving to post-login pages where the customer ID is available. Whenever a customer ID is selected for an access request, the data returned will only be for post-login data (hits where the Customer ID was available) by default and not for pre-login data. If organizations choose to include pre-login data, they should enable the ID expansion option in Privacy Service so that all sync’d ID activities are returned. There are a couple of examples in Adobe’s documentation that I would recommend everyone to read through, link here.
What are data governance labels in Adobe Analytics?
We’re all aware that not all of the information organizations acquire about their customers is personal and confidential. Understanding digital asset engagement, on the other hand, is also a right for every organization, but it cannot be tied to any visitor as an identity. To be equitable to both customers and organizations, Adobe Analytics has data governance labels where organizations can set their data categories in a simple interface. As a consequence, when an access or delete request is made, only variables labeled as identity, sensitive, or private are accessed or deleted with anonymizing the visitors for the rest of the variables ensuring that customer privacy and the organization’s need are met at the same time.
What is the impact of data governance in Adobe Analytics reporting?
Deleting acquired data will undoubtedly provide us with two numbers, before and after the data is deleted. To deal with this, data is not truly deleted; rather, the previous value is replaced with a new random value based on the variables (For more details, check out the link here). Therefore, with a few exceptions, even if data is deleted, the numbers in the reporting will not change. However, we should be aware that if a customer returns to the website after a deletion process, they are considered new and everything starts over for analytics tracking.
Other considerations in Data Governance
Namespace: If a customer’s identity is captured in multiple variables across different report suites, it is more difficult for organizations to include all of the variables with the access or delete request. This can be simplified when they employ a Namespace (a simple, friendly identifier name such as customer id, loyalty id, account id, and so on) to tag the variables. Organizations can now include the namespace in their request to make the lookup process easier.
Time to access & delete: The request for privacy data access or deletion is not real-time, but it does take time. So, it is a must and important for organizations to prioritize requests and update customers accordingly. Specifying requests that are not a result of customers should be kept low and will be processed within 30 days by Adobe i.e. organizations that leverage Privacy Service to clean their data internally. The Privacy Service API is not an appropriate tool for data cleansing or repairs and will have unintended consequences of delaying important and legal requirements from end customers.
Not report-suite specific: When the customer request access and delete data, the data for the identifier is fetched from all the report suites. Specifying report suites inside the Privacy Service are currently unavailable, therefore request processing cannot be validated separately for the development report suite for testing purposes. There is a workaround for this, which you can find out more about here.
Data Retention mandate: Adobe Analytics cannot assist you with processing requests to the Data Privacy API, i.e., processing access or deletion requests you receive from your end customers, if the data retention period for the report suite has not been set.
Deletion handling: A historical report that was run before Data Privacy deletion will match the same report run after deletion has been performed by Adobe. This is accomplished by completely disassociating the deleted data from the data subject, while leaving non-identifiable data in place so that reported values remain consistent.
Summary Note
I’ve been planning to write this article for a long time because it’s much easier if someone summarizes everything in a single post rather than combing through multiple pages of documentation. At the completion of a protracted read using documentation, we would probably end up with several questions and distract ourselves from the basic understanding, which is vital. Said that, data governance plays an important role in Adobe Analytics especially when GDPR and CCPA are involved. So, set your data retention policy, familiarize yourself with data privacy labels, identities, namespaces, ID expansion, and so on.
I am sure I have skipped a few considerations, but now that you have a basic understanding of data governance, you can help yourself by going through Adobe’s documentation. Happy learning & exploring!
