保护隐私的网页广告点击归因

典型的网站由来自各种来源的众多组件构成。构成网站的许多来源对用户来说是不透明的，一些第三方资源旨在识别和跟踪用户浏览网页的行为，通常是为了重新定向广告和衡量广告活动的效果。

第三方网页跟踪和广告活动衡量的结合，使许多人将网页隐私与无广告网页混为一谈。我们认为这是一种误解。在线广告及其效果衡量，不需要网站 A（您点击广告的网站）知道您在网站 B 上购买了商品。衡量所需的数据仅仅是，某人在网站 A 上点击广告后在网站 B 上进行了购买。

今天，我们推出一项新技术，旨在实现在网页上进行广告点击归因，同时保护用户隐私。我们在设计这项技术时遵循了以下原则：

• 用户不应在跨网站的广告点击归因目的中被唯一识别。这意味着广告点击和转化事件的组合数据不应在网络规模上归因于单个用户。为实现此目的，我们的设计具有以下特性：
  • 每个广告商投放广告的网站上，最多可以并行衡量 64 个广告活动。这个小数字意味着广告活动 ID 不能被转化为用户标识符。
  • 广告商自己的网站上最多可以区分 64 个转化事件。这意味着转化 ID 也被限制，不能被转化为用户标识符。
• 只有用户访问的网站才应参与衡量广告点击和转化。这意味着不透明的第三方不应收到广告点击归因报告，我们通过要求广告链接是第一方网页的一部分，并且仅报告转化发生在哪个第一方网站上来强制执行此规定。
• 浏览器应代表用户行事，并在报告广告点击归因时尽力保护隐私。我们通过以下方式实现这一点：
  • 即使用户处于常规浏览模式，也在专用的隐私浏览模式下发送归因报告。
  • 禁止将 Cookies 等数据用于报告目的。
  • 将报告随机延迟 24 到 48 小时。
  • 当用户处于隐私浏览模式时，完全不支持保护隐私的广告点击归因。
• 浏览器供应商不应知晓用户的广告点击或转化。因此，我们将该功能设计为在设备上完成所有工作。浏览器供应商看不到任何广告点击归因数据。

至关重要的是，我们的解决方案避免信任任何相关方——无论是广告网络、商家还是其他中间方——并大幅限制它们之间传递数据的熵，以防止跟踪标识符的通信。

广告点击归因简述

下面是一个广告点击归因的简单示例：
一家在线商店在搜索引擎网站上投放广告。如果用户点击了广告并最终购买了商品，在线商店和广告投放的搜索引擎网站都希望知道；他们希望将购买行为归因于广告点击，以便商店知道在哪里投入广告预算。这种归因用于衡量哪些广告是有效的。

传统的、侵犯隐私的广告点击归因

传统上，广告点击归因是通过使用 Cookie 和所谓的“跟踪像素”来完成的。以下是其工作原理的说明：

上图显示了用户 John

1. 在 search.example 上搜索“烤架”，
2. 点击一个广告，将其带到 shop.example，以及
3. 最终将一个价值 90 美元的烤架添加到购物车。

在 shop.example 上的每次操作之后，shop.example 都会向 search.example 发送一个跟踪像素（一个对不可见图像的请求），以报告购买进度。

在没有适当隐私保护的浏览器中，每当 shop.example 向 search.example 发送此类跟踪像素时，search.example 都会通过 John 的 Cookie 来识别他。这种普遍存在的技术使得 search.example 能够了解 John 在 shop.example 上以及所有其他发送类似跟踪像素的网站上的所有行为。更糟糕的是，所有这些像素无论 John 是否点击过广告都会触发。

毋庸置疑，携带 Cookie 的跟踪像素使 search.example 等网站能够建立起关于人们兴趣、购买力、习惯、年龄等方面的巨大档案。我们将此称为跨网站跟踪，Safari 通过 WebKit 的智能跟踪预防 (ITP) 功能阻止了这种情况的发生。

随着越来越多的浏览器认识到跨网站跟踪的问题，我们应该期待侵犯隐私的广告点击归因成为历史。

保护隐私的广告点击归因

我们提出了一种现代的广告点击归因方法，它不允许对用户进行跨网站跟踪，但确实提供了衡量在线广告效果的手段。它内置于浏览器本身并在设备上运行，这意味着浏览器供应商无法看到哪些广告被点击或进行了哪些购买。

保护隐私的广告点击归因包含三个步骤：

