反馈报告 - 2023 年第 2 季度

2023 年第 2 季度季度报告，总结了收到的有关 Privacy Sandbox 提案的生态系统反馈和 Chrome 的回复。

根据对 CMA 的承诺，Google 已同意每季度公开提供有关其 Privacy Sandbox 提案利益相关方互动流程的报告（请参阅承诺的第 12 段和第 17(c)(ii) 段）。这些 Privacy Sandbox 反馈摘要报告是通过汇总 Chrome 从反馈概览中列出的各种来源（包括但不限于 GitHub 问题、privacysandbox.com 上提供的反馈表单、与行业利益相关方举行的会议和 Web 标准论坛）收到的反馈而生成的。Chrome 欢迎从生态系统中获得反馈，并积极探索将所学知识融入设计决策的方法。

反馈主题的排名依据是每个 API 的普遍性。具体方法是汇总 Chrome 团队针对给定主题收到的反馈量，并按数量从高到低排序。我们通过查看公开会议（W3C、PatCG、IETF）、直接反馈、GitHub 以及 Google 内部团队和公开表单中出现的常见问题，确定了常见的反馈主题。

具体而言，我们查看了 Web 标准机构会议的会议记录，并考虑了 Google 的 1 对 1 利益相关方会议记录、各个工程师收到的电子邮件、API 邮寄名单和公开反馈表单，以获取直接反馈。然后，Google 协调了参与这些各种宣传活动的团队，以确定与每个 API 相关的主题的相对普遍性。

关于 Chrome 对反馈的回复的说明是根据已发布的常见问题解答、对利益相关方提出的问题的实际回复，以及专门为此次公开报告活动确定的立场而制定的。我们收到了有关 Topics API、Protected Audience API 和 Attribution Reporting API 的大量问题和反馈，这反映了当前开发和测试的重点。

在当前报告期结束后收到的反馈可能尚未获得 Chrome 团队的回复。

CHIPS
具有独立分区状态的 Cookie
DSP
需求方平台
FedCM
Federated Credential Management
FPS
First-Party Set
IAB
美国互动广告局
IDP
身份提供商
IETF
互联网工程任务组
IP
互联网协议地址
openRTB
实时出价
加时赛
Origin 试用版
PatCG
“私密广告技术”社区群组
RP
依赖方
SSP
供应方平台
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 会进行审核，如果申请获得批准，则会签发邓氏编码。
从源试用版过渡到正式版 从 Origin 试用版转换为正式版会影响当前的 Origin 试用版测试人员吗？ 从 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 目前正在评估其他排名方法，并探索可能有助于提升排名的其他信号。我们会在适当时候向整个生态系统通报修订后的计划。
敏感程度 Topics API 的目标应是确保通过 Topics API 获取或派生的用户信息的个人敏感性低于使用现有跟踪方法派生的信息。 我们认为，Topics API 比现有技术在隐私保护方面有显著优势，可显著限制用户的重标识，并且旨在排除敏感主题。我们承认，主题可以与第一方数据相关联或组合使用来创建敏感类别，但我们认为 Topics API 在保护用户隐私方面迈出了重要一步，并致力于不断改进该 API。
分类结构 向主题分类添加 ID、版本控制和其他元数据结构 目前，API 响应中包含分类 ID。随着我们逐步实现长期治理，建议您查看 Topics 对象，并根据需要添加版本控制方面的其他元数据。
发布商控制 发布商应对其网站应被归入哪些主题有发言权。 网站分类错误可能会使 Topics 信号的整体实用性略有降低，但与任何其他网站相比，被错误分类的具体网站受到的影响不会更大也不会更小。这是因为，网站的情境信息始终可用于其网站上的竞价，即使出现错误分类，也能提供与正确主题类似的信息。欢迎点击此处提供有关此主题的反馈。

