通过 Amazon Clean Rooms 助力广告行业实现隐私保护的数据协作

0. 背景 – 隐私保护的挑战

随着数据隐私保护意识的提高，企业如何在保护用户隐私的同时，进行有效的数据协作和分析，已成为一个值得关注的难题。尤其是对于广告行业来说，不同的广告主和媒体方经常需要共享一些用户数据来进行精准的广告投放和归因分析，但与此同时又需要严格地保护用户隐私，避免 PII 用户可识别信息的泄露，而亚马逊云科技推出的 Clean Rooms 服务正是为了帮助企业解决这个难题。Clean Rooms 允许企业在不泄露隐私数据的前提下，与合作伙伴一起多方分析和获取协作数据集的洞察。它提供了一系列全面的、细致的数据访问控制、查询控制、输出限制和查询日志记录等功能,企业完全可以根据自己的隐私合规要求，自定义配置数据的使用方式和访问规则。

报告《State of the Data 2023: The Path to Profitability Requires Privacy Compliance》指出，从 2021 年苹果的 iOS 14.5 发布后，其更新的核心内容为 App Tracking Transparency（ATT）要求应用程序必须首先获取用户是否允许数据收集以进行广告投放的同意请求，这使得数字营销和广告行业发生了颠覆性的变化，因为 ATT 要求像 Meta 这样的平台在用户选择禁止收集数据后从广告业务中清除用户数据。而且，随着越来越多的数据隐私法规得到推广和执行，广告主更有动力寻找解决方案并在衡量广告效果的解决方案上投入更多。

图片来自 liftoff 2022 App Marketer Survey

然而，在 Clean Rooms 中的数据协作不受这些清除要求的影响，存储在各自账号 S3 中的数据在保持不动的情况下，通过 Clean Rooms 多方安全计算技术和分析规则的约束可以实现保护隐私的数据协作。这意味着营销人员可以利用 Clean Rooms 更好地了解用户在广告中的互动，同时保持严格的用户隐私。

图片来自 liftoff 2022 App Marketer Survey

例如，某知名零售品牌作为广告主，可以将自己的用户行为数据，如浏览商品、加入购物车等行为数据关联到 Clean Rooms 协作中。另一边，某大型媒体公司作为媒体方，可以将自己的广告投放和用户点击数据关联到同一个协作中。两家企业都可以设置特定的规则，限制这些数据只能用于广告归因分析，而不泄漏用户个人隐私数据或者能用于用户画像等其他用途。然后，被指定的协作参与者就可以开始对这两个数据集运行各种归因相关的分析查询，例如点击率分析、转化率分析等，并进一步得到精准的广告效果数据。所有查询和结果都会在数据所在原始位置进行，亚马逊云科技会自动应用访问规则，而无需将原始数据移出其环境，这里 Clean Rooms 采用先进的加密技术也会确保查询和处理过程中数据的安全性。

1. 走进 Clean Rooms

使用 Clean Rooms 的第一步是在亚马逊云科技的管理控制台中创建一个“协作”，协作是一个安全的逻辑边界，只有受邀的成员才能加入。加入协作的企业可以将自己的数据集关联到协作中，并指定数据集的使用规则，例如只允许用于某些特定目的的分析。此外，Clean Rooms 还提供了完善的查询日志记录功能，参与方可以查看查询记录，审计是否符合规则要求，这些都为实现可解释性、可审计性的数据协作提供了有力支持。

以广告行业为例，使用 Clean Rooms 通常分为以下几个步骤：

1）上传数据：媒体和广告主上传数据到自己账号的 S3 存储桶中，此时双方可以约定是否使用数据加密。数据加密是可选项不是必选项，如果要进行加密，可以参考亚马逊云平台提供的 Cryptographic Computing for Clean Rooms (C3R) 客户端加密工具。

2）创建协作：媒体侧创建一个新的协作，然后邀请广告主进行参与，然后分配相应的能力。这里，Clean Rooms 提供两种能力可以分配：查询方和结果获取方。通常来说，在广告分析中更多地由广告主进行分析并获得数据结果，例如：

