Privacy Sandbox on Android 开发者预览版现已推出!了解如何开始使用,并继续提供反馈

归因报告

提供反馈

现在,移动归因和衡量解决方案经常会使用跨方标识符,例如广告 ID。Attribution Reporting API 旨在通过消除对跨方用户标识符的依赖来提供更好的用户隐私保护,并支持跨应用和跨网站进行归因和转化衡量的关键用例。

该 API 具有以下结构机制,这些机制提供了一个用于加强隐私保护的框架,本文档后面几个部分将对其进行更加详细的介绍:

上述机制可限制跨两个不同应用或网域关联用户身份的能力。

Attribution Reporting API 支持以下用例:

  • 转化报告:通过向广告主显示各个维度(例如广告系列、广告组和广告素材)的转化(触发器)次数和转化(触发器)值,协助广告主衡量其广告系列的效果。
  • 优化:通过提供可用于训练机器学习模型的每次展示归因数据,提供有助于优化广告支出的事件级报告。
  • 无效活动检测:提供可用于无效流量和广告欺诈检测与分析的报告。

概括来讲,Attribution Reporting API 的运作方式如下(本文档后面几个部分将对其进行更加详细的介绍):

  1. 广告技术平台完成注册流程,以使用 Attribution Reporting API。
  2. 广告技术平台向 Attribution Reporting API 注册归因来源(广告点击或观看)。
  3. 广告技术平台向 Attribution Reporting API 注册触发器(广告主应用或网站上的用户转化)。
  4. Attribution Reporting API 将触发器与归因来源进行匹配(一种转化归因),并且一个或多个触发器通过事件级报告和可汇总的报告发送到设备外的广告技术平台。

注册广告技术平台

为了使用 Attribution Reporting API 并确保隐私保护机制按预期发挥作用,所有广告技术平台(包括 Google 的广告技术平台)都需要完成一个简易的注册流程。该流程的细节仍在开发中,我们欢迎您提供反馈。

该注册流程可确保广告技术平台不会进行不必要的自身复制操作,即可获取关于用户在网站和应用中的活动的更多信息。例如,对于指定的归因来源和触发器,Attribution Reporting API 会限制广告技术平台可以查看的跟踪数据量和信息量。如需详细了解这些限制,请参阅本文档中后面的在归因报告中查看衡量数据部分。

如果有合理的业务需求(例如运营多个独立的产品线),企业可以注册多次,但不得合并通过多次注册获得的数据来绕过隐私保护限制。

在注册过程中,广告技术平台会提供诸如以下信息:

  • 联系信息和商家信息
  • 用于接收事件级报告和可汇总报告的回传网址
  • Attribution Reporting API 用例

注册归因来源(点击或观看)

Attribution Reporting API 会将广告点击和观看作为归因来源。如需注册广告点击或广告观看,请调用 registerAttributionSource()。该 API 需要以下参数:

  • 归因来源 URI:平台将向此 URI 发出请求,以便获取与归因来源关联的元数据。
  • 输入事件InputEvent 对象(如果是点击事件)或 null(如果是观看事件)。

当该 API 向归因来源 URI 发出请求时,广告技术平台应使用新的 HTTP 标头 Attribution-Reporting-Register-Source 返回归因来源元数据进行响应,其中包含以下字段:

  • Source event ID:一个可对 64 位无符号整数进行编码的 DOMString。该值表示与相应归因来源(广告点击或观看)关联的事件级数据。
  • Destination:一个来源,其 eTLD+1 或应用软件包名称表示触发器事件的发生位置。
  • Expiry (optional):过期时间(以秒为单位),超过该时间后应从设备中删除相应来源。默认值为 30 天,最小值为 2 天,最大值为 30 天。该值会四舍五入到最接近的天数。
  • Source priority (optional):一个有符号的 64 位整数,在有多个归因来源可与指定的触发器相关联时,用于选择该触发器应与哪个归因来源相关联。

    收到触发器后,该 API 会查找来源优先级值最高的匹配归因来源,并生成报告。每个广告技术平台都可以定义自己的优先级策略。

    值越高,表示优先级越高。

  • Install and post-install attribution windows (optional):用于确定安装后事件的归因,本文档后面部分将对其进行介绍。

归因来源元数据响应可能会在以下单独的标头中包含其他数据:

以下代码段显示了归因来源数据的当前设计:

