Real-time Customer Profile中的隐私请求处理

Adobe Experience Platform Privacy Service会按照隐私法规(如《通用数据保护条例》(GDPR)和California Consumer Privacy Act (CCPA))的规定,处理客户访问、选择退出销售或删除其个人数据的请求。

本文档介绍与在Adobe Experience Platform中处理Real-time Customer Profile隐私请求相关的基本概念。

注意

本指南仅介绍如何在Experience Platform中对配置文件数据存储进行隐私请求。 如果您还计划为平台数据湖发出隐私请求,除本教程外,请参阅数据湖🔗中隐私请求处理指南。

有关如何为其他Adobe Experience Cloud应用程序发出隐私请求的步骤,请参阅Privacy Service文档

入门指南

在阅读本指南之前,建议您对以下Experience Platform服务有一定的了解:

  • Privacy Service:管理客户在Adobe Experience Cloud应用程序中访问、选择退出销售或删除其个人数据的请求。
  • Identity Service:通过跨设备和系统桥接身份,解决客户体验数据碎片化所带来的根本难题。
  • Real-time Customer Profile:根据来自多个来源的汇总数据提供统一的实时客户资料。

了解身份命名空间

Adobe Experience Platform Identity Service跨系统和设备桥接客户身份数据。 Identity Service 使用 份名称,通过将身份值与其原始系统相关联,来提供身份值的上下文。命名空间可以表示一个通用概念,如电子邮件地址(“电子邮件”),或将标识与特定应用程序(如Adobe Advertising Cloud ID(“AdCloud”)或Adobe Target ID(“TNTID”))相关联。

Identity Service维护全局定义(标准)和用户定义(自定义)身份命名空间的存储区。 标准命名空间适用于所有组织(例如,“电子邮件”和“ECID”),而您的组织也可以创建自定义命名空间以满足其特定需求。

有关Experience Platform中身份命名空间的更多信息,请参阅身份命名空间概述

提交请求

以下各节概述了如何使用Privacy Service API或UI向Real-time Customer Profile发出隐私请求。 在阅读这些部分之前,强烈建议您查看Privacy ServiceAPIPrivacy ServiceUI文档,以了解有关如何提交隐私作业的完整步骤,包括如何以请求负载正确设置提交的用户身份数据的格式。

重要

Privacy Service只能使用不执行身份拼合的合并策略处理Profile数据。 如果您使用UI确认是否正在处理隐私请求,请确保使用策略,其中“None”作为ID拼合类型。 换言之,您不能使用将ID拼合设置为“专用图”的合并策略。

另外,请务必注意,无法保证完成隐私请求所花费的时间。 如果在请求仍在处理时,Profile数据中发生更改,则无法保证是否处理了这些记录。

使用 API

在API中创建作业请求时,userIDs中提供的任何ID都必须使用特定的namespacetype。 必须为namespace值提供由Identity Service识别的有效标识命名空间,而type必须为standardunregistered(对于标准命名空间和自定义命名空间,分别为)。

注意

您可能需要为每个客户提供多个ID,具体取决于身份图以及Platform数据集中配置文件片段的分发方式。 有关更多信息,请参阅下一节配置文件片段

此外,请求有效负载的include数组必须包含请求所针对的不同数据存储的产品值。 向Data Lake发出请求时,阵列必须包含值“ProfileService”。

以下请求会为Profile存储中的单个客户数据创建新的隐私作业。 在userIDs数组中为客户提供了两个标识值;一个使用标准Email标识命名空间,另一个使用自定义Customer_ID命名空间。 它还包括include数组中Profile (ProfileService)的产品值:

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

使用UI

在UI中创建作业请求时,请务必在​产品​下选择​AEP Data Lake​和/或​配置文件,以便分别处理存储在Data Lake或Real-time Customer Profile中的数据的作业。


隐私请求中的配置文件片段

在Profile数据存储中,单个客户的个人数据通常由多个配置文件片段组成,这些片段通过身份图与人员关联。 在向Profile存储发出隐私请求时,请务必注意,请求仅在配置文件片段级别处理,而不是在整个配置文件级别处理。

例如,假设您将客户属性数据存储在三个单独的数据集中,这些数据集使用不同的标识符将该数据与各个客户关联:

数据集名称 主标识字段 存储的属性
数据集1 customer_id address
数据集2 email_id firstNamelastName
数据集3 email_id mlScore

其中一个数据集使用customer_id作为其主要标识符,而另两个数据集则使用email_id。 如果要仅使用email_id作为用户ID值发送隐私请求(访问或删除),则将仅处理firstNamelastNamemlScore属性,而address不会受到影响。

要确保您的隐私请求处理所有相关的客户属性,您必须为可能存储这些属性的所有适用数据集提供主标识值(每个客户最多9个ID)。 有关通常标记为身份的字段的更多信息,请参阅架构组合基础知识中有关标识字段的部分。

注意

如果您使用不同的沙盒来存储Profile数据,则必须对每个沙盒发出单独的隐私请求,并在x-sandbox-name标头中指示相应的沙盒名称。

删除请求处理

当Experience Platform收到来自Privacy Service的删除请求时,Platform向Privacy Service发送确认,确认该请求已被接收,且受影响的数据已被标记为删除。 隐私作业完成后,将从Data Lake或Profile存储中删除记录。 删除作业仍在处理,但数据会被软删除,因此任何Platform服务都无法访问。 有关跟踪作业状态的更多信息,请参阅Privacy Service 文档

重要

成功的删除请求会删除客户(或一组客户)收集的属性数据,但请求不会删除在身份图中建立的关联。

例如,使用客户email_idcustomer_id的删除请求会删除这些ID下存储的所有属性数据。 但是,随后在同一customer_id下摄取的任何数据仍将与相应的email_id关联,因为关联仍然存在。

在将来的版本中, Platform将在数据被实际删除后向Privacy Service发送确认。

后续步骤

阅读本文档后,您便了解了处理Experience Platform中的隐私请求所涉及的重要概念。 建议您继续阅读本指南中提供的文档,以加深对如何管理身份数据和创建隐私作业的了解。

有关处理Platform资源中Profile未使用的隐私请求的信息,请参阅数据湖🔗中有关隐私请求处理的文档。

在此页面上