1. 存储广告点击。这由广告点击时托管广告的页面完成。
2. 将转化与存储的广告点击匹配。这在广告点击后导航到的网站上完成。转化不必在点击后立即发生，也不必发生在特定的着陆页上，只要是同一个网站即可。
3. 发送广告点击归因数据。这在转化与广告点击匹配后由浏览器完成。

让我们详细地介绍这些步骤，以及我们为保护用户隐私所采取的措施。

步骤 1：存储广告点击

锚点元素，通常被称为链接，现在支持两个新的可选属性：adDestination 和 adCampaignID。

如下图所示，adDestination 是广告点击将用户导航到的域，而 adCampaignID 是广告活动的标识符。

如果用户在 search.example 上点击广告链接，浏览器将通过潜在的重定向来跟踪导航，以确保用户实际登陆 shop.example。如果成功，浏览器会存储该广告点击，其中包含以下数据（此处以简单英语呈现）：用户在 search.example 上点击了 shop.example 的广告活动 55。

以下是此步骤的重要隐私方面：

• 该链接需要是第一方网站（主框架）上的一个元素，而不是 iframe 中的链接。这是为了满足用户期望并能够向用户提供控制权。用户只能被期望理解他们在哪个第一方网站上点击了广告，以及在哪个第一方网站上进行了购买。我们还认为，提供广告的第一方网站应该承担广告活动表现的归因，这一点很重要。
• search.example 和 shop.example 都无法读取存储的广告点击数据或检测其是否存在。
• 浏览器只在有限时间内存储广告点击。在 WebKit 的实现中，这个时间是七天。
• 广告活动 ID 的熵需要适当限制，以避免成为跨网站跟踪向量。WebKit 的实现允许值在 0 到 63 之间，即 search.example 上最多可并行运行 64 个 shop.example 广告活动。

步骤 2：将转化与存储的广告点击匹配

为了实现广告点击归因，浏览器需要能够将转化与存储的广告点击匹配。什么是转化？

• 将商品添加到购物车是一种转化。
• 注册新服务是一种转化。
• 输入送货或支付信息是一种转化。
• 最终完成购买是一种转化。

将转化与广告点击匹配，使得 shop.example 能够理解某个特定的广告活动可能有效地促使客户将商品添加到购物车，但在结账流程中却出现了问题。

保护隐私的广告点击归因如何检测转化并将其与存储的广告点击匹配？它利用了传统的跟踪像素！

在上图中，search.example 在其自己的服务器基础设施上将对现有跟踪像素的请求重定向到一个知名位置，以向浏览器表明这实际上是一个正在发生的转化。请注意，ITP 等隐私保护措施通常会确保在此请求中不发送任何 Cookie。

知名位置末尾的路径参数“20”是转化数据。这使得 shop.example 有机会说明关于转化的信息，例如客户在销售漏斗中的位置、转化的价值、发生的时间，或者他们认为任何相关的信息。

重定向到知名位置还可能包含一个可选的优先级参数，该参数指示在多个转化与同一存储广告点击匹配时，该特定转化的重要性。

以下是此步骤的重要隐私方面：

• search.example 和 shop.example 都不知道是否存在任何要匹配的存储广告点击数据。
• 浏览器不会告诉 search.example 或 shop.example 是否存在匹配项。
• 广告转化数据的熵需要适当限制，以避免成为跨网站跟踪向量。WebKit 的实现允许值在 0 到 63 之间，即六位比特来区分转化事件。如前所述，shop.example 决定这些比特中包含什么。例如，他们可能会用两位比特来表示货币价值，分为四个范围：{小于 $10，介于 $10 和 $50 之间，介于 $51 和 $200 之间，高于 $200}。

我们还期望实现一个 JavaScript API，将此信息发送到 .well-known 位置，以消除对跟踪像素的要求，但我们希望公开讨论该 API 中应包含什么，因为它比改造现有跟踪像素更具前瞻性。

步骤 3：发送广告点击归因数据

现在我们来到第三个也是最后一个步骤——浏览器报告之前点击过广告的用户发生了转化。

一旦浏览器将转化与存储的广告点击匹配，它就会设置一个在 24 到 48 小时之间随机的计时器。当计时器触发时，浏览器会向同一个知名位置发出一个短暂的、无状态的 POST 请求。在我们的示例中，该请求将发送到 https://search.example/.well-known/ad-click-attribution/20/55，并将引用方请求头设置为 https://shop.example。

简单来说，这份报告会说：24 到 48 小时前，某位用户在 search.example 上点击了 shop.example 的广告活动 55，并在 shop.example 上完成了转化，转化数据为 20。

