Labeling best practices

Labeling needs to be reviewed each time a new report suite is created or when a new variable is enabled within an existing report suite. You may also need to review the labeling when new solution integrations are enabled, as they can expose new variables that may require labeling. A re-implementation of your mobile apps or websites may change the way that existing variables are used, which may also necessitate updates to labels.

The I1, I2, S1 and S2 labels have the same meanings as the correspondingly named DULE labels in Adobe Experience Platform. However, they are used for very different purposes. Within Adobe Analytics, these labels are used to help identify fields that should be anonymized as the result of a Privacy Service request. Within Adobe Experience Platform, they are used for access control, consent management and for enforcing marketing restrictions on labeled fields. Adobe Experience Platform supports many additional labels that are not used by Adobe Analytics. If you utilize the Analytics Data Connector to import your Adobe Analytics data into Adobe Experience Platform, you should make sure that any I1, I2, S1 and S2 labels that you have applied within Adobe Analytics are also applied to the schemas in Adobe Experience Platform that are used by the imported report suites.

Directly vs indirectly identifiable IDs

Before you can figure out which labels should be applied to which variables/fields, it is first necessary to understand the IDs that you are capturing in your Analytics data, and to decide which you will use for Data Privacy requests. Data Privacy expands the scope of what can be considered to be an ID. IDs fall into two broad classes: directly identifiable (identity label: I1) and indirectly identifiable (identity label: I2).

• A directly identifiable ID (I1): Either names the person or provides a direct method of contacting them. Examples would include someone’s name (even a common name like John Smith that may be shared by hundreds of people), any of their email addresses or phone numbers, etc. A mailing address without a name might be considered directly identifiable, even though it may only identify a household or business rather than a specific person within that household or business.
• An indirectly identifiable ID (I2): Does not allow identification of an individual by itself, but can be combined with other information (that may or may not be in your possession), to identify someone. Examples of an indirectly identifiable ID include a customer loyalty number, or an ID used by a company’s CRM system that is unique for each of their customers. Under Data Privacy, the anonymous IDs stored in the tracking cookies used by Analytics may be deemed to be indirectly identifying, even though they can only identify a device rather than an individual; on a shared device, these cookies cannot distinguish between different users of the system. For example, while the cookie cannot be used to find a computer containing the cookie, if someone has access to the computer and locates the cookie, they can then tie the Analytics cookie data back to the computer.

An IP address is also considered to be indirectly identifiable, because at any given moment it might only be assigned to a single device. However, ISPs can and often do change the IP addresses for most users regularly, so over time an IP address may have been used by any of their users. It is also not uncommon for many customers of an ISP or multiple employees within a business on the same intranet to share the same external IP address. Because of this, Adobe does not support using an IP address as the ID for a Data Privacy request. However, when an ID that we accept is used as part of a delete request, we will clear the IP addresses that occurred with that ID as well. You must decide if other collected IDs exist that may fall into this category, of I1 or I2, but are not suitable for use as a distinguishing ID for Data Privacy requests.

Even if your company collects many different IDs within your Analytics data, you may elect to use only a subset of these IDs for Data Privacy requests. Reasons for this might include:

• Within your own systems, you can map one of the IDs (for example, email address) to a different ID (such as CRM ID). Then, for consistency, you decide to only use the CRM ID for Data Privacy requests in your Data Privacy processing.
• You do not have a method of validating that someone is actually the person associated with the ID. For example, it can be very difficult to validate that an IP address was only ever used by a single person and that the person submitting the request is actually that person.
• Some IDs may correspond to multiple people and you do not want to risk returning information about one person to someone else with that same ID. For example, even if you can verify that someone’s name is John Smith, you may not want to return all data about all John Smiths in your system.
• Another example is a device ID, such as the Analytics Cookie ID. If the ID occurs on a cell phone app, you may decide that all interactions using that ID should be available to the owner of the cell phone. However, if it occurs on a shared device, such as a home computer or one in a library or internet cafe, you may decide that you cannot distinguish between users of that device and the risk of returning data for a different user is too great to allow using this type of ID.

Best Practices for IDs supported by Analytics

Use this table to determine the types of IDs that you will use when submitting Data Privacy requests to Analytics. Once you know this information, it will be easier to determine the other labels you should use for your variables.

Best Practices for setting Delete labels

The delete labels DEL-DEVICE and DEL-PERSON should be used sparingly. When applied to a variable that does not contain an ID that was used as part of the Data Privacy request, counts (metrics) in historical Analytics reports will almost always change.

• We recommend that one of these labels be applied to any variable that is labeled I1, I2 or S1. They cannot be applied to any variable that does is not labeled I1, I2 or S1.

• The DEL-labels will result in these variables being anonymized (the ID will be replaced with a random string prefixed with “Data Privacy-”). The same anonymized value will replace all instances of the original value in all hits that have been identified by an ID used in the request. If the original value in this field was one of those IDs, then report metrics will not change.

• Generally, if a field has the label ID-DEVICE, then you should also assign the label DEL-DEVICE.

• Similarly, if a field has the label ID-PERSON, then you should also assign the label DEL-PERSON.

• If a field does not have an ID-label, but does contain identifying information that you want anonymized, then the appropriate label (DEVICE or PERSON) depends on your implementation. If you only use cookie IDs for Data Privacy requests, then you should use DEL-DEVICE.

• If you use custom IDs on a different field with an ID-PERSON label, and you only want this cleared on rows where that ID occurs, then use DEL-PERSON.

• Note that if a DEL-DEVICE or DEL-PERSON label is specified on any variable that is not also used as an ID for that request (including an expanded ID), then unique values in that variable will only be anonymized on hits where a specified (or expanded) ID occurs. If other hits contain the same value, it will not be updated in those other locations. This can result in counts (metrics) changing.

  For example, if you have three hits containing the value “foo” in eVar7, but only one of them also contains an ID in a different variable that is matched for a delete, then “foo” on that hit will be modified to a value like “Data Privacy-123456789”, while it will remain unchanged in the other two hits. A report that shows the number of unique values for eVar7 will now show one more unique value than it did previously. A report that shows the top values for eVars may include “foo” with only two instances (rather than 3 previously), and the new value will show up as well, with a single instance.

Best Practices for setting Access labels

While very few fields will have any of the other labels, it will be common for a large number of fields to have ACC labels. The appropriate access labels will depend on the IDs you are using for Data Privacy requests.