允许发布商控制其分类存在风险。网站可能会故意对其网站进行错误分类，降低对所有人的实用性，或者在不太常见的主题中编码敏感含义，从而侵害用户隐私。
Chrome 扩展程序 允许 Chrome 扩展程序管理和过滤主题，类似于当前的 Cookie 管理扩展程序 正如GitHub 上所讨论的，这应该已经可行，但我们欢迎生态系统提供更多反馈。
转换为正式版 从源试用版转换为正式版后，Topics API 会受到什么影响吗？ 从 Origin 试用版转换为正式版的用户不会丢失任何数据。
隐私权 主机名可能包含 Topics API 可能会泄露的私密信息 我们采取了多种措施来确保隐私安全，如本文所述。
欺诈和滥用行为 如何防止通过欺诈性访问操纵主题 点击此处了解缓解措施。
主题分类器 网站可以请求更改其主题分类吗？ 我们希望听取生态系统对此主题的反馈，欢迎在此处提供反馈。
Topics 提供商网站 将托管许多主题内容的特定网站指定为“特殊主题提供商网站”，并根据网页上提供的标记训练分类器。 我们正在讨论此提案，欢迎您提供更多反馈。

Protected Audience API（以前称为 FLEDGE）

反馈主题 摘要 Chrome 回复
流量整形 使用 SSP 驱动的过滤功能优化每秒查询次数 (QPS) 负载的性能影响 我们花了大量时间思考流量整形问题，建议 SSP 利用缓存功能。
测试量 由于 SSP 和 DSP 难以获得大量流量，因此很难测试 Protected Audience。 我们一直在与 SSP 和 DSP 合作伙伴合作，共同采用和测试 Protected Audiences。该功能已正式推出，我们相信，启用 PA 的流量所占的百分比将使合作伙伴更愿意进行测试。
复杂性 实现 Protected Audience 解决方案需要投入大量精力和费用。 我们知道，新技术（包括 Privacy Sandbox）很难采用。Privacy Sandbox 团队正在与众多利益相关方密切合作，为他们提供相关培训和支持，并不断评估其他加速器，以支持生态系统采用 Privacy Sandbox。
可信执行环境 支持非公共云环境中的可信执行环境 (TEE) 虽然我们正在探索除云端解决方案之外可能支持的选项，但鉴于本地安全限制，目前无法支持本地 TEE，因为这需要对 Privacy Sandbox 进行耗时的评估。鉴于 Privacy Sandbox 的安全要求以及本地部署所带来的重大挑战，我们认为，继续扩大和改进基于云的部署（例如，除了 AWS 之外还支持 GCP）对整个生态系统最为有利。不过，我们欢迎您提供更多反馈，说明为何需要这样的要求。
费用结构 与客户端模型相比，出价和竞价服务提案会增加广告技术平台的费用和复杂性。 我们目前正在制定一项指南，用于估算在出价和竞价服务器中支持出价和竞价工作流的费用。该指南将与广告技术平台使用情况相关联，从而实现我们设计的目标之一。
K-Anon 时间轴 何时对 `renderUrl` 强制执行计划的 k-匿名性约束条件？ 我们正在制作有关违规处置时间表的说明，并将很快发布。
runAdAuction 限制 Chrome 能否限制 runAdAuction 只能从顶级页面调用？ 虽然我们的设计完全支持从顶级网页调用 runAdAuction，但我们认为，如果将其限制为只能从顶级网域调用，对发布商而言更为有害。

我们从生态系统中听到了很多反馈，其中特别提到 Privacy Sandbox 需要尽可能减轻发布商和广告主的负担。该反馈与 Web 开发的一般原则相符，即网站所有者可以在运营网站时使用第三方工具。Privacy Sandbox 的目标一直是鼓励打造健康的生态系统，而无需规定发布商和广告技术平台的运作方式。

我们认为，允许发布商选择在其网站上调用 runAdAuction 的方式和人员，可让发布商灵活地找到最符合其需求的途径。
实现方面的支持 Chrome 能否构建或贡献多卖方竞价的开源实现？ Privacy Sandbox 旨在开发不依赖第三方 Cookie 或其他跨网站标识符的隐私保护技术。我们希望鼓励建立健康的生态系统，但无需规定广告技术平台的运作方式。

我们已在 GitHub 代码库中发布了有关这些 API 运作方式的指南，并愿意与业界一起探索解决方案。