Attribution-Reporting-Register-Source: {
  "source_event_id": "[64 bit unsigned integer]",
  "destination": "[eTLD+1 or app package name]",
  "expiry": "[64 bit signed integer]",
  "source_priority": "[64 bit signed integer]"
}
Attribution-Reporting-Register-Aggregate-Source: <aggregation-key-data>
Attribution-Reporting-Redirects: <Ad tech partner URLs>

以下步骤显示了一个示例工作流程:

  1. 广告技术 SDK 调用该 API 以启动归因来源注册,并指定该 API 要调用的 URI:

    registerAttributionSource(
        Uri.parse("https://adtech.example/attribution_source?my_ad_click_id=123"),
        myClickEvent);
    
  2. 该 API 使用以下标头之一向 https://adtech.example/attribution_source?my_ad_click_id=123 发出请求:

    <!-- For click events -->
    Attribution-Reporting-Source-Info: navigation
    
    <!-- For view events -->
    Attribution-Reporting-Source-Info: event
    
  3. 该广告技术平台的 HTTPS 服务器使用包含以下内容的标头进行回复:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "234",
        "expiry": "60000",
        "source_priority": "5"
    }
    Attribution-Reporting-Redirects: https://adtechpartner1.example?their_ad_click_id=567,
    https://adtechpartner2.example?their_ad_click_id=890
    Attribution-Reporting-Source-Info: navigation
    
  4. 该 API 向 Attribution-Reporting-Redirects 中指定的每个网址发出请求。在本示例中,指定了两个广告技术合作伙伴网址,因此 API 将向 https://adtechpartner1.example?their_ad_click_id=567 发出一个请求,并向 https://adtechpartner2.example?their_ad_click_id=890 发出另一个请求。

  5. 该广告技术平台的 HTTPS 服务器使用包含以下内容的标头进行回复:

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "789",
        "expiry": "120000",
        "source_priority": "2"
    }
    

    请注意,广告技术平台的回复可以在 Attribution-Reporting-Register-Source 标头中指定不同的元数据。

根据前面步骤中显示的请求,注册了三个导航(点击)归因来源。

注册触发器(转化)

广告技术平台可以使用 triggerAttribution() 方法注册触发器,即转化(例如安装或安装后事件)。

triggerAttribution() 方法需要触发器 URI 参数。该 API 会向此 URI 发出请求,以便获取与触发器关联的元数据。

该 API 会跟踪重定向。广告技术服务器响应应包含一个称为 Attribution-Reporting-Register-Event-Trigger 的 HTTP 标头,该标头表示关于一个或多个已注册触发器的信息。标头的内容应经过 JSON 编码,并且包含以下字段:

  • Trigger data:该数据用于识别触发器事件(如果是 3 位,则表示点击;如果是 1 位,则表示观看)
  • Trigger priority (optional):有符号的 64 位整数,表示相应触发器相对于同一归因来源的其他触发器的优先级
  • Deduplication key (optional):有符号的 64 位整数,用于识别以下情况:同一广告技术平台针对同一归因来源多次注册了同一触发器

广告技术服务器响应可能会在以下标头中包含其他数据:

多个广告技术平台可以使用 Attribution-Reporting-Redirects 字段中的重定向或多次调用 triggerAttribution() 方法来注册同一触发器事件。我们建议您使用 Deduplication key 字段,以避免在同一个广告技术平台为同一个触发器事件提供了多个响应时,报告中包含重复的触发器。

以下代码段显示了触发器数据的当前设计:

Attribution-Reporting-Register-Event-Trigger: {
    // trigger_data returned in reports is truncated to the last 1 or 3 bits,
    // based on conversion type
    "trigger_data": "[unsigned 64-bit integer]",
    "trigger_priority": "[signed 64-bit integer]",
    "deduplication_key": "[signed 64-bit integer]"
}
Attribution-Reporting-Aggregate-Trigger-Data: <aggregation-key-data>
Attribution-Reporting-Aggregate-Values: <aggregation-value-data>
Attribution-Reporting-Redirects: <Ad tech partner URLs>

