Data Privacy Labels for Analytics Variables
Why label your data? why-label
Adobe’s customers, as the Data Controllers, are responsible for complying with applicable Data Privacy laws such as GDPR and 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.
- Cannot be set on events
- Cannot be set on Merchandising eVars
- Cannot be set on events
- Cannot be set on Merchandising eVars
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
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
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.
- Also requires I1 or I2 or S1 label
- Cannot be set on events
- Cannot be set on Merchandising eVars
- Cannot be set on Classifications
- You must submit requests using an ID-DEVICE or set expandIDs to true, or this label will never apply.
- Also requires I1 or I2 or S1 label
- Cannot be set on events
- Cannot be set on Merchandising eVars
- Cannot be set on Classifications
- You must submit requests using an ID-PERSON label set on some variable within this report suite and submit requests using that ID, or this label will never apply.
Data Privacy Identity labels
Also requires I1 or I2 label.
- Cannot be set on events
- Cannot be set on Merchandising eVars
- Cannot be set on Classifications
- Also requires I1 or I2 label.
- Cannot be set on events
- Cannot be set on Merchandising eVars
- Cannot be set on Classifications
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
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.
- Click Select Namespace and select one of the existing namespaces.
- Click Apply.
Define a new namespace
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.
-
Click Select Namespace and type in the namespace title.
-
Press Enter to add this namespace. Only now will the Apply button be activated.
-
Click Apply.
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.
- Custom Success Events
- Merchandising eVars
- Multi-valued variables (mvVars)
- Hierarchy variables
- S1/S2
- ACC-ALL, ACC-PERSON
- I1/I2
- ID-DEVICE, ID-PERSON
- DEL-DEVICE, DEL-PERSON
- I1/I2, S1/S2
- ACC-ALL, ACC-PERSON
- ID-DEVICE, ID-PERSON
- DEL-DEVICE, DEL-PERSON
- Traffic variables (props)
- Commerce variables (non-merchandising eVars)
- I1/I2, S1/S2
- ID-DEVICE, ID-PERSON
- DEL-DEVICE, DEL-PERSON)
Variables to which labels other than ACC-ALL/ACC-PERSON can be assigned/modified variables
- Conversion Dimensions
- Custom Traffic Dimensions
None / I1 / I2
None / S1 / S2
Activity Map Link,
Activity Map Page
None / I1 / I2
None / DEL-DEVICE / DEL-PERSON
Variables can contain URL parameters, which may include directly or indirectly identifiable data. If your implementation does not collect directly or indirectly identifiable data in these variables, then they do not need Identity or deletion labels.
Note that delete clears the URL parameters, but preserves the base URL.
ID-DEVICE/ID-PERSON
DEL-DEVICE/DEL-PERSON
You cannot remove the ID or DEL labels (set to None), but you can change them to be either the DEVICE or PERSON variants, depending on your custom ID implementation.
If you do not use the custom visitor ID, then the setting does not matter.
- Standard Dimensions
- Data Processing Dimensions
IP Address
IP Address 2
ClickMap Action (Legacy),
ClickMap Context (Legacy),
Page,
Page URL,
Original Entry Page URL,
Referrer,
Visit Start Page URL
None / I1 / I2
None / DEL-DEVICE / DEL-PERSON
Variables can contain URL parameters, which may include directly or indirectly identifiable data. If your implementation does not collect directly or indirectly identifiable data in these variables, then they do not need Identity or deletion labels.
Note that delete clears the URL parameters, but preserves the base URL.
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.
- Traffic Variables (props)
- Commerce Variables (eVars)
Existing value is replaced with a new value of the form “Data Privacy-356396D55C4F9C7AB3FBB2F2FA223482” where the 32-digit hexadecimal value after the “Data Privacy-” prefix is a cryptographically strong 128-bit pseudorandom number.
Because it is essentially being replaced by a random string, there is no way to determine the original value from this new value, and no way to derive the new value knowing the original value. For a given variable, if the identical value as that being replaced occurs within other hits that are also being deleted as part of the same Data Privacy request, all instances of that value will be replaced with the same new value.
If some instances of a value are replaced with one delete request, and a later request deletes other (new) instances of the original value, the new replacement value will be different than the original replacement value.
Existing value is replaced by a new value of the form “G-7588FCD8642718EC50” where the 18 hexadecimal digits after the “G-” prefix are the first 18 digits of a cryptographically strong 128-bit pseudorandom number. All comments that apply to deletion of traffic and commerce variables apply here as well.
The Purchase ID is a transaction ID whose main purpose is to make sure that a purchase is not credited twice, such as when someone refreshes their purchase confirmation page. The ID itself may tie the purchase to a row in your own DB where the purchase is recorded. In most cases it is not necessary to delete this ID, so it is not deleted by default.
If you are still able to tie the purchase back to a user after the Data Privacy delete request of your own data, then you may need to delete this field, so that the Analytics data for this visitor cannot be tied back to the purchaser.
- MCID
- Custom Visitor ID
- IP Address
- IP Address 2
- ClickMap Action (Legacy)
- ClickMap Context (Legacy)
- Page
- Page URL
- Original Entry Page URL
- Referrer
- Visit Start Page URL
- Latitude
- Longitude
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:
Zip Code
Geo Zip Code
Geo Latitude
Geo Longitude
Visitor ID
MCID / ECID
These IDs have a DEL-DEVICE label, but the DEL-PERSON label cannot be added. If you specify ID Expansion with each request, then these IDs will automatically be deleted for all delete requests, even those using an ID-PERSON.
If you do not use ID Expansion, but want these cookie IDs anonymized on hits that contain a matching ID in a prop or eVar, you can work around this labeling limitation by labeling the prop or eVar with an ID-DEVICE label, even if it really identifies a person (all DEL-PERSON labels would also need to be changed to DEL-DEVICE labels). In this case, because only some instances of the visitor ID or ECID are being anonymized, unique visitor counts will change in historical reporting.
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 HHSS (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.