Adobe® Experience Cloud

Adobe Analytics and GDPR

Contents

Adobe Analytics and GDPR....................................................................................3

Frequently Asked Questions..................................................................................5

Adobe Analytics GDPR Workflow...........................................................................9

View/Manage Report Suite's Data Governance Settings......................................................10

Label Report Suite Data........................................................................................................12

Submit Access and Delete Requests....................................................................................18

GDPR Labels for Analytics Variables...................................................................22

Namespaces...........................................................................................................32

ID Expansion..........................................................................................................35

Labeling Best Practices........................................................................................38

Labeling Example..................................................................................................43

GDPR and Data Connectors (Genesis)................................................................46

GDPR Terminology................................................................................................49

Contact and Legal Information.............................................................................52

Adobe Analytics and GDPRLast updated 1/22/2019

Adobe Analytics and GDPRThis document describes what you need to do in Adobe Analytics to support your data subjects' GDPR access anddelete rights.

Adobe Overview

Important: The contents of this document are not legal advice and are not meant to substitute for legal advice.Please consult your company's legal department for advice concerning GDPR.

On May 25, 2018, the European Union's General Data Protection Regulation (GDPR) goes into effect. For moreinformation about Adobe's response and what this means for you as an Adobe customer, see GDPR and YourBusiness.

When Adobe is providing software and services to an enterprise, Adobe is acting as a data processor for any personaldata it receives and stores on behalf of our customers, as part of providing the services. As a data processor, Adobeprocesses personal data in accordance with your company’s permission and instructions (for example, as set outin your agreement with Adobe).

As the data controller, you will determine the personal data that Adobe processes and stores on your behalf. If youuse Adobe Experience Cloud solutions, Adobe might host personal data for you depending on the solutions you useand the information you choose to send to your Adobe Experience Cloud account. For a list of examples, see AdobeExperience Cloud privacy.

How Adobe Handles GDPR Data

The Adobe Cloud Platform (ACP) provides an integrated solution that connects your brand's data governanceinfrastructure with the Adobe tools it uses to create and manage consumer experiences. The data governancefeatures of the Adobe Cloud Platform enable a direct linkage of data governance policy to data usage.

Familiarize yourself with how Adobe Analytics handles GDPR which discusses steps for GDPR readiness and howto integrate with the Adobe Experience Cloud GDPR API.

GDPR Readiness and your Adobe Analytics Data

Adobe realizes that you are most familiar with the custom data in your report suites and we are giving you theopportunity to define your data governance settings and preferences.

To that end, Adobe Analytics provides a Data Governance user interface that lets you, as the data controller, setprivacy labels on your Analytics reports suites and all the dimensions and metrics in those report suites.You canidentify the columns in your data set that contain directly identifiable data or indirectly identifiable data so that you

3Adobe Analytics and GDPR

can submit your access and delete requests to address that data. For each request, the labels defined in the AnalyticsData Governance user interface will be honored for the specific identifier that corresponds to that request.

See Label Report Suite Data for more information on how to set the labels.

Prerequisites

• Familiarize yourself with GDPR terminology.• Link your login company to an Experience Cloud organization, if it isn't already. Contact Adobe Customer Care

and refer to Organizations and account linking.• Map any Adobe Analytics report suite that you want to set up for data governance to your Experience Cloud

organization.• Set a data retention policy for each report suite so that GDPR Delete and Access requests can be honored.

Note: Adobe Analytics cannot assist you with processing requests to the GDPR API, i.e., processing accessor deletion requests you receive from your end users, if the data retention period has not been set in AdobeAnalytics. Please contact your Customer Success Manager in order to set your data retention period.

• Check your permissions: to use the Data Governance Management interface in Adobe Analytics, you must be anAdobe Analytics Administrator.

4Adobe Analytics and GDPR

Frequently Asked Questions

AnswerQuestion

When GDPR takes e ect, Adobe Analytics will support processingverified requests submitted by Data Controllers to the Experience Cloud

How will Adobe Analytics supportaccess and delete requests for end

1.

GDPR API to enable a more automated process. Adobe’s GDPR APIusers (data subjects) validated bycustomers (data controllers)? is designed to help process individual rights requests (e.g., access and

delete requests) for our customers’ data stored across Adobe ExperienceCloud solutions. It is flexible and scales according to the number of dataaccess and delete requests your company receives from data subjects.Also, the GDPR API allows the customer to check the status on howthe data access and delete requests are being fulfilled.

For more details see GDPR API documentation.

The Data Controller (i.e. The Adobe Customer) has the soleresponsibility for providing data subjects with personal data in response

Who will be responsible forreceiving, accepting, and fulfillingGDPR requests from end users?

2.

to an individual rights request under GDPR. The Data Controller alsohas the sole responsibility for receiving requests and accepting therequest – validating the data subject’s identity and then fulfilling therequest, part of which may involve contacting Adobe with data subjects’IDs that may be associated with data stored in Adobe Analytics. As theData Processor, Adobe must provide reasonable assistance to thecontroller to process verified requests within an acceptable amount oftime.

The data controllers will determine how to resolve identity for requestsfrom the data subjects. Consider deploying Adobe's GDPR ID Retrieval

How will Adobe Customers (datacontrollers) find out which GDPR

3.

Tag.Your development teams will save time by using our GDPR IDrequests map to which IDs inretrieval tag to capture user IDs (cookie IDs), and then using our GDPRAdobe Analytics for GDPR

processing? API to send those user IDs to the relevant solutions in the AdobeExperience Cloud for GDPR request processing.

The GDPR API can support a broad range of customer IDs acrossmultiple Adobe solutions. If a data subject submits a request along withan identifier (custom variable – prop or eVar), then Adobe Analytics willscan then entire retained history of the data collected for the givenidentifier.

For more details about how to configure custom IDs stored in Analyticsprops or eVars, please refer to the Analytics documentation onNamespaces.

Data Governance is a new tool within Adobe Analytics that providesdata controllers the ability to apply data controls and classifications

How can Adobe Analytics DataGovernance assist withprocessing GDPR requests?

4.

across their Analytics data. This new tool empowers Adobe customersto customize the processing of their GDPR data access and data delete

5Frequently Asked Questions

AnswerQuestion

requests. In the Data Governance console, admins can define thedesired settings that should be applied to various data columns thatreside in Adobe Analytics. Once those labels are defined, Adobe willhonor and process any downstream access or delete requests accordingto the customers’ desired label settings. It is the responsibility of thedata controller to review and council with their legal representativesregarding these label settings. Adobe Analytics encourages clients toset up data labeling correctly in advance of GDPR e ective date, whichis May 25th, 2018 to allow customize completion of request utilizingGDPR API.

The Data Governance tool contains the following data labels:

• Identity Data Labels: used to classify data that can identify an individualeither directly or in combination with other data. (None, I1, I2)

• Sensitive Data Labels: used to classify data as data that may bedefined as sensitive under applicable law. (None, S1, S2) Note thatcurrently the use of Sensitive Data in Adobe Analytics is generallyprohibited except for precise geo-location data properly obtained underapplicable law, which may be considered Sensitive Data in somejurisdictions.

• GDPR Data Labels: used to define the fields that may contain personalidentifiers for use in GDPR requests or that should be removed aspart of a GDPR delete request. These labels may overlap the Identityand Sensitive Data labels, in some cases.

For more information on Data Governance labels, see GDPR Labelsfor Analytics Variables.

For a step-by-step walkthrough to get ready for GDPR, see AdobeAnalytics GDPR Workflow.

Where do we get started on gettingGDPR ready with AdobeAnalytics?

5.

GDPR is a good opportunity to re-consider your consent managementstrategy and practices, including determining when consent is needed

How should data controllers thinkabout consent when it comes touser engagement?

6.

and thinking about the value proposition for the user. Consider the valueproposition for consumer privacy, which can help drive conversion andloyalty.

The consent management space (e.g., tools, standards, best practices)is rapidly evolving, and is an area to watch. To minimize impact on userengagement, controllers should work with vendors in this space andwith their counsel, and follow emerging EU laws and guidance onconsent and cookies. Thinking about “experiential privacy” by using anon-brand, contextually relevant experience that sets out the valueproposition of your data collection activities is a good strategy.

6Frequently Asked Questions

AnswerQuestion

GDPR generally provides that personal data generally should not beretained for longer than necessary to achieve the purpose for which itwas collected.

How should data controllers thinkabout data retention when itcomes to GDPR?

7.

As Adobe detailed in its customer communication in February 2018, weapplies a 25-month data retention plan to most customers unless otherarrangements have been made (subject to customer notification andauthorization). Customers will be required to set their data retentionpolicy before Adobe can process GDPR request.

Adobe Analytics requires customers to set their data retention to processtheir GDPR requests. Each report suite’s current data retention policyis displayed in the new Data Governance Admin UI. Customers shouldcontact their Adobe representative if they need to adjust their dataretention policies. Please refer to Adobe Analytics Data Retention FAQS.

Customers can request that their data be deleted sooner than 25 monthsby calling customer care. Customers can also extend data retention

Can a customer reduce or extendthe Default Data Retention Period?

8.

beyond 25 months by purchasing an extension. Extensions are availablein increments of 1 (one) additional year, up to a maximum of 8 (eight)additional years (for a total of 10 years). These extensions may requireupdated contract terms and additional fees.

If a customer uses Adobe Analytics Data Feeds to export data fromAnalytics into their enterprise data warehouse or into other systems

What privacy considerationsshould a data controller account

9.

outside of Adobe, it is the responsibility of the Customer (the Datafor when personal data is exportedfrom Adobe Analytics? Controller) to ensure that delete requests are applied to the data. This