一旦短暂的、无状态的 POST 请求发出，存储的广告点击就会被消耗，并且不能进一步转化。这部分解释了为什么我们有 24 小时的最小延迟。在此延迟期间，shop.example 有机会发出进一步的转化信号，例如销售漏斗中的下一步转化，并且只有最重要的转化才会在 POST 请求中发送。重要性通过转化重定向中可选的优先级参数进行控制，如上所述。

以下是此步骤的重要隐私方面：

• search.example 和 shop.example 都不知道归因请求已被安排。
• 24-48 小时的延迟确保了广告点击后不久发生的转化不会允许 search.example 对用户进行推测性画像。延迟的随机性确保了请求本身不会揭示转化发生在一天中的哪个时间。如果 shop.example 想要一天中的时间数据，他们将不得不将部分六位转化数据用于此目的。
• 短暂的、无状态的请求确保该请求不与通过其他浏览建立的状态关联。这里的“短暂”在 Safari 中被称为隐私浏览。
• 如果内容拦截器希望阻止此类转化报告，知名位置允许设定一个简单的规则。

隐私考量

为了实现广告点击归因，需要发送一些关于在两个网站上发生的事情的数据位。今天的广告点击归因实践对数据位没有实际限制，这允许使用 Cookie 对用户进行全面的跨网站跟踪。这是侵犯隐私的行为，因此我们有义务阻止此类广告点击归因在 Safari 和 WebKit 中发生。

但是，通过将归因数据的熵保持在足够低的水平，我们相信报告可以以保护隐私的方式进行。

以下是我们对保护隐私的广告点击归因的隐私考量摘要：

• 只有在第一方页面上提供的链接才能存储广告点击归因数据。这确保了用户有机会理解保护隐私的广告点击归因是如何工作的。
• 广告点击发生的网站和转化发生的网站都不能查看广告点击数据是否已存储、是否已匹配或是否已安排报告。
• 广告点击应仅在有限时间内存储，例如一周。不能期望用户理解他们今天进行的购买归因于几个月前进行的广告点击。
• 广告活动 ID 和转化数据的熵都需要限制到无法重新用于用户跨网站跟踪的程度。我们建议这两种数据各使用六位比特，即值在 0 到 63 之间。
• 广告点击归因请求应随机延迟 24 到 48 小时。这确保了广告点击后不久发生的转化不会允许对用户进行推测性跨网站画像。延迟的随机性确保了请求本身不会揭示转化发生在一天中的哪个时间。
• 浏览器不应保证发送多个广告点击归因请求的特定顺序，因为顺序本身可能被滥用以增加熵并允许对用户进行跨网站跟踪。
• 浏览器应使用短暂会话（也称为隐私模式或隐身模式）来发出广告点击归因请求。
• 浏览器不应在广告点击归因请求或响应中使用或接受任何凭据，例如 Cookie、客户端证书或基本认证。
• 浏览器应提供开启和关闭广告点击归因的方式。我们打算将默认设置设为开启，以鼓励网站转向此技术并放弃一般的跨网站跟踪。
• 浏览器不应在隐私/隐身模式下启用广告点击归因。

在 Safari 技术预览版中试用！

我们很高兴在 Safari 技术预览版 82+ 中提供保护隐私的广告点击归因作为一项实验性功能。

首先，启用“开发”菜单，然后转到“实验性功能”子菜单。

在那里，您会找到“广告点击归因”，它会启用该功能本身；以及“广告点击归因调试模式”，它为开发者启用调试日志记录，并将 24-48 小时的延迟缩短为固定的 1 分钟延迟，也供开发者使用。

调试链接属性

一个希望将广告点击归因数据推送到浏览器中的跨网站锚点元素看起来像这样：
<a href="https://some.site.example" addestination="https://shop.example" adcampaignid="55">

要调试此类元素，请使用 Web Inspector 的控制台，并启用“保留日志”设置。以下是您在归因属性出现问题时可能会看到的一些控制台警告示例：

广告点击归因要正常工作，adcampaignid 和 addestination 都需要设置。

广告点击归因仅在主框架中受支持。

这表示锚点元素不属于主框架。

addestination 不能与当前网站相同。 这项技术旨在用于跨网站的广告点击归因。在同一网站内没有必要使用它。

调试广告点击的存储

要调试锚点元素以外的任何内容，您需要使用系统日志 (syslog)。以下是实现方法：

1. 在“开发”–>“实验性功能”子菜单中启用“广告点击归因调试模式”。
2. 在您的 macOS 终端中，运行：log stream -info | grep AdClickAttribution。

现在，如果您点击一个带有 adDestination 和 adCampaignID 属性的跨网站元素，您应该会在 syslog 中看到以下内容：
正在存储广告点击。

调试转化

