Topics API for Web 概览

Topics API 支持针对用户兴趣投放广告 (IBA)，而无需跟踪用户访问的网站。

实现状态

Topics API 是什么？

Topics API 是一种 Privacy Sandbox 机制，旨在保护隐私，同时允许浏览器与第三方分享有关用户兴趣的信息。它可以投放针对用户兴趣的广告 (IBA)，而无需跟踪用户访问的网站。

针对用户兴趣投放广告是 Topics API 中的一个关键概念。这是一种个性化广告，即根据用户最近访问过的网站推断出的兴趣，为其选择广告。这与内容相关广告不同，后者旨在将广告与用户正在访问的网页上的内容进行匹配。

针对用户兴趣的广告对广告客户（想要宣传其产品或服务的网站）和发布商（利用广告帮助其内容创收的网站）都有益：

  • IBA 可以帮助广告客户覆盖潜在客户。
  • IBA 可以补充背景信息，以帮助发布商通过广告为网站提供资金。

Topics API 提供了一种新的针对用户兴趣投放广告的方式，它使用根据近期用户活动分配给浏览器的主题（兴趣类别）。这些主题可以对背景信息进行补充，从而帮助选择合适的广告。

运作方式

过去，人们会使用第三方 Cookie 和其他机制来跟踪用户在各个网站上的浏览行为，从而推断出感兴趣的主题。我们正在逐步淘汰这些机制。

利用 Topics API，浏览器可以根据用户的浏览活动观察并记录用户可能感兴趣的主题。这些信息会记录在用户的设备上。然后，Topics API 便可授权 API 调用方（例如广告技术平台）访问用户感兴趣的主题，但不会透露有关用户浏览活动的额外信息。

观察祖先实体主题

从 Chrome 114 开始，当调用方针对网页上的用户观察到某个主题时，浏览器也会将调用方视为已观察到该主题的所有祖先实体。

例如，如果浏览器记录调用方观察的是用户的 Shopping/Apparel/Footwear/Boots，则也会将其视为已观察到该主题的祖先实体：Shopping/Apparel/Footwear、Shopping/Apparel 和 Shopping。

以前，为了让浏览器将调用方视为已观察到（举例来说）Shopping/Apparel，该特定主题必须作为观察到的主题由 API 返回。这意味着，如果在某个网页上针对用户的调用者观察到 Shopping/Apparel，而在另一个网页上观察到 Shopping/Apparel/Footwear/Boots，则 API 会将 Shopping/Apparel 视为在这两个页面上都观察到了。

周期

当然，Topics API 必须确保其所提供的相关主题始终保持最新状态。浏览器会根据用户在某个时间段（称为一个周期，当前为一周）内的浏览活动推断其主题。每个用户都有自己的周期（周期为“每个用户”），并且初始开始时间是随机的。系统会从用户在每个周期内最感兴趣的前五个主题中随机挑选一个主题作为该时间段的主题。为了进一步加强隐私保护并确保所有主题都得到代表，该主题有 5% 的几率从兴趣分类中所有可能的主题中随机选择。

Topics API 有三项主要任务：

  • 将浏览器活动映射到感兴趣的主题。根据当前的 Topics API 设计，主题是根据用户访问的网页的主机名推断出来的。例如，针对水族箱的网站推断的主题可能是“/宠物与动物/宠物/鱼类与水族箱”。
  • 根据用户的近期浏览活动计算他们最常浏览的主题。
  • 提供访问用户当前感兴趣的主题的机制，帮助选择适当的广告。

Topics API 提供人类可读、易于理解的主题，因此可以为用户提供有意义的控制。

如何挑选和选择主题

主题是从包含层级类别的分类中选择的，例如 /艺术与娱乐/音乐与音频/灵魂与 R&B 和/商业与工业/农业与林业。这些主题已由 Chrome 精选出来进行初始测试，但我们的目标是使分类成为由可信的生态系统贡献者维护的资源。分类必须足够小，以便许多用户的浏览器都可以与每个主题相关联。目前的主题数量为 469，但我们预计最终主题数量在几百到几千之间。

