什么是汇总键、它们在 Attribution Reporting API 中的使用方式,以及您如何将目标转化为键。
作为一家广告技术公司,您需要在多个地理位置投放针对不同产品类别的广告系列,您需要帮助广告客户回答以下问题:
- 我的各个广告系列在每个地理区域内为每种产品类别带来了多少次购买?
- 我的各个广告系列在各个地理区域中为每种产品类别带来了多少收入?
虽然许多广告技术公司都鼓励广告主配置多种转化类型,但将重点放在最重要的转化(例如购买)上,可以确保针对这些重要事件提供详细而准确的摘要结果。
为此,您需要在收集数据之前考虑好要回答哪些问题。
维度、键和值
要解答这些问题,我们来看一下维度、键和值。
尺寸
要了解广告系列是如何带来收入的(如此处所述),您需要跟踪以下维度:
- 广告系列 ID:特定广告系列的标识符。
- 地理位置 ID:投放广告的地理区域。
- 商品类别:您定义的商品类别。
虽然广告投放(广告投放时间)时“广告系列 ID”和“地理位置 ID”维度是已知的,但用户完成转化(转化时间)时,可以从触发事件知道产品类别。
在此示例中,您想跟踪的尺寸如下图所示:
什么是汇总键(存储分区)?
术语“汇总键”和“存储分区”指的是同一个概念。汇总键在用于配置报告的浏览器 API 中使用。“存储分区”一词用于可汇总报告和摘要报告以及汇总服务 API。
汇总键(简称“键”)是一段数据,用于表示所跟踪的维度的值。系统随后会沿着每个汇总键汇总数据。
例如,假设您正在跟踪“产品类别”、“地理位置 ID”和“广告系列 ID”维度。
位于地理位置 ID 7 的用户在看到广告系列 ID 12 的广告后,通过购买产品类别 25 中的产品完成了转化,那么您可以设置如下图所示的汇总键:
稍后您会看到,在实践中,汇总键看起来并不像这样,但现在我们重点了解该键中包含的信息。
什么是可汇总的值?
要解答您针对我们概述的维度所提出的问题,您需要提供以下信息:
- 购买次数(购买交易次数)。一旦汇总并显示在摘要报告中,就会成为总购买次数(摘要值)。
- 每次购买带来的收入(购买价值)。汇总报告并在摘要报告中显示后,这将是总收入(摘要值)。
其中每种转化(一次转化的购买次数和一次转化的购买价值)都是可汇总的价值。您可以将可汇总的值视为衡量目标的价值。
问题 | 可汇总的价值 = 衡量目标 |
---|---|
进行多少次购买交易... | 购买交易数量 |
收入是多少... | 购买价值 |
位于地理位置 ID 7 的用户看到广告系列 ID 12 的广告,后来又花 120 美元购买了“产品类别 25”的产品(假设您的货币为美元)而完成了转化,那么您可以设置如下所示的汇总键和可汇总值:
系统会针对多个用户的每个键对可汇总的值进行求和,以生成汇总的数据分析,并在摘要报告中以摘要值的形式生成汇总值。
对可汇总的值进行求和,以生成与您的衡量目标相关的汇总数据分析。
请注意,此图省略了解密,代表了一个未应用噪声的简化示例。在下一部分,我们将概述这个带有噪声的示例。
从键和值到报告
现在,我们来讨论一下可汇总的键和值与报告之间的关系。
可汇总的报告
当用户点击或查看广告并在稍后完成转化时,您会指示浏览器存储一个 {aggregate key, aggregatable value} 对。
在我们的示例中,当用户点击或查看广告并在稍后完成转化时,您指示浏览器生成两次贡献(每个衡量目标一个)。
稍后您会看到,{aggregate key, aggregatable value} 可汇总报告并不完全是这样的。不过,现在我们重点看报告中包含的信息。
当您指示浏览器生成两次贡献时,浏览器会生成可汇总报告(如果报告可以将转化与之前的浏览或点击相匹配)。
可汇总报告包含:
- 您已配置的字幕稿。
- 关于点击或观看事件和转化事件的元数据:转化发生的网站等。查看可汇总报告中的所有字段。
可汇总报告采用 JSON 格式,其中包括一个载荷字段,将用作最终摘要报告的数据输入。
载荷包含一系列贡献,其中每个贡献都是一个 {汇总键, 可汇总的值} 对:
- 存储分区:聚合键,编码为字节串。
- value:相应衡量目标的可汇总值,以字节串编码。
示例如下:
{
"data": [
{
"bucket": "111001001",
"value": "11111010000",
}
],
"operation": "histogram"
}
在实践中,可汇总报告的编码方式会使存储分区和值看起来与前面的示例不同(即存储分区可能看起来像 \u0000\u0000\x80\u0000
)。Bucket 和 value 都是字节串。
摘要报告
下面汇总了许多浏览器和设备(用户)的可汇总报告:
- 广告技术平台请求针对一组给定键以及一组来自多个不同浏览器(用户)的给定可汇总报告的摘要报告。
- 可汇总报告由汇总服务解密。
- 对于每个键,系统会汇总可汇总报告中的可汇总值。
- 向汇总值添加噪声。
系统会生成包含一组 {aggregate key, summary value} 对的摘要报告。
摘要报告包含一组 JSON 字典样式的键值对。每个键值对均包含:
- 存储分区:聚合键,编码为字节串。
- value:指定衡量目标的十进制摘要值,对所有可用的可汇总报告进行求和,并添加了额外的干扰数据。
例如:
[
{"bucket": "111001001", "value": "2558500"},
{"bucket": "111101001", "value": "3256211"},
{...}
]
实际上,摘要报告的编码方式会使存储分区和值看起来与示例中所述的不同(即存储分区可能类似于 \u0000\u0000\x80\u0000
)。bucket 和 value 都是字节字符串。
汇总键的实际运用
汇总键(存储分区)由广告技术公司定义,通常分为两个步骤:用户点击或观看广告,以及用户完成转化。
密钥结构
我们将使用“键结构”这一术语来指定编码到键中的维度集。
例如,广告系列 ID x 地理位置 ID x 产品类别就是一个关键结构。
密钥类型
系统会针对指定键在多个用户/浏览器上对可汇总值进行求和。但我们发现可汇总价值可以跟踪不同的衡量目标,如购买价值或购买次数。您希望确保汇总服务会对同一类型的可汇总值求和。
为此,请在每个键中对一段数据进行编码,以告诉您摘要值所表示的内容(即该键所指的衡量目标)。一种方法是为您的键额外创建一个维度来表示衡量目标类型。
在前面的示例中,此衡量目标类型将具有两个不同的可能值:
- “购买次数”是第一种衡量目标。
- 购买价值是第二种衡量目标。
如果您有 n 个衡量目标,那么相应衡量目标类型将有 n 个不同类型的值。nn
您可以将键的维度视为一种指标。例如,“针对每个地理位置,每个广告系列对特定产品的购买次数”。
键大小、维度大小
密钥的最大大小以位为单位,即创建完整密钥时零和 1 的二进制数。该 API 支持的密钥长度为 128 位。
此大小允许非常精细的键,但更精细的键更有可能产生更多噪声值。如需详细了解噪声,请参阅了解噪声。
如前所述,维度编码到汇总键中。每个维度都有特定的基数,即一个维度可以采用的不同值的数量。每个维度都需要由特定数量的位表示,具体取决于其基数。使用 n 位时,可以表示 2^n 个不同的选项。nn
例如,一个“国家/地区”维度的基数可能是 200,因为世界上有大约 200 个国家/地区。对此维度进行编码需要多少位?
7 位只会存储 2^7 =128 个不同的选项,少于必要的 200 个。
8 位将存储 2^8 =256 个不同的选项,多于必要的 200 个选项,因此您可以使用 n=8 位来对此维度进行编码。
键编码
在浏览器中设置密钥时,它们应采用十六进制编码。在摘要报告中,键将以二进制形式显示(并作为命名的存储分区)。
设置完整密钥的两个关键部分
假设您使用键跟踪以下维度:
- 广告系列 ID
- 地理位置 ID
- 产品类别
虽然投放广告(广告投放时间)时广告系列 ID 和地理位置 ID 维度是已知的,但产品类别可以在用户完成转化(转化时间)时触发事件中得知。
在实践中,这意味着您需要通过两个步骤设置键:
- 您需要在点击或查看时设置该键的一部分:广告系列 ID x 地理位置 ID。
- 您需要在转化时设置键的第二部分:产品类别。
这些按键的不同部分称为“按键部分”。
密钥通过对密钥片段的 XOR (^) 进行计算。
例如:
- 来源端键部分 =
0x159
- 触发器端键部分 =
0x400
- 键 =
0x159 ^ 0x400 = 0x559
对齐关键部分
两个 64 位密钥部分使用精心放置的 64 位填充器/偏移(16 个零)扩展至 128 位,因此 XOR 密钥部分等同于将它们串联起来,这样更便于推理和验证:
- 来源端键部分 =
0xa7e297e7c8c8d0540000000000000000
- 触发器端键部分 =
0x0000000000000000674fbe308a597271
- 键 =
- 0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 =
- 0xa7e297e7c8c8d054674fbe308a597271
每次广告点击或观看有多个键
在实际操作中,您可以为每个归因来源事件(广告点击或观看)设置多个键。例如,您可以设置:
- 用于跟踪地理位置 ID x 广告系列 ID 的键。
- 跟踪广告素材类型 x 广告系列 ID 的另一个键。
我们来看看策略 B 中的另一个示例。
将维度编码为键
请求摘要报告时,您需要告知汇总服务您要访问哪些指标,方法是请求获取一组特定汇总键的摘要报告。
摘要报告包含原始 {key, summary value} 对,并且不包含与该键有关的其他信息。这意味着:
- 如果将键设置为在用户查看或点击广告并在稍后完成转化时设置,您需要根据它们所代表的维度的值可靠地设置键。
- 在定义您想请求摘要报告的键时,您需要根据想要查看汇总数据的维度值,可靠地即时生成或访问这些键,与用户查看/点击广告以及完成转化时设置的键相同。
使用键结构映射对维度进行编码
要将维度编码为键,您可以在定义键时(在广告投放时间之前)提前创建和维护键结构映射。
键结构映射表示您的每个维度及其在键中的位置。
实际上,创建和维护按键结构映射意味着您必须实现和维护解码器逻辑。如果您正在寻找不需要执行此操作的方法,请考虑改用基于哈希的方法。
示例如下:
假设您打算跟踪特定广告系列、地理区域和产品的购买和购买价值。
产品类别、地理位置 ID 和广告系列 ID 必须是键中的维度。此外,由于您想要跟踪两个不同的衡量目标(购买次数和购买价值),因此您需要在键中添加一个用于跟踪键类型的维度。这样,您就可以定义在摘要报告中收到 {key, aggregatable value} 对时可汇总的值实际表示的内容。
设定这些衡量目标后,您的键具有以下维度:
- 产品类别
- 衡量目标类型
- 地理位置 ID
- 广告系列 ID
现在,查看各个维度时,假设您的应用需要跟踪以下内容:
- 29 个不同的产品类别。
- 北美洲、中美洲、南美洲、欧洲、非洲、亚洲、加勒比海和大洋洲。
- 16 个不同的广告系列。
以下是对键中的每个维度进行编码所需的位数:
- 商品类别:5 位 (2^5 = 32 > 29)。
- 衡量目标类型:1 位。衡量目标是购买次数或购买价值,这意味着两种不同的可能性;因此,一个位数就足够了。
地理位置 ID:3 位 (2^3 = 8)。您还可以为地理位置 ID 定义一个维度映射,以便了解每个二进制值代表的地理区域。您的“地理位置 ID”维度的维度映射可能如下所示:
密钥中的二进制值 地理位置 000 北美洲 001 中美洲 010 南美洲 011 欧洲 100 非洲 101 亚洲 110 加勒比人 111 大洋洲 广告系列 ID:4 位 (2^4 = 16)
遵循此结构的键将为 13 位(5 + 1 + 3 + 4)。
在此示例中,这些键的键结构映射将如下所示:
键中的维度顺序由您决定。
为了说明维度是如何构成键结构的,我们将使用二进制表示法,因此,广告系列 ID(第 1 位)位于最右边,而商品类别(最后位)位于最左边。
在每个维度中,最高有效位(携带最大数值的位)是最左边的位。最低有效位(携带最小数值的位)是最右边的位。
我们来看看如何使用键结构映射来解码键。
我们以 0b1100100111100 作为任意示例键,并假设您知道该键遵循上图中的键结构映射。
根据键结构映射,此键将解码为:
11001 0 011 1100
因此,键 0b1100100111100 表示在欧洲发布的广告系列 ID 12 的商品类别 25 的购买次数。
使用哈希函数对维度进行编码
您可以使用哈希函数,以一致且可靠的方式动态生成键,而不是使用键结构映射。
工作原理如下:
- 选择一种哈希算法。
- 在投放广告时,生成一个字符串,其中包含要跟踪的所有维度及其值。要生成源端键段,请对此字符串进行哈希处理,并考虑添加 64 位的零后缀,以便将其与触发器端键段对齐,并使 XOR 更易于推断。
- 来源端键部分
= <64 位十六进制哈希值("COUNT, campaignID=12, geoID=7"))><64 位 00000000...> - 请注意,COUNT 与键结构映射方法中 measurementGoalType=0 的编码相同。COUNT 更精简、更明确。
- 来源端键部分
- 在转化时,生成一个字符串,其中包含要跟踪的所有维度及其值。如需生成触发器端键段,请对此字符串进行哈希处理,并添加 64 位零前缀:
- 触发器端键部分 = <64 位 00000000...><64 位十六进制哈希值("productCategory=25")>
- 浏览器对这些关键部分进行 XOR 运算以生成密钥。
- 128 位汇总密钥
= <64 位十六进制源端密钥段哈希值><64 位十六进制源端密钥段哈希值>
- 128 位汇总密钥
- 稍后,当您准备好请求此密钥的摘要报告时,即可即时生成该报告:
- 根据您感兴趣的维度,像先前一样生成来源端和触发器端键部分。
- 来源端键部分
= <64 位十六进制哈希值("COUNT, campaignID=12, geoID=7"))><64 位 00000000...> - 触发器端键部分
= <64 位 00000000...><64 位十六进制哈希值("productCategory=25")> - 触发器端键部分 = toHex(hash("productCategory=25"))
- 来源端键部分
- 与浏览器一样,对这些关键部分进行 XOR 运算,以生成浏览器之前生成的相同密钥。
- 128 位汇总键
= <64 位源端密钥片段哈希><64 位源端密钥片段哈希>
- 128 位汇总键
- 根据您感兴趣的维度,像先前一样生成来源端和触发器端键部分。
如果您使用的是这种基于哈希的方法,请参考以下实用提示:
- 始终使用相同的维度顺序。这样可以确保哈希可以可靠地重新生成。(“COUNT, CampaignID=12, GeoID=7”将不会生成与“COUNT, GeoID=7, CampaignID=12”相同的哈希值)。有一种简单的方法就是按字母数字对维度进行排序。这就是我们将在示例中执行的操作,不过我们始终会将“COUNT”或“VALUE”设为维度中的第一项。这是为了方便阅读,因为 COUNT 或 VALUE 所编码的信息在概念上与所有其他维度略有不同。
- 跟踪您在键中使用的维度集。您需要避免根据一组您从未使用过的维度生成键。
- 如果使用了合适的哈希函数,则哈希冲突很少会发生,但检查之前用过的哈希(应存储这些哈希以解释汇总服务的结果),可以避免引入与旧键冲突的新键。
请参阅每次点击或浏览只记录一次转化示例,了解如何实际使用基于哈希的键。
可汇总值的实际应用
该广告技术公司会在用户完成转化时设置可汇总的值。
为保护用户隐私,每位用户贡献的内容都有一个上限。在与单个来源(广告点击或观看)关联的所有可汇总值中,任何值都不能高于特定贡献限制。
我们将此限制称为 CONTRIBUTION_BUDGET
。在说明中,此限制称为 L1 预算,但它与 CONTRIBUTION_BUDGET
相同。
如需深入了解贡献预算,请参阅摘要报告的贡献预算。
示例:每次点击或浏览只记录一次转化
在此示例中,我们假设您想要回答以下问题:
- 每个地区哪些产品类别最有价值?
- 在每个地区,哪些广告系列策略最为有效?
我们还假设您的应用场景需要每周数据分析。
您还需要跟踪以下内容:
- 16 个不同的广告系列。
- 北美洲、中美洲、南美洲、欧洲、非洲、亚洲、加勒比海和大洋洲。
- 29 个不同的产品类别。
衡量的指标
虽然许多广告技术公司都鼓励广告主配置多种转化类型,但将重点放在最重要的转化(如购买)上,可以确保这些重要转化事件的汇总结果详细且准确。 事实上,您衡量的指标越多,每个指标的贡献预算就越小,因此每个值可能含有较多噪声。因此,您需要仔细选择要衡量的指标。
在本示例中,我们将介绍针对每次点击或浏览仅衡量一次转化(即购买)的广告系列设置。
您仍会衡量购买次数和购买价值,并获取各种重要的汇总统计信息,例如总购买价值和地理位置细分。 这样可使噪声保持在合理范围内,并确保针对贡献预算采用简单的扩展方法。
货币呢?
在不同区域投放广告系列意味着需要考虑币种。 您可以执行以下操作:
- 将币种设为汇总键中的专用维度。
- 或者,根据广告系列 ID 推断币种,然后将所有币种转换为参考币种。
在此示例中,我们假定您可以根据广告系列 ID 推断出币种。这样,您就可以将任何给定的购买价值从用户的本地货币转换为您选择的参考货币。您也可以在用户购买商品时,即时执行该转化。
通过这种方法,所有可汇总的价值均采用相同的参考货币,因此可以相加来生成总的汇总购买价值,即购买总价值。
将目标转化为关键
设定衡量目标和指标后,您可以为关键策略提供多种选项。我们来重点了解其中的两种策略:
- 策略 A:单一精细的键结构。
- 策略 B:两个粗略的关键结构。
策略 A:一个深层树(一个精细的键结构)
在策略 A 中,您将使用一个精细的键结构,其中包含所需的所有维度:
您的所有密钥都使用此结构。
您将此键结构拆分为两种键类型,以支持两个衡量目标。
- 键类型 0:衡量目标类型 = 0,您决定将其定义为购买次数。
- 键类型 1:衡量目标类型 = 1,您决定将其定义为购买价值。
摘要报告如下所示:
您可以将策略 A 视为“单深树”策略:
- 摘要报告中的每个摘要值均与您所跟踪的所有维度相关联。
- 您可以将这些汇总值与其中每个维度一起汇总,这样总览数据的维度就可深入到您拥有的维度数量。
采用策略 A 时,您应按以下方式回答您的问题:
问题 | 回答 |
---|---|
每个地区哪些产品类别最有价值? | 对所有广告系列的摘要报告中的购买摘要数量和价值求和。 您可以查看每个地理位置 ID x 产品类别的购买交易次数和价值。 针对每个地区,比较不同产品类别的购买价值和数量。 |
在每个地区,哪些广告系列策略最为有效? | 对摘要报告中所有商品类别中的摘要购买次数和值求和。 这样您便可以查看每个广告系列 ID x 地理位置 ID 的购买次数和价值。 针对每个地区比较不同广告系列的购买价值和数量。 |
在策略 A 中,您也可以直接回答第三个问题:
“我在各个地理区域的每个广告系列为每个产品带来了多少收入?”
虽然汇总值会有噪声,但您可以确定每个广告系列之间测量的值差异何时并非仅由噪声所致。如需了解如何实现此操作,请参阅了解噪声。
策略 B:两个浅层树(两个粗略的密钥结构)
在策略 B 中,您将使用两个粗略的键结构,每个结构都包含您所需的部分维度:
您将每个关键结构拆分为两个关键类型,以支持两个衡量目标。
- 衡量目标类型 = 0,您决定将其定义为“购买次数”。
- 衡量目标类型 = 1,您决定将其定义为购买价值。
您最终会得到四种密钥类型:
- 密钥类型 I-0:密钥结构 I、购买次数。
- 键类型 I-1:键结构 I、购买价值。
- 密钥类型 II-0:密钥结构 II、购买次数。
- 键类型 II-1:键结构 II、购买价值。
摘要报告如下所示:
您可以将策略 B 视为“两棵浅树”策略:
- 摘要报告中的汇总值对应于两个小维度集合中的一个。
- 您可以将这些汇总值与这些维度集中的每个维度一起汇总,这意味着这些汇总值不如选项 A 中的深度,因为可供汇总的维度较少。
对于策略 B,您需要按如下方式回答您的问题:
问题 | 回答 |
---|---|
每个地区哪些产品类别最有价值? | 直接访问摘要报告中的摘要购买计数和值。 |
在每个地区,哪些广告系列策略最为有效? | 直接访问摘要报告中的摘要购买计数和值。 |
决策:策略 A
策略 A 更简单;所有数据都遵循相同的键结构,这也意味着您只需维护一个键结构。
不过,如果使用策略 A,您需要对摘要报告中收到的汇总值求和,才能回答一些问题。其中每个汇总值都是嘈杂的。通过对这些数据进行求和,您还可以对噪声进行求和。
策略 B 则不同,摘要报告中提供的汇总值已为您提供所需的信息。这意味着,策略 B 所产生的噪声影响可能比策略 A 小。
您应如何确定要使用哪种策略?对于现有广告客户或广告系列,您可以使用历史数据来确定转化量是更适合策略 A 还是策略 B。不过,对于新的广告客户或广告系列,您可能需要:
- 使用精细键收集一个月的数据(策略 A)。 由于您延长了数据收集的时长,因此汇总值将较高,而噪声相对较低。
- 以合理的准确性评估每周转化次数和购买价值。
在此示例中,假设每周购买次数和购买价值足够高,策略 A 会产生您认为适用于您的用例的噪声百分比。
由于策略 A 更简单且会产生噪声影响,而不会影响您做出决策的能力,因此您决定采用策略 A。
选择哈希算法
您决定采用基于哈希的方法生成密钥。为此,您需要选择哈希算法来支持该方法。
我们假定您选择了 SHA-256。您也可以使用更简单的、安全性较低的算法,例如 MD5。
在浏览器中:设置键和值
现在,您已经确定了键结构和哈希算法,接下来就可以在用户点击或查看广告时注册键和值,并随后进行转化。
接下来,我们将概述您将设置为在浏览器中注册键和值的标头:
设置来源端关键部分
当用户点击或查看广告时,在 Attribution-Reporting-Register-Aggregatable-Source
标头中设置汇总键。在此阶段,对于每个键,您只能设置在投放广告时已知的键部分(即键部分)。
我们来生成关键部分:
密钥 ID 的来源端键部分... | 包含您要设置的维度值的字符串 | 此字符串的十六进制哈希值,截断到前 64 位(64/4 = 16 个字符1) | 附加零以简化 XOR 运算的十六进制哈希。这是源端密钥段。 |
---|---|---|---|
key_purchaseCount | COUNT、CampaignID=12、GeoID=7 | 0x3cf867903fbb73ec | 0x3cf867903fbb73ec0000000000000000 |
key_purchaseValue | VALUE,CampaignID=12,GeoID=7 | 0x245265f432f16e73 | 0x245265f432f16e730000000000000000 |
现在,我们来设置关键部分:
// Upon receiving the request from the publisher site
res.set(
"Attribution-Reporting-Register-Aggregatable-Source",
JSON.stringify(
[{
"id": "key_purchaseCount",
"key_piece": "0x3cf867903fbb73ec0000000000000000"
}, {
"id": "key_purchaseValue",
"key_piece": "0x245265f432f16e730000000000000000"
}]
))
请注意,最终报告中不会显示密钥 ID。它们仅用于在浏览器中设置键时,以便来源端和触发器端键部分可以相互映射并组合为完整键。
可选:事件级报告
如果您需要同时使用事件级报告和可汇总报告,请确保对于给定的来源,事件级数据(来源事件 ID 和触发器数据)和汇总键可以匹配。
举例来说,如果您打算使用事件级报告来运行模型,分析哪种类型的广告往往会促成最多的购买量,您就可以同时使用这两种报告。
用户完成转化
当用户完成转化时,像素请求通常会发送到广告技术平台服务器。收到此请求后:
- 设置转化端(触发器端)关键部分以完成键。
您将通过
Attribution-Reporting-Register-Aggregatable-Trigger-Data
标头设置这些关键部分。 - 通过标头
Attribution-Reporting-Register-Aggregatable-Values
设置该转化的可汇总值。
设置触发器端键部分以完成键
我们来生成关键部分:
密钥 ID 的触发器端键部分... | 包含您要设置的维度值的字符串 | 此字符串的十六进制哈希值,截断到前 64 位(64/4 = 16 个字符1) | 附加零以简化 XOR 运算的十六进制哈希。这是源端密钥段。simplify |
---|---|---|---|
key_purchaseCount | 产品类别=25 | 0x1c7ce88c4904bbe2 | 0x0000000000000000f9e491fe37e55a0c |
key_purchaseValue | (相同) | (相同) | (相同) |
现在,我们来设置关键部分:
// Upon receiving the pixel request from the advertiser site
res.set(
"Attribution-Reporting-Register-Aggregatable-Trigger-Data",
JSON.stringify(
[
// Each dictionary independently adds pieces to multiple source keys
{ "key_piece": "0x0000000000000000f9e491fe37e55a0c",
"source_keys": ["key_purchaseCount", "key_purchaseValue"]},
]
))
请注意,如何通过在 source_keys
中列出多个密钥 ID 来向多个密钥添加相同的密钥段 - 该密钥段将添加到两个密钥中。
设置可汇总的值
在设置可汇总值之前,您需要对这些值进行纵向扩容,以减少噪声。
假设用户以 52 美元的价格购买了商品类型 25。
您不能直接将这些值设置为可汇总的值:
key_purchaseCount
:1 次转化key_purchaseValue
:52 美元
相反,在注册这些可汇总值之前,您需要对其进行缩放,以最大限度减少噪声。
贡献预算有两个目标,因此您可以决定将贡献预算一分为二。
在这种情况下,每个目标最多分配 CONTRIBUTION_BUDGET/2
(=65,536/2=32,768)。
我们假设根据网站所有用户的交易记录,假设单个用户的最高购买价值为 1,500 美元。可能存在离群值,例如,支出超过该总和的用户极少,但您可以决定忽略这些离群值。
购买价值的调整系数应为:
((CONTRIBUTION_BUDGET
/2) / 1,500) = 32,768/1,500 = 21.8~ 22
购买次数的缩放比例为 32,768/1 = 32,768,因为您决定针对每个广告点击或观看(来源事件)最多跟踪一次购买。
您现在可以设置以下值:
key_purchaseCount
:1*32768 = 32768key_purchaseValue
:52*22 = 1144
在实际使用中,您可以使用专用头文件 Attribution-Reporting-Register-Aggregatable-Values
对其进行设置,如下所示:
// Instruct the browser to schedule-send a report
res.set(
"Attribution-Reporting-Register-Aggregatable-Values",
JSON.stringify(
{
"key_purchaseCount": 32768,
"key_purchaseValue": 1144,
}
))
系统会生成可汇总报告
浏览器将转化与之前的视图或点击进行匹配,并生成可汇总报告,其中包括报告元数据旁边的加密载荷。
以下示例展示了可在可汇总报告的载荷中找到的数据(如果数据以明文形式读取):
[ {
key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece XOR conversion-side key piece for the key key_purchaseCount
value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
}, {
key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece XOR conversion-side key piece for the key key_purchaseValue
value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
}]
在这里,您可以在一个可汇总报告中查看两项不同的贡献。
请求获取摘要报告
- 批量生成可汇总报告。请遵循批处理中提供的建议。
- 生成您要查看其数据的密钥。例如,如需查看广告系列 ID 12 x 地理位置 ID 7 x 产品类别 25 的 COUNT(总购买次数)和 VALUE(总购买价值)的摘要数据,请执行以下操作:
您要请求的指标1 | 来源端密钥部分 | 扳机侧钥匙片 | 用于向汇总服务发出请求的键2 |
---|---|---|---|
总购买次数 (COUNT) | 0x3cf867903fbb73ec 0000000000000000 |
0x00000000000000 00f9e491fe37e55a0c |
0x3cf867903fbb73 ecf9e491fe37e55a0c |
总购买价值 (VALUE) | 0x245265f432f16e73 0000000000000000 |
0x0000000000000000 f9e491fe37e55a0c |
0x245265f432f16e73 f9e491fe37e55a0c |
- 向汇总服务请求这些键的摘要数据。
处理摘要报告
最后,您会收到一份摘要报告,可能如下所示:
[
{"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
"value": "2558500"},
{"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
"value": "687060"},
…
]
第一个存储分区是二进制形式的 COUNT 键。第二个存储分区是二进制形式的 VALUE 键。请注意,虽然键是异构的(COUNT 与 VALUE),但它们包含在同一报告中。
缩减值
- 2,558,500 是指此密钥的购买次数,按您之前计算的缩放比例按比例计算得出。购买计数的缩放比例为 32,768。将 2,558,500 除以目标的贡献预算:2,558,500/32,768 = 156.15 次购买。
- 687,060 → 687,060/22 = 总购买价值 $31,230。
因此,摘要报告可为您提供以下数据分析:
Within the reporting time period, campaign #12
run in Europe drove about 156 purchases (± noise)
for the product category #25.
Within the reporting time period, campaign #12
run in Europe drove $31,230 of purchases (± noise)
for the product category #25.