• a）受众细分 – 比如根据地域、人口统计学、兴趣爱好等进行细分，以便更有针对性地投放广告。
• b）测量投放效果 – 比如曝光量、点击率、转化率等，这可以评估广告活动的效果。
• c）归因分析 – 确定是哪个广告渠道或触点促成了最终转化，这有助于找到最有效的广告渠道。

接下来，广告主接受请求并参与协作，然后设置存储查询结果的位置和格式。

3）付费选项：除了查询和获取结果，还需要有人来为执行这些操作的计算资源进行付费。Clean Rooms 采用的是按需付费的模式，服务会根据查询工作负载的情况自动扩展，并在空闲的时候自动关闭以节约成本。Clean Rooms 的计算单元是 Clean Rooms Processing Units (CRPUs)，类似于 Amazon Redshift Serverless 服务中的 Redshift Processing Units (RPUs)，用户使用的 CRPU 时长来支付（最低收费 60 秒），起始资源是 32 个 CRPU，更多价格详细信息，请参考链接。

今年 11 月，Clean Rooms 新增一项功能，允许协作方灵活地选择负责支付的协作成员。在之前，查询的协作成员必须是付费方，而现在协作创建者现在可以配置付款方，将执行查询的成员与支付费用的成员分离开来。例如，媒体方同意在协作中支付查询计算费用，即使在协作中运行查询的是广告主，这样相当于媒体为广告主提供的一项高级数据服务。借助付款配置，费用不再局限于由运行查询的用户承担。

4）配置数据表：然后，数据协作方开始对自己的数据进行相应的配置，在 Clean Rooms 环境中，需要使用 Amazon Glue 服务作为辅助，通过其 Data Catalog 功能来定义存储在 S3 中的数据，据此创建并配置 Configured Table 配置表。在配置过程中，需要使用到 Clean Rooms 最核心的分析规则 Analysis Rule，正是通过这些规则来约束数据如何在 Clean Rooms 中被查询，包括限定数据连接和聚合规则、控制明细条目等，这在下一小节将会详细展开说说。创建好了的 Configured Table 可以与一个或多个协作关联，即媒体方创建好多个统一的基础数据表和规则，然后可以和不同广告主进行协作分析。

无论是媒体还是广告主，都需要对 Glue 进行一些操作，如果对自己的数据和 Glue 服务比较熟悉，可以直接定义数据结构和元数据信息，如果不是特别熟悉的情况下可以使用 Glue 的内置 Crawler 功能对数据进行自动爬取。

5）关联数据表：下一步，就是将创建好的数据表关联到协作中，这里需要设置或者创建 Service Role 服务角色。Clean Rooms 会通过服务角色来查询和过滤基础数据表，需要注意的是该服务角色只能被 Clean Rooms 服务本身 Assume 使用，其他协作成员无法直接访问底层数据，数据隐私和安全可以得到保证。

6）查询、获取结果：根据上述的内容进行配置后，相应的查询协作方（例如广告主）就可以按照预定的规则对数据进行分析，然后按照实际使用的计算资源进行付费（例如媒体）。

2. 核心 – 分析规则 Analysis Rule

在使用 Clean Rooms 进行协作分析前，所有成员都必须对其数据表配置分析规则，这也是 Clean Rooms 的核心所在。分析规则最主要的目的就是设置并增强对隐私的控制，因为这些规则直接决定了最终数据查询和结果的获取。例如，分析规则可以规定查询控制以确定如何连接 Configured Table 以及可以选择哪些列，还可以通过设置查询结果控制（如输出行的聚合阈值，某一聚合的数据量比如大于 2）来限制查询输出，最终 Clean Rooms 会拒绝并移除任何不符合分析规则的数据行。

如果没有配置分析规则，则 Configured Table 可以关联到协作但无法查询，查询只能引用具有相同分析规则类型的配置表。要配置分析规则，首先要选择一种分析规则类型（类型包含以下三种：Aggregation、List 和 Custom，详细对比见下表），然后指定对应的规则细节。

