提交访问和删除请求

如果您的客户（用户/数据主体）希望知道您保留了哪些与他们有关的数据或决定要从您的 Analytics 属性中删除这些数据，您作为数据控制者有责任回应这些请求。数据控制者确定您的组织与数据主体交互的方式（例如，通过数据主体用户门户），并负责管理与数据主体的交互。数据控制者还负责在请求得到满足后，关闭数据主体的循环。换句话说，Adobe Experience Cloud 作为数据处理者，将不会直接从数据主体接收请求或将数据直接返回给他们。Adobe 将从您（作为数据控制者）那里接收请求，并将数据只返回给您。

您可能还需要确保您的移动设备应用程序和网站具有与数据主体权利相关的弹出通知和支持材料，内容涉及可直接或间接识别他们的数据以及您收集的其他数据。

管理用户同意

作为数据控制者，您有责任在收集与数据主体相关的数据（可能包括 Adobe Analytics 数据）之前获得他们的明确同意，并且有责任在您的网站上实施选择退出机制。该机制允许您的数据主体退出以后的 Adobe Experience Cloud 数据收集。

验证用户及其数据

作为数据控制者，您有责任验证自称是数据主体的用户的真实身份，并且他们有权访问所请求的数据。另外，您还有责任确保将正确的数据返回给数据主体，并且他们不会意外收到有关其他数据主体的数据。

这包括先审查由 Adobe Analytics 在数据隐私访问请求中返回的数据，然后再将这些数据发送给数据主体。如果您使用人员 ID，并且返回的不仅有存在此 ID 的数据，还有共享设备上有时会存在此 ID 的其他点击数据，此时应当特别注意。请参阅 ID 扩展。

每个文件均会合并来自所有报表包的数据，并自动删除额外的重复命中项。您可以确定要将其中的哪些文件返回给数据主体。或者，您可以提取其中的部分数据，并与来自其他系统的数据合并，然后再将它们返回给数据主体。

提交请求

您可以通过我们的 Privacy Service UI 或 Privacy Service API 提交数据隐私访问和删除请求。

注意

数据隐私 API 支持在一个请求中批量提交多个用户。当前支持的限制是：允许单个请求 JSON 文件中有 1000 个独立用户（每个用户可以有多个 ID）。

JSON 请求示例

以下是可能通过数据隐私 API 或用户界面提交的 JSON，请求为三位用户进行数据隐私处理。

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

请注意，“user”部分有三个数据块，代表三个单独的请求，可能是三个独立的数据主体。

  • 第一个请求是使用传统 Adobe Analytics Cookie ID (AAID) 的访问请求。
  • 第二个请求也是访问请求，但是它是使用 MCID/ECID Cookie 的访问请求。
  • 第三个请求是针对指定 ID 提出的访问和删除请求。虽然为所有请求指定了 ID 扩展，但这对第三个请求的影响最大，因为它是唯一使用非 Cookie ID 的请求。因此，该请求还要找到与使用此指定 CRM-ID 或电子邮件地址的任何设备关联的 Cookie ID，并扩展请求以包括这些 ID。

请记住以下事项

  • 必须使用您的 Experience Cloud 组织的值来更新“companyContexts”部分的“5D7236525AA6D9580A495C6C@AdobeOrg”值。
  • “type”和“namespace”字段在命名空间部分有更多详细介绍。
  • “description”字段被忽略。
  • “key”字段可以包含您想要的任何值。如果您有用于跟踪数据隐私请求的内部 ID，则可以将该值添加到此处，以便更轻松地将 Adobe 系统中的请求与自己系统中的请求进行匹配。

响应详情

本节包含关于访问和删除响应的详细信息。

访问响应详情

针对访问请求而返回的数据将为您（数据控制者）提供一个 URL，您可以借助此 URL 下载一个 ZIP 文件，其中包含您拥有的每个 Adobe 产品的目录。在 Analytics 文件夹内，可能存在：

  • 人员文件 — 从包含匹配的 ID-PERSON 标签的命中项派生

    • CSV 文件 — 每个匹配的命中项在该文件中都有一个对应的行，每个具有 ACC-ALL 或 ACC-PERSON 标签的字段都有一个对应的列，它们按时间戳排序。
    • HTML 摘要文件 — 每个 ACC-ALL 或 ACC-PERSON 标签都有一个对应的条目。每个条目会列出该字段的所有唯一值以及每个值出现的次数。包含时间戳的字段将进行四舍五入，以指定唯一的日期。

  • 设备文件 — 从命中项派生，这些命中项当中的一个字段与指定的 ID-DEVICE 匹配，但没有任何字段与指定的 ID-PERSON 匹配

    • CSV 文件 — 每个匹配的命中项在该文件中都有一个对应的行，每个具有 ACC-ALL 标签的字段都有一个对应的列，它们按时间戳排序。
    • HTML 摘要文件 — 每个 ACC-ALL 标签都有一个对应的条目。每个条目会列出该字段的所有唯一值以及每个值出现的次数。包含时间戳的字段将进行四舍五入，以指定唯一的日期。

每个文件均会合并来自所有报表包的数据，并自动删除额外的重复命中项。

您可以确定要将其中的哪些数据返回给数据主体。或者，您可以提取其中的部分数据，并与来自其他系统的数据合并，然后再将它们返回给数据主体。

删除响应详情

删除请求不会返回任何数据 — 只向数据隐私 API 返回一个指示请求已成功完成的状态。

对您的数据进行数据隐私处理测试

通常情况下，在向公众发布之前，Analytics 客户会设置一些测试报表包来验证功能。预生产网站或应用程序会将数据发送到这些测试/开发/QA 报表包中，以评估在将实际流量发送到生产报表包之前代码完成时的运行情况。

但是，在正常配置下，在将请求应用到生产报表包之前，不能先在这些测试报表包上对 GPDR 请求的处理进行测试。这是因为，数据隐私请求会自动应用于 Experience Cloud 组织中的所有报表包，通常也是您公司的所有报表包。

在将数据隐私请求应用于所有报表包之前，您仍可以使用以下几种方法测试您的数据隐私处理：

  • 一种选择是，设置一个单独的 Experience Cloud 组织，其中仅包含测试报表包。然后，使用此 Experience Cloud 组织进行数据隐私测试，并使用常规的 Experience Cloud 组织进行实际的数据隐私处理。

  • 另一种选择是，为测试报表包中的 ID 分配与生产报表包中的 ID 不同的命名空间。

    例如，您可以在测试报表包中为每个命名空间添加“qa-”作为前缀。当您提交仅带有 qa 前缀的命名空间的数据隐私请求时，这些请求将仅针对您的测试报表包运行。之后，当您提交不带 qa 前缀的请求时，它们将应用于您的生产报表包。我们推荐使用这种方法，除非您使用 visitorId、AAID、ECID 或 customVisitorId 命名空间，因为这些命名空间均为硬编码，您无法在测试报表包中为它们指定备用名称。

在此页面上