我们不打算构建任何特定实现，因为我们的核心职责是构建平台技术，而不是规定使用这些技术的策略。我们的技术将帮助广告技术公司为客户提供卓越的服务，同时为消费者提供适当的隐私保护机制。
多卖家竞价 Chrome 是否会强制与组件竞价共享“内容相关”胜出广告？ Protected Audience API 旨在让发起多卖方竞价的各方能够将信息传递给组件竞价（注意：仅限在发起竞价之前）。

不过，我们发现浏览器无法区分某条信息是否为内容相关性胜出者，因此无法强制屏蔽或要求提供特定信息。
用户对意见征求跟踪的偏好设置 Adtech 询问 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 合作伙伴提出此请求并提供更多详细信息，因为到目前为止，这主要还是 DSP 方面的问题。
更新频率 dailyUpdate 的调用频率（每个兴趣群体每天最多 1 次）可能不适用于某些用例，例如更新商品信息。 感谢您的反馈。还有其他解决方案可让广告技术平台使用以不同节奏刷新的信号，例如 K/V 查询。
广告质量控制 发布商如何实施广告质量控制？ 目前，Protected Audience API 提供了一些功能，可让发布商告知 SSP 他们可以在竞价配置中预出价时建立的特定控件（即基于与广告关联的标签的拒绝名单）。欢迎您就生态系统可能需要的任何其他功能提供反馈。
调试 forDebuggingOnly 功能何时会被移除？ 我们计划弃用 forDebuggingOnly，以应对因第三方 Cookie 弃用而导致的流失事件。我们计划最早在 2026 年弃用胜出事件的 forDebuggingOnly。
跨设备兴趣群体 提案：为经过身份验证的用户代理启用跨设备兴趣群组 我们正在评估此提案，但跨设备定位的高度特定性会带来严重的隐私问题，如此 GitHub 问题中所述。
（也报告在第 1 季度）动态再营销 在第三方 Cookie 弃用后，是否仍可通过 Protected Audience API 实现动态再营销？ 我们认为，此用例可以使用 Protected Audience 实现，如本文所述。
点击“相关数据” 向 browserSignals. 添加与点击相关的数据 我们目前正在请您说明点击发生的时间，以便提供初步排名。
（也将在 2022 年第 4 季度报告）Protected Audience 中的用户定义函数 Protected Audience API 将如何支持用户定义的函数 (UDF)？这些函数可由最终用户编程，以扩展 API 的功能。 提出此问题的广告技术平台还提到，他们仍在评估如何使用 UDF，因此至少在正式发布之前，我们还没有可采取行动的反馈。
币种 货币金额不应使用浮点数表示。 我们已在此处详细介绍了这个问题。
非 DSP 广告选择功能 广告服务器在 Protected Audience API 竞价中发挥着什么作用？ 我们知道，广告服务器要求继续提供出价后广告选择 / 动态广告素材优化服务。我们目前正在评估当前 Protected Audience API 与这些请求之间的详细差距分析。
GenerateBid 支持 Google Ads 的提案，即从 generateBid 返回每个广告兴趣群组的多个候选广告，并在 `scoreAd` 中为这些候选广告评分。 我们目前正在评估此问题。欢迎点击此处提供其他反馈。
竞价订单 Protected Audience API 竞价是否必须是最后一个运行的竞价，以便它可以从所有其他竞价的结果中获取输入？ 没有技术要求要求 Protected Audience API 最后运行。
非用户发起的导航 公开非用户发起的导航 我们正在审核此请求，并在此处讨论 ，欢迎您提供更多反馈。
缓存 如果用户状态发生变化，SSP 不应从缓存中构建给定 DSP 的 perBuyerSignal。 我们了解到，缓存并非适用于 perBuyer 信号的每种用例，因此正在评估其他方案。我们欢迎生态系统就缓存是否适用于其用例提供任何其他反馈。
Attribution Reporting 和 Protected Audience Attribution Reporting API 和 Protected Audience API 如何协同工作？ 目前，Protected Audience API 支持与 Attribution Reporting API 的两种模式（事件级报告和摘要报告）集成。我们已于 6 月 1 日详细介绍了经过改进的 Protected Audience API 与 Attribution Reporting 集成。您可以点击此处了解详情。
服务器端点 在最终设计中，服务器端点是否会是可信汇总服务器？ 服务器端点是由广告技术平台维护的端点，独立于用于处理收集和转换的报告的可信汇总服务器。目前，我们没有计划对报告端点进行任何更改。当前设计旨在确保可汇总的报告本身（包含加密载荷）不会泄露跨网站数据，因此不需要可信端点。另外一个复杂因素是，不同的广告技术平台可能有不同的理想批处理策略。欢迎点击此处提供其他反馈。
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 时，Web-to-app 用例不在其范围内，但我们希望听取生态系统对此用例重要性的看法。
k-匿名性 如何处理 k-匿名性回退 我们正在讨论此问题，欢迎您提供更多反馈。