以下步骤显示了一个示例工作流程:

  1. 广告技术 SDK 调用该 API 以启动触发器注册,并提供注册所用的 URI:

    triggerAttribution(
        Uri.parse("https://adtech.example/attribution_trigger?app_install=123"));
    
  2. 该 API 向 https://adtech.example/attribution_trigger?app_install=123 发出请求。

  3. 该广告技术平台的 HTTPS 服务器使用包含以下内容的标头进行回复:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "1122",
        // This returns 010 for click-through conversions (CTCs) and 0 for
        // view-through conversions (VTCs) in reports
        "trigger_priority": "3",
        "deduplication_key": "3344",
    }
    Attribution-Reporting-Redirects: https://adtechpartner.example?app_install=567
    
  4. 该 API 向 Attribution-Reporting-Redirects 中指定的每个网址发出请求。在此示例中,因为仅指定了一个网址,所以该 API 会向 https://adtechpartner.example?app_install=567 发出请求。

  5. 该广告技术平台的 HTTPS 服务器使用包含以下内容的标头进行回复:

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "5566",
        "trigger_priority": "3",
        "deduplication_key": "3344"
    }
    

    根据前面步骤中的请求注册了两个触发器。

采用了来源优先归因算法

Attribution Reporting API 采用了来源优先归因算法,以便将触发器(转化)与归因来源进行匹配。如果多个广告技术平台注册了一个归因来源(如本文档后面部分所述),那么系统会针对每个广告技术平台独立进行这种归因。对于每个广告技术平台,触发器事件都会归因于优先级最高的归因来源。如果存在多个具有相同优先级的归因来源,该 API 会选择最后注册的归因来源。未被选中的所有其他归因来源都会被舍弃,并且不再符合参与未来触发器归因的条件。

安装后归因

在有些情况下,即使最近发生了其他符合条件的归因来源,也需要将安装后触发器归因于促成安装的同一归因来源。

该 API 允许广告技术平台设置安装后归因期,因此可以支持此用例:

  • 注册归因来源时,请指定安装归因回溯期,即预计发生安装事件的时间范围(通常为 2-7 天,可接受的范围为 2-30 天)。
  • 注册归因来源时,请指定安装后归因回溯期,在此期间内的任何安装后触发器事件都应与促成安装的归因来源相关联(通常为 7-30 天,可接受的范围为 0-30 天)。
  • Attribution Reporting API 会验证应用安装发生时间,并在内部按照来源优先归因逻辑将安装归因于相应的归因来源。不过,系统不会将安装事件发送到广告技术平台,也不会计入平台各自的速率限制。
  • 安装后归因回溯期内发生的所有后续触发器都归因于与已验证的安装相同的归因来源,前提是该归因来源符合条件。

    我们正在想方设法支持用户卸载并重新安装应用的用例。

将来,我们可能会探索通过扩展设计来支持更先进的归因模型。

支持基于应用的触发器路径和基于网站的触发器路径的所有组合

借助 Attribution Reporting API,可以对单个 Android 设备上的以下触发器路径进行归因:

  • 从应用到应用:用户在某个应用中看到广告,然后在该应用或已安装的其他应用中完成转化。
  • 从应用到网站:用户在某个应用中看到广告,然后在移动浏览器或应用浏览器中完成转化。
  • 从网站到应用:用户在某个移动浏览器或应用浏览器中看到广告,然后在应用中完成转化。
  • 从网站到网站:用户在某个移动浏览器或应用浏览器中看到广告,然后在同一设备上的同一浏览器或其他浏览器中完成转化。

我们允许网络浏览器支持已在网络上公开的新功能,例如与 Privacy Sandbox for the Web's Attribution Reporting API(可以调用 Android API 来实现跨应用和跨网站进行归因)相似的功能。

为单个归因来源确定多个触发器的优先级

一个归因来源可能会导致多个触发器。例如,购买流程可能会涉及“应用安装”触发器、一个或多个“添加到购物车”触发器和“购买”触发器。每个触发器都会根据来源优先归因算法(本文档后面部分将对其进行介绍)归因于一个或多个归因来源。

可归因于单个归因来源的触发器数量有限制;如需了解详情,请参阅本文档中后面的在归因报告中查看衡量数据部分。如果有多个触发器超出了这些限制,引入优先级逻辑有助于恢复最有价值的触发器。例如,广告技术平台的开发者可能希望优先获取“购买”触发器,而非“添加到购物车”触发器。

为了支持这种逻辑,可以为触发器设置单独的优先级字段,并且在指定的报告期内,在应用限制之前先选择优先级最高的触发器。

允许多个广告技术平台注册归因来源或触发器