为避免敏感类别，主题必须公开、经过人工挑选，并保持最新状态。Chrome 最初提议进行测试的分类已经过人工挑选，排除了通常被认为敏感的类别，例如民族或性取向。

对于排名前 50,000 个的网站，Chrome 中的 Topics API 实现会使用手动挑选的公开替换列表将主机名映射到主题。对于其他网站，Topics API 使用机器学习模型根据主机名推断主题。

Chrome 的 Topics API 实现会下载表示模型的 TensorFlow Lite 文件，以便在用户设备的本地使用。

您可以访问 TensorFlow Lite 模型文件，以及从 chrome://topics-internals 中推断出的主机名主题。

下图是一个简化示例，演示了 Topics API 如何帮助广告技术平台选择适当的广告。该示例假定用户的浏览器已有将网站主机名映射到主题的模型。

此图显示了 Topics API 生命周期中从用户访问网站到展示广告的各个阶段。
Topics API 生命周期图从简要的角度介绍了 API 操作的各个阶段。

API 调用方仅接收它们观察到的主题

Topics API 的一个设计目标是实现针对用户兴趣投放的广告，而无需与当前与第三方 Cookie 共享信息的实体更多。Topics API 的设计宗旨是，只能针对在有限时间范围内已观察到主题的 API 调用方返回这些主题。如果 API 调用方在 Topics API 已映射到某个主题的网站上包含的代码调用了 document.browsingTopics() 方法，则可以说该调用方已观察到该主题。

该 API 仅返回调用方在最近三个周期内观察到的主题。这有助于阻止与用户共享 API 所取代技术（包括第三方 Cookie）之外的更多实体。

返回的主题数量取决于 API 调用方之前观察到的主题数量，以及用户可用的主题数量（例如累积的数据的周数）。可返回从 0 到 3 个主题的任何值，因为对于最近的三个周期，可以分别指示一个主题

如需详细了解如何使用和测试 Topics API，请参阅 Topics API 开发者指南。

该 API 如何减少数字“指纹”收集

Topics API 提供了多种机制，帮助确保仅使用 Topics API 难以跨网站重新识别大量用户：

  • 由于主题分类提供的主题较为粗略，因此每个主题应该都有大量用户。事实上，每个主题的用户数量下限都有保证，因为返回的主题有 5% 的时间是随机的。
  • 系统会从用户最感兴趣的前五个主题中随机返回这些主题。
  • 如果用户频繁访问同一网站（例如每周），该网站上运行的代码每周最多可以学习一个新主题。
  • 在同一周期内，不同的网站会针对同一用户收到不同的主题。在一个网站上为用户返回的主题与在另一个网站上返回的主题匹配的可能性只有 1/5。这样一来，系统就更加难以确定他们是否为同一用户。
  • 系统每周为用户更新一次主题，这限制了信息的共享速度。换言之，该 API 不会过于频繁地提供主题更新，从而有助于减少数字“指纹”收集。
  • 系统只会为之前曾针对同一用户观察到相同主题的 API 调用方返回相应主题。这种方法有助于限制实体了解（或分享）它们未亲自观察到的用户兴趣相关信息的可能性。

API 如何解决与 FLoC 相关的问题

2021 年 FLoC 源试用获得了广告技术和网络生态系统贡献者提供的各种反馈。特别是，人们担心 FLoC 同类群组可能会被用作识别用户身份的数字“指纹”收集途径，或可能揭示用户与敏感类别的关联。还有一些呼吁让 FLoC 对用户而言更加透明且更易于理解。

Topics API 在设计时就考虑到了这种反馈。该计划旨在探索其他方法来支持针对用户兴趣投放广告，比如更高的透明度、更强的隐私保障，以及针对敏感类别的不同方法。

后续步骤

详细了解具体主题及其工作原理。

如果您是广告技术开发者，请试用并参与 Topics API。如需更多深度资源，请参阅开发者指南。

互动和分享反馈