衡量数字广告的效果

Attribution Reporting API（及其他 API）

反馈主题 摘要 Chrome 回复
其他 VTC 事件级报告配置 关于备选 VTC 事件级报告配置的反馈 我们收到了一些反馈，指出当前的事件级配置不太理想，因此希望您就最佳全局配置提供反馈。我们乐意听取有关此问题的更多反馈，并认为我们的灵活事件级说明文档也有助于解决此问题。
灵活的事件级配置 灵活事件级配置功能的状态如何？ 我们已分享有关灵活事件级配置的文档。此功能仍处于提案阶段，我们希望获得更多反馈，了解该功能对生态系统是否有价值。
灵活的事件级配置 如何协调来自不同方的相互矛盾的报告？ 大多数报告场景都可以通过使用汇总报告来解决，而灵活事件级配置提案专门用于提高事件级报告的灵活性，这些报告最常用于优化用例。我们欢迎您针对此场景提供任何其他生态系统评论/反馈。
来源注册 如果来源注册在触发器注册之后，会怎么样？ 目前，如果来源注册在触发器注册之后发生，则来源和触发器将无法相互归因。这似乎是一个极端情况。我们欢迎您就此问题提供任何其他反馈，如果许多广告技术平台似乎都遇到了此问题，我们会尝试解决此问题。
与多个广告代理机构合作 当广告客户与多个广告代理机构合作时，DSP 如何使用 Attribution Reporting API？ 该 API 支持重定向，因此即使广告客户与多个广告代理机构合作，也可以使用该 API。此外，为了确保该 API 能够加强隐私保护，我们对重定向设置施加了一些限制。我们还针对广告技术平台提出的特定场景，确定了一种可能的解决方法，即使用 Shared Storage API。我们欢迎您就此场景提供任何其他反馈，并将根据这些反馈继续迭代。
目标平台限制 自动刷新的广告用例可能会受到目标平台数量限制的影响。 我们在 5 月 1 日的 WICG 会议中讨论了这个问题，希望就合理的限制值征求反馈。我们在“包含事件级报告的归因报告”说明文档中添加了说明，指出浏览器可以限制来源网站所代表的“目标位置”eTLD+1 的数量。（请参阅拉取请求）。
Attribution Reporting 和 Protected Audience Attribution Reporting API 和 Protected Audience API 如何协同工作？ 目前，Protected Audience API 支持与 Attribution Reporting API 的两种模式（事件级报告和摘要报告）集成。我们已于 6 月 1 日分享了有关改进后的 Protected Audience API 与 Attribution Reporting 集成的更多信息。您可以点击此处了解详情。
灵活的事件级配置 现在，参数可配置，因此我们分享了有关噪声模拟的最佳实践。 我们已在 GitHub 上分享了代码，任何人都可以使用这些代码来评估他们想要测试的任何灵活事件级配置的信息增益和噪声影响。我们非常期待选择使用此代码进行测试并想分享反馈的用户与我们联系。
跨应用和跨网站归因衡量 跨应用和跨网站归因衡量功能何时推出？ 我们于 5 月 9 日宣布了一项通过 Attribution Reporting API 进行跨应用和跨网站归因衡量的实验。虽然我们计划在 Chrome 115 中正式发布相关性和效果衡量 API，但目前不打算在 Chrome 115 中正式发布跨应用和网站归因衡量功能。
删除重复的转化 如何将独立效果衡量解决方案与 ARA 进行对账？ 与当前的标准做法一样，广告客户需要与第三方独立衡量服务提供商合作，以去除转化报告中的重复数据。我们提供了有关如何为事件级报告删除重复转化的资源。
归因报告数据库更新期间的数据丢失 在 Chrome 按照公告更新归因报告数据库时，会丢失任何数据吗？ 从 Chrome 稳定版 115 开始，我们将默认为部分 Chrome 用户启用相关性和效果衡量 API。随着我们监控潜在问题，此功能的正式版发布范围将逐步扩大。我们的目标是在 2023 年第 3 季度之前，在一段时间内达到 100% 的可用性。这与相关性和效果衡量来源试用期结束的时间相吻合。从 7 月开始，测试人员将能够注册以访问这些正式版 API。这样一来，用户在注册后就可以在原始试用版发布和正式版发布之间使用该产品。您的原始试用令牌将在 9 月 19 日之前有效，但我们建议您在该日期之前注册 API，以便顺利完成原始试用，而不中断任何正在进行的测试。

