蜜豆视频

Privacy request processing in Real-Time Customer Profile

蜜豆视频 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 Real-Time Customer Profile within 蜜豆视频 Experience Platform.

Getting started

This guide requires a working understanding of the following Platform components:

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 Real-Time Customer Profile using the Privacy Service API or UI. Before reading these sections, you should review, or be aware of, the Privacy Service API or Privacy Service UI documentation. These documents provide complete steps on how to submit a privacy job, including how to properly format submitted user identity 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. To delete the profile data associated with an identity, the array must include the value ProfileService. To delete the customer鈥檚 identity graph associations, the array must include the value identity.

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

Request

curl -X POST \
  https://platform.adobe.io/data/core/privacy/jobs \
  -H 'Authorization: Bearer {ACCESS_TOKEN}' \
  -H 'x-api-key: {API_KEY}' \
  -H 'x-gw-ims-org-id: {ORG_ID}' \
  -H 'Content-Type: application/json' \
  -d '{
    "companyContexts": [
      {
        "namespace": "imsOrgID",
        "value": "{ORG_ID}"
      }
    ],
    "users": [
      {
        "key": "user12345",
        "action": ["access","delete"],
        "userIDs": [
          {
            "namespace": "Email",
            "value": "ajones@acme.com",
            "type": "standard"
          },
          {
            "namespace": "Customer_ID",
            "value": "12345678",
            "type": "unregistered"
          }
        ]
      }
    ],
    "include": ["ProfileService","identity"],
    "expandIds": false,
    "priority": "normal",
    "regulation": "ccpa"
}'

Product response

For Profile Service, once the privacy job has been completed, a response is returned in JSON format with information regarding the user IDs requested.

{
    "privacyResponse": {
        "jobId": "7467850f-9698-11ed-8635-355435552164",
        "response": [
            {
                "sandbox": "prod",
                "mergePolicyId": "none",
                "result": {
                    "person": {
                        "gender": "female"
                    },
                    "personalEmail": {
                        "address": "ajones@acme.com",
                    },
                    "identityMap": {
                        "crmid": [
                            {
                                "id": "5b7db37a-bc7a-46a2-a63e-2cfe7e1cc068"
                            }
                        ]
                    }
                }
            },
            {
                "sandbox": "prod",
                "mergePolicyId": "none",
                "result": {
                    "person": {
                        "gender": "male"
                    },
                    "id": 12345678,
                    "identityMap": {
                        "crmid": [
                            {
                                "id": "e9d439f2-f5e4-4790-ad67-b13dbd89d52e"
                            }
                        ]
                    }
                }
            }
        ]
    }
}

Using the UI

When creating job requests in the UI, be sure to select AEP Data Lake and/or Profile under Products in order to process jobs for data stored in the data lake or Real-Time Customer Profile, respectively.

Profile fragments in privacy requests fragments

In the Profile data store, the personal data for an individual customer will often be comprised of multiple profile fragments, which are associated with the person through the identity graph. When making privacy requests to the Profile store, it is important to note that requests are only processed on the profile-fragment level, rather than the entire profile.

For example, consider a situation where you are storing customer attribute data in three separate datasets, which use different identifiers to associate that data with individual customers:

One of the datasets uses customer_id as its primary identifier, whereas the other two use email_id. If you were to send a privacy request (access or delete) using only email_id as the user ID value, only the firstName, lastName, and mlScore attributes would be processed, while address would not be affected.

To ensure that your privacy requests process all relevant customer attributes, you must provide the primary identity values for all applicable datasets where those attributes may be stored (up to a maximum of nine IDs per customer). See the section on identity fields in the basics of schema composition for more information on fields that are commonly marked as identities.

Delete request processing delete

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 records are then removed once the privacy job has completed.

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

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

Profile requests versus identity requests profile-v-identity

If a delete request is made for Profile (ProfileService) but not Identity Service (identity), the resulting job removes the collected attribute data for a customer (or set of customers) but does not remove the associations established in the identity graph.

For example, a delete request that uses a customer鈥檚 email_id and customer_id removes all attribute data stored under those IDs. However, any data which is thereafter ingested under the same customer_id will still be associated with the appropriate email_id, as the association still exists.

To remove the profile and all identity associations for a given customer, make sure to include both Profile and Identity Service as target products in your delete requests.

Merge policy limitations merge-policy-limitations

Privacy Service is only able to process Profile data using a merge policy that does not perform identity stitching. If you are using the UI to confirm whether your privacy requests are being processed, ensure that you are using a policy with None as its ID stitching type. In other words, you cannot use a merge policy where ID stitching is set to Private graph.

Next steps

By reading this document, you have been introduced to the important concepts involved with processing privacy requests in Experience Platform. To deepen your understanding of how to manage identity data and create privacy jobs, continue reading the documentation provided in this guide.

For information on processing privacy requests for Platform resources not used by Profile, see the document on privacy request processing in the data lake.