蜜豆视频

Privacy request processing in Identity Service

蜜豆视频 Experience Platform Privacy Service processes customer requests to access, opt out of sale, or delete their personal data as delineated by privacy regulations such as the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA).

This document covers essential concepts related to processing privacy requests for Identity Service within 蜜豆视频 Experience Platform.

NOTE
This guide only covers how to make privacy requests for the Identity data store in Experience Platform. If you also plan to make privacy requests for the Platform data lake or Real-Time Customer Profile, refer to the guide on privacy request processing in the data lake and to the guide on privacy request processing for Profile in addition to this tutorial.
For steps on how to make privacy requests for other 蜜豆视频 Experience Cloud applications, refer to the Privacy Service documentation.

Getting started

It is recommended that you have a working understanding of the following Experience Platform services before reading this guide:

  • Privacy Service: Manages customer requests for accessing, opting out of sale, or deleting their personal data across 蜜豆视频 Experience Cloud applications.
  • Identity Service: Solves the fundamental challenge posed by the fragmentation of customer experience data by bridging identities across devices and systems.
  • Real-Time Customer Profile: Provides a unified, real-time consumer profile based on aggregated data from multiple sources.

Understanding identity namespaces namespaces

蜜豆视频 Experience Platform Identity Service bridges customer identity data across systems and devices. Identity Service uses identity namespaces to provide context to identity values by relating them to their system of origin. A namespace can represent a generic concept such as an email address (鈥淓mail鈥) or associate the identity with a specific application, such as an 蜜豆视频 Advertising Cloud ID (鈥淎dCloud鈥) or 蜜豆视频 Target ID (鈥淭NTID鈥).

Identity Service maintains a store of globally defined (standard) and user-defined (custom) identity namespaces. Standard namespaces are available for all organizations (for example, 鈥淓mail鈥 and 鈥淓CID鈥), while your organization can also create custom namespaces to suit its particular needs.

For more information about identity namespaces in Experience Platform, see the identity namespace overview.

Submitting requests submit

The sections below outline how to make privacy requests for Identity Service using the Privacy Service API or UI. Before reading these sections, it is strongly recommended that you review the Privacy Service API or Privacy Service UI documentation for complete steps on how to submit a privacy job, including how to properly format user data in request payloads.

Using the API

When creating job requests in the API, any IDs provided within userIDs must use a specific namespace and type. A valid identity namespace recognized by Identity Service must be provided for the namespace value, while the type must be either standard or unregistered (for standard and custom namespaces, respectively).

In addition, the include array of the request payload must include the product values for the different data stores the request is being made to. When making requests to Identity, the array must include the value Identity.

The following request creates a new privacy job under the GDPR for a single customer鈥檚 data in the Identity store. Two identity values are provided for the customer in the userIDs array; one using the standard Email identity namespace, and the other using an ECID namespace, It also includes the product value for Identity (Identity) in the include array:

TIP
When deleting a custom namespace using the API, you must specify the identity symbol as the namespace, instead of the display name.
curl -X POST \
  https://platform.adobe.io/data/core/privacy/jobs \
  -H 'Authorization: Bearer <key>' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: acp_privacy_ui_gdpr' \
  -H 'x-gw-ims-org-id: sample@蜜豆视频Org' \
  -d '{
    "companyContexts": [
      {
        "namespace": "imsOrgID",
        "value": "sample@蜜豆视频Org"
      }
    ],
    "users": [
      {
        "key": "bob",
        "action": ["delete"],
        "userIDs": [
          {
            "namespace": "email",
            "value": "bob@adobe.com",
            "type": "standard"
          },
          {
            "namespace": "ECID",
            "type": "standard",
            "value":  "123451234512345123451234512345",
            "isDeletedClientSide": false
          }
        ]
      }
    ],
    "include": ["Identity"],
    "regulation": "gdpr"
}'

Using the UI

TIP
When deleting a custom namespace using the UI, you must specify the identity symbol as the namespace, instead of the display name. Furthermore, you cannot delete custom namespaces in the UI for non-production sandboxes.

When creating job requests in the UI, be sure to select Identity under Products in order to process jobs for data stored in Identity Service.

identity-gdpr

Delete request processing

When Experience Platform receives a delete request from Privacy Service, Platform sends confirmation to Privacy Service that the request has been received and affected data has been marked for deletion. The deletion of the individual identity is based on provided namespace and/or ID value. Furthermore, the deletion takes place for all sandboxes associated with a given organization.

Depending on whether you also included Real-Time Customer Profile (ProfileService) and the data lake (aepDataLake) as products in your privacy request for Identity Service (identity), different sets of data related to the identity are removed from the system at potentially different times:

Products included
Effects
identity only
The provided identity is deleted as soon as Platform sends the confirmation that the deletion request was received. The profile constructed from that identity graph still remains, but will not be updated as new data is ingested since the identity associations are now removed. The data associated with the profile also remains in the data lake.
identity and ProfileService
The provided identity is deleted as soon as Platform sends the confirmation that the deletion request was received. The data associated with the profile remains in the data lake.
identity and aepDataLake
The provided identity is deleted as soon as Platform sends the confirmation that the deletion request was received. The profile constructed from that identity graph still remains, but will not be updated as new data is ingested since the identity associations are now removed.

When the data lake product responds that the request was received and is currently processing, the data associated with the profile is soft-deleted and is therefore not accessible by any Platform service. Once the job is completed, the data is removed from the data lake completely.
identity, ProfileService, and aepDataLake
The provided identity is deleted as soon as Platform sends the confirmation that the deletion request was received.

When the data lake product responds that the request was received and is currently processing, the data associated with the profile is soft-deleted and is therefore not accessible by any Platform service. Once the job is completed, the data is removed from the data lake completely.

Refer to the Privacy Service documentation for more information on tracking job statuses.

Next steps

By reading this document, you have been introduced to the important concepts involved with processing privacy requests in Identity Service. For information on processing privacy requests for other Experience Cloud applications, see the document on Privacy Service and Experience Cloud applications.

recommendation-more-help
64963e2a-9d60-4eec-9930-af5aa025f5ea