如此公告中所述，更新后，从旧版（M113 及更低版本）注册的数据将不会迁移，因此可能会丢失数据。此数据丢失不会显示在调试报告中，我们会尽量避免从 114 到 115 的数据丢失。
结算 使用归因报告按每次转化费用结算 如这篇文章所述，由于事件级报告和摘要报告中会添加噪声，因此 Attribution Reporting API 可能不适用于按转化费用结算的需求。我们鼓励生态系统参与者在 GitHub 上分享有关 Attribution Reporting API 对各种结算模型有何影响的反馈。

汇总服务

反馈主题 摘要 Chrome 回复
可汇总报告延迟时间更改 在收到生态系统反馈后，对将可汇总报告延迟时间从 [10-60 分钟] 更改为 [0-10 分钟] 的提案的积极回应 我们很高兴看到业界对我们提出的变更有积极的反响，并鼓励业界继续就我们的提案提供反馈。
本地解决方案 汇总服务能否部署在本地数据中心？ 虽然我们正在探索除云端解决方案之外的潜在支持选项，但鉴于本地安全限制，目前无法支持本地 TEE，因为这需要对 Privacy Sandbox 进行耗时的评估。鉴于 Privacy Sandbox 的安全要求以及本地部署所带来的重大挑战，我们认为，继续扩大和改进基于云的部署（例如，除了 AWS 之外还支持 GCP）对整个生态系统最为有利。不过，我们欢迎您提供更多反馈，说明为何需要这样的要求。
重新处理不同时间段的报告 能够重新处理不同时间段的报告 我们曾收到过类似的请求，希望能够按不同的日期范围拆分批次。其中一个提案是允许使用广告技术平台定义的标签扩展共享 ID，以便将报告拆分为不同的批次。我们目前正处于评估此流程的早期阶段，并会随着此提案的演变，及时向生态系统通报最新动态。
可信执行环境的隐私权影响 对可信执行环境的隐私保护影响持积极态度 我们很高兴得知生态系统对我们的提案有积极的反响。在我们不断迭代和开发的过程中，欢迎您提供更多反馈。
服务条款 接受汇总服务条款的截止期限是什么？ 虽然我们尚未指定接受条款及条件的截止期限，但我们鼓励生态系统公司尽快接受条款及条件，以免注册延迟。我们建议公司在有任何疑问时与我们联系。
密钥发现 借助键发现功能，测试人员无需明确列出可能的键组合，即可查询汇总报告，以处理跨广告网络归因的摘要报告，从而提升效果和准确性。 我们目前正在探索可能的解决方案和权宜解决方法，欢迎生态系统提供更多反馈。

Private Aggregation API

