If your customers (consumers/data subjects) want to know what data you maintain about them or decide they want to be deleted from your Analytics properties, you as the data controller are responsible for responding to those requests. The data controller determines how your organization will interact with data subjects (e.g., through a data subject user portal) and manages interactions with the data subject. It also is the controller’s responsibility to close the loop with the data subject when the request is fulfilled. In other words, Adobe Experience Cloud, as the data processor, will not accept requests directly from data subjects or return data directly to them. Rather, Adobe will receive requests from and return data to only you as the data controller.
You also may want to ensure your mobile apps and websites will have relevant pop-up notices and supporting materials about data subjects’ rights regarding their directly identifiable or indirectly identifiable data, and other data you collect.
You, as the data controller, are responsible for obtaining explicit consent from your data subjects before you collect data about them (possibly including Adobe Analytics data) and for implementing an opt-out mechanism on your web site. This lets your data subjects opt out of future Adobe Experience Cloud data collection.
You, as the data controller, are responsible for verifying that the data subject is who they say they are and that they have a right to the data they are requesting. Further, it is your responsibility to ensure that the correct data is returned to the data subject and that they don’t inadvertently receive data about other data subjects.
This includes reviewing the data returned by Adobe Analytics as part of a Data Privacy access request before sending it on to the data subject. Particular care should be taken if you are using Person IDs, and returning not only data where that ID is present, but also data for other hits on a shared device where that ID was sometimes present. See ID Expansion.
Each file combines data from all your report suites, automatically removing extra copies of replicated hits. You can decide which of these files to return to the data subject. Or you may extract some of this data and combine with data from other systems before returning it to the data subject.
You can submit Data Privacy access and delete requests through our Data Privacy UI portal or via our Data Privacy API.
The Data Privacy API supports batch submissions for multiple users in a single request. The currently supported limit is 1000 separate users (may have multiple IDs per user) in a single request JSON file.
Here is the JSON that might be submitted through the Data Privacy API or UI, requesting Data Privacy processing for three users.
{
"companyContexts": [
{
"namespace": "imsOrgID",
"value": "5D7236525AA6D9580A495C6C@AdobeOrg"
}
],
"users": [
{
"key": "Data Privacy-1234",
"action": ["access"],
"userIDs": [
{
"namespace": "AAID",
"namespaceId", 10,
"type": "standard",
"description": "Legacy Visitor ID",
"value": "2D783E5885312539-4000010360000181",
}
]
},
{
"key": "Data Privacy-1235",
"action": ["access"],
"userIDs": [
{
"namespace": "ECID",
"namespaceId": 4,
"type": "standard",
"description": "This is the ID generated by the Adobe ID service.",
"value": "22470866493385587460528148368265592748",
}
]
},
{
"key": "Data Privacy-1236",
"action": ["access","delete"],
"userIDs": [
{
"namespace": "CRM-ID",
"type": "analytics",
"description": "namespace defined on eVar17 in some report suites",
"value": "ACME-12345678"
},
{
"namespace": "email address",
"type": "analytics",
"description": "namespace defined on eVar23 in some report suites",
"value": "john@mail.com"
}
]
}
],
"expandIds": true
}
Notice there are three blocks in the user’s section, representing three separate requests, presumably for three separate data subjects.
Keep in mind that
This sections contains details on access and delete responses.
Access Response Details
The data returned for an access request provides you, the data controller, with a URL you can use to download a ZIP file containing a directory for each Adobe product you own. Within the Analytics folder, there may be:
Person Files - Derived from hits containing a matched ID-PERSON label
Device Files - Derived from hits where one of the fields matched a specified ID-DEVICE but none matched a specified ID-PERSON
Each file combines data from all your report suites, automatically removing extra copies of replicated hits.
You can decide which of these to return to the data subject. Or you may extract some of this data and combine with data from other systems before returning it to the data subject.
Delete Response Details
No data is returned for delete requests - only a status to the Data Privacy API that the request was completed successfully.
Typically, Analytics customers will set up some test report suites to verify functionality before it is released to the general public. Pre-production websites or apps will send data into these test/dev/QA report suites to evaluate how things will work when the code releases before real traffic is sent to the production report suites.
However, with a normal configuration, GPDR request processing cannot be tested first on these test report suites, before applying requests to production report suites. The reason for this is that a Data Privacy request is automatically applied to all report suites in the Experience Cloud organization, which is often all report suites for your company.
There are a few ways that you can still test your Data Privacy processing prior to applying it to all your report suites:
One option is to set up a separate Experience Cloud organization that contains only test report suites. Then use this Experience Cloud organization for your Data Privacy testing and your normal Experience Cloud organization for actual Data Privacy processing.
Another option is to assign different namespaces to the IDs in your test report suites, versus those in your production report suites.
For example, you can prefix each namespace with “qa-” in your test report suites. When you submit Data Privacy requests with only namespaces with the qa prefix, these requests will only run against your test report suites. Later, when you submit requests without the qa prefix, they will apply to your production report suites. This is the recommended approach, unless you use the visitorId, AAID, ECID or customVisitorId namespaces, because these are hardcoded and you cannot specify alternate names for them in your test report suites.