转化是通过同站 HTTP 重定向到 /.well-known/ad-click-attribution/[0 到 63 之间的十进制值，表示转化数据]来发出的信号。这里的同站意味着 search.example 需要是将重定向到 https://search.example/.well-known/ad-click-attribution/ 的服务器。这样做的原因是 search.example 应该控制其网站上存储的广告点击何时被消耗。请注意，转化重定向是作为 shop.example 上的子资源完成的，因此我们指的不是与主框架同站。

一旦您执行此类重定向，syslog 可能会出现以下错误消息之一：

转化未被接受，因为 HTTP 重定向不是同站的。 这是前面提到的要求，即必须是 search.example 重定向到 search.example/.well-known/ad-click-attribution/。

转化未被接受，因为它是通过与第一方同站的 HTTP 重定向请求的。 再次强调，这项技术旨在用于跨网站的广告点击归因。在同一网站内没有必要使用它。

转化未被接受，因为 URL 的协议不是 HTTPS，或者 URL 包含一个或多个用户名、密码、查询字符串和片段。 对知名位置的请求必须是 HTTPS，并且不能包含用户名、密码、查询字符串或片段。

转化未被接受，因为 URL 路径未以 /.well-known/ad-click-attribution/ 开头。

转化未被接受，因为转化数据无法解析或高于允许的最大值 63。

转化未被接受，因为 URL 路径包含无法识别的部分。 这是一个包罗万象的错误消息，用于 URL 包含无法识别的路径元素或长度不正确的情况。

检测成功转化

如果您正确地将重定向设置到知名位置，您应该在 syslog 中看到以下消息：
已获取转化，转化数据：20，优先级：0。

这里您看到的是优先级参数。它是服务器发出信号，表明某个特定转化有多重要，以便浏览器可以报告最重要的转化。以销售漏斗为例。在那里，多个转化会接连发生：添加到购物车、输入送货信息、输入支付信息，以及最终完成购买。最有可能的是，最终完成的购买是应该与广告活动 ID 一起报告的转化。优先级可以是 0 到 63，值越高表示优先级越高，并且优先级值仅用于内部簿记，即不会在任何请求中发送。

因此，我们假设重定向是使用转化数据 20 和优先级 12 完成的，如下所示：
https://search.example/.well-known/ad-click-attribution/20/12

现在，如果存在与此转化匹配的存储广告点击，您将在 syslog 中看到详细的转化信息：

已将存储的广告点击转化为转化数据：20，优先级：12。 这表示先前未转化的广告点击已转化为转化。

已用新的转化数据：20 和优先级：12 重新转化了广告点击，因为它具有更高的优先级。 这适用于存在更高优先级的转化，该转化与已安排的转化请求匹配的情况。广告点击被保留，用高优先级转化重新转化，并安排报告。

已用新的转化数据：20 和优先级：12 替换了先前转化的广告点击，因为它具有更高的优先级。 这适用于存在一个不同的广告点击（用户可能点击了多个广告），该广告点击具有已安排的转化请求但优先级较低的情况。新转化的、具有更高优先级的广告点击替换了旧的。

最后，您将在 syslog 中看到报告请求的调度情况：
正在设置计时器，将转化请求的触发时间设为调试模式超时 60 秒，而常规超时时间为 111003 秒。 这是广告点击归因调试模式的特殊情况。 вместо 24 到 48 小时的延迟，只有 60 秒的延迟。日志消息会告知实际延迟时间本应是多少，在本例中约为 31 小时。

接收转化报告

当预设计时器触发时，将向 ./well-known/ad-click-attribution/[转化数据]/[广告活动 ID] 发出 HTTP POST 请求，有效地报告之前点击过相关广告的用户发生了转化。在我们的示例中，此请求将发送到：
https://search.example/.well-known/ad-click-attribution/20/55
…并将 referrer 请求头设置为：
https://shop.example/

当此请求即将发出时，您将在 syslog 中看到以下条目：
即将为转化触发归因请求。

如果请求出现问题，您会在 syslog 中看到它：
广告点击归因请求收到错误：[错误消息]。

反馈和错误报告发送地址

保护隐私的广告点击归因正处于通过 W3C Web 平台孵化器社区组 (WICG) 被提议为标准的早期阶段。请加入讨论并提交问题，以讨论这项技术如何适应您的用例。

如果您发现 Safari 技术预览版中的实验性功能未按说明工作，请在 https://bugs.webkit.org 提交 WebKit 错误报告并抄送 John Wilander。

有关保护隐私的广告点击归因的技术咨询，您可以在 Twitter 上找到我：@johnwilander