有多个广告技术平台接收归因报告的情况很常见。因此,该 API 允许多个广告技术平台注册同一个归因来源或触发器。广告技术平台必须同时注册归因来源和触发器,才能接收来自该 API 的回传。

归因来源

registerAttributionSource() 方法支持归因来源重定向:

  1. 调用 registerAttributionSource() 方法的广告技术平台可以在响应中提供一个额外的 Attribution-Reporting-Redirects 字段,该字段表示合作伙伴广告技术的重定向网址集合。
  2. 然后,该 API 会调用重定向网址,以便合作伙伴广告技术平台可以注册归因来源。

Attribution-Reporting-Redirects 字段中可以列出多个合作伙伴广告技术平台网址,但合作伙伴广告技术平台无法指定自己的 Attribution-Reporting-Redirects 字段。

该 API 还允许不同的广告技术平台各自调用 registerAttributionSource()

触发器

对于触发器注册,系统会以类似方式支持第三方:广告技术平台可以使用额外的 Attribution-Reporting-Redirects 字段,也可以各自调用 triggerAttribution() 方法。

当广告主使用多个广告技术平台来注册同一个触发器事件时,应使用重复信息删除键。重复信息删除键旨在消除这些关于同一事件的重复报告引发的歧义。如果您未提供重复信息删除键,重复的触发器可能会作为不同的触发器回报给每个广告技术平台。

归因示例

在本部分所述的示例中,广告主使用了两个广告投放技术平台(Adtech A 和 Adtech B)和一个衡量合作伙伴 (MMP)。

首先,Adtech A、Adtech B 和 MMP 必须各自完成注册,才能使用 Attribution Reporting API。

下面的列表提供了一系列假设的用户操作(每天发生一个),以及 Attribution Reporting API 如何针对 Adtech A、Adtech B 和 MMP 处理这些操作:

第 1 天:用户点击 Adtech A 投放的广告

Adtech A 使用其 URI 调用 registerAttributionSource()。API 向该 URI 发出请求,并使用 Adtech A 服务器响应中的元数据注册该点击。

Adtech A 还会在 Attribution-Reporting-Redirects 标头中添加 MMP 的 URI。API 向 MMP 的 URI 发出请求,并使用 MMP 服务器响应中的元数据注册该点击。

第 2 天:用户点击 Adtech B 投放的广告

Adtech B 使用其 URI 调用 registerAttributionSource()。API 向该 URI 发出请求,并使用 Adtech B 服务器响应中的元数据注册该点击。

与 Adtech A 一样,Adtech B 同样在 Attribution-Reporting-Redirects 标头中添加了 MMP 的 URI。API 向 MMP 的 URI 发出请求,并使用 MMP 服务器响应中的元数据注册该点击。

第 3 天:用户观看由 Adtech A 投放的广告

API 的响应方式与第 1 天相同,只不过会为 Adtech A 和 MMP 各注册一次观看。

第 4 天:用户安装应用,该应用使用 MMP 来衡量转化

MMP 使用其 URI 调用 triggerAttribution()。API 向该网址发出请求,并使用 MMP 服务器响应中的元数据注册该转化。

MMP 还会在 Attribution-Reporting-Redirects 标头中添加 Adtech A 和 Adtech B 的 URI。API 向 Adtech A 和 Adtech B 的服务器发出请求,并使用服务器响应中的元数据相应地注册该转化。

图 1 说明了上述列表中描述的过程:

图 1. 关于 Attribution Reporting API 如何响应一系列用户操作的示例。

归因过程的工作原理如下:

  • Adtech A 将点击的优先级设为高于观看的优先级,因此将安装归因于第 1 天的点击。
  • Adtech B 将安装归因于第 2 天。
  • MMP 将点击的优先级设为高于观看的优先级,并将安装归因于第 2 天的点击。第 2 天的点击是优先级最高且最近发生的广告事件。

在归因报告中查看衡量数据

Attribution Reporting API 支持以下类型的报告(本文档后面将对其进行更加详细的介绍):

  • 事件级报告可将特定归因来源(点击或观看)与位数有限的高保真度触发器数据相关联。
  • 可汇总的报告不一定与特定归因来源相关联。与事件级报告相比,这些报告可提供更丰富、保真度更高的触发器数据,但这些数据只能以汇总形式提供。

这两种报告互为补充,可以同时使用。

事件级报告