also applies to on-premise implementations of Adobe Data Workbench(Insight), where an ongoing Adobe Analytics data feed is populating theData Workbench data. Adobe may provide tools to assist in finding anddeleting the records from certain types of data feeds, including thoseused for Data Workbench, but it is still the Customer’s (Data Controller's)responsibility to ensure that the data is deleted consistent with theirown, internal data retention and deletion policies.

Please also consider cases where employees may have downloadedAdobe Analytics reports that contain personal data.These reports mayneed to be updated or deleted if a GDPR or other privacy-related deleterequest is received involving an ID that may be present in the report.Customers should work with your company’s legal counsel to determineretention periods, and privacy and security requirements that shouldbe applied to these types of documents.

The GDPR API is provided to help you fulfill GDPR requests, which aretime sensitive. Using this API for other purposes is not supported by

Some data we were not supposedto collect was accidentally sent

10.

Adobe and may impact Adobe’s ability to provide timely turn-around ofinto Adobe Analytics. Can we use

7Frequently Asked Questions

AnswerQuestion

the GDPR API to clean up thisdata?

high priority, user-initiated GDPR requests for other Adobe customers.We ask that you do not use the GDPR API for other purposes such asclearing out data that was accidentally submitted across large groupsof visitors.

You should also be aware that any visitor who has a hit deleted (updatedor anonymized) as a result of a GDPR deletion request will have theirstate information reset.The next time the visitor returns to your website,they will be a new visitor. All eVar attribution will start again, as willinformation such as visit numbers, referrers, first page visited, etc. Thisside effect is undesirable for situations where you want to clear out datafields, and highlights one reason why the GDPR API is inappropriatefor this use.

Please contact your Account Manager (CSM) to coordinate with ourEngineering Architect consulting team to further review and providelevel of effort to remove any PII or data issues.

The GDPR API is provided to help you fulfill GDPR requests, which aretime sensitive. Using this API for other purposes is not supported by

Our legal team has determinedthat values we have been

11.

Adobe and may impact Adobe’s ability to provide timely turn-around ofcollecting in a variable for years,high priority, user-initiated GDPR requests for other Adobe customers.no longer comply with our updatedWe ask that you do not use the GDPR API for other purposes such asprivacy policy. Can we use theclearing out data that was accidentally submitted across large groupsof visitors.

GDPR API to clear out all valuesfrom this variable?

You should also be aware that any visitor who has a hit deleted (updatedor anonymized) as a result of a GDPR deletion request will have theirstate information reset.The next time the visitor returns to your website,they will be a new visitor. All eVar attribution will start again, as willinformation such as visit numbers, referrers, first page visited, etc. Thisside effect is undesirable for situations where you want to clear out datafields, and highlights one reason why the GDPR API is inappropriatefor this use.

Please contact your Account Manager (CSM) to coordinate with ourEngineering Architect consulting team to further review and providelevel of effort to remove any PII or data issues.

Additional GDPR Resources:

• GDPR Common Terms• Experience Cloud GDPR Care Package• Experiential Privacy Blog Post

8Frequently Asked Questions

Adobe Analytics GDPR Workflow

Welcome to Adobe Analytics and GDPR readiness! This workflow outlines the steps you need to take to make yourAdobe Analytics implementation ready to support your data subjects' GDPR access and delete rights.

Links to Instructions and More InformationTask DescriptionStep #

Refer to Map report suites to an organization.Ensure that any of your report suites thatmight contain GDPR-relevant data aremapped to your Experience Cloud (or IMS)organization.

GDPR requests are submitted using anExperience Cloud Organization and will beapplied to all report suites claimed by thatOrganization. Requests will not apply toreport suites not mapped to thatOrganization, even if they are part of yourlogin company.

A data retention policy needs to be in place in order forAdobe to service GDPR data access/delete requests.

Set your data retention policy.

For more information, see this Analytics Data RetentionFAQ.

Read these topics in this documentation set:Familiarize yourself with DULE/GDPRlabels, Adobe Analytics IDs, namespaces,and ID expansion.

• GDPR Labels for Analytics Variables

•

• Labeling Best Practices

Follow the instructions in Label Report Suite Data.Assign identity, sensitivity, and datagovernance labels to each variable in areport suite.

Note: Remember that Labelingneeds to be reviewed each time anew report suite is created or whennew variable is enabled within anexisting report suite.You may alsoneed to review the labeling when newsolution integrations are enabled, asthey can expose new variables thatmay require labeling. Are-implementation of your mobileapps or websites may change theway that existing variables are used,which may also necessitate updatesto labels.

9Adobe Analytics GDPR Workflow

Links to Instructions and More InformationTask DescriptionStep #

As an Adobe Analytics customer, you can submitindividual GDPR requests to access and delete customerdata, by calling the Adobe Experience Cloud GDPR API.

Connect to the Adobe GDPR API andsubmit Access and Delete Requests.

You can submit any Analytics identifiers (as described inthe section Labeling Best Practices) in the requests alongwith their respective namespace IDs (data source IDs).

Follow the instructions in View/Manage Report Suite'sData Governance Settings.

View and manage your report suite's GDPRsettings.

View/Manage Report Suite's Data Governance Settings

The Data Governance dialog in the Admin Tools provides an overview of which report suites have been configuredfor data governance, whether they have been mapped to an Experience Cloud organization, and whether a dataretention policy is in place for this report suite.

1. Log in to Adobe Experience Cloud.2. Navigate to Analytics > Admin > Data Governance.

You will see all the report suites that are part of your login company:

10Adobe Analytics GDPR Workflow

DescriptionSetting

The first line lists the friendly name of the report suite.The second line contains the internalname of the report suite. If you are allowed to set labels for a report suite, the first line willbe a clickable link that takes you to the labeling page.

Report Suites

OrganizationMapping

• Mapped: This report suite has already been mapped to the same Experience Cloudorganization as the Analytics login company that you are logged in to. Only report suitesthat have this setting can be labeled.

• Map Report Suite: Clicking this link will let you map a report suite to an Experience Cloudorganization.

This means you will be redirected to the Experience Cloud Organization – Report SuiteMapping Admin page where you have to find the report suite, and assign it to theappropriate organization. Once that is done, navigate back to this Data Governance UI.

• Mapped to Another Organization: Another Experience Cloud organization has alreadymapped this report suite to their organization.

The Analytics GDPR implementation requires that you have a data retention policy in place.Data RetentionPolicy

This setting shows whether

• a data retention policy is in place for this report suite, and• how long the data is retained by Adobe before it is deleted. The default data retention

period is 25 months.

Note: Adobe Analytics cannot assist you with processing requests to the GDPRAPI, i.e., processing access or deletion requests you receive from your end users,if the data retention period has not been set. Please contact your Customer SuccessManager in order to set your data retention period.

Grouping functionality is not currently implemented.Groups

Click the funnel icon to open or close the side bar.Left-hand side bar

The Organization Mapping section displays the number of report suites that fall into eachof the described categories.

The Data Retention Policy section displays each unique data retention policy currently inplace for your organization and the number of report suites that were assigned that retentionpolicy.

If you mark the checkbox next to one or more of the report suites, the Export to CSVoption displays. This option lets you download a CSV file containing all current labeldefinitions for all variables for all selected report suites.

Export to CSV

We recommend that your legal team review your labeling choices and this option facilitatesthis review. Instead of needing to perform the review while logged into the Data GovernanceUI, you can share the .CSV file with them.

11Adobe Analytics GDPR Workflow

DescriptionSetting

Label Report Suite Data

Labeling report suite data means that you assign identity, sensitivity, and data governance labels to each variablein a given report suite. Make sure you first familiarize yourself with the labels and their definitions.

• Assign or Edit Report Suite Labels• Copy Labels to Report Suite(s)

Note: Remember that Labeling needs to be reviewed each time a new report suite is created or when a newvariable is enabled within an existing report suite.You may also need to review the labeling when new solutionintegrations are enabled, as they can expose new variables that may require labeling. A re-implementation ofyour mobile apps or websites may change the way that existing variables are used, which may also necessitateupdates to labels.

Assign or Edit Report Suite Labels

Example:You, as the data controller, plan to collect email addresses and cookie IDs from data subjects to processtheir GDPR requests. These cookie IDs are stored in a report suite in Adobe Analytics. To create a label for emailaddresses and cookie IDs, you must use the Adobe Cloud Platform's Data Usage Labeling & Enforcement (DULE)framework in Analytics.

1. In Analytics, navigate to Admin > Data Governance > [select report suite].

12Adobe Analytics GDPR Workflow

2. Select which group of variables you want to label.

• Standard Dimensions (Adobe Analytics out-of-the-box dimensions)• Standard Metrics (Adobe Analytics out-of-the-box metrics)• Conversion Events (Custom success events)• Merchandising Conversion Dimensions (Merchandising eVars)• Conversion Dimensions (non-merchandising eVars)• Custom Traffic Dimensions (props)• Solution Dimensions and Events (Dimensions/events related to solutions such as Mobile, Video, Activity

Map, etc., and integrations with solutions such as Adobe Campaign, Adobe Experience Manager, AdvertisingCloud, etc.)

• Data Processing Dimensions (variables not exposed directly in reporting through the Adobe Analytics UI, butavailable to you through Data Feeds and/or Data Warehouse requests)

13Adobe Analytics GDPR Workflow

3. (Optional) Click the information (i) icon next to each variable to better understand its most common values overthe last 90 days. (This functionality is not available for Data Processing Dimensions, because they are not availablein the Analytics UI.)

4. Select one or more variables by clicking their checkbox, then select the Edit icon (to the right) to edit one or morevariable(s).

5. The Identity Data labels dialog opens automatically. These labels classify data that can be used by itself or incombination with other data to identify or enable direct contact with an individual. For more information on theseoptions, refer to Identity Data Labels (DULE).

Note: The Data Usage Labeling & Enforcement (DULE) Framework is designed to provide a uniform wayacross Solutions/Services/Platforms to capture, communicate, and use metadata about data across theAdobe Experience Cloud.The metadata helps data controllers indicate which data is personal information,which data is sensitive data, and what contract restrictions are associated with data.

14Adobe Analytics GDPR Workflow

6. Open the Sensitive Data section to set Sensitive Data Labels, which categorize geolocation data. For moreinformation on these options, refer to Sensitive Data Labels (DULE).

7. Open the GDPR Data section to set Data Governance Labels. Use this section to instruct Adobe how to handleeach variable for GDPR access and delete requests, as well for defining which variables should be scanned to

15Adobe Analytics GDPR Workflow

find data subject IDs for these requests. For more information on these options, refer to Data Governance Labels(GDPR).

8. Click Apply once you have completed all labeling.

Copy Labels to Report Suite(s)

If you want to apply the same DULE/GDPR settings to more than one report suite, you can follow these steps:

1. Select the variable group (Standard Dimensions, Conversion Dimensions, etc.) containing the variable you wantto copy. Note that you can only copy the labels for one group of variables at a time.

2. Select some or all of the variables in this group.3. Click Copy Labels to Report Suite(s) at the top right of the Data Governance dialog.

16Adobe Analytics GDPR Workflow

4. Either check Select All to copy labels for the selected variables to all report suites or select the individual reportsuites that you want to copy the labels to.

Important: Keep in mind that all report suites you select have to be mapped to your Experience Cloudorganization.

When you copy the labels for a variable or set of variables into a different report suite, the copy goes to thevariable in the corresponding position in the destination report suite. For Standard Dimensions, Standard Metrics,Solution Dimensions and Events and Data Processing Dimensions, the labels will be copied to the variable withthe same name in the destination report suite.

However, for Conversion Variables (eVars), Merchandising Conversion Dimensions and Custom Traffic Dimensions(props) the copy be will to the variable with the same number in the destination report suite. For example, eVar12will be copied into eVar12 in all destination report suites. The names of these variables will be ignored indetermining the target of the copy. If the corresponding variable is not enabled in the destination report suite, thecopy will fail for that variable.

When copying the labels for classifications defined for a variable, the labels will be copied to a classification onthe corresponding variable in the destination report suite (such eVar7 to eVar7) that has a name identical to theclassification being copied. Otherwise, the copy for that classification's labels will fail.

A status message is displayed after a set of labels has been applied. The status message will include the namesof any destination variables or classifications and their report suites for which the copy failed.

Important: You should always check the destination report suites to make sure that the labels copied overcorrectly. This is especially important for variables that have ID or DEL labels.

5. Click Apply.

17Adobe Analytics GDPR Workflow

Submit Access and Delete Requests

Note: This page describes functionality that will be available at a later date.

• Overview• Manage Consumer Consent• Validate Users and Their Data• Submit Requests• Sample JSON Request• Response Details• Testing GDPR Processing on Your Data

Overview

If your customers (consumers/data subjects) want to know what data you maintain about them or decide they wantto be deleted from your Analytics properties, you as the data controller are responsible for responding to thoserequests. The data controller determines how your organization will interact with data subjects (e.g., through a datasubject user portal) and manages interactions with the data subject. It also is the controller's responsibility to closethe loop with the data subject when the request is fulfilled. In other words, Adobe Experience Cloud, as the dataprocessor, will not accept requests directly from data subjects or return data directly to them. Rather, Adobe willreceive 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 supportingmaterials about data subjects' rights regarding their directly identifiable or indirectly identifiable data, and other datayou collect.

Manage Consumer Consent

You, as the data controller, are responsible for obtaining explicit consent from your data subjects before you collectdata about them (possibly including Adobe Analytics data) and for implementing an opt-out mechanism on your website. This lets your data subjects opt out of future Adobe Experience Cloud data collection.

Validate Users and Their Data

You, as the data controller, are responsible for verifying that the data subject is who they say they are and that theyhave a right to the data they are requesting. Further, it is your responsibility to ensure that the correct data is returnedto 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 GDPR access request before sending iton to the data subject. Particular care should be taken if you are using Person IDs, and returning not only data wherethat ID is present, but also data for other hits on a shared device where that ID was sometimes present (ID Expansion).

Each file combines data from all your report suites, automatically removing extra copies of replicated hits.You candecide which of these files to return to the data subject. Or you may extract some of this data and combine with datafrom other systems before returning it to the data subject.

Submit Requests

You can submit GDPR access and delete requests through our GDPR UI portal or via our GDPR API.

18Adobe Analytics GDPR Workflow

Note: The GDPR API supports batch submissions for multiple users in a single request.The currently supportedlimit is 1000 separate users (may have multiple IDs per user) in a single request JSON file.

Sample JSON Request

Here is the JSON that might be submitted through the GDPR API or UI, requesting GDPR processing for threeusers.

{ "companyContexts": [ { "namespace": "imsOrgID", "value": "5D7236525AA6D9580A495C6C@AdobeOrg" } ], "users": [ { "key": "GDPR-1234", "action": ["access"], "userIDs": [ { "namespace": "AAID", "namespaceId", 10, "type": "standard", "description": "Legacy Visitor ID", "value": "2D783E5885312539-4000010360000181", } ] }, { "key": "GDPR-1235", "action": ["access"], "userIDs": [ { "namespace": "ECID", "namespaceId": 4, "type": "standard", "description": "This is the ID generated by the Adobe ID service.", "value": "22470866493385587460528148368265592748", } ] }, { "key": "GDPR-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 threeseparate data subjects.

19Adobe Analytics GDPR Workflow

• The first request is an access request using a traditional Adobe Analytics cookie ID (AAID).• The second request is also an access request but is using an MCID/ECID cookie.• The third request is requesting both access and delete for the specified IDs. While ID Expansion is specified for

all of the requests, it will have the biggest impact on this third request, as it is the only one that uses non-cookieIDs. As a result, this request will also discover cookie IDs associated with any devices with the specified CRM-IDor email address, and expand the request to include those IDs as well.

Keep in mind that

• The value “5D7236525AA6D9580A495C6C@AdobeOrg” in the “companyContexts” section must be updated withthe value of your own Experience Cloud organization.

• The “type” and “namespace” fields are described in more detail in the Namespaces section.• The “description” fields are ignored.• The “key” fields can contain any value that you want. If you have an internal ID that you are using for tracking

GDPR requests, you could place that value here, to make it easier to match requests in Adobe’s system to thosein your own systems.

Response Details

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 aZIP 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

• A .CSV file with one row for every matching hit, and one column for every field with an ACC-ALL or ACC-PERSONlabel, sorted by timestamp.

• An HTML summary file with one entry for every ACC-ALL or ACC-PERSON label. Each entry lists all uniquevalues for that field and the number of times each occurred. Fields containing timestamps are rounded to specifyonly unique days.

• Device Files – Derived from hits where one of the fields matched a specified ID-DEVICE but none matched aspecified ID-PERSON

• A .CSV file with one row for every matching hit, and one column for every field with an ACC-ALL label, sorted bytimestamp.

• HTML summary file with one entry for every ACC-ALL label. Each entry will list all unique values for that field andthe number of times each occurred. Fields containing timestamps are rounded to specify only unique days.

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 withdata 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 GDPR API that the request was completed successfully.

Testing GDPR Processing on Your Data

Typically, Analytics customers will set up some test report suites to verify functionality before it is released to thegeneral public. Pre-production websites or apps will send data into these test/dev/QA report suites to evaluate howthings will work when the code releases before real traffic is sent to the production report suites.

20Adobe Analytics GDPR Workflow

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 GDPR request is automaticallyapplied 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 GDPR 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 usethis Experience Cloud organization for your GDPR testing and your normal Experience Cloud organization foractual GDPR processing.

• Another option is to assign different namespaces to the IDs in your test report suites, versus those in your productionreport suites.

For example, you can prefix each namespace with “qa-“ in your test report suites.When you submit GDPR requestswith only namespaces with the qa prefix, these requests will only run against your test report suites. Later, whenyou submit requests without the qa prefix, they will apply to your production report suites. This is the recommendedapproach, unless you use the visitorId, AAID, ECID or customVisitorId namespaces, because these arehardcoded and you cannot specify alternate names for them in your test report suites.

21Adobe Analytics GDPR Workflow

GDPR Labels for Analytics Variables• Why Label Your Data?• DULE Labels• Sensitive Data Labels (DULE)• Data Governance Labels (GDPR)• Provide a Namespace when Labeling a Variable as ID-DEVICE or ID-PERSON• Variable Types and the GDPR/DULE Labels they support• Variables to which Labels other than ACC-ALL/ACC-PERSON can be assigned/modified• Deletion Handling• Variables that Don’t Support the Expected Delete Labels• Date Fields for Access Requests

Why Label Your Data?

Many Adobe customers have legal teams that have reviewed the GDPR law and that have drawn their own conclusionsabout how data should be handled in order to conform with GDPR. The legal interpretations may differ acrosscompanies and the desired data handling settings may also differ across customers. Since customers have differingpreferences for GDPR data processing and differing data sets, Adobe is enabling Adobe customers, as the datacontroller, to customize their desired settings for GDPR data processing for their unique data. This allows eachunique customer to process GDPR requests in the way that makes most sense for their brand and their unique dataset.

Adobe Analytics provides tools for labeling data according to its sensitivity and contractual restrictions. Labels areimportant and useful for helping: (1) identify data subjects, (2) determine which data to return as part of an accessrequest, and (3) identify 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 IDsthat you are capturing in your Analytics data, and to decide which you will use for GDPR requests.

The Adobe Analytics GDPR implementation supports the following labels for identity data, sensitive data, and datagovernance.

DULE Labels

Note: The Data Usage Labeling & Enforcement (DULE) Framework is designed to provide a uniform wayacross all Adobe Solutions/Services/Platforms to capture, communicate, and use metadata about data acrossthe Adobe Experience Cloud.The metadata helps data controllers indicate which data is personal information,which data is sensitive data, and what contract restrictions are associated with data. In this initial release,Analytics is exposing only the DULE labels that are relevant to GDPR. As other Adobe products implementsupport for DULE labels, future releases will introduce additional sensitive data labels, as well as contractuallabels, which will help ensure that data shared between products is used only in legally permissible ways.

Identity Data Labels (DULE)

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

22GDPR Labels for Analytics Variables

Other RequirementsDefinitionLabel

Directly identifiable: Data that can specifically identify or enabledirect contact with an individual, such as a name or an emailaddress.

I1 • Cannot be set on events• Cannot be set on Merchandising eVars

Indirectly identifiable: Data that can be used in combinationwith any other data to identify or enable direct contact with anindividual or device.

I2 • Cannot be set on events• Cannot be set on Merchandising eVars

Does not allow identification of an individual by itself, but can becombined with other information (that may or may not be in yourpossession) to identify someone. Examples include a customerloyalty number, or an ID used by a company's CRM system thatis unique for each of their customers.

Sensitive Data Labels (DULE)

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

DefinitionLabel

Precise geo-location data related to latitude and longitude that can be used to determine the exactlocation of a device (within 100 meters or less).

S1

Geo-location data that can be used to determine a broadly defined geo-fence area.S2

Data Governance Labels (GDPR)

Data Governance labels provide users the ability to classify data that reflects privacy-related considerations andcontractual conditions to be compliant with regulations and corporate policies.

GDPR Access Labels

Other RequirementsDefinitionLabel

Select this option if this variable does not containdata that must be included in data returned to thedata subject as part of a GDPR access request.

None

Fields with this label will be returned forall GDPR requests.

Values in this field should be included in all GDPRaccess requests.

If this hit came from a device shared by multipleindividuals, by applying this label, you, as the data

ACC-ALL

controller, are indicating that it is acceptable to sharethe data in this field with any individual who hadaccess to the shared device.

23GDPR Labels for Analytics Variables

Other RequirementsDefinitionLabel

You must also have an ID-PERSON labelset on some variable within this report

Values in this field should be included only for GDPRaccess requests when we are reasonably certain

ACC-PERSON

suite, and submit requests using that ID,or this label will never apply.

that the hit was from the data subject, as determinedby a GDPR request ID matching an ID-PERSONfield’s value.

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

GDPR Delete Labels

Other RequirementsDefinitionLabel

A delete label is required only for fieldsthat contain a value that would allow a hit

Unlike the other labels, these Delete labels are notmutually exclusive.You can select either, both or

to be associated with the data subject (i.e.none. A separate None label is not necessary,that would allow identification of the datasubject).

because None is indicated simply by not checkingeither of the Delete options.

Other personal information (favorites,browsing/purchase history, healthconditions, etc.) does not need to bedeleted since the association with thedata subject will be severed.

For GDPR delete requests, values in this field shouldbe anonymized only for requests where a specifiedID-DEVICE is present in the hit.

DEL-DEVICE • Also requires I1 or I2 or S1 label• Cannot be set on events• Cannot be set on Merchandising eVars• Cannot be set on Classifications

If the same value occurs on other hits, which arenot being deleted, then those other instances will

• You must submit requests using anID-DEVICE or set expandIDs to true, orthis label will never apply.not be changed. This will result in the counts

changing for reports which compute unique countson this field. On shared devices, this may removeidentifiers for other individuals, beyond just the datasubject.

Counts do not change if this field also has anID-DEVICE label and the value in this field was usedas an ID for the GDPR request.

For GDPR delete requests, values in this field shouldbe anonymized only for requests where a specifiedID-PERSON is present in the hit.

DEL-PERSON • Also requires I1 or I2 or S1 label• Cannot be set on events• Cannot be set on Merchandising eVars• Cannot be set on Classifications

If the same value occurs on other hits, which arenot being deleted, then those other values will not

• You must also have an ID-PERSONlabel set on some variable within this

24GDPR Labels for Analytics Variables

Other RequirementsDefinitionLabel

report suite and submit requests usingthat ID, or this label will never apply.

be changed. This will result in the counts changingfor reports which compute unique counts on thisfield. Counts will not change if this field also has anID-PERSON label and the value in this field wasused as an ID for the GDPR request.

GDPR Identity Labels

Other RequirementsDefinitionLabel

You need to set one of these other labelsonly if this field contains an ID that you

This variable does not contain an ID that will be usedfor GDPR requests.

None

will use when submitting access or deleterequests through the GDPR API or UI.

This field contains an ID that can be used to identifya device for a GDPR request , but cannot distinguishbetween different users of a shared device.

ID-DEVICE • Also requires I1 or I2 label• Cannot be set on events• Cannot be set on Merchandising eVars• Cannot be set on Classifications

You do not need to specify this label for all variablesthat contain IDs (that is what the I1/I2 labels are for).Use this label if you submit GDPR requests usingIDs stored in this variable and want to search thisvariable for the specified ID.

This field contains an ID that can be used to identifyan authenticated user (a specific person) for aGDPR request.

ID-PERSON • Also requires I1 or I2 label• Cannot be set on events• Cannot be set on Merchandising eVars• Cannot be set on Classifications

You do not need to specify this label for all variablesthat contain IDs (that is what the I1/I2 labels are for).Use this label if you will submit GDPR requestsusing IDs stored in this variable and want to searchthis variable for the specified ID.

Provide a Namespace when Labeling a Variable as ID-DEVICE or ID-PERSON

When you label a variable as ID-DEVICE or ID-PERSON, you are prompted to provide a namespace.You can eitheruse 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, youcan select one of these existing namespaces.You should reuse the namespace if this variable contains the sametype of IDs as other variables that are already labeled with this namespace and you want to search all of them whensubmitting a request.

1. Click Select Namespace and select one of the existing namespaces.2. Click Apply.

25GDPR Labels for Analytics Variables

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.

1. Click Select Namespace and type in the namespace title.

2. Press Enter to add this namespace. Only now will the Apply button be activated.3. Click Apply.

The string you specify as the namespace is the same string you should use when submitting requests through theGDPR API as the value of the “namespace” parameter. The request will then cause Adobe Analytics to search allvariables 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 theI1/I2 labels are for). Use this label if you will be submitting GDPR requests using IDs stored in this variable and wantto search this variable for the specified ID. As an example, if eVar1 can contain an email address, and eVar2 cancontain a login user name, but you will only ever submit requests using the user name, then you might label eVar1as 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, somecustom 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 theeVar, then only the eVar requires an ID label and a namespace, as 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 thesame namespace and Adobe will search both variables for occurrences of the ID specified as part of a GDPR request

26GDPR Labels for Analytics Variables

with this namespace.You should still have DEL labels on all of these variables, so that the value is anonymized nomatter 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 thevalue from prop7 into eVar3. In this scenario, eVar3 will always contain the CRM ID if it is known, so only eVar3requires an ID-PERSON label.

Variable Types and the GDPR/DULE Labels they support

GDPR/DULE labeling affects four broad classes of Analytics variables. Not all variables support all labels.This tableshows which variables support or don't support which labels.

Unsupported LabelsSupported LabelsVariable Type

I1/I2S1/S2• Custom Success Events• Merchandising eVars

ID-DEVICE, ID-PERSONACC-ALL, ACC-PERSON• Multi-valued variables (mvVars)

DEL-DEVICE, DEL-PERSON• Hierarchy variables

ID-DEVICE, ID-PERSONI1/I2, S1/S2Classifications

DEL-DEVICE, DEL-PERSONACC-ALL, ACC-PERSON,

-All labels• Traffic variables (props)

• Commerce variables(non-merchandising eVars)

I1/I2, S1/S2ACC-ALL, ACC-PERSONMost other variables

(See table below for exceptions) ID-DEVICE, ID-PERSON

DEL-DEVICE, DEL-PERSON

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

CommentModifiable LabelsVariablesGroup

AllAll, except classificationsConversionDimensions

•

None / I1 / I2Classifications• Custom Traffic

DimensionsNone / S1 / S2

None / S1 / S2AllConversion Events

Variables can contain URLparameters, which may include directly

None / I1 / I2

None / DEL-DEVICE /DEL-PERSON

Activity Map Link,

Activity Map Page

Solution Dimensionsand Events

or indirectly identifiable data. If yourimplementation does not collectdirectly or indirectly identifiable data in

27GDPR Labels for Analytics Variables

CommentModifiable LabelsVariablesGroup

these variables, then they don’t needIdentity or deletion labels.

Note that delete clears the URLparameters, but preserves the baseURL.

You cannot remove the ID or DELlabels (set to None), but you can

ID-DEVICE/ID-PERSON

DEL-DEVICE/DEL-PERSON

Custom Visitor IDData ProcessingDimensions

change them to be either the DEVICEor PERSON variants, depending onyour custom ID implementation.

If you don’t use the custom visitor ID,then the setting does not matter.

You cannot remove the DEL label, butyou can change it to be either

DEL-DEVICE/DEL-PERSONIP Address

IP Address 2

• Standard Dimensions• Data Processing

Dimensions DEL-DEVICE or DEL-PERSON, orboth.

Variables can contain URLparameters, which may include directly

None / I1 / I2

None / DEL-DEVICE /DEL-PERSON

ClickMap Action(Legacy),

ClickMap Context(Legacy),

or indirectly identifiable data. If yourimplementation does not collectdirectly or indirectly identifiable data in

Page, these variables, then they don’t needIdentity or deletion labels.Page URL,

Note that delete clears the URLparameters, but preserves the baseURL.

Original Entry PageURL,

Referrer,

Visit Start Page URL

Deletion Handling

Adobe Analytics support for GDPR 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 GDPR deletion will matchthe same report run after deletion has been performed.This is accomplished by completely disassociating the deleteddata 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.

Deletion MethodVariables

Existing value is replaced with a new value of the form“GDPR-356396D55C4F9C7AB3FBB2F2FA223482” where the 32-digit hexadecimal

• Traffic Variables (props)

28GDPR Labels for Analytics Variables

Deletion MethodVariables

• Commerce Variables(eVars)

value after the “GDPR-“ prefix is a cryptographically strong 128-bit pseudorandomnumber. Because it is essentially being replaced by a random string, there is no wayto determine the original value from this new value, and no way to derive the newvalue knowing the original value.

For a given variable, if the identical value as that being replaced occurs within otherhits that are also being deleted as part of the same GDPR request, all instances ofthat value will be replaced with the same new value.

If some instances of a value are replaced with one delete request, and a later requestdeletes other (new) instances of the original value, the new replacement value willbe 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

Purchase ID

cryptographically strong 128-bit pseudorandom number. All comments that apply todeletion of traffic and commerce variables apply here as well.

The Purchase ID is a transaction ID whose main purpose is to make sure that apurchase is not credited twice, such as when someone refreshes their purchaseconfirmation page.The ID itself may tie the purchase to a row in your own DB wherethe purchase is recorded. In most cases it is not necessary to delete this ID, so it isnot deleted by default. If you are still able to tie the purchase back to a user after theGDPR delete request of your own data, then you may need to delete this field, sothat the Analytics data for this visitor cannot be tied back to the purchaser.

Value is a 128-bit integer and is replaced with a cryptographically strong 128-bitpseudorandom value.

Visitor ID

Value is cleared (set to either the empty string or 0 depending on the variable’s type).• MCID

• Custom Visitor ID

• IP Address

• IP Address 2

URL parameters are cleared/removed. If the value does not look like a URL, thenthe value is cleared (set to the empty string).

• ClickMap Action (Legacy)

• ClickMap Context (Legacy)

• Page

• Page URL

• Original Entry Page URL

• Referrer

• Visit Start Page URL

Precision is reduced to no better than 1 km.• Latitude

29GDPR Labels for Analytics Variables

Deletion MethodVariables

• Longitude

Variables that Don’t Support the Expected Delete Labels

This section intends to clarify information about Analytics variables that don’t support deletion. Sometimes, thesevariables get deleted by non-Analytics users (such as the legal team) who do not understand the type of datacontained in the variable and make incorrect assumptions based on the name of the variable. Here is a list of someof these variables and why they don’t require deletion, or why they don’t require a specific deletion label.

CommentsVariable

New visitor id is a Boolean that is true the first time we see a given visitor ID.There is no needto delete it once the visitor ID is anonymized. After anonymization, it will correspond to thefirst time we have seen this anonymized ID.

New Visitor ID

Zip codes are set only for hits originating in the USA. They are not set for hits coming fromthe EU. Even when set, they only provide a broad geographic area that makes re-identificationof the data subject difficult.

Zip Code

Geo Zip Code

These provide a rough location derived from the IP address.The accuracy is generally similarto that of a zip code, within a few dozen kilometers of the actual location.

Geo Latitude

Geo Longitude

The User Agent identifies the version of the browser that was used.User Agent

Specifies the Analytics report suite (as a number) containing the data.User ID

Specifies the name of the Analytics report suite containing the data.Report Suite ID

These have a DEL-DEVICE label, but the DEL-PERSON label cannot be added. If you specifyID Expansion with each request, then these IDs will automatically be deleted for all deleterequests, even those using an ID-PERSON.

Visitor ID

MCID / ECID

If you do not use ID Expansion, but want these cookie IDs anonymized on hits that contain amatching ID in a prop or eVar, you can work around this labeling limitation by labeling theprop or eVar with an ID-DEVICE label, even if it really identifies a person (all DEL-PERSONlabels would also need to be changed to DEL-DEVICE labels). In this case, since only someinstances of the visitor ID or ECID are being anonymized, unique visitor counts will changein historical reporting.

The Adobe Media Optimizer ID is a solution variable that has an unmodifiable DEL-DEVICElabel. It is populated from a cookie just as the Visitor ID and MCID are. It should be deleted

AMO ID

from hits whenever those other IDs are deleted. See the description for those variables formore details.

30GDPR Labels for Analytics Variables

Date Fields for Access Requests

There are five standard variables that contain timestamps:

DefinitionTime Stamp

The time that Adobe Analytics received the hit.Hit Time UTC

Time that the hit occurred, which for some mobile apps and other implementationsmay be earlier than the time it was received. For example, if a network connection

Custom Hit Time UTC

was not available when it occurred, the app may hold the hit and send it in when aconnection becomes available.

Same value as Custom Hit Time UTC, but in the time zone of the report suite, ratherthan GMT.

Date Time

The Custom Hit Time UTC value for the first hit received for the visitor ID value forthis hit.

First Hit Time GMT

The Custom Hit Time UTC value for the first hit received for the current visit for thisvisitor ID.

Visit Start Time UTC

The code for generating the files returned for GDPR access requests requires that at least one of the first threetimestamp variables be included in the access request (have an ACC label that applies to the type of request). Ifnone 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 GDPR access requests will convert the values in these fields from unix timestampsto date/time fields of the format YYYY-MM-DD HH:MM:SS (for example, 2018-05-01 13:49:22). In the summaryHTML file, these timestamp values will be truncated to only include the date, YYYY-MM-DD, to reduce the numberof unique values that occur for these fields.

31GDPR Labels for Analytics Variables

NamespacesEach ID that you want to be able to search for is assigned a namespace, which is a custom string that identifies thatID in any variable where it is used across all your report suites.

The namespace string is used to identify the field(s) that you want searched when providing an ID as part of a GDPRrequest. When a GDPR request is submitted, the request will include a JSON section specifying the data subjectIDs to use for the request. Multiple IDs can be included as part of a single request for a data subject. The JSONincludes:

• A "namespace" field containing the namespace string.• A "type" field that for most Adobe Analytics requests contains the value "analytics".• A "value" field containing the ID that Analytics should search for in the associated namespace variables from each

of your report suites.

Refer to the Experience Cloud GDPR API documentation for more details.

NotesCode SampleID Type

The value must be specified as two hexadecimalnumbers separate by a dash. All hexadecimal

Legacy Analytics Tracking Cookie, alsoknown as the Adobe Analytics ID (AAID):

{ namespace: "AAID",

Cookie ID

digits that are alphabetic characters must bespecified using upper case. The hexadecimal

type: "standard",values should not have any leading zeros (note value:

"2CCEEAE88503384F-1188000089CA"}

the difference from the same value specified inthe deprecated form, where the leading zeros arerequired).

It is also acceptable to use:

“namespaceId”: 10

instead of or in addition to

“namespace”: “AAID”

and you may see some other Adobe products usethat form.

Deprecated form:Legacy Analytics Tracking Cookie:Deprecated form

{

The value should be specified as two 16-digithexadecimal numbers or as two 19-digit decimalnumbers. The numbers should be separated by"namespace": "visitorId",

"type": "analytics", a dash, underscore or colon. Leading zeros should"value":

be added if either number doesn’t have enoughdigits.

"2cceeae88503384f-00001188000089ca"}

The value must be specified as a 38-digit decimalnumber. If you are pulling this number from the

Experience Cloud ID Service Cookie

{ namespace: "ECID", two mcvisid_high/low or post_msvisid_high/low type: "standard",

columns from a data feed or Data Warehouse value: "00497781304058976192356650736267671594"}

report, you must zero pad each of the two

32Namespaces

NotesCode SampleID Type

numbers to 19 digits and then concatenate themwith the high value first.

It is also acceptable to use:

“namespaceId”: 4

instead of or in addition to

“namespace”: “ECID”

and you may see some other Adobe products usethat form.

Note: The Experience Cloud ID (ECID) waspreviously known as the Marketing CloudID (MCID), and is still referred to by thatname in some existing documentation.

Note: These IDs are the only IDs supported by Analytics that use a "type" value other than"analytics".

If the format of the value portion of any of these cookie IDs does not follow the format describedfor that ID, then the GDPR request will fail, with an error of “Value not formatted correctly.”

You will most commonly collect these cookie IDs using the new privacy JavaScript, which willautomatically provide all of the relevant key/value pairs for these JSON IDs.

This JavaScript code populates the JSON with other key/value pairs besides those listed above(namespace, type, value), but the fields listed above are the most important for Analytics GDPRprocessing and the only ones you need to provide if you collect the IDs in some other way.

33Namespaces

NotesCode SampleID Type

The namespace is also predefined for the customvisitor ID.

{ namespace: "customVisitorID", type: "analytics", value: "<ID>"}

CustomVisitor ID

For IDs in custom traffic or conversion variables(props or eVars), you should label the variable

{ namespace: "Email Address", type: "analytics", value: "john@xyz.com"

IDs in CustomVariables

with an ID-DEVICE or ID-PERSON label and then},

assign your own namespace name to that type of{ namespace: "CRM ID", ID. See Provide a Namespace when Labeling a

Variable as ID-DEVICE or ID-PERSON. type: "analytics", value: "123456-ABCD"}

You can also see namespaces that you havepreviously defined for other variables or reportsuites and reuse one of those, so that the samenamespace can easily be used for all your reportsuites that store that type of ID. It is also possibleto assign the same namespace to multiplevariables within a report suite. For example, somecustomers store a CRM ID in a traffic variable anda conversion variable (depending on the page, itis sometimes in one or the other or both), and theycould assign the namespace "CRM ID" to bothvariables.

Note: You cannot use the friendly name ofa variable (the name displayed in thereporting UI) or the variable’s number (suchas eVar12) when specifying the namespaceto the GDPR API, unless this is also thenamespace you specified when applyingthe ID-DEVICE or ID-PERSON label to thisvariable. Using a namespace rather than afriendly name allows the same user identityblock to specify the correct variable formultiple report suites in these cases:

• The ID is in different eVars in some of thereport suites, or

• The friendly names don’t match (such aswhen the friendly name has been localizedfor a specific report suite)

For more information, see Provide a Namespace when Labeling a Variable as ID-DEVICE or ID-PERSON.

34Namespaces

ID ExpansionThe IDs you submit do not always cover all of the hit data that Analytics can associate with the data subject. Analyticscan create an expanded set of IDs to include this associated data into the GDPR requests.You can request thisoption with an optional parameter to each GDPR request you submit, added to the JSON request:"expandIds": true

See the Sample JSON Request for an example of how to include this option with the request. For more details, referto the GDPR API documentation.

ConsiderationsType

Many Analytics customers originally used the (Legacy) Analytics Cookie, but are now using theExperience Cloud ID Service (ECID), previously known as the Marketing Cloud ID Service

Cookie IDExpansion

(MCID). For their website visitors who first visited after the transition, only the ECID exists.However, for those who first visited when only the Legacy Cookie was available, but have sincevisited: some of their data will have both cookies, but the older data will only have the AnalyticsCookie, and in rare cases, the newest data may only have an ECID.

You want to make sure you find all the data for a visitor identified via an Analytics (Visitor ID)Cookie or ECID. Therefore, if you currently use the ECID and previously used the AnalyticsCookie, whenever you submit a request using either type of ID, you should include both IDs inthe request, or specify the expandIds option. When you specify expandIds, Adobe will check forother ECIDs or Analytics Cookies that corresponds to any cookie IDs you provide. The requestwill be automatically expanded to include these newly identified cookie IDs.

On e-commerce web sites, it is not uncommon for a visitor to browse around the site, add thingsto their cart and then start the checkout process before they log in to the site. If the ID used to

Custom ID toCookie IDExpansion identify users for a GDPR request is stored in a custom variable only when the user is logged

in, then this pre-login activity will not be associated with the ID. Utilizing the Analytics cookie ID,customers can choose to associate the browsing that was performed prior to login with thepurchase after login, since the cookie ID persists across the login.

Let's suppose your implementation stores a login ID (CRM ID, user name, loyalty number, emailaddress, etc., or a hash of any of these values) in a custom variable (prop or eVar) or customvisitor ID, and then uses this ID for a GDPR access request.The data subject might be surprisedthat info about all their browsing is not returned as part of an access request, especially if youhave promoted to them items viewed but not yet purchased.

Analytics GDPR processing therefore supports ID Expansion, where Analytics finds all cookieIDs that occur in the same hit as any custom ID and then expands the request to include thoseIDs as well.

When expandIDs is specified along with any namespace other than a cookie namespace, therequest will be expanded to include any cookie IDs (ECID or Analytics Cookie), found in hitscontaining any of the specified IDs. Cookie ID expansion, as described above, will then beperformed on any newly found cookie IDs.

When the expandIDs option is used for an access request and the specified ID has a label ofID-PERSON, then two sets of files will be returned.The first set (the person set) will contain data

35ID Expansion

ConsiderationsType

only from hits where the specified ID was found. The second set (the device set) will containdata only from hits from the expanded IDs, where the specified ID was not present.

During the first few months after GDPR went live, the vast majority of Analytics GDPR requests did not request IDexpansion, but determining the appropriate value for your organization is up to you.You should consult with yourlegal team about whether ID expansion is required for your data with the IDs that you use and the data you collectwithin Adobe Analytics. A primary consideration should be that on a shared device, from which multiple users havevisited your site, using ID expansion will include data from hits from other users of the device in data returned byaccess requests (in the device file). Even if you have followed best practices in labeling, such that no private datais included in the device file, such as pages visited, the device file will contain the number of pages visited and thetimes of each of those visits. Is it OK if you share this information with someone who may not have been the visitor?

For a delete request, where ID expansion is not used, if you use a non-cookie ID (any ID other than the ECID orAnalytics cookie) to identify hits that should be deleted, and that ID has an ID-DEVICE label, then unique visitorcounts in reports will change, because only some instances of the cookie IDs will be anonymized, while others willbe left unchanged. If you are not specifying ID expansion, then it is recommended that you either use a cookie IDfor requests, or use IDs with an ID-PERSON label.

When Adobe performs ID expansion, it can require an additional full data scan, which will increase the time that ittakes Adobe to complete the request, often adding a week to the processing time.

Other GDPR Request Flags

In addition to the “expandIDs” flag, Analytics supports two other flags that can be passed as part of a GDPR request.These flags with their default values are:

"analyticsDeleteMethod": "anonymize""priority": "normal"

In the future, the “analyticsDeleteMethod” may support a value of “purge” in addition to the default value of“anonymize”. When supported, it will cause the entire hit to be delete rather than simply updating the values of hitfields that have DEL labels.

In addition to its default value, the priority field also supports a value of “low”.You should specify this value forrequests that are not a result of a data subject request and thus do not have a legal requirement to be completedwithin 30 days. Note that Adobe discourages the use of the GDPR API for reasons other than data subject initiatedrequests. The GDPR API is not an appropriate tool for data cleansing or repairs and will have unintendedconsequences.

Important:

The GDPR API is intended to help you fulfill GDPR requests, which are time sensitive. Using this API for otherpurposes is not supported by Adobe and may impact Adobe’s ability to provide timely turn-around of highpriority, user-initiated GDPR requests for other Adobe customers. We ask that you do not use the GDPR APIfor other purposes such as clearing out data that was accidentally submitted across large groups of visitors.

Be aware that any visitor who has a hit deleted (updated or anonymized) as a result of a GDPR deletionrequest will have their state information reset. The next time the visitor returns to your website, they will be anew visitor. All eVar attribution will start again, as will information such as visit numbers, referrers, first pagevisited, etc. This side effect is undesirable for situations where you want to clear out data fields, and highlightsone reason why the GDPR API is inappropriate for this use.

36ID Expansion

Please contact your Adobe Account Manager (CSM) to coordinate with our Engineering Architect consultingteam to further review and provide level of effort to remove any PII or data issues.

37ID Expansion

Labeling Best Practices• Directly vs Indirectly Identifiable IDs• Best Practices for IDs Supported by Analytics• Best Practices for Setting Delete Labels• Best Practices for Setting Access Labels

Note: Remember that Labeling needs to be reviewed each time a new report suite is created or when newvariable is enabled within an existing report suite.You may also need to review the labeling when new solutionintegrations are enabled, as they can expose new variables that may require labeling. A re-implementation ofyour mobile apps or websites may change the way that existing variables are used, which may also necessitateupdates to labels.

Directly vs Indirectly Identifiable IDs

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

• A directly identifiable ID (I1): Either names the person or provides a direct method of contacting them. Exampleswould 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 directlyidentifiable, even though it may only identify a household or business rather than a specific person within thathousehold or business.

• An indirectly identifiable ID (I2): Does not allow identification of an individual by itself, but can be combined withother information (that may or may not be in your possession), to identify someone. Examples would include acustomer loyalty number, or an ID used by a company's CRM system that is unique for each of their customers.Under GDPR, the anonymous IDs stored in the tracking cookies used by Analytics may be deemed to be indirectlyidentifying, even though they can only identify a device rather than an individual; on a shared device, these cookiescannot distinguish between different users of the system. For example, while the cookie cannot be used to find acomputer containing the cookie, if someone has access to the computer and locates the cookie, they can then tiethe Analytics cookie data back to the computer.

An IP address is also considered to be indirectly identifiable, because at any given instance in time, it might onlybe 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 customersof an ISP or multiple employees within a business on the same intranet to share the same external IP address.Because of this, Adobe will not support using an IP address as the ID for a GDPR request. However, when an IDthat 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 there exist other IDs that you collect that may fall into this category, of I1 or I2, but not suitablefor use as a distinguishing ID for GDPR requests.

Even if your company collects many different IDs within your Analytics data, you may elect to use only a subset ofthese IDs for GDPR 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 CRMID). Then, for consistency, you decide to only use the CRM ID for GDPR requests in your GDPR 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 personsubmitting the request is actually that person.

38Labeling Best Practices

• Some IDs may correspond to multiple people and you don't want to risk returning information about one person tosomeone else with that same ID. For example, even if you can verify that someone's name is John Smith, you maynot 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 maydecide that all interactions using that ID should be available to the owner of the cell phone. However, if it occurson a shared device, such as a home computer or one in a library or internet cafe, you may decide that you cannotdistinguish between users of that device and the risk of returning data for a different user is too great to allow usingthis 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 GDPR requests to Analytics. Onceyou know this information, it will be easier to determine the other labels you should use for your variables.

RecommendationsID Type

These cookies identify a device or, more specifically, a browser for a user of a device.For a shared device where a common login is used, this ID could apply to any/all users

Cookie IDs

• (Legacy) AnalyticsCookie of the device. Adobe has created some unified JavaScript that you can place on your

website to collect these cookies if you want to allow them to be used for GDPR requests.• Experience Cloud IDService cookie (ECID),

Users of the Adobe Analytics Mobile SDK also have an Experience Cloud ID (ECID).There are API calls within the SDK to read this ID, so you can enhance your app to collectit for a GDPR request.

previously known asthe Marketing CloudID (MCID)

Many companies consider the browser cookie IDs to be shared device IDs. As a result,in consultation with their legal teams, they may elect not to support using them asacceptable IDs for GDPR requests, or they may elect to return only a very limited amountof data when these IDs are used or they may only accept them for delete requests.

These cookies have an ID-DEVICE label that cannot be changed (as well as I2 andDEL-DEVICE labels). The default Adobe Analytics configuration will return only genericinformation about the device, such as device type, OS, browser, etc. plus the time/datesthat your website was visited when using these IDs. However, if you choose to supportthese IDs for GDPR requests, as discussed below, you can add or remove ACC-ALLlabels to configure the exact set of fields you desire be returned for a GDPR accessrequest.

Especially if the report suite corresponds to a mobile app, and your mobile app requiresa login, you may decide that the Experience Cloud ID for the device does correspond toa specific user and you will therefore want to label more of the fields with the ACC-ALLlabel, including the names of pages visited, products viewed, etc.

Note: If you specify the “expandIds” option in your GDPR request, then yourrequests will always include Cookie IDs, in addition to any other IDs you specify.See ID Expansion for more details. In these instances, hits that have only a cookieID, but not another ID, will only return data labeled ACC-ALL as part of the accessrequest.

39Labeling Best Practices

RecommendationsID Type

Some customers place IDs in custom traffic variables (props) or custom conversionvariables (eVars). While the most common is a CRM ID, others include email addresses,user login names, customer loyalty numbers or hashes of these values .

IDs in Custom Variables

• If you want to use one of these IDs for GDPR requests, you should give the fieldcontaining it an ID-PERSON label.

• (Much less common) If an ID in one of these custom variables only identifies a devicethat may be shared by multiple people, then you can instead use an ID-DEVICE label.

• These fields also require I1 or I2 labels, and should include a DEL-PERSON orDEL-DEVICE label. Typically, the PERSON/DEVICE option of the DEL label will matchthe PERSON/DEVICE option of the ID label.

It is rare for a report suite to have more than one or two custom variables containing IDsthat you would want to use to identify data subjects for GDPR requests.You may havemultiple variables that are assigned I1 or I2 labels, but typically only one or two of thesewould also have ID-PERSON or ID-DEVICE labels.

Even though this is not widely used, Analytics also supports an implementation where acustom visitor ID can be provided, which if present is used in place of the Legacy AnalyticsTracking Cookie. This field has the labels I2, ID-PERSON and DEL-PERSON.

Custom Visitor ID

Many implementations derive this ID from a CRM ID so it is only present while someoneis logged into their site.This allows the same Custom Visitor ID to be used across devices.One technical drawback is that tracking that happens before the user logs in cannot betied to tracking collected after they are logged in. If, instead, you use the custom visitorID to simply identify a device, you should change the ID-PERSON and DEL- PERSONlabels to ID-DEVICE and DEL- DEVICE, respectively.

Best Practices for Setting Delete Labels

Note: Props are always case insensitive. eVars are case insensitive by default, but can be configured throughAdobe Customer Care to be case sensitive. If you have a case-sensitive eVar that contains an ID, it is yourresponsibility to use the proper case when submitting a GDPR request so that the case used in the requestmatches the case used in hits containing these IDs.

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

• We recommend that one of these labels be applied to any variable that is labeled I1, I2 or S1. They cannot beapplied 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 prefixedwith "GDPR-").The same anonymized value will replace all instances of the original value in all hits that have beenidentified by an ID used in the request. If the original value in this field was one of those IDs, then report metricswill 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.

40Labeling Best Practices

• If a field does not have an ID-label, but does contain identifying information that you want anonymized, then theappropriate label (DEVICE or PERSON) depends on your implementation. If you only use cookie IDs for GDPRrequests, 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 wherethat ID occurs, then use DEL-PERSON.

• If you are using ID expansion, and want all the value cleared for all hits on all identified devices then useDEL-DEVICE.You can apply both the DEL-DEVICE and DEL-PERSON labels in this case if you prefer, but theDEL-PERSON label is unnecessary, because the ID Expansion means that all rows that match a person ID willalso match a device ID.

• If you will not be specifying to use ID Expansion, but will use a mix of device and person IDs for different requests,then you may want to specify both DEL-DEVICE and DEL-PERSON labels for variables that should be deletedwhen either type of ID is used.

• Note that if a DEL-DEVICE or DEL-PERSON label is specified on any variable that is not also used as an ID forthat request (including an expanded ID), then unique values in that variable will only be anonymized on hits wherea specified (or expanded) ID occurs. If other hits contain the same value, it will not be updated in those otherlocations. 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 IDin a different variable that is matched for a delete, then “foo” on that hit will be modified to a value like“GDPR-123456789”, while it will remain unchanged in the other two hits. A report that shows the number of uniquevalues for eVar7 will now show one more unique value than it did previously. A report that shows the top valuesfor eVars may include “foo” with only two instances (rather than 3 previously), and the new value will show up aswell, 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 ACClabels. The appropriate access labels will depend on the IDs you are using for GDPR requests.

...use these RecommendationsIf you use...

If the only IDs you are using are cookie IDs or those with an ID-DEVICE label, then youshould only use the ACC-ALL label.

Device IDs Only

You will get one pair of files for each access request, one containing a row for eachmatching hit with all the specified ACC-ALL fields and a second containing a summaryof this data.

If you are only using custom IDs that have the ID-PERSON label and are not doing IDexpansion, then you should use ACC-PERSON labels. However, you do not need to

Person IDs with no IDExpansion

change the default ACC-ALL labels; these fields will automatically be included in theaccess request.

You will get one pair of files for each access request, one containing a row for eachmatching hit with all the specified ACC-DEVICE and ACC-PERSON fields and a secondcontaining a summary of this data.

If you include both device and person IDs in GDPR requests, or if you use custom IDs(custom visitor ID or an ID in a prop or eVar), then you need to pay attention to the ACC

Mixed IDs and/or IDExpansion

41Labeling Best Practices

...use these RecommendationsIf you use...

labels you use. Each access request will return two pairs of data files, one pair containingdata from hits which contained a matched person ID and a second containing data fromhits that did not match a person ID, but did match a device ID.

The "person ID" files contain data on all hits that matched the person IDs with all fieldsthat have either an ACC-PERSON or and ACC-ALL label (one file with all matched hitsand the other as a summary).

The "device ID" file pair contains only fields that have an ACC-ALL label and containsonly hits that did not contain any matching person ID. These files may contain datagenerated by other users of a shared device, so you will want to consider carefully theset of fields that contain the ACC-ALL label. The default labeling within Analytics onlyapplies this label to generic information fields related to the device (device type, OS,browser, etc.) plus the date/time of each hit.

You may elect to receive both the device and person file sets from Adobe and then onlyshare the person files, so as not to share data potentially generated by other users ofa shared device. Or you may wish to combine data from one or both sets with otherinformation that you know about the data subject and return it in your own format.

42Labeling Best Practices

Labeling Example• Sample Hit Data• Sample Access Request• Sample Delete Request

Sample Hit Data

Suppose you have the following hit data:

• The first row contains the labels for each variable.• The second row is the name of the variable. If it has an ID label, it contains the assigned namespace in parentheses.• Hit data starts in the third row.

I2

ID-DEVICE

DEL-DEVICE

ACC-ALL

I2

DEL-DEVICE

DEL-PERSON

ACC-ALL

I2

DEL-PERSON

ACC-PERSON

I2

ID-DEVICE

DEL-DEVICE

ACC-ALL

I2

ID-PERSON

DEL-PERSON

ACC-PERSON

Labels

MyEvar3MyEvar2MyEvar1Visitor ID

(AAID)

MyProp1

(user)

Variable Name

(Namespace) (xyz)

XMA77MaryHit Data

YNB88Mary

ZOC99Mary

WPD77John

UNE88John

VQF44John

XRG55John

ZNA66Alice

Sample Access Request

If I submit an access request, the summary file will contain the values indicated in the table below. A request mayreturn only a device file, only a person file or one of each.Two summary files are only returned if a person ID is usedand expandIds is true.

Data in Summary Access FileReturnedFile Type

API Values

MyEvar3MyEvar2MyEvar1Visitor IDMyProp1expandIDsNamespace/ID

X, WM, PVariable notpresent

77Variable notpresent

devicefalseAAID=77

X, WM, P77devicetrueAAID=77

X, Y, ZM, N, OA, B, C77, 88, 99Marypersonfalseuser=Mary

43Labeling Example

Data in Summary Access FileReturnedFile Type

API Values

X, Y, ZM, N, OA, B, C77, 88, 99Marypersontrueuser=Mary

U, WN, Pnot present77, 88not presentdevice

X, Y, ZM, N, OA, B, C77, 88, 99Marypersontrueuser=Mary

AAID=66 U, W, ZN, Pnot present66, 77, 88not presentdevice

XM, Rnot present55, 77not presentdevicefalsexyz=X

W, XM, P, Rnot present55, 77not presentdevicetruexyz=X

Notice that the setting for expandIDs does not make any difference to the output when a cookie ID is used.

Sample Delete RequestWith a delete request using the API values in the first row of the table, the hit table will be updated to look somethinglike this:

AAID=77

expandIDs value does not matter

MyEvar3MyEvar2MyEvar1AAIDMyProp1

GDPR-9152GDPR-7398A42Mary

YNB88Mary

ZOC99Mary

GDPR-8216GDPR-1866D42John

UNE88John

VQF44John

XRG55John

WNA66Alice

Note: Only cells on rows containing AAID = 77 and a DEL-DEVICE label are impacted.

user=Mary

expandIDs=false

MyEvar3MyEvar2MyEvar1AAIDMyProp1

XGDPR-3681GDPR-186677GDPR-0523

YGDPR-1975GDPR-217888GDPR-0523

ZGDPR-2864GDPR-904599GDPR-0523

WPD77John

UNE88John

VQF44John

44Labeling Example

user=Mary

expandIDs=false

XRG55John

WNA66Alice

Note: Only cells on rows containing user=Mary and a DEL-PERSON label are impacted. Also, in practice thevariable containing A_ID would probably be a prop or eVar and its replacement value would be a string startingwith “GDPR-“, followed by a random number (GUID), rather than replacing the numeric value with a different,random numeric value.

user=Mary

expandIDs=true

MyEvar3MyEvar2MyEvar1AAIDMyProp1

GDPR-9152GDPR-8183GDPR-085909GDPR-5782

GDPR-6821GDPR-2911GDPR-610416GDPR-5782

GDPR-4395GDPR-0219GDPR-271483GDPR-5782

GDPR-8216GDPR-8454D09John

GDPR-2930GDPR-2911E16John

VQF44John

XRG55John

WNA66Alice

Note:

• Cells on rows containing user=Mary and a DEL-DEVICE or DEL-PERSON label are impacted, as well ascells with a DEL-DEVICE label on rows containing any Visitor ID that occurred on a row containing user=Mary.

• MyEvar2 in the fourth and fifth rows is updated because these rows contain the same Visitor ID values asthose on the first and second rows, so ID expansion includes them for device-level deletes.

• The values of MyEvar2 in rows two and five match both before and after the delete, but after the delete nolonger matches the value N that occurs in the last row, because that row was not updated as part of thedelete request.

• MyEvar3 behaves very differently than it did without ID expansion, because without ID expansion, noID-DEVICES matched. Now AAID matches on the first five rows.

45Labeling Example

GDPR and Data Connectors (Genesis)This page lists all the Partner variables in the Data Connectors (previously known as Genesis) that could potentiallycontain data subjects' directly identifiable data or indirectly identifiable data.

This information lets you identify any directly identifiable data or indirectly identifiable data imported via our connectors,when they receive a GDPR request.

If you are using an integration of any of the below connectors, you can simply check which partnervariables/classifications in your integration may potentially contain directly identifiable data or indirectly identifiabledata.

Note: This information is provided to help you identify variables that must be labeled, but it is your responsibilityas the data controller to apply the appropriate labels or perform other actions for GDPR readiness (updatingclassifications, etc.).

TypeVariablesConnector Name

eVarVisitor IDAlset

ClassificationsApp Store Object ID -> App Store User

App Store Object ID -> Review Comment

appFigures

App Store Object ID -> Review Title

eVarRecipient IDAprimo Enterprise MarketingManagement

eVarVisitor IDCheetahMail

eVarRecipient IDContactLab 2.0

eVarRecipient IDDatran Media

eVarRecipient IDDelivra

eVarDialog Tech CallerDialog Tech

ClassificationsDialog Tech Caller -> City

Dialog Tech Caller -> First Name

Dialog Tech Caller -> Last Name

Dialog Tech Caller -> State

Dialog Tech Caller -> Street Address

Dialog Tech Caller -> Zip Code

eVarEmail eVarDREAMmail 2.0

46GDPR and Data Connectors (Genesis)

TypeVariablesConnector Name

ClassificationsTracking Code -> Source ID

Tracking Code -> Source Name

Dynamic Signal

Tracking Code -> User ID

Tracking Code -> User Name

eVarVisitor IDeDialog Precision Central

eVarRecipient IDEmarsys Xpress

eVarVisitor IDEmailvision CampaignCommander

ClassificationsMessage ID -> Mailing List Name

Message ID -> Manager ID

Message ID -> Manager Name

eVarEmail AddressEpsilon Harmony

eVarCustomer Key

eVarVisitor IDExact Target

eVarForesee Respondent IDForeSee (v2.0)

ClassificationsForesee Respondent ID -> variable name 1

...

Foresee Respondent ID -> variable name n

ClassificationsForeSee Response List -> Response

ForeSee Response List -> Survey > Question >Response

Foresee Feedback

eVarRecipient IDListrak

eVarEmail Recipient IDLyris HQ

eVarBroadlog IDNeolane - Enterprise MarketingPlatform

eVarRecipient IDoptivo broadmail

47GDPR and Data Connectors (Genesis)

TypeVariablesConnector Name

eVarVisitor IDResponsys

eVarVisitor IDResponsys 2.0

eVarCustomer ID

eVarRecipient IDSelligent

ClassificationsRecipient ID -> RecipientField1

Recipient ID -> RecipientField2

Recipient ID -> RecipientField3

Recipient ID -> RecipientField4

Recipient ID -> RecipientField5

eVarVisitor IDSilverpop Engage

eVarSilverpop IDSilverpop Engage (v2.0)

eVarEmail Address

eVarCustomer IDSynergy!360

eVarVisitor IDThinData EMS

eVarVisitor IDWhatCounts Email

eVarVisitor IDYesmail Enterprise

48GDPR and Data Connectors (Genesis)

GDPR Terminology

Binding Corporate Rules (BCRs) - a set of binding rules put in place to allow multinational companies andorganizations to transfer personal data that they control from the EU to their affiliates outside the EU (but within theorganization)

Biometric Data - any personal data relating to the physical, physiological, or behavioral characteristics of an individualwhich allows their unique identification

Consent - freely given, specific, informed and explicit consent by statement or action signifying agreement to theprocessing of their personal data

Data Concerning Health - any personal data related to the physical or mental health of an individual or the provisionof health services to them

Data Controller - the entity that determines the purposes, conditions and means of the processing of personal data

Data Erasure - also known as the Right to be Forgotten, it entitles the data subject to have the data controller erasehis/her personal data, cease further dissemination of the data, and potentially have third parties cease processingof the data

Data Portability - the requirement for controllers to provide the data subject with a copy of his or her data in a formatthat allows for easy use with another controller (more info here)

Data Processor - the entity that processes data on behalf of the Data Controller

Data Protection Authority - national authorities tasked with the protection of data and privacy as well as monitoringand enforcement of the data protection regulations within the Union

Data Protection Officer - an expert on data privacy who works independently to ensure that an entity is adheringto the policies and procedures set forth in the GDPR (more info here)

Data Subject - a natural person whose personal data is processed by a controller or processor

Delegated Acts - non-legislative acts enacted in order to supplement existing legislation and provide criteria orclarity

Derogation - an exemption from a law

Directive - a legislative act that sets out a goal that all EU countries must achieve through their own national laws

Encrypted Data - personal data that is protected through technological measures to ensure that the data is onlyaccessible/readable by those with specified access

Enterprise - any entity engaged in economic activity, regardless of legal form, including persons, partnerships,associations, etc.

Filing System - any specific set of personal data that is accessible according to specific criteria, or able to be queried

GDPR - the General Data Protection Regulation (GDPR) is a legal framework that sets guidelines for the collectionand processing of personal information of individuals within the European Union (EU). The GDPR sets out theprinciples for data management and the rights of the individual, while also imposing fines that can be revenue based.GDPR covers all companies that deal with the data of EU citizens, so it is a critical regulation for corporate complianceofficers at banks, insurers, and other financial companies. GDPR will come into effect across the EU on May 25,2018.

49GDPR Terminology

Genetic Data - data concerning the characteristics of an individual which are inherited or acquired which give uniqueinformation about the health or physiology of the individual

Group of Undertakings - a controlling undertaking and its controlled undertakings

Identity Management Services (IMS) - Adobe’s implementation of Federated ID and OAuth 2.0 for authenticationof Adobe ID users and authorization for Adobe resources.You must integrate IMS with your Adobe application orservice to enable your users to log in and access Adobe services. Users can log in directly with Renga (Adobe’sidentity services provider), or log in through a trusted third party authentication domain (such as Google, Facebook,or a corporate/organization LDAP).

Experience Cloud organization ID - refers to an Adobe authorization token for service-to-service authentication,which does not require user login. It is issued to an IMS client, and has no associated user. An IMS client needs aservice token to authorize back-channel requests between services. (The term “system token” is occasionally usedto mean service token.)

Main Establishment - the place within the Union that the main decisions surrounding data processing are made;with regard to the processor

Personal Data - any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectlyidentify the person

Personal Data Breach - a breach of security leading to the accidental or unlawful access to, destruction, misuse,etc. of personal data

Privacy by Design - a principle that calls for the inclusion of data protection from the onset of the designing ofsystems, rather than an addition

Privacy Impact Assessment - a tool used to identify and reduce the privacy risks of entities by analyzing thepersonal data that are processed and the policies in place to protect the data

Processing - any operation performed on personal data, whether or not by automated means, including collection,use, recording, etc.

Profiling - any automated processing of personal data intended to evaluate, analyze, or predict data subject behavior

Pseudonymisation - the processing of personal data such that it can no longer be attributed to a single data subjectwithout the use of additional data, so long as said additional data stays separate to ensure non-attribution

Recipient - entity to which the personal data are disclosed

Regulation - a binding legislative act that must be applied in its entirety across the Union

Representative - any person in the Union explicitly designated by the controller to be addressed by the supervisoryauthorities

Right to be Forgotten - also known as Data Erasure, it entitles the data subject to have the data controller erasehis/her personal data, cease further dissemination of the data, and potentially have third parties cease processingof the data

Right to Access - also known as Subject Access Right, it entitles the data subject to have access to and informationabout the personal data that a controller has concerning them

Subject Access Right - also known as the Right to Access, it entitles the data subject to have access to andinformation about the personal data that a controller has concerning them

Supervisory Authority - a public authority which is established by a member state in accordance with article 46

50GDPR Terminology

Trilogues - informal negotiations between the European Commission, the European Parliament, and the Councilof the European Union usually held following the first readings of proposed legislation in order to more quickly agreeto a compromise text to be adopted.

51GDPR Terminology

Contact and Legal InformationInformation to help you contact Adobe and to understand the issues concerning your use of this product anddocumentation.

Help & Technical Support

The Adobe Experience Cloud Customer Care team is here to assist you and provides a number of mechanisms bywhich they can be engaged:

• Check the Experience Cloud help pages for advice, tips, and FAQs• Ask us a quick question on Twitter @AdobeExpCare• Log an incident in our customer portal• Contact the Customer Care team directly• Check availability and status of Experience Cloud Solutions

Service, Capability & Billing

Dependent on your solution configuration, some options described in this documentation might not be available toyou. As each account is unique, please refer to your contract for pricing, due dates, terms, and conditions. If youwould like to add to or otherwise change your service level, or if you have questions regarding your current level,please contact your Account Manager.

Feedback

We welcome any suggestions or feedback regarding this solution. Enhancement ideas and suggestions can beadded to our Customer Idea Exchange.

Legal

© 2019 Adobe Systems Incorporated. All Rights Reserved.Published by Adobe Systems Incorporated.

Terms of Use | Privacy Center

Adobe and the Adobe logo are either registered trademarks or trademarks of Adobe Systems Incorporated in theUnited States and/or other countries. A trademark symbol (®, ™, etc.) denotes an Adobe trademark.

All third-party trademarks are the property of their respective owners. Updated Information/Additional Third PartyCode Information available at http://www.adobe.com/go/thirdparty.

52Contact and Legal Information