反馈主题 摘要 Chrome 回复
举报来源 报告来源是如何定义的？ 报告来源始终是 Private Aggregation 调用方的脚本来源。
128 位密钥空间 明确说明 128 位密钥空间限制 我们将更明确地说明此键空间限制，并解决各个网页之间的不一致问题。我们建议您使用哈希策略来确保不超出此键空间。
每个报告的贡献度上限 目前，每个报告的贡献次数上限为 20 次，此上限过低。 我们可以考虑拆分报告，而不是在达到上限时截断报告，而不是增加贡献内容的数量上限。随着此提案的不断演变，我们将与整个生态系统互动。
覆盖面报告 请求跨平台/跨设备覆盖面报告。覆盖面是品牌广告的基础指标。广告客户依赖于跨平台/跨设备的近似覆盖面和频次报告来分析其广告系列并分配支出。覆盖面模型使用第三方 Cookie 作为衡量第三方环境中展示的广告的信号，因此在第三方 Cookie 被弃用后，广告技术平台要求提供替代解决方案。
 Privacy Sandbox 团队正在探索在弃用第三方 Cookie 后支持跨网域覆盖面方法的功能。
我们欢迎生态系统提供更多反馈。

限制隐蔽跟踪

用户代理缩减/用户代理客户端提示

反馈主题 摘要 Chrome 回复
（也将在 2023 年第 1 季度报告）针对其他外形规格的提示 请求使用用户代理客户端提示 (UA-CH) 提供额外的设备规格，例如电视、VR 我们仍在研究一些关键的设计决策（是提供单个值（例如“TV”）还是提供一系列外形规格功能），但仍然有兴趣对此构想进行原型设计。
隐私预算 如果发送的请求过多，隐私预算限制可能会导致 UA-CH 请求变为非确定性请求。 目前，我们没有关于隐私预算提案的新动态，但我们已承诺，在第三方 Cookie 被弃用之前，不会限制 UA 客户端提示的请求。
网站兼容性 网站使用 UA-CH 品牌限制某些浏览器访问网站。 品牌列表有有效的用例，其中之一就是兼容性。UA 可以自由拥有多个品牌，以解决这些问题。

IP 保护（以前称为 Gnatcatcher）

反馈主题 摘要 Chrome 回复
欺诈和滥用行为 公司如何通过 IP 地址保护功能设置防欺诈措施？ 我们理解防欺诈用例的重要性及其可能对这些用例造成的影响。我们计划在今年夏天晚些时候发布有关支持防欺诈功能的更多详细信息。我们希望生态系统提供反馈，以便我们更好地支持防欺诈用例。
GeoIP 详细了解地理位置信息的测试和部署时间表 Chrome 近期发布了新信息，详细介绍了我们的地理位置信息 (GeoIP) 计划。我们计划在第 3 季度发布有关部署时间表的更多信息。我们预计将 IP 保护功能作为用户选择启用的功能，先面向一小部分流量推出。之所以这样做，是因为我们知道，此提案可能需要公司做出一些重大变更，因此我们希望在更广泛地推出该功能之前，给生态系统留出时间进行调整并提供反馈。
账号身份验证 通过代理服务器进行账号身份验证的具体运作方式是什么？ 我们计划在今年夏天晚些时候发布有关账号身份验证的更多详细信息，不过我们已经分享了一些初步注意事项。

跳出跟踪缓解措施

反馈主题 摘要 Chrome 回复
测试指南 有关如何测试跳出跟踪缓解措施的信息 我们在 5 月份发布了一篇 博文，详细介绍了如何测试跳出率跟踪缓解措施。
文档 反弹跟踪提案中的信息清晰明了 当前提案仍在完善中，Chrome 会继续更新该提案，以便向整个生态系统提供清晰的信息。我们正在努力提供更多详细信息，欢迎您提供任何其他反馈。
删除 Cookie 弹跳跟踪缓解措施会删除网域中的所有 Cookie 吗？ 跳出率跟踪缓解措施 (BTM) 会清除所有存储空间和所有缓存，如此处所述。
规避跳出跟踪缓解措施 通过使用弹出式窗口或新标签页执行重定向，可能会绕过跳出率跟踪器分类。 “反弹跟踪缓解措施”规范仍在开发中。到目前为止，我们主要关注的是同一标签页重定向，但我们计划在未来改进弹出式窗口流程。欢迎点击此处提供其他反馈。

隐私预算

反馈主题 摘要 Chrome 回复
邻近区域定位 隐私预算可能会影响邻近区域定位用例。 我们已收到有关此问题的反馈，希望进一步了解生态系统可能受到的影响。