通常来说，广告分析中的投放效果衡量和归因会使用到 Aggregation 聚合类型的分析规则。例如， A 是一家品牌方，该公司以电子邮件地址、姓名和实际地址的形式拥有与客户有关的第一方数据。这些数据是通过各种交易收集的，包括网站转换。B 是一家广告商，这家公司代表他们的客户投放广告，并获取印象数据，包括电子邮件地址、活动 ID 等。A 与 B 合作即将到来的销售活动进行广告宣传，然后 A 想知道与 B 合作的活动是否成功的细节信息，但他们都不想暴露任何用户隐私，Clean Rooms 可以很好地完成这个需求。

假设 A 的客户数据如下所示：

fields = [
    "email_address",
    "date_created",
    "state",
    "city",
    "country",
    "zip",
    "first_name",
    "last_name",
    "status",
    "birth_country"
]

A 在其网站上也有关于转换的数据，如下所示：

fields = [
    "email_address",
    "date",
    "creative_id",
    "event_type",
    "version",
    "price",
    "currency",
    "transaction_id"
]

B 拥有来自看过 A 投放广告的用户的展示数据，如下所示：

fields = [
    "email_address",
    "date",
    "creative_id"
]

A 和 B 在 Clean Rooms 创建协作并共享了它们的数据表，作为数据消费者，A 可以运行如下查询，进行重叠分析（通过 Creative ID 划分）：

SELECT COUNT(DISTINCT c.email_address) as counts, c.creative_id
FROM conversions c
INNER JOIN impressions i
ON i.email_address = c.email_address
GROUP BY c.creative_id
ORDER BY counts DESC

List 在广告分析中也有很多应用场景，例如数据增强，也比较容易理解主要目标就是通过多方数据结合起来来为自己的数据做补充和增强，更多详细信息可以参考这里。

此外，如果 Aggragation 和 List 都不能满足需求的话，可以使用 Custom 类型完全自定义数据查询的规则，并使用到更多的 SQL 内容，例如窗口函数、外连接、CTE、子查询等。自定义分析规则也支持比 Aggragation 和 List 类型更高级的使用案例：

• 定制归因分析：根据不同的归因模型（如首次/末次点击归因、时间衰减归因等）进行广告归因效果分析
• 基准测试：将某段时间内的广告数据与另一段时间或标准进行比较，判断广告表现是否有提升
• 增量分析：评估新增广告投放的增量效果，了解新增投放对整体效果的贡献
• 受众发现：深入挖掘不同受众群体的特征，为精准营销提供支持

相比聚合和列表分析规则，自定义分析规则提供了更丰富和灵活的分析功能，可以满足更复杂的业务分析需求，让广告市场营销人员可以获得更深入的洞察，从而制定更精准的营销策略。

3. 数据连接

Clean Rooms 最终还是需要和各个广告平台以及自身的数据平台打交道，目前亚马逊云科技提供了超多数据源（进到 Clean Rooms）和数据目标（在 Clean Rooms 分析完成后）的对接支持解决方案。这些解决方案可以分为三类，供不同场景使用。

第一类是亚马逊云科技平台提供的解决方案，充分利用各项云服务快速搭建起来，通常包含可以一键启动的 CloudFormation 模版和源代码。例如 Data Connectors for Clean Rooms 解决方案，它可以使用户可以轻松地将来自营销平台的数据导入指导工作流，为广告和营销数据选择应用程序源，对数据进行规范化和映射，并生成在 Clean Rooms 中协作所需的元数据目录。

第二类是合作伙伴解决方案，可以借助合作伙伴长久以来在亚马逊云科技上运行和支持工作负载的丰富经验。亚马逊云科技的先进技术使得广告分析团队、市场营销团队、媒体和代理机构等能够更轻松地与合作伙伴建立联系。以 LiveRamp 为例，LiveRamp 将身份识别服务和功能引入云数据环境，使他们能够在数据平台内构建统一的客户视图。

第三类是平台提供的解决方案指南，以提供架构参考和说明为主。以 TikTok Ads 广告为例，指南为广告主提供了在 Clean Rooms 分析后上传（通过 EventBridge、SQS 和 Lambda）输出受众到 TikTok Ads 的方法，而无需构建自定义工作流。

三类解决方案侧重不同，可以根据实际的需求进行灵活选择或者组合使用。

4. 最佳实践 x10