将触发器归因于归因来源后,系统会生成事件级报告,并将其存储在设备上,直到可以在某个报告发送期(本文档后面将对其进行更加详细的介绍)内将其发回到每个广告技术平台的回传网址。

如果只需极少量的触发器相关信息,事件级报告非常有用。对于点击,事件级触发器数据只能有 3 位,这意味着,可以为触发器指定 8 个类别中的一个。对于观看,事件级触发器数据只能有 1 位。此外,事件级报告不支持对高保真度触发器端数据(例如具体价格或触发时间)进行编码。

事件级报告包含诸如以下数据:

  • 目标位置:表示触发器发生位置的广告主应用软件包名称或 eTLD+1
  • 归因来源 ID注册归因来源时使用的同一个归因来源 ID
  • 触发器类型:1 或 3 位低保真度触发器数据,具体取决于归因来源的类型

为事件级报告应用的隐私保护机制

触发器数据的保真度有限

该 API 为浏览型转化触发器提供 1 位数据,为点击触发器提供 3 位数据。归因来源会继续支持完整的 64 位元数据。

您应评估是否以及如何减少触发器中表达的信息,以便能够通过事件级报告中有限的位数来表示。

差分隐私噪声框架

该 API 的目标是,通过使用 k-随机化响应为每个来源事件生成含噪声的输出,使事件级衡量满足本地差分隐私要求。

无论是否要如实报告归因来源事件,都会应用噪声。系统会在设备上注册一个归因来源,归因来源正常注册的概率为 $ p $,并且设备从该 API 的所有可能输出状态(包括完全不报告任何内容,或提供多份虚假报告)中随机选择的概率为 $ 1-p $。

如果满足以下等式,则 k-随机化响应就是一种 epsilon 差分隐私算法:

\[ p = \frac{k}{k + e^ε - 1} \]

如果 ε 的值较低,实际输出会受到 k-随机化响应机制的保护。我们还在对确切的噪声参数进行研究,并且可能会根据反馈进行更改。

可用触发器(转化)方面的限制

每个归因来源的触发器数量有限制,当前方案如下:

  • 1-2 个触发器(如果广告归因来源是观看)
  • 3 个触发器(如果广告归因来源是点击)

这些限制是在考虑了归因来源和触发器的优先级之后应用的。

每个归因来源的广告技术平台数量限制

可与单个归因来源相关联的广告技术平台的数量有限制。这些限制是在考虑了归因来源和触发器的优先级之后应用的。

发送报告的具体时间范围

对于广告观看这种归因来源,报告会在来源过期 1 小时后发送。您可以配置此过期天数,但它不能少于 2 天,也不能超过 30 天。

广告点击这种归因来源的报告无法配置,并且在来源过期之前的指定时间点(相对于来源注册时间的时间点)发送。从归因来源注册到过期之间的时间会拆分为多个报告期。每个报告期都有一个截止时间(从归因来源注册时间算起)。在每个报告期结束时,设备都会收集自上一个报告期以来发生的所有触发器,并发送定期报告。该 API 支持以下报告期:

  • 2 天:设备会收集归因来源注册后最多 2 天内发生的所有触发器。报告会在归因来源注册 2 天零 1 小时后发送。
  • 7 天:设备会收集归因来源注册后 2 到 7 天内发生的所有触发器。报告会在归因来源注册 7 天零 1 小时后发送。
  • 自定义时长,由归因来源的“expiry”属性定义。报告会在指定过期时间过去 1 小时后发送。该值不能少于 2 天,也不能超过 30 天。

可汇总的报告

事件级报告相比,可汇总的报告可以更快地提供来自设备的保真度更高的触发器数据。这些保真度更高的数据只能以汇总方式获取,并且不会与特定触发器或用户相关联。汇总键最多可为 128 位,这使得可汇总的报告支持报告诸如以下用例:

  • 关于触发器值(如收入)的报告
  • 处理更多触发器类型

此外,可汇总报告使用与事件级报告相同的来源优先归因逻辑,但支持更多归因于点击或观看的转化。

关于 Attribution Reporting API 如何准备和发送可汇总报告的总体设计(如图 1 所示)如下:

  1. 设备向广告技术平台发送加密的可汇总报告。
  2. 广告技术平台向汇总服务发送一批可汇总的报告以进行汇总。
  3. 汇总服务读取一批可汇总的报告,然后对其进行解密和汇总。
  4. 最终的汇总数据发回到广告技术平台。
