2023 年第 2 季度的季度报告，其中总结了生态系统对 Privacy Sandbox 提案的反馈以及 Chrome 的回应。
根据其对 CMA 的承诺，Google 已同意公开提供季度报告，说明其 Privacy Sandbox 提案所涉及的利益相关方互动流程（请参阅承诺的第 12 和 17(c)(ii) 段）。这些 Privacy Sandbox 反馈摘要报告通过汇总 Chrome 从反馈概览中列出的各种来源收到的反馈生成，这些来源包括但不限于：GitHub 问题、privacysandbox.com 上提供的反馈表单、与行业利益相关方的会议，以及网络标准论坛。Chrome 欢迎您从生态系统中获得反馈，并正在积极探索将学到的知识融入设计决策的方法。
反馈主题按 API 的普遍性排名。方法是汇总 Chrome 团队就特定主题收到的反馈量，并按数量降序整理。他们通过查看公开会议（W3C、PatCG、IETF）、直接反馈、GitHub 以及通过 Google 内部团队和公开表单提出的常见问题来确定常见反馈主题。
更具体地说，我们审核了网络标准机构会议的会议记录，对于直接反馈，还考虑了 Google 的 1 对 1 利益相关方会议记录、个人工程师收到的电子邮件、API 邮寄名单和公共反馈表单。然后，Google 协调参与这些各种推广活动的团队，确定新出现的主题与每个 API 相关的相对普遍性。
Chrome 对反馈的回应说明源自于已发布的常见问题解答、对利益相关方提出的问题的实际回复，以及我们专门为此公开报告练习确定的立场。体现了当前开发和测试工作的重点，以及就 Topics API、Protected Audience API 和 Attribution Reporting API 提出的问题和反馈。
当前报告期结束后收到的反馈可能尚未纳入 Chrome 响应。
首字母缩略词词汇表
- 条状标签
- 具有独立分区状态的 Cookie
- DSP
- 需求方平台
- FedCM
- 联合凭据管理
- FPS
- First Party Set
- IAB
- 美国互动广告局
- 身份提供方
- 身份提供方
- IETF
- 互联网工程任务组
- IP
- 互联网协议地址
- openRTB
- 实时出价
- 加时赛
- 源试用
- PatCG
- 隐私广告技术社区小组
- RP
- 依赖方
- 供应方平台
- 供应方平台
- TEE
- 可信执行环境
- UA
- 用户代理字符串
- UA-CH
- 用户代理客户端提示
- W3C
- 万维网联盟
- WIPB
- 蓄意 IP 盲目
一般性反馈，没有具体的 API/技术
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 数据治理与法规遵从 | 关于在遵守监管要求的情况下使用 Privacy Sandbox 的生态系统指南。 | 与任何新技术一样，每家公司都有责任确保自己对 Privacy Sandbox 的使用符合法律规定；Google 无法向其他方提供法律建议。但我们知道，这是该生态系统感兴趣的一个关键领域。对于每个 API，我们都发布了大量技术文档，为进行必要的法律评估提供了依据。此外，我们也在努力提供其他材料，为各家公司遵守监管要求提供支持。 |
| CMA 定量测试方案 | 详细了解 CMA 定量测试方案 | 我们正在与 CMA 合作设计相关实验，这些实验旨在让您了解弃用第三方 Cookie 的影响，以及推出 Privacy Sandbox 提案对整个生态系统的影响。4 月份，CMA 发布了有关测试和试验期间可能出现的简要指南，并于 6 月发布了详细指南。我们鼓励与 CMA 直接分享有关 CMA 定量测试方案的问题或反馈。 |
| Chrome 协助测试模式 | 关于测试时间表的更多信息和澄清 | 我们在 5 月 18 日发布了一篇博文，其中详细介绍了由 Chrome 协助的两种测试模式。这些详细信息并非最终版本，随着工作进展，我们会在 2023 年第 3 季度发布进一步的实现指南。 |
| 分区存储 | 在 Chrome 协助测试期间，是否会使用分区存储空间？ | 存储空间分区将在第三方 Cookie 弃用实验之前面向所有用户提供。因此，它将为实验的所有实验组启用。在此期间，网站可以选择启用弃用试用，以恢复未分区的存储空间。 |
| 制作支持 | Chrome 采用什么流程来为影响生态系统的 Privacy Sandbox 技术问题和上报问题提供支持？ | Google 提供了多种渠道，以供广告技术平台报告问题和进行必要的上报。 如要详细了解如何提供反馈和上报公共论坛和非公开论坛，请参阅我们的开发者帖子。 |
| 报名时间表 | 当前的注册时间范围过短 | 我们仍在评估政策的执行期限，希望能听听生态系统给出的建议，了解哪个期限更合适。 |
| 邓氏编码 | 详细了解注册和认证的邓氏编码要求 | 参与者可以访问 Dun & Bradstreet 网站，找到获取邓氏编码的要求。具体要求因市场而异，因此参与者应确保浏览网站查看他们感兴趣的特定市场。不过，一般而言，参与者需要提供其商家的基本信息，例如企业名称、地址以及企业主或管理员的联系信息。参与者可能还需要提供财务信息，如商家的年收入。申请完成后，D&B 将对其进行审核，如果申请获得批准，则会签发邓氏编码。 |
| 从源试用转换为正式版 | 从源试用转换为正式版是否会影响当前的源试用测试人员？ | 自 7 月起，测试人员将能够使用已正式发布的相关性和效果衡量 API。源试用的可用性和正式版将会出现重叠的情况。 |
| AdExchanger 研究 | 详细了解问卷调查方法 | 此问卷调查请受访者估算其业务的同步率和收入。受访者具体回答问题的方法由他们自己决定。 |
| 参数值 | 噪声等级、匿名性阈值和隐私预算等参数值是如何确定的？ | 此 GitHub 解释器阐述了 Privacy Sandbox API 背后的更通用的原则。许多值尚未最终确定，欢迎就这一主题提供反馈。 |
展示相关的内容和广告
主题
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 隐私保护 | 评估 Topics API 在隐私保护方面的研究 | 我们积极参与研究社区，通过论文、报告和研讨会演示文稿展示我们对 Topics API 隐私属性的研究。我们很高兴看到研究社区有更多外部成员参与这一领域。 Topics API 让大规模跟踪用户变得过于困难，从而可以防止用户在网络上进行常规跟踪。这些论文表明我们使用 Topics API 取得了成功。它比第三方 Cookie 更注重隐私保护，并能保护用户，同时为用户喜欢访问的网站提供支持。 |
| 主题分类不够精细 | 宽泛的主题分类不包含更精细的主题，包括特定区域的主题。 | 为响应该生态系统之前提供的反馈，我们在 6 月 15 日发布了一篇博文，详细说明了新的分类法，其中包括根据生态系统的反馈进行了众多改进。在改进分类体系的过程中，我们与整个生态系统中的多家公司进行了合作，例如 Raptive（以前称为 CafeMedia）和 Criteo。更新后的类目移除了系统认为不太有用的类别，取而代之的是更符合广告客户兴趣的类别，同时我们继续承诺排除可能敏感的主题。 我们建议广告生态系统中查阅最新的分类法，并就变更内容提供反馈。 |
| 分类和分类器更新流程 | 有关主题分类和分类器发布频率以及各公司如何为此类更新做准备的更多信息。 | 正如最近的博文中所分享的那样，我们预计分类会随着时间的推移而不断演变，并且希望分类的管理最终将过渡到代表整个行业内相关方的外部方。我们还在 topics-announce 论坛中分享了公开范围渐增计划。 |
| 对第一方信号的影响 | 近期类目更新中主题数量的增加可能极具价值，并因此会降低其他基于兴趣的第一方信号的价值。 | 在 2023 年第 1 季度的报告中，CMA 评论说：“我们了解到，Google 一直在与广告技术供应链中的多个市场参与者讨论其提议的新分类法。虽然一些大型发布商曾表示，更广泛地利用主题会加大其基于第一方数据的解决方案的竞争压力，但我们初步的观点是，更高的实用性有利于提升整体竞争水平 - 特别是小型发布商在弃用第三方 Cookie 后能够继续利用其广告资源创收的能力。我们的观点符合 CMA 的这条评论。 |
| 对不同类型的利益相关方的实用性 | 与其他生态系统参与者相比，充当 SSP 和 DSP 的广告技术平台可能拥有显著优势。 | 与之前几个季度相比，我们的回应保持不变： “Google 承诺 CMA 设计和实施 Privacy Sandbox 提案时，不会因为自利 Google 自己的业务来影响竞争，并且考虑到对数字广告竞争以及对发布商和广告主（无论规模如何）的影响。我们将继续与 CMA 密切合作，确保我们的工作符合这些承诺。随着 Privacy Sandbox 测试的不断进行，我们将评估的关键问题之一是新技术对不同类型的利益相关方的影响。在这方面，反馈至关重要，尤其是有助于我们进一步改进技术设计的具体、切实可行的反馈。我们与 CMA 合作制定了定量测试方法，并且支持 CMA 发布有关实验设计的说明，以便向市场参与者提供更多信息，并有机会评论提议的方法。” |
| 后代主题 | 由于主题选择条件是浏览器访问频率，细分的碎片化是否会导致后代主题从未上升到顶部？ | Chrome 目前正在评估其他排名方法，并探索可能有助于提高排名的其他信号。我们会在适当情况下向 YouTube 生态系统传达修订后的计划。 |
| 敏感程度 | Topics API 应力求确保通过 Topics API 获取或衍生的用户信息应比使用当今的跟踪方法所能获得的个人敏感度更低。 | 我们认为 Topics API 的隐私保护程度远远超过当前技术，在很大程度上限制了对用户的重标识，其设计宗旨是排除敏感主题。我们承认主题可以通过关联第一方数据或与第一方数据结合使用来创建敏感类别，但我们相信 Topics API 能够向保护用户隐私迈进一步，并致力于持续改进此 API。 |
| 类目结构 | 向主题类目添加 ID、版本控制和其他元数据结构 | 目前，我们在 API 响应中加入了分类 ID。在推进长期治理的过程中，有必要查看 Topics 对象，并根据需要添加有关版本控制的其他元数据。 |
| 发布商控制 | 发布商应对其网站归类为哪些 Topics 有发言权。 | 网站分类错误可能会导致 Topics 信号作为整体信号的实用性略微降低，但被错误分类的特定网站受此影响的可能性丝毫不亚于任何其他网站。这是因为网站的背景信息始终可在其网站上用于竞价，即使是在分类错误的情况下，也可以提供与正确主题相当的信息。我们欢迎您在此处就此主题提供反馈。 允许发布商控制其分类存在风险。网站可能会故意对网站进行错误分类，降低网站的实用性，或对不常见主题中的敏感含义进行编码，从而损害用户隐私。 |
| Chrome 扩展程序 | 允许 Chrome 扩展程序管理和过滤主题，类似于当前的 Cookie 管理扩展程序 | 正如 GitHub 上所讨论的那样，这应该已经成为可能，但我们欢迎生态系统中的用户提供更多反馈。 |
| 过渡到正式版 | 从源试用转换为正式版时，Topics API 是否会受到影响？ | 如果用户从源试用转换为正式版，则不会丢失任何数据。 |
| 隐私权 | 主机名可能包含隐私信息，而 Topics API 可能会泄露这些信息 | 我们采取了多种缓解措施来保护隐私，详见此处。 |
| 欺诈和滥用行为 | 如何防止有人通过欺诈性访问来操纵 Topics | 点击此处了解相关缓解措施。 |
| 主题分类器 | 网站是否可以请求更改其 Topics 分类？ | 我们衷心期待收到生态系统中关于这一主题的反馈，欢迎点击此处提供反馈。 |
| 主题提供程序网站 | 将托管众多主题内容的特定网站指定为“特殊主题提供商网站”，并根据网页上提供的标记训练分类器。 | 我们正在讨论该方案，欢迎您提供更多反馈。 |
Protected Audience API（以前称为 FLEDGE）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 根据流量情况调整投放速度 | 通过 SSP 驱动的过滤以优化每秒查询次数 (QPS) 负载对性能的影响 | 我们花了大量时间考虑“根据流量情况调整投放速度”，并建议 SSP 利用缓存。 |
| 测试音量 | 对 Protected Audience 的测试具有挑战性，因为 SSP 和 DSP 难以获得大量流量。 | 我们一直致力于让 SSP 和 DSP 合作伙伴采用和测试 Protected Audiences。正式版已经开始，我们相信启用 PA 的流量百分比会使合作伙伴更愿意对其进行测试。 |
| 复杂性 | 实施 Protected Audience 解决方案需要投入大量精力和成本。 | 我们了解，新技术的采用很难，包括 Privacy Sandbox。Privacy Sandbox 团队与众多利益相关方密切合作，为他们开展相关工作提供指导和支持，同时不断评估其他推动因素，以便支持生态系统采用。 |
| 可信执行环境 | 对非公有云环境中可信执行环境 (TEE) 的支持 | 虽然我们正在探索在基于云的解决方案之外可能支持的其他方案，但由于本地的安全限制而需要对 Privacy Sandbox 进行评估，目前很难支持本地 TEE。鉴于 Privacy Sandbox 的安全性要求以及本地部署带来的巨大挑战，我们认为继续扩展和改进基于云的部署（例如，在 AWS 之外同时支持 GCP）对生态系统最有利。不过，我们欢迎大家就此要求的必要性提供其他反馈。 |
| 费用结构 | 与客户端模型相比，出价和竞价服务提案会增加广告技术平台的费用和复杂性。 | 我们正在制定指南来估算在出价和竞价服务器中支持出价和竞价工作流程所需的费用，该指南将与广告技术的使用相关，以实现我们的设计目标之一。 |
| K-Anon 时间表 | 计划何时对 `renderUrl` 强制执行 k-匿名性限制条件？ | 我们正在为即将发布的执行时间表提供解释说明。 |
| runAdAuction 限制 | Chrome 能否将 runAdAuction 限制为只能从顶级调用？ |
虽然我们的设计完全支持从顶部调用 runAdAuction，但我们认为，将发布商限制为仅可从顶级网域调用会更有危害。有开发者向我们明确表示，Privacy Sandbox 需要尽可能减轻发布商和广告主的负担。这些反馈符合网站开发的一般原则，网站所有者可以使用第三方工具运行其网站。Privacy Sandbox 的目标是鼓励健康的生态系统，而无需规定发布商和广告技术平台的运作方式。 我们相信，通过允许发布商选择如何以及由谁在其网站上调用 runAdAuction，我们可以让发布商灵活地找到符合其要求的最佳途径。 |
| 实现方面的支持 | Chrome 能否构建或协助实现多卖家竞价的开源实现？ | Privacy Sandbox 旨在开发不依赖第三方 Cookie 或其他跨网站标识符的隐私保护技术。我们希望促进生态系统的健康发展，而无需规定广告技术平台的运作方式。 我们已在 GitHub 代码库中发布了有关 API 工作原理的指南，并乐意与业界一起探索解决方案。 我们不打算开发任何具体的实现方案，因为我们的核心职责是开发平台技术，而不是制定使用这些技术的策略。我们的技术将帮助广告技术公司在为消费者提供恰当的隐私保护措施的情况下，为客户提供最好的服务。 |
| 多卖家竞价 | Chrome 是否会强制与组件竞价共享“内容相关”胜出者？ | Protected Audience API 旨在让发起多卖方竞价的各方能够将信息传递给组件竞价（注意：仅在发起竞价之前）。 也就是说，我们无法让浏览器区分某条信息是否是与情境相关的胜出者，因此我们无法强制执行屏蔽或要求提供某些信息。 |
| 用户意见征求跟踪的用户偏好设置 | 广告技术平台询问 PA 如何正确实现用户意见征求跟踪 | 我们的回应包括我们在第 1 季度的回答： “就具体广告而言，相关广告技术平台是最有利的一方，可以控制展示哪些广告素材或选择广告素材的方式。” 我们在 5 月的 WICG Protected Audience 会议中讨论了与此问题相关的一些场景，欢迎就此问题进一步提供反馈和讨论。 |
| 自定义受众群体 | Protected Audience API 是否支持与创建自定义受众群体相关的 SSP 用例？ | 借助 Protected Audience API，SSP 和其他广告技术提供商可以拥有和管理自定义受众群体。我们正在制定有关 SSP 如何与 PA API 集成的更多指南，并将提供给 SSP 和其他广告技术提供商，以支持其集成工作。 |
| 表现形式 | Protected Audience API 是否支持视频广告？ | 视频广告可通过以下两种方式之一投放：VAST XML 或 HTML（最终也可将 VAST XML 加载到视频播放器中的外播广告）。买方可通过 render网址 返回任一格式。VAST 规范近期进行了更新，以支持 Attribution Reporting API。投放视频广告的网站需要为通过 Protected Audience API 投放广告的方式做好准备。这意味着，请确保展示位置代码可以将网址从 Protected Audience iframe 传递到视频播放器。对于围栏框架，我们将努力在满足使用围栏框架的要求之前满足视频需求（该要求将于 2026 年之后推出）。 |
| 进度 | 如何将投放节奏用例与 Protected Audience API 搭配使用？ | 感谢您的反馈。我们很希望看到更多 SSP 合作伙伴能够提供与此要求相关的更多细节，因为迄今为止这主要是需求方平台关注的问题。 |
| 更新频率 | 来自 dailyUpdate 的来电频率（每个兴趣群体每天最多 1 次）可能不足以满足某些使用情形（例如更新商品信息）的需求。 |
感谢您的反馈。还有其他一些解决方案可用于允许广告技术平台使用以不同节奏刷新的信号，例如 K/V 查询。 |
| 广告质量控制 | 发布商如何实施广告质量控制？ | 现在，Protected Audience API 为发布商提供了相关功能，以便告知 SSP 某些控件，这些控件可以在竞价配置和出价前建立（例如根据与广告关联的标签设置拒绝名单）。我们欢迎您针对生态系统可能需要的任何其他功能提供反馈。 |
| 调试 | 何时会移除“forDebuggingOnly”功能？ |
我们计划针对因弃用第三方 Cookie 而导致的损失事件停用 forDebuggingOnly。我们计划最早在 2026 年停止接受获胜活动的forDebuggingOnly。 |
| 跨设备兴趣组 | 关于为经过身份验证的用户代理启用跨设备兴趣群体的提案 | 我们正在评估此方案，但跨设备定位的高度特异性带来了极大的隐私问题，如此 GitHub 问题中所述。 |
| （第 1 季度也进行了报告）动态再营销 | 在第三方 Cookie 被弃用后，能否使用 Protected Audience API 进行动态再营销？ | 我们相信，使用 Protected Audience 时可以实现这一用例，如此处所述。 |
| 点击相关数据 | 向 browserSignals. 添加与点击相关的数据 |
目前我们要求进一步说明点击发生的时间，以便提供初步排名。 |
| （2022 年第 4 季度也进行了报告）Protected Audience 中的用户定义函数 | Protected Audience API 如何支持用户定义的函数 (UDF)？最终用户可以对这些函数进行编程，以扩展该 API 的功能。 | 提出此问题的广告技术平台还表示，他们仍在评估 UDF 可以实现哪些功能，因此至少要到正式版发布之前，这里还没有切实可行的反馈。 |
| 币种 | 货币金额不应使用浮点数表示。 | 我们在此处详细说明了该问题。 |
| 非 DSP 广告选择功能 | 广告服务器在 Protect Audience API 竞价中发挥什么作用？ | 我们了解到广告服务器需要继续提供出价后广告选择 / 动态广告素材优化服务。我们目前正在评估当前的 Protected Audience API 与这些请求之间存在的详细差异分析。 |
| GenerateBid | 支持 Google Ads 的提案，即从 generateBid 为每个广告兴趣群体返回多个候选广告，并在 `scoreAd` 中为这些候选广告评分。 |
目前正在评估。我们欢迎您在此处提供其他反馈。 |
| 竞价订单 | 是否必须使用 Protected Audience API 竞价，才能从其他所有竞价的结果中获取意见？ | Protected Audience API 最后运行没有技术要求。 |
| 非用户发起的导航 | 公开非用户发起的导航 | 我们正在审核此申请并在此进行讨论 ，欢迎您提供其他反馈。 |
| 缓存 | 如果用户状态发生变化，SSP 不应从缓存中构建指定 DSP 的 perBuyerSignals。 | 我们知道，缓存并非适用于 perBuyer 信号的每种用例，因此我们正在评估更多选项。我们欢迎生态系统中的发布商就缓存是否适合其使用场景提供任何其他反馈。 |
| Attribution Reporting 和 Protected Audience | Attribution Reporting API 和 Protected Audience API 如何协同工作？ | 目前，Protected Audience API 支持适用于这两种 Attribution Reporting API 模式（事件级报告和摘要报告）的集成。我们于 6 月 1 日分享了有关改进后 Protected Audience API 与归因报告集成的更多信息。您可以点击此处了解相关信息。 |
| 服务器端点 | 在最终设计中，服务器端点会是可信聚合服务器吗？ | 服务器端点是一个由广告技术平台维护的端点，该端点独立于用于处理收集和转换报告的可信汇总服务器。我们目前未计划对报告端点进行任何更改。当前的设计旨在确保可汇总报告本身（通过加密载荷）不会泄露跨网站数据，因此应该不需要使用可信端点。另一个复杂性是，不同的广告技术平台可能具有不同的所需批处理策略。我们欢迎您在此处提供其他反馈。 |
| WebIDL | 当前的 Protected Audience API 规范与 WebIDL 规范不兼容。 | 我们会评估这些反馈，并在此讨论该问题。 |
| 意见征求管理 | Protected Audience API 中如何处理意见征求信号传递？ | 背景信息不在 Protected Audience API 的范围内。我们正在讨论此问题，欢迎您提供其他反馈。 |
| 基于帐号的营销 | 是否有基于帐号的营销用例？ | Protected Audience API 支持各种基于受众群体的营销用例。我们将继续了解 Protected Audience API 如何为这种特定应用场景提供有力支持，欢迎生态系统中就此问题提供更多反馈。 |
| 组件竞价 | 组件竞价参与者得分是多少？ | 组件竞价不会直接对兴趣组进行评分，而是对 DSP 通过 generateBid 函数提交的广告和出价进行评分。generateBid() 函数会根据兴趣群体运行。DSP 会在执行 generateBid 时返回以下内容：
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| 外部贡献 | 请求支持外部针对键值对服务器 GitHub 代码库贡献代码。 | 我们希望更新相关流程，以支持外部用户对 GitHub 代码的贡献。 |
| 兴趣组规模 | IG 最多支持多少个密钥？ | 目前，一个 IG 的大小上限为 50 kb，并且包含密钥。我们欢迎进一步讨论大小限制。 |
| 批量处理 | 如何减少 K/V 服务器调用次数？ | 您可以使用 HTTP Cache-Control 标头来减少 K/V 调用次数。例如，它可以跨组成部分竞价进行缓存，也可以跨单个网页上的广告位进行缓存。 |
| 版本控制 | 支持多个版本的广告技术代码 | 出价和竞价服务将支持多个版本的广告技术代码。在出价和竞价 API 中，SelectAd 请求可以指定用于竞价请求（即用于出价 / 竞价和报告）的代码版本。 |
| 共享存储空间 | 支持向出价和竞价服务中的共享存储空间写入数据。 | 目前，出价和竞价服务不支持共享存储空间，但欢迎您提供更多反馈，让我们了解为什么此类使用情形对整个生态系统至关重要。 |
| 从网站到应用 | 支持从网站到应用共享兴趣群体。 | 目前，“从网站到应用”功能尚未纳入 Chrome 和 Android 上的 Protected Audience API 部署范围，但我们希望能听听生态系统中有关此用例的重要性。 |
| K-匿名性 | 如何处理 K-匿名性回退 | 我们正在讨论此问题，欢迎您提供其他反馈。 |
衡量数字广告
Attribution Reporting（和其他 API）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 替代性浏览型转化事件级报告配置 | 有关其他 VTC 事件级报告配置的反馈 | 我们收到了一些反馈，指出当前的事件级配置并不是最优的，因此我们希望您就最佳的全局配置提供反馈。我们非常乐意就此问题提供更多反馈，相信灵活的事件级铺垫消息也有助于解决此问题。 |
| 灵活的事件级配置 | 灵活事件级配置功能处于什么状态？ | 我们分享了有关灵活事件级配置的文档。该功能仍处于提案阶段，我们正在征求更多反馈，以了解该功能是否对生态系统有价值。 |
| 灵活的事件级配置 | 如何协调来自不同方的冲突报告？ | 大多数报告方案都是通过使用汇总报告来解决的，而灵活的事件级配置提案专门用于提高事件级报告的灵活性，而事件级报告最常用于优化用例。我们欢迎您就此情况对该生态系统做出任何其他意见/反馈。 |
| 来源注册 | 如果来源注册在触发器注册之后发生，该怎么办？ | 目前，如果来源注册发生在触发器注册之后，则来源和触发器将无法相互归因。这似乎属于极端情况。我们欢迎您就此问题提供任何其他反馈。如果许多广告技术平台都可能遇到这种情况，我们将设法予以解决。 |
| 与多个广告代理机构合作 | 当广告客户与多个广告代理机构合作时，DSP 如何使用 Attribution Reporting API？ | 该 API 支持重定向，因此，即使广告客户与多个广告代理机构合作，该 API 也可使用。此外，为了确保该 API 能够更好地保护隐私，我们对重定向设置了一些限制。我们还确定了一种可能的权宜解决方法：针对广告技术平台引发的特定场景，使用 Shared Storage API。我们欢迎您就这一情形提供任何其他反馈，并将继续根据这些反馈不断改进。 |
| 目标页面限制 | 自动刷新广告用例可能会受到目标页面限制的影响。 | 我们在 5 月 1 日的 WICG 会议上讨论了此问题，现希望就合理的限制征求反馈意见。我们在包含事件级报告的归因报告铺垫消息中新增了内容，指出浏览器可以限制源网站代表的“destination”eTLD+1 数量。（请参阅拉取请求）。 |
| Attribution Reporting 和 Protected Audience | Attribution Reporting API 和 Protected Audience API 如何协同工作？ | 目前，Protected Audience API 支持适用于这两种 Attribution Reporting API 模式（事件级报告和摘要报告）的集成。我们于 6 月 1 日分享了有关改进后 Protected Audience API 与归因报告集成的更多信息。您可以点击此处了解相关信息。 |
| 灵活的事件级配置 | 分享噪声模拟的最佳实践，因为参数可以配置。 | 我们在 GitHub 上提供了共享代码，任何人都可以使用该代码来评估要测试的任何灵活事件级配置的信息增益和噪声影响。我们非常希望能够了解任何选择使用代码进行测试的人的反馈，并乐于分享反馈。 |
| 跨应用和跨网站归因衡量 | 跨应用和跨网站归因衡量何时推出？ | 我们在 5 月 9 日宣布，将通过 Attribution Reporting API 进行跨应用和跨网站归因衡量的实验。虽然我们计划在 Chrome 115 中针对相关性和效果衡量 API 推出正式版，但目前尚未计划在 Chrome 115 中实现跨应用和跨网站归因衡量的正式版。 |
| 删除重复的转化 | 如何让独立的效果衡量解决方案与 ARA 保持一致？ | 与目前的标准做法一样，广告客户需要与第三方独立衡量服务提供商合作，以删除重复的转化报告。我们提供了有关如何为事件级报告删除重复的转化的资源。 |
| Attribution Reporting 数据库更新期间数据丢失 | 当 Chrome 按照公告更新归因报告数据库时，数据是否会丢失？ | 从 Chrome 稳定版 115 开始，我们将开始默认为部分 Chrome 用户启用相关性和效果衡量 API。我们会持续监控潜在问题，并会逐步完善正式版。目标是 2023 年第 3 季度之前在几周内实现 100% 的可用性。这将与相关性和衡量源试用的结束时间相一致。从 7 月份开始，测试人员将能够通过注册申请使用这些 API（正式版）。这样一来，源试用的可用性和通过注册参与的正式版之间会有重叠。您的源试用令牌的有效期截至 9 月 19 日，但我们建议您在该 API 到期前注册 API，以便在源试用不中断任何正在进行的测试的情况下无缝转换。 正如此公告中所述，在旧版（M113 及更早版本）中注册的数据在更新后将不会迁移，因此可能会丢失数据。此数据丢失不会显示在调试报告中，我们会尽力避免从 114 到 115 的数据丢失。 |
| 结算 | 使用 Attribution Reporting 进行每次转化费用结算 | 如这篇文章中所述，Attribution Reporting API 可能不适合进行每次转化费用结算需求，因为事件级报告和摘要报告中添加了干扰数据。我们鼓励生态系统参与者分享反馈，了解 Attribution Reporting API 对各种结算模式的影响。 |
汇总服务
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 可汇总报告延迟更改 | 对于将可汇总报告延迟时间从生态系统反馈更改为 [10-60 分钟] 至 [0-10 分钟] 的提案的正面反应 | 我们很高兴看到这些提议的更改得到了积极回应，并鼓励生态系统继续就我们的提案提供反馈。 |
| 本地解决方案 | 可以在本地数据中心部署汇总服务吗？ | 虽然我们正在探索在基于云的解决方案之外可能支持的其他方案，但由于本地的安全限制而需要对 Privacy Sandbox 进行评估，目前很难支持本地 TEE。鉴于 Privacy Sandbox 的安全性要求以及本地部署带来的巨大挑战，我们认为继续扩展和改进基于云的部署（例如，在 AWS 之外同时支持 GCP）对生态系统最有利。不过，我们欢迎大家就此要求的必要性提供其他反馈。 |
| 重新处理不同时间段的报告 | 能够重新处理不同时间段的报告 | 我们听到过类似的请求，希望能够针对不同的日期范围拆分批次。一种方案是，支持使用广告技术平台定义的标签来扩展共享 ID，以便将报告拆分为不同的批次。我们目前还在评估此流程的早期阶段，并会随着此提案的发展及时更新相关生态系统。 |
| 可信执行环境的隐私权影响 | 对可信执行环境可能对隐私造成的影响的积极态度 | 我们很高兴听到生态系统对我们的提案产生了积极影响，也欢迎您在不断迭代和开发的过程中提供更多反馈。 |
| 服务条款 | 接受汇总服务条款的截止日期是什么时候？ | 虽然我们尚未指定接受这些条款及条件的截止时间，但我们建议生态系统公司尽快接受这些条款及条件，以免延误注册流程。我们鼓励相关公司如有任何疑问，请与我们联系。 |
| 密钥发现 | 借助关键发现功能，测试人员无需明确列出可能的键组合即可查询汇总报告，即可处理摘要报告以进行跨广告网络归因，以提高性能和准确性。 | 我们目前正在探索可能的解决方案和解决方法，欢迎生态系统提供其他反馈。 |
Private Aggregation API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 报告来源 | 如何定义报告来源？ | 举报来源始终是不公开汇总调用方的脚本来源。 |
| 128 位密钥空间 | 阐明 128 位密钥空间限制 | 我们将使该键空间限制更加明确，并解决各页面之间的不一致问题。我们建议您使用哈希策略来保持在此键空间内。 |
| 每个报告的最大贡献 | 目前每个报告 20 项贡献的限制过低。 | 我们愿意考虑拆分报告，而不是根据限制进行截断，而不是增加最大贡献数。随着此提案的不断完善，我们会与生态系统保持密切联系。 |
| 覆盖面报告 | 请求获取跨平台/跨设备报告的覆盖面。覆盖面是品牌广告的一项基本指标。广告客户依靠跨平台/跨设备估算数据来生成覆盖面和频次报告，从而分析其广告系列并分配支出。覆盖面模型使用第三方 Cookie 作为信号来衡量在第三方环境中展示的广告，因此广告技术平台在第三方 Cookie 被弃用后提出了替代解决方案。 |
Privacy Sandbox 团队正在探索相关功能，以便在第三方 Cookie 弃用后支持跨网域覆盖方法。 欢迎 YouTube 广告生态系统提供更多反馈。 |
限制隐蔽跟踪
用户代理缩减/用户代理客户端提示
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| （2023 年第 1 季度也进行了报告）关于其他外形规格的提示 | 请求用户代理客户端提示 (UA-CH)，以提供电视、VR 等其他外形规格 | 我们仍在努力做出一些关键的设计决策（是提供“电视”之类的单一值，还是提供外形规格功能的列表），但对设计这种想法的原型设计依然感兴趣。 |
| 隐私预算 | 如果发送的请求过多，隐私预算限制可能会导致 UA-CH 请求变得不确定。 | 目前，我们没有关于隐私预算提案的新动态，但承诺在第三方 Cookie 被弃用之前，不会限制请求获取 UA 客户端提示的请求。 |
| 网站兼容性 | 网站使用 UA-CH 品牌限制某些浏览器访问网站。 | 有一些有效的品牌列表用例，其中一个就是兼容性。UA 可以免费使用多个品牌来解决这些问题。 |
IP 保护（以前称为 Gnatcatcher）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 欺诈和滥用行为 | 公司可以如何制定 IP 保护反欺诈措施？ | 我们了解防欺诈应用场景的重要性，以及它们可能产生的影响。我们计划在今年夏末发布有关支持反欺诈的更多详细信息。我们正在寻求生态系统方面的反馈，希望能了解我们如何才能更好地支持反欺诈用例。 |
| GeoIP | 详细了解 GeoIP 的测试和部署时间表 | Chrome 最近发布了新信息，详细说明了我们的 GeoIP 计划。我们计划在第三季度发布有关部署时间表的更多信息。我们最初预计会对一小部分流量以用户选择启用功能的形式推出 IP 保护。这样做的原因是，我们知道该提案可能会给公司带来一些重大变更，因此我们希望给生态系统留出一些时间进行调整，在这项功能更广泛地推出之前就能提供反馈。 |
| 账号身份验证 | 通过代理服务器进行帐号身份验证的工作原理是怎样的？ | 我们计划在今年夏末发布有关帐号身份验证的更多详情，不过之前我们已经分享了一些初步注意事项。 |
“反弹跟踪缓解措施”相关提案
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 测试指南 | 有关如何测试跳出跟踪缓解措施的信息 | 我们在 5 月发布了一篇 博文，详细说明了如何测试“反弹跟踪缓解措施”相关测试。 |
| 文档 | 阐明跳出跟踪提案 | 当前方案是一项非常完善的工作，Chrome 团队也会不断更新该提案，以便向生态系统提供清晰明了的信息。我们正在努力提供更多详细信息，欢迎您提供任何其他反馈。 |
| Cookie 删除 | 跳出跟踪缓解措施会删除网域中的所有 Cookie 吗？ | 跳出跟踪缓解措施 (BTM) 将清除所有存储空间和所有缓存，如此处所述。 |
| 规避“跳出跟踪”缓解措施 | 使用弹出式窗口或新标签页执行重定向，可能会绕过跳出跟踪器分类。 | “反弹跟踪缓解措施”规范仍在制定中。到目前为止，我们所关注的大多是同一标签页重定向，但我们计划日后开发弹出式窗口流程。我们欢迎您在此处提供其他反馈。 |
隐私预算
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 邻近区域定位 | 隐私预算可能会影响邻近区域定位用例。 | 我们已收到关于此问题的反馈，希望能详细了解 YouTube 生态系统可能产生的影响。 |
强化跨网站隐私边界
First-Party Set
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| （已在前几个季度中报告）网域限制 | 请求增加关联网域的数量 | Chrome 正在评估“关联子集”的适当数值限制，以便在已确定的用例的隐私保护和实用性之间取得平衡。Chrome 表示，“关联子集”的确切数值尚未最终确定。 |
| 嵌入式用例 | 支持需要 First-Party Set、CHIP 和共享存储空间的嵌入式用例 | Chrome 已收到关于此用例的反馈，我们的团队正在开展调查，欢迎您提供更多反馈。 |
| 代码库管理 | 有关在存在差异或被忽视时从 GitHub 代码库中移除 First-Party Set 的政策信息 | Chrome 已收到关于此使用情形的反馈。我们的团队正在调查，欢迎您提供其他反馈。 |
| 用户培训 | Chrome 应提高用户对 First-Party Set 的认知度和理解，以提高采用率。 | Chrome 致力于向用户介绍 First-Party Set，为此，发布了一篇 帮助中心文章（链接到 Chrome 界面）。Chrome 还致力于继续学习如何在适当的环境中为用户提供最佳的指导。 |
| 发布 3PCD | 弃用第三方 Cookie 后，第三方 Cookie 将继续保留在 First-Party Set 中。 | 虽然 requestStorageAccess 和 requestStorageAccessFor 确实让第三方 Cookie 再次可用于明确定义的特定用例，但它们现在需要网站主动调用，而不是像当前第三方 Cookie（在 Chrome 中）那样默认可用。尽管单个集中的此调用无需用户批准，但用户可以在“设置”中选择停用此行为，以防止出现此情况。 用户可参阅帮助中心文章（链接到 Chrome 界面）了解更多信息。我们计划在现有开发者指南的基础上进行补充，FPS 提升至 100%。 |
| First-Party Set 提交 | 重命名所需的 .well-known/first-party-set 以包含 .json 扩展名。 |
我们进行这项更改是为了确保支持某些网站托管方案。 |
| IANA 注册 | first_party_sets.JSON 应向 IANA 注册 |
我们正在考虑此提案，欢迎您点击此处提供其他反馈。 |
Fenced Frames API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 广告屏蔽 | 使用围栏框架可让广告拦截器更轻松地屏蔽广告。 | 扩展程序可以与围栏框架的互动方式类似于与 iframe 的互动方式。围栏框架要导航到的实际网址对扩展程序也可见，因此它们可以像在 iframe 中那样应用任何网址匹配规则来屏蔽广告。直接无条件地屏蔽所有围栏框架可能会破坏围栏框架的非广告用例。 |
共享存储空间 API
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 采用范围更广 | 共享存储空间应是可在各浏览器上使用的业界标准。 | 我们欢迎并认可此反馈。Chrome 团队将继续积极参与 W3C 论坛，以推进相关提案、征求反馈意见并推动客户采用该提案。 |
| 输出门 | 共享存储空间的输出门控过于有限。 | 我们正在考虑这些反馈，并欢迎生态系统提供其他反馈，说明输出门控有限的原因。 |
| 法规遵从 | 共享存储空间如何处理数据保留政策等法规遵从？ | 共享存储空间可让您灵活地实现和自定义逻辑，以控制任何存储数据的生命周期和有效期。广告技术平台可以根据写入时间戳更新或清除共享存储空间数据。 |
| A/B Testing | 如何对 Shared Storage 和 Protected Audience API 进行 A/B 测试？ | 我们正在努力发布有关此事的更多指南，希望日后分享更多详情。 |
| 共享存储空间上限 | 达到共享存储空间上限后会发生什么情况？ | 如果达到该限制，系统将不会存储进一步的输入。 |
| 对同一网页加载的多次访问 | 如果在同一网页加载时多次访问共享存储空间，会发生什么情况？ | 处理这种情况的最佳方法是使用 window.sharedStorage.append(key, value) 函数。而不是更新每个广告的值，因为如果存在多个广告，可能会导致冲突。附加函数只会将新值添加到原先值的末尾。 |
| iframe 功能 | 在第三方 Cookie 被弃用后，共享存储空间是否会支持某些 iframe 功能？ | 在第三方 Cookie 被弃用后，iframe 中的本地存储将按顶级网站进行分区，但 iframe 本身不会被屏蔽。iframe 本地存储中的数据无法在多个顶级网站上复制，但仍可在 iframe 内使用本地存储。 |
条状标签
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 分区限制 | 每个分区网站 10 KiB 的数据仍然非常庞大，并且希望降低该数量。 | Firefox 已在 CHIPS 方面给出 积极的立场。对于 Webkit 支持，我们建议开发者就 此 GitHub 问题直接向 Apple 提供反馈，告知 Apple 有关分区 Cookie 而非分区存储的使用情形。 |
| 基于身份验证的嵌入 | 由于不同的分区会影响经过身份验证的嵌入，因此 CHIP 可能会影响当前的 SSO 登录流程。 | 我们打算利用 Storage Access API（包含用户提示）来支持经过身份验证的嵌入用例，并且最近发送了 意图原型。 |
| 终身政策 | 可能的生命周期政策是否适用于第一方 Cookie？ | 目前，我们不打算对第一方 Cookie 施加有效期限制。 |
FedCM
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| OAuth 授权支持 | 在授权非配置文件 OAuth 范围方面保持一致 | 我们正在通过 W3C FedID CG 积极征求网络身份社区的意见，以了解在弃用第三方 Cookie 后，支持除基本身份验证之外的授权的最佳方式。 |
| 对 SAML 的支持 | 就 SAML 支持要求达成一致 | 弃用第三方 Cookie 后，该团队正在积极寻求研究和教育社区提供 SAML 支持需求（以及 OpenID Connect 支持）方面的意见。 |
打击垃圾内容和欺诈行为
Private State Token API（和其他 API）
| 反馈主题 | 摘要 | Chrome 响应 |
|---|---|---|
| 探索新信号 | 一些合作伙伴对探索由浏览器促进的设备完整性或用户信任的信号表示积极。一般来说，对于专门构建的新信号足以维持当前的欺诈检测水平，他们也会保持谨慎。 | 我们非常高兴能在反欺诈和网络安全社区中一起探索新的提案，也确认并分享他们的顾虑，这正是“打击垃圾内容和欺诈”成为 Privacy Sandbox 的核心工作流的原因，也是我们继续优先投资于保护网络安全的原因，并致力于改善用户隐私。 |
| PST 正面反馈 | 一些合作伙伴曾表示有兴趣在各种防欺诈或网络安全用例中测试或利用 PST。 | 我们非常高兴听到您的支持，并且有兴趣进一步探索使用 PST 的新解决方案。我们在 Chrome 开发者网站上提供了相关资源和示例代码，欢迎您进一步提供反馈。 |
| 欺诈和滥用行为 | 广告欺诈防范指南 / 在第三方 Cookie 弃用后进行衡量检测的指南（在标识符不再可用时）。 | 我们引入了私密状态令牌等工具，这些工具有助于恢复第三方 Cookie 为防欺诈目的而丢失的部分信号，但目前采用了新的隐私控制机制。我们正在积极投资开发新的反欺诈和反滥用提案，以便通过其他 Privacy Sandbox 变更保留相关功能。 |
| 颁发者到来源信息比率 | 从颁发者到源的信息速率足够高，能够识别唯一身份用户。 | 我们更新了规范，更清楚地说明了可使用私密状态令牌传递哪些用户数据。根据设计，一次最多可以使用 6 个公钥，这些公钥可能代表特定用户的“状态”。这些密钥集每 60 天只能更新一次（除非在需要紧急密钥轮替的极少数情况下），随着时间的推移，联接更多用户数据的可能性会降低。使用任何新的网络 API 时，都会提供实用性与它提供的新用户信息之间的平衡。我们预计 PST 在保护用户隐私的同时，还能实现受第三方 Cookie 弃用影响的关键防欺诈用例，从而取得了适当的平衡。 |
| 提取集成 | fetch 集成既复杂又没有必要。 |
使用 fetch 有利有弊，我们希望在网络生态系统内进一步实现标准化，但我们认为现在还为时过早，直到我们对标准有更深入的了解。当某个标准出现时，我们也承诺以负责任的方式让 Web 开发者过渡到该标准。 |
| 存储位置 | 私密状态令牌密钥配置应存储在与 PrivacyPass 协议相同的位置。 | 在源试用期间进行测试时，开发者表示他们更希望能够灵活地将密钥存储在常规网址上，而不是存储在 .well-known 目录中。PrivacyPass 中的密钥承诺格式并不适合密钥集旨在支持隐式“公共元数据”值的版本。如果 PrivacyPass 的某个变体最终使用公开元数据（采用 POPRF、部分 RSA 盲加密或密钥集）实现标准化，我们可能会改用未来版本的 PST 以支持这一点。 |
| API 的标头实现 | 有关 API 标头实现的问题 | 随着该 API 的标准化以及生态系统使用日渐成熟，我们有望既支持该 API 的标准非标头版本，也有可能最终废弃该标头版本（如果使用率足够低），或者有足够的开发者工具/支持将发布/兑换请求与其他数据相关联的标准方法。我们正在讨论这个问题。 |
| 注册 | 让颁发者向浏览器供应商注册是否切实可行？ | 我们更新了该规范，说明了私密状态令牌的发卡机构注册流程。虽然它采用自己的流程，但与 Privacy Sandbox 其他工作的注册计划类似，我们会要求颁发者就他们打算如何使用 PST 发表公开声明，并认可可保护用户隐私的技术限制。 |