增强跨网站隐私边界

First-Party Set

反馈主题 摘要 Chrome 回复
（也报告在前几个季度）网域限制 请求扩大关联域名数量 Chrome 正在评估适当的数字上限，以便在已确定的用例中平衡隐私性和实用性。从一开始，Chrome 就表示关联子集的确切数量尚未确定。
嵌入式用例 支持需要使用 First-Party Set、CHIP 和共享存储空间的嵌入式用例 Chrome 已收到有关此用例的反馈，相关团队正在进行调查，并欢迎您提供更多反馈。
代码库管理 有关在存在差异或疏忽时从 GitHub 代码库中移除第一方组合的政策信息 Chrome 已收到有关此用例的反馈。相关团队正在调查此问题，欢迎您提供更多反馈。
用户培训 Chrome 应提高用户对第一方组的认知度和了解度，以推动其采用。 Chrome 致力于向用户介绍第一方集合，并已发布一篇 帮助中心文章（可通过 Chrome 界面访问）。Chrome 还会继续研究如何在适当的上下文中最好地向用户提供指导。
3PCD 后 在第三方 Cookie 被弃用后，第三方 Cookie 将继续存在于第一方 Cookie 集内。 虽然 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 中一样应用任何网址匹配规则进行屏蔽。仅仅无条件屏蔽所有围栏帧可能会破坏围栏帧的非广告用例。

Shared Storage API

反馈主题 摘要 Chrome 回复
更广泛的采用 共享存储空间应是适用于所有浏览器的业界标准。 我们欢迎并感谢您提供此反馈。Chrome 将继续积极参与 W3C 论坛，为该提案提供支持、征求反馈并推动其采用。
输出门 共享存储空间输出门过于有限。 我们正在考虑这些反馈，并欢迎生态系统提供更多反馈，说明输出门过于有限的原因。
法规遵从 共享存储空间如何处理数据保留政策等监管合规性问题？ 借助共享存储空间，您可以灵活地实现和自定义逻辑，以控制任何存储数据的生命周期和到期时间。广告技术平台可以根据写入时间戳更新或清除共享存储空间数据。
A/B 测试 如何针对 Shared Storage API 和 Protected Audience API 进行 A/B 测试？ 我们正在努力发布有关此问题的更多指南，希望日后能分享更多详细信息。
共用存储空间上限 超出共享存储空间上限后会怎么样？ 如果达到此限制，系统将不会再存储其他输入。
在同一网页加载时进行多次访问 如果在同一网页加载期间多次访问共享存储空间，会发生什么情况？ 处理此问题的最佳方法是使用 window.sharedStorage.append(key, value) 函数。而不是更新每个广告的值，因为如果有多个广告，这可能会导致冲突。附加函数只会将新值添加到现有值的末尾。
iframe 功能 在第三方 Cookie 被弃用后，某些 iframe 功能无法正常运行，Shared Storage 是否会支持这些功能？ 弃用第三方 Cookie 后，iframe 中的本地存储空间将由顶级网站进行分区，但 iframe 本身不会被屏蔽。iframe 的本地存储空间中的数据无法跨多个顶级网站复制，但仍可在 iframe 中使用本地存储空间。

CHIPs

反馈主题 摘要 Chrome 回复
分区限制 每个分区网站 10 KiB 的大小仍然很大，希望能缩减。 Firefox 已对 CHIPS 表示 支持。如需 Webkit 支持，我们建议开发者直接通过 此 GitHub 问题向 Apple 提供反馈，说明在哪些用例中分区 Cookie 优于分区存储。
经过身份验证的嵌入 由于不同的分区会影响经过身份验证的嵌入，CHIP 可能会影响当前的 SSO 登录流程。 我们打算利用 Storage Access API（带有用户提示）来支持经过身份验证的内嵌用例，最近已发送 意图进行原型设计。
终身政策 潜在的生命周期政策是否适用于第一方 Cookie？ 我们目前没有计划对第一方 Cookie 施加生命周期限制。

FedCM