图 1. Attribution Reporting API 准备和发送可汇总的报告时遵循的流程。

可汇总的报告包含以下与归因来源相关的数据:

  • 来源:表示广告投放位置的应用软件包名称或 eTLD+1 网址。
  • 目标位置:表示触发器发生位置的应用软件包名称或 eTLD+1 网址。
  • 日期:以归因来源表示的事件的发生日期。
  • 载荷:触发器值,以加密的键值对形式收集,在可信的汇总服务中用于计算汇总数据。

汇总服务

以下服务提供了汇总功能,并且有助于防范对汇总数据的不当访问。

这些服务由不同的负责方(本文档后面将对其进行更加详细的介绍)进行管理:

  • 汇总服务是广告技术平台预计会部署的唯一服务。
  • 密钥管理隐私预算服务由称为“验证方”的可信方运行。这些验证方负责验证运行汇总服务的代码是否为 Google 提供的公开代码,并验证所有汇总服务用户是否享受相同的密钥和预算服务。
汇总服务

广告技术平台必须提前部署基于 Google 提供的二进制文件的汇总服务。

该汇总服务在托管于云端的可信执行环境 (TEE) 中运行。TEE 具有以下安全优势:

  • 它可确保在 TEE 中运行的代码是由 Google 提供的特定二进制文件。除非满足此条件,否则汇总服务无法获取运行所需的解密密钥。
  • 它可为运行中的进程提供安全保障,使其免于被外部监控或篡改。

这些安全优势使得汇总服务可以更安全地执行敏感操作,例如访问加密数据。

如需详细了解汇总服务的设计、工作流程和安全注意事项,请参阅 GitHub 上的汇总服务文档

密钥管理服务

这项服务负责验证汇总服务运行的是否为经过批准的二进制文件版本,如果是,则为广告技术平台中的汇总服务提供其触发器数据的正确解密密钥。

隐私预算服务

这项服务负责跟踪广告技术平台的汇总服务访问特定触发器(可以包含多个汇总键)的频率,并限制为仅可以访问适当数量的解密数据。可以对每个触发器执行一次解密。

Aggregatable Reports API

用于为可汇总的报告创建贡献内容的 API 使用的基本 API 与为事件级报告注册归因来源时使用的基本 API 相同。以下部分介绍了该 API 的扩展。

注册可汇总的来源数据

当该 API 向归因来源 URI 发出请求时,广告技术平台可以使用新的 HTTP 标头 Attribution-Reporting-Register-Aggregate-Source 进行响应,借此注册一个汇总键列表。对于每个汇总键,该列表中都包含以下字段:

  • Source event ID:键名称字符串。用作联接键,与触发器端键组合在一起后形成最终键。
  • Key piece:键的位串值。
  • Key offset:一个表示偏移索引的整数值,用于将此键部分与触发器端键部分组合在一起。

最终键是此部分和触发器端部分的组合,使用 key offset 字段来串联位串。最终键不得超过 128 位;如果键超过 128 位,则会被截断。

在下面的示例中,广告技术平台使用该 API 收集以下信息:

  • 在广告系列级汇总转化次数
  • 在地理位置级汇总购买价值
Attribution-Reporting-Register-Aggregate-Source:
[{
  // Generates a "101011001" key prefix named "campaignCounts".
  "source_event_id": "campaignCounts",
  "key_piece": "101011001", // User saw ad from campaign 345 (out of 511).
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
},
{
  // Generates a "101" key prefix named "geoValue".
  "source_event_id": "geoValue",
  // Source-side geo region = 5 (US) but pad with 0s since the shop operates in
  // ~100 separate countries.
  "key_piece": "0000101",
  "key_offset": 0 // The first part of the key
                  // when combined with trigger-side keys.
}]

注册可汇总的触发器

触发器注册包括两个额外的标头。

第一个标头用于在触发器端注册一个汇总键列表。广告技术平台应使用 HTTP 标头 Attribution-Reporting-Aggregate-Trigger-Data 进行响应。对于每个汇总键,该列表中都包含以下字段:

  • Key piece:键的位串值。
  • Key offset:一个整数值,在将归因来源键部分与触发器键部分进行组合时用作偏移索引。
  • Source keys:一个字符串列表,其中包括归因来源端键的名称,触发器键应与这些键组合在一起以形成最终键。

