Analytics 变量的数据隐私标签

Adobe的客户作为数据控制者，有责任遵守适用的数据隐私法律，例如《通用数据保护条例》(GDPR)和《加州消费者隐私法案》(CCPA)。 客户应咨询自己的法律团队，确定应如何处理其数据才符合数据隐私法。Adobe 了解每个客户都有与隐私相关的独特需求，这就是为什么 Adobe 允许客户自定义其所需的数据隐私数据处理设置。这允许每个独特客户采用对其品牌和独特数据集最为合理的方式处理数据隐私请求。

Adobe Analytics 根据数据的敏感性和合同限制提供了数据标签设置工具。标签对于以下步骤至关重要：（1）识别数据主体，（2）确定哪些数据可在访问请求中返回，以及（3）识别必须在删除请求中删除的数据字段。

在您搞清楚要将哪些标签应用于哪些变量/字段之前，首先需要知道您在 Analytics 数据中捕获的 ID，并确定要将哪些 ID 用于数据隐私请求。

Adobe Analytics 数据隐私实施支持以下用于身份数据、敏感数据和数据管理的标签。

身份数据标签 identity-data-labels

身份数据“I”标签用于对可识别或联系特定人员的数据进行分类。

敏感数据标签 sensitive-data-labels

敏感数据“S”标签用于对诸如地理数据之类的敏感数据进行分类。未来，会引入其他敏感数据标签，用于识别其他类型的敏感信息。

数据治理标签（数据隐私） data-governance-labels

数据治理标签使用户能够对反映隐私相关考虑因素和合同条件的数据进行分类，从而帮助 Adobe 客户遵守法规和公司政策。

数据隐私访问标签 access

尽管很少会有变量设置其他任何标签，但预计访问标签将会应用到许多变量中。不过，您需要咨询您的法律团队，以决定应该将收集的哪些数据与“数据主体”共享。

数据隐私删除标签 delete

与其他标签不同，这些“删除”标签并不是相互排斥的。您可以选择两者之一、同时选择两者，或者选择“无”。无标签不需要另外单独选择，因为不勾选任何一个“删除”选项即表示选择了无。

“删除”标签仅用于包含某个值的字段，该值允许点击与“数据主体”相关联（即允许标识“数据主体”）。不需要删除其他个人信息（收藏夹、浏览/购买历史、健康状况等），因为这会切断与“数据主体”的关联。

数据隐私身份标签 identity

在为变量设置 ID-DEVICE 或 ID-PERSON 标签时提供命名空间 provide-namespace

在为变量设置 ID-DEVICE 或 ID-PERSON 标签时，系统会提示您提供一个命名空间。您可以使用先前已定义的命名空间或者定义一个新的命名空间。

使用先前已定义的命名空间 previously-defined

如果以前为登录公司的任何报告包中的其他变量分配了 ID 标签，则可选择这些现有的命名空间之一。如果此变量包含的 ID 类型与之前已使用此命名空间设置标签的其他变量包含的 ID 类型相同，并且您希望在提交请求时搜索所有这些变量，则应重复使用该命名空间。

定义新的命名空间 define

您也可以定义一个新的命名空间。我们建议将命名空间字符串限制为字母数字字符，以及下划线、短划线和空格。这些字符串将全部转换为小写字母。

指定为命名空间的字符串与您在通过数据隐私 API 提交请求时，作为“namespace”参数的值使用的字符串相同。随后，该请求将促使 Adobe Analytics 搜索报告包中的所有变量，这些变量与该请求指定的 ID 共享此命名空间。