根据 Clean Rooms 的服务使用和安全合规上的策略控制文档，这里整理了十条最佳实践对其进行一些展开说明，这些实践也对应了使用 Clean Rooms 的不同阶段。上一小节介绍了分析规则如何限定了数据的访问和隐私的保护，是整个 Clean Rooms 的核心，所以最佳实践基本上都是围绕分析规则而提出的：

— I. 设计阶段 —

1）独立表：为不同的查询场景创建单独的 Configured Table（例如，受众分析和数据增强），用户可以使用同一个底层 Amazon Glue 表创建多个 Configured Table，然后在配置分析规则时选择不同的类型，比如 Aggregation 和 List，各层关系如下图所示。

— II. 执行阶段 —

2）限定列：在分析规则中指定协作中查询所必需的列（例如，维度列、列表列、连接列）。这可能有助于降低不同攻击的风险，避免其他成员对数据进行逆向工程。使用 Allowlist Columns 特性来记录将来可能想要查询的其他列，如果想要自定义可用于特定协作的列，可以参考上一条原则：使用相同的底层 Glue 表创建新的 Configured Table。

3）限函数：在分析规则中指定协作中分析所必需的函数，这可以帮助降低函数错误带来的风险，这些错误可能会在单个数据点上显示信息。如果想要自定义可用于特定协作的列，也可以参考第一条原则：使用相同的底层 Glue 表创建新的 Configured Table。

4）约束行：在行级值敏感的任何列上添加聚合约束，包括 Configured Table 中的列，这些列也作为聚合约束存在于其他协作成员的表和分析规则中。这还包括 Configured Table 中不可查询的列，即在 Configured Table 中但不在分析规则中的列。聚合约束可以帮助降低将查询结果与协作之外的数据关联起来的风险。

— III. 验证阶段 —

5）学示例：在设置分析规则后，查看 Clean Rooms 控制台上提供的示例查询。需要注意的是，除了示例查询之外，还可以执行满足条件的其他查询。

6）做测试：创建测试协作和分析规则，以测试使用指定的分析规则创建的限制。

7）做检查：检查协作者的 Configured Table 和分析规则，以查看它们是否与协作商定的内容相匹配。这可以帮助降低其他成员设计自己的数据以运行未达成一致的查询的风险。

8）做更新：可以为协作中 Configured Table 添加或更新分析规则，并检查所有与 Configured Table 相关联的协作及其产生的影响，这有助于确保没有协作使用过时的分析规则。

— IV. 监控阶段 —

9）查执行：检查在协作中运行的查询，以查看是否匹配用例或为协作商定的查询。当打开查询日志记录功能时，在查询日志中可以看到这些内容，建议开启。这可以帮助降低成员运行未达成一致的分析和潜在攻击的风险，目前查询日志中的内容包含以下信息：

analysisRule – 查询规则

analysisTemplateArn – 分析模版

collaborationId – 协作 ID

configuredTableID – 表 ID

directQueryAnalysisRulePolicy.custom.allowedAnalysis – 允许的分析模版

directQueryAnalysisRulePolicy.v1.custom.allowedAnalysisProviders – 允许的分析提供者

eventID – 事件 ID

eventTimestamp – 事件时间戳

parameters.parametervalue – 参数

queryText – 运行的 SQL 定义

queryValidationErrors – 校验错误

schemaName – 表引用名

10）查规则：检查协作成员的分析规则和查询中使用的 Configured Table 列，以查看它们是否与协作中商定的列相匹配。当打开查询日志记录功能时，在查询日志中可以看到这些内容，建议开启。这可以帮助降低其他成员设计自己的数据来执行未达成一致的查询的风险。

5. 小结

综上，本文介绍了 Clean Rooms 在面临广告行业隐私数据保护需求挑战时提供的数据协作解决方案，以及 Clean Rooms 中的分析规则、数据连接和最佳实践等。可以看到，Clean Rooms 为广告行业实现隐私保护的数据协作提供了重要支持，而随着服务的不断完善和新功能的增添，相信它将为企业开启更多高效、安全的协作新模式，实现隐私保护和商业价值的双赢。

6. 参考资料

https://www.amazon.science/blog/computing-on-private-data

https://aws.amazon.com/solutions/advertising-marketing/data-clean-rooms/

https://www.wpromote.com/whitepaper/state-of-the-data-2023

本篇作者