Data Privacy Labels for Analytics Variables

Adobe’s customers, as the Data Controllers, are responsible for complying with applicable Data Privacy laws such as General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA). Customers should consult with their own legal teams to determine how their data should be handled to comply with Data Privacy laws. Adobe understands that each of its customers has unique needs related to privacy, which is why Adobe enables its customers to customize their desired settings for Data Privacy data processing. This allows each unique customer to process Data Privacy requests in the way that makes most sense for their brand and their unique data set.

Adobe Analytics provides tools for labeling data according to its sensitivity and contractual restrictions. Labels are an important step for: (1) identifying Data Subjects, (2) determining which data to return as part of an access request, and (3) identifying data fields that must be deleted as part of a deletion request.

Before you can figure out which labels should be applied to which variables/fields, you need to understand the IDs that you are capturing in your Analytics data, and to decide which you will use for Data Privacy requests.

The Adobe Analytics Data Privacy implementation supports the following labels for identity data, sensitive data, and data governance.

Identity data labels identity-data-labels

Identity data “I” labels are used to categorize data that can identify or contact a specific person.

Sensitive data labels sensitive-data-labels

Sensitive data “S” labels are used to categorize sensitive data such as geographic data. Additional Sensitive Data labels will be introduced in the future to identify other types of sensitive information.

Data Governance labels (Data Privacy) data-governance-labels

Data Governance labels provide users the ability to classify data that reflects privacy-related considerations and contractual conditions to help Adobe’s customers remain compliant with regulations and corporate policies.

Data Privacy Access labels access

While few variables will receive any of the other labels, it is expected that access labels will be applied to many of your variables. However, it is up to you, in consultation with your Legal team, to decide which data you have collected should be shared with Data Subjects.

Data Privacy Delete labels delete

Unlike the other labels, these Delete labels are not mutually exclusive. You can select either, both or none. A separate None label is not necessary, because None is indicated simply by not checking either of the Delete options.

A Delete label is required only for fields that contain a value that would allow a hit to be associated with the Data Subject (i.e. that would allow identification of the Data Subject). Other personal information (favorites, browsing/purchase history, health conditions, etc.) does not need to be deleted since the association with the Data Subject will be severed.

Data Privacy Identity labels identity

Provide a namespace when labeling a variable as ID-DEVICE or ID-PERSON provide-namespace

When you label a variable as ID-DEVICE or ID-PERSON, you are prompted to provide a namespace. You can either use a previously defined namespace or define a new one.

Use a previously defined namespace previously-defined

If you have previously assigned an ID label to other variables in any of the report suites in your login company, you can select one of these existing namespaces. You should reuse the namespace if this variable contains the same type of IDs as other variables that are already labeled with this namespace and you want to search all of them when submitting a request.

Define a new namespace define

You can also define a new namespace. We recommend that namespace strings be limited to alphanumeric characters, plus the characters underscore, dash and space. They will be converted to all lower case.

The string you specify as the namespace is the same string you should use when submitting requests through the Data Privacy API as the value of the “namespace” parameter. The request then causes Adobe Analytics to search all variables in all of your report suites that share this namespace for the ID you specified with the request.

You do not need to specify the ID-DEVICE or ID-PERSON labels on all variables that contain IDs (that is what the I1/I2 labels are for). Use this label if you will be submitting Data Privacy requests using IDs stored in this variable and want to search this variable for the specified ID. As an example, if eVar1 can contain an email address, and eVar2 can contain a login user name, but you will only ever submit requests using the user name, then you might label eVar1 as I1, ACC-PERSON, DEL-PERSON, but eVar2 as I2, ACC-PERSON, DEL-PERSON, ID-PERSON with namespace “user name”. You can then submit a request with a user section JSON block such as:

{
     "namespace": "user name",
     "type": "analytics",
     "value": "rocketman123"
}

It is acceptable to use the same namespace for different variables within the same report suite. For example, some custom implementations store a CRM-ID in both a prop and an eVar. If the CRM-ID always occurs in one of them (such as the eVar), and only occasionally occurs in the other (the prop), and never in the prop when not also in the eVar, then only the eVar requires an ID label and a namespace because Adobe can search only in that eVar for the ID. If, however, the CRM-ID sometimes occurs in one variable and sometimes in the other, then both should have the same namespace and Adobe will search both variables for occurrences of the ID specified as part of a Data Privacy request with this namespace. You should still have DEL labels on all of these variables, so that the value is anonymized no matter where it occurs.

As another example, you might have a CRM ID that is sometimes sent in via eVar1 and sometimes sent in via prop7. You then have a processing rule that copies the value from eVar1, if it exists, into eVar3. Otherwise, it copies the value from prop7 into eVar3. In this scenario, eVar3 will always contain the CRM ID if it is known, so only eVar3 requires an ID-PERSON label.

Variable types and the Data Privacy labels they support variable-types

Data Privacy labeling affects four broad classes of Analytics variables. Not all variables support all labels. This table shows which variables support or do not support which labels.

Variables to which labels other than ACC-ALL/ACC-PERSON can be assigned/modified variables

Deletion handling deletion

Adobe Analytics support for Data Privacy deletion requests is designed to minimize impacts to reporting. In most cases, the metrics displayed in reports should not change. A historical report that was run before Data Privacy deletion will match the same report run after deletion has been performed. 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.

The following table describes how various variables are “deleted”. This is not a complete list.

Variables that may not support the expected Delete labels no-delete-support

This section intends to clarify information about Analytics variables that may not support deletion. Sometimes, these variables get deleted by non-Analytics users (such as the legal team) who do not understand the type of data contained in the variable and make assumptions based on the name of the variable.

It is important to understand what type of data is contained in each variable prior to making a decision about labeling or deletion, and not to rely on variable name alone. Here is a list of some of these variables and why they may not require deletion, or why they may not require a specific deletion label:

Date fields for access requests access-requests

There are five standard variables that contain timestamps:

The code for generating the files returned for Data Privacy access requests requires that at least one of the first three timestamp variables be included in the access request (have an ACC label that applies to the type of request). If none of these are included, then Custom Hit Time UTC will be treated as if it has an ACC-ALL label.

The hit-level CSV file returned for Data Privacy access requests will convert the values in these fields from unix timestamps to date/time fields of the format YYYY-MM-DD HH:MM:SS (for example, 2018-05-01 13:49:22). In the summary HTML file, these timestamp values will be truncated to only include the date, YYYY-MM-DD, to reduce the number of unique values that occur for these fields.