您不需要为包含 ID 的所有变量指定 ID-DEVICE 或 ID-PERSON 标签（这是 I1/I2 标签的用途）。如果您要使用存储在此变量中的 ID 提交数据隐私请求，并想要为指定的 ID 搜索此变量，请使用此标签。例如，如果 eVar1 包含一个电子邮件地址，eVar2 包含一个登录用户名，但是您仅使用用户名提交请求，那么您可能会为 eVar1 设置标签 I1、ACC-PERSON、DEL-PERSON，但是为 eVar2 设置标签 I2、ACC-PERSON、DEL-PERSON，以及具有命名空间“user name”的 ID-PERSON。然后，您可以使用“user”部分的 JSON 数据块提交请求，例如：

{
     "namespace": "user name",
     "type": "analytics",
     "value": "rocketman123"
}

在同一个报告包中，为不同变量使用相同的命名空间是可以接受的。例如，一些自定义实施将 CRM-ID 存储在 prop 和 eVar 中。如果 CRM-ID 总是出现在这两者的其中一个当中（例如 eVar）、只是偶尔出现在另外一个当中 (prop)，并且当 CRM-ID 没有出现在 eVar 中时它也绝不会出现在 prop 中，那么，只有 eVar 需要 ID 标签和命名空间，这是因为 Adobe 可以只在该 eVar 中搜索 ID。但是，如果 CRM-ID 有时出现在一个变量中，有时出现在另一个变量中，那么它们应该具有相同的命名空间，而且 Adobe 将搜索这两个变量，以查找指定为使用此命名空间的数据隐私请求一部分的 ID 的出现次数。您仍应在所有这些变量中包含 DEL 标签，以便无论该值何时出现，它都是匿名化的。

列举另一个示例，您可能拥有一个 CRM ID，并且有时会通过 eVar1 发送，有时通过 prop7 发送。然后您使用一个处理规则，将 eVar1 的值（如果存在）复制到 eVar3 中。否则，它会将 prop7 的值复制到 eVar3。在这种情况下，如果 CRM ID是已知的，eVar3 将始终包含该 CRM ID，因此只有 eVar3 需要 ID-PERSON 标签。

变量类型及其支持的“数据隐私”标签 variable-types

“数据隐私”标签功能影响四大类 Analytics 变量。 并非所有变量都支持所有标签。下表显示了各类变量对各种标签的支持情况。

可为其分配/修改除 ACC-ALL/ACC-PERSON 以外的标签的变量 variables

删除处理 deletion

Adobe Analytics 对数据隐私删除请求的支持旨在最大限度地减少对报告的影响。在大多数情况下，报告中显示的量度不应发生变化。在执行数据隐私删除之前运行的历史报告将与执行删除之后运行的同一报告相匹配。这是通过将已删除的数据与“数据主体”完全解除关联、同时又保留不可识别的数据来完成的，以便使报告的值保持一致。

下表描述了如何“删除”各种变量。这不是一个完整的列表。

可能不支持预期“删除”标签的变量 no-delete-support

本节旨在阐明有关可能不支持删除的 Analytics 变量的信息。有时候，这些变量会被非 Analytics 用户（例如法律团队）删除，这些用户不了解变量中包含的数据类型，因此会根据变量的名称做出假设。

在做出有关标签或删除的决定之前，了解每个变量中包含的数据类型非常重要，而不是仅依赖变量名称。以下是其中一些变量的列表，以及它们可能不需要删除、或者可能不需要特定的删除标签的原因：

访问请求的日期字段 access-requests

有五个标准变量包含时间戳：

用于生成为数据隐私访问请求返回的文件的代码，要求访问请求中至少包含前三个时间戳变量中的一个（具有一个适用于该请求类型的 ACC 标签）。若不包含上述三个中的任意一个，则“自定义点击时间 UTC”将被视为含有 ACC-ALL 标签。

为数据隐私访问请求返回的点击级别CSV文件将这些字段中的值从unix时间戳转换为YYYY-MM-DD HH:MM:SS格式的日期/时间字段（例如，2018-05-01 13:49:22）。 在摘要HTML文件中，这些时间戳值将被截断为仅包括日期YYYY-MM-DD，以减少这些字段中出现的唯一值的数量。