以下代码段依然采用在可汇总的报告中注册汇总来源数据中的示例:

Attribution-Reporting-Aggregate-Trigger-Data:
[
  // Each dictionary independently adds pieces to multiple source keys.
  {
    "key_piece": "10",// Conversion type purchase = 2
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 9,
    // Apply this suffix to:
    "source_keys": ["campaignCounts"]
  },
  {
    "key_piece": "10101",// Purchase category shirts = 21
    // Combine key piece at offset index 9 with attribution source key piece.
    "key_offset": 7,
    // Apply this suffix to:
    "source_keys": ["geoValue" ]
  }
]

第二个标头用于注册应对每个键有贡献的值的列表。广告技术平台应使用 HTTP 标头 Attribution-Reporting-Aggregate-Values 进行响应。

每个触发器都可以对可汇总的报告做出多项贡献。对任何指定归因来源的贡献总量受 $ L1 $ 参数制约,对于指定的归因来源,对所有汇总键的贡献(值)的总和不得超过该参数。超过这些限制会导致未来的贡献悄然下降。初始方案是将 $ L1 $ 设为 $ 2^{16} $ (65536)。汇总服务中的噪声会按照与此参数成一定比例进行缩放。因此,建议根据分配给指定汇总键的 $ L1 $ 隐私预算部分,适当缩放为指定汇总键报告的值。该方法有助于确保,在应用了噪声时,汇总报告能够尽可能保持较高的保真度。这种机制非常灵活,可以支持多种汇总策略。

在以下示例中,通过在 campaignCountsgeoValue 之间分配 $ L1 $ 贡献,将在这两者之间平均分配隐私预算:

Attribution-Reporting-Aggregate-Values:
{
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
    "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
    "geoValue": 1664
}

上面的示例生成了以下汇总计数:

[
  // campaignCounts:
  {
    // The attribution source key piece "101011001" (offset 0)
    // is concatenated with  "10" (offset 9) trigger key piece to form
    // the final key "10101100110" = 1382.
    "key": "1382",
    "value": 32768
  },
  // geoValue:
  {
    // The attribution source key piece "0000101" (offset 0)
    // is concatenated with  "10101" (offset 7) trigger key piece to form
    // the final key "000010110101" = 181.
    "key": "181",
    "value": "1664"
  }
]

可以反转缩放比例以获得正确的值,即应用的模除噪声:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

差分隐私

该 API 的一个目标是拥有一个可以支持差分隐私汇总衡量的框架。这可以通过添加与 $ L1 $ 预算成比例的噪声来实现,例如拾取具有以下分布的噪声:

\[ Laplace(\frac{ε}{L1}) \]

未来的注意事项和待解决的问题

Attribution Reporting API 正在开发中。此外,我们还在探索未来可能会推出的功能,例如非最终点击归因模型和跨设备衡量用例。

此外,我们希望就以下几个问题向社区征求反馈:

  1. 我们计划允许多个广告技术平台注册归因来源和触发器,以便实现第三方衡量。在我们当前的方案中,只有发起 API 调用的广告技术平台可以指定第三方广告技术平台列表。为了简化我们的 API 设计,我们可以改为仅指定下一个广告技术平台,来允许广告技术平台进行菊花链重定向。
  2. 为了启用“从应用到网站”衡量(触发器可以发生在应用或网站中),广告技术平台需要在归因来源和触发器注册中提供相同的目标位置字段。我们正在评估使用网站 eTLD+1(即使触发器发生在应用中)是否合理。
  3. 为了防止生成重复的触发器报告,如果广告技术平台多次注册同一触发器,我们建议您使用重复信息删除键。我们正在评估应用是否可以将这种重复信息删除键传递给所有广告技术平台,包括第三方平台。
  4. 对于归因来源注册,我们正在评估提议的第三方和重定向设计(包括自归因网络的设计)是否可行。特别是,我们想知道您是否需要清楚看到重定向路径中的每个人。
  5. 我们正在评估有多个归因来源(一些基于网络,一些基于应用)导致触发的情况,以及是否存在任何需要发生的特殊归因。
  6. 注册归因来源时,广告技术平台只能指定一个应用目标。我们想知道这是否适合您的用例。
  7. 我们想知道您是否具有需要 API 为经过验证的安装发送报告的用例。这些报告会计入广告技术平台各自的速率限制。