反馈主题 摘要 Chrome 回复
OAuth 授权支持 就授予非个人资料 Oauth 范围的授权达成一致 我们正在通过 W3C FedID CG 积极征求 Web Identity 社区的意见，以便在弃用第三方 Cookie 后，除了基本身份验证之外，还能以最佳方式支持授权。
支持 SAML 符合 SAML 支持要求 该团队正在积极征求研究和教育界人士就第三方 Cookie 弃用后 SAML 支持需求（以及 OpenID Connect 支持需求）的反馈。

打击垃圾内容和欺诈行为

Private State Tokens API（及其他 API）

反馈主题 摘要 Chrome 回复
探索新信号 多位合作伙伴对探索浏览器提供的设备完整性或用户信任信号表示了积极态度。通常，他们还会谨慎考虑专用信号是否足以保持当前的欺诈检测水平。 我们很高兴能与反欺诈和网络安全社区一起探索新方案，同时也能了解并分享他们的顾虑。这正是“打击垃圾内容和欺诈行为”一直是 Privacy Sandbox 的核心工作流的原因，也是我们在改善用户隐私保护的同时，继续优先投资于保护网络安全的原因。
对 PST 的正面反馈 多位合作伙伴表示有意测试或利用 PST 来实现各种反欺诈或网络安全用例。 我们很高兴得知您支持并有意进一步探索利用 PST 的新解决方案。您可以访问 Chrome 开发者网站，获取相关资源和示例代码。我们期待收到进一步的反馈。
欺诈和滥用行为 在第三方 Cookie 弃用后，当标识符不再可用时，衡量中广告欺诈防范 / 检测方面的指南。 我们推出了私密状态令牌等工具，这些工具有助于恢复因第三方 Cookie 而丢失的部分信号，以便进行防欺诈保护，但同时还会采用新的隐私控制措施。我们正在积极投资于新的反欺诈和反滥用提案，以便在其他 Privacy Sandbox 变更生效后保留相关功能。
发卡机构与发卡国家/地区信息的比率 发卡机构与来源的信息比率足够高，可以识别唯一身份用户。 我们更新了规范，以更明确地说明可以使用私密状态令牌传输哪些用户数据。设计上，一次最多可以使用 6 个公钥，这可能代表特定用户的“状态”。这些密钥集只能每 60 天更新一次（在极少数情况下需要紧急轮替密钥除外），这会降低随着时间推移联接更多用户数据的可能性。对于任何新的 Web API，都需要在提供的实用性和提供的新用户信息量之间取得平衡。我们估计，在保护用户隐私的同时，PST 可为受第三方 Cookie 弃用影响的关键防欺诈用例提供适当的平衡。
Fetch 集成 fetch 集成复杂且不必要。 使用 fetch 有优点也有缺点，我们希望在 Web 生态系统中进一步实现标准化，但在我们对标准的具体形式有更清晰的认识之前，现在还为时过早。如果有标准出现，我们也将负责任地帮助 Web 开发者过渡到该标准。
存储位置 私密状态令牌密钥配置应与 PrivacyPass 协议存储在同一位置。 在源代码测试期间，开发者表示，他们更希望能够灵活地将密钥存储在常规网址中，而不是在 .well-known 目录中。PrivacyPass 中的密钥提交格式特别不适用于旨在允许使用隐式“公共元数据”值的版本。如果 PrivacyPass 的变体最终采用公开元数据（作为 POPRF、部分 RSA 盲化或密钥集）进行标准化，我们可能会改用未来版本的 PST 来支持该变体。
API 的头文件实现 与 API 的标头实现相关的问题 随着该 API 的标准化和该 API 的生态系统使用成熟，我们有望同时支持该 API 的标准非标头版本，并最终弃用标头版本（如果使用量足够低，或者有足够的开发者工具/支持来以标准方式将发放/兑换请求与其他数据相关联）。我们正在讨论此问题。
注册 让发卡机构向浏览器供应商注册是否可行？ 我们更新了规范，以介绍私密状态令牌的发行商注册流程。虽然它使用自己的流程，但与 Privacy Sandbox 的其余工作类似，我们要求发行商公开声明其打算如何使用 PST，并确认保护用户隐私的技术限制。