本頁面由 Cloud Translation API 翻譯而成。

瞭解 Attribution Reporting 的匯總鍵

匯總鍵是什麼、在 Attribution Reporting API 中的用途，以及如何將目標轉譯為鍵。

一家廣告技術公司，在多個地點放送不同產品類別的廣告活動，因此希望協助廣告主回答下列問題：

各個產品類別中的每個廣告活動帶來的購買次數為何？
各個產品類別針對各個產品類別中的各個廣告活動所帶來的收益為何？

雖然許多廣告技術公司都鼓勵廣告客戶設定各種轉換類型，但建議將重點放在最重要的轉換 (例如購買)，以確保這些重要事件的摘要結果正確且準確。

因此，在收集資料前，您必須思考自己想回答的問題。

維度、鍵和值

為了回答這些問題，我們來看看維度、鍵和值。

尺寸

按照這裡的說明，瞭解廣告活動如何產生收益，建議您追蹤下列維度：

廣告活動 ID：特定廣告活動的 ID。
地理位置 ID：放送廣告的地理區域。
產品類別：您定義的產品類型。

雖然「廣告活動 ID」和「地理位置 ID」維度會在廣告放送 (廣告放送時間) 時得知，但當使用者完成轉換 (轉換時間) 時，觸發事件就會得知產品類別。

在這個範例中，您想要追蹤的尺寸如下圖所示：

什麼是匯總鍵 (值區)？

詞彙「匯總鍵」和「值區」指的是相同的事物。匯總鍵用於設定報表的瀏覽器 API。「值區」一詞用於可匯總報表和摘要報表，以及匯總服務 API 中。

匯總鍵 (簡稱鍵) 是一種資料，代表所追蹤維度的值。資料稍後會沿著各個匯總鍵進行匯總。

舉例來說，假設您要追蹤「產品類別」、「地理區域 ID」和「廣告活動 ID」這三項維度。

當位於地理區域 ID 7 的使用者看到廣告活動 ID 12 的廣告，且之後購買產品類別 25 的產品完成轉換時，您可以設定匯總鍵，如下圖所示：

您會在稍後看到匯總鍵在實務上看起來不太一樣，但我們現在要著重於該鍵中包含的資訊。

什麼是可匯總值？

如果您對本文列出的維度有任何疑問，請參閱下列文章：

購買次數 (購買次數)。摘要報表提供匯總資料及顯示後，將會是總購買次數 (摘要值)。
每次購買的收益 (購物價值)。摘要報表提供匯總資料且可使用後，系統將以總收益 (摘要值) 為單位。

這些轉換 (一次轉換的購買計數，以及一次轉換的購買價值) 都是可匯總的值。您可以將可匯總的值視為成效評估目標的值。

問題	可匯總值 = 評估目標
問題	可匯總值 = 評估目標	有多少購買...	購買次數
為收益...	購物價值

假設位於地理區域 ID 7 的使用者看到廣告活動 ID 12 的廣告，之後購買了產品類別為 $120 美元的 25 美元 (假設貨幣為美元) 並完成轉換 (假設貨幣為美元)，您可以設定匯總鍵和可匯總值，如下所示：

可匯總值是許多使用者的每個鍵的總和，以摘要報表中的摘要值的形式呈現。

系統會將可匯總的值加總，產生評估目標的匯總洞察資料。

請注意，此圖省略解密作業，代表未套用雜訊的簡化範例。在下一節中，我們會以雜訊說明這個範例。

從鍵/值到報表

接下來說明可匯總鍵/值與報表的關係。

可匯總報表

當使用者點擊或瀏覽廣告，且之後完成轉換時，您會指示瀏覽器儲存 {aggregate key, ggregatable value} 組合。

在本例中，當使用者點擊或觀看廣告，並在之後完成轉換時，您會指示瀏覽器產生兩個貢獻 (每個評估目標各一次)。

稍後您會看到 {aggregate key, aggregatable value} 可匯總報表看起來與此不同，但現在我們來談談報表中包含的資訊。

指示瀏覽器產生兩項貢獻後，瀏覽器會產生可匯總報表 (如果能將轉換與先前的資料檢視或點擊比對)。

可匯總報表包含：

您設定的貢獻。
關於點擊或瀏覽事件和轉換事件的中繼資料 (發生轉換的網站等)。查看可匯總報表中的所有欄位。

可匯總報表採用 JSON 格式，並包含其他項目，也就是酬載欄位，做為最終摘要報表的資料輸入內容。

酬載包含貢獻清單，每個貢獻都是 {匯總鍵, 可匯總值} 的組合：

bucket：匯總為位元組字串的匯總鍵。
value：該測量目標的可匯總值，以位元組字串形式編碼。

範例如下：

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

實際上，可匯總報表的編碼方式使值區和值看起來與上述範例不同 (也就是值區看起來可能像 \u0000\u0000\x80\u0000)。Bucket 和 value 都是位元組字串。

摘要報表

可匯總報表在多種瀏覽器和裝置 (使用者) 上匯總顯示，資料如下：

廣告技術請求提供了特定一組鍵的摘要報表，以及來自多種不同瀏覽器 (使用者) 的一組可匯總報表。
匯總服務會將可匯總報表解密。
對於每個鍵，系統都會將可匯總報表中的可匯總值加總。
在摘要值中加入雜訊。

結果會是摘要報表，內含一組 {匯總鍵, 摘要值} 組合。

摘要報表包含 JSON 字典樣式的鍵/值組合。每個組合都包含：

bucket：匯總為位元組字串的匯總鍵。
value：特定評估目標 (以小數點表示) 的摘要值，是從所有可用的可匯總報表中加總值，並增加雜訊等級。

示例：

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

在實務上，摘要報表編碼的方式會使值區和值看起來與範例說明不同 (即值區看起來可能像 \u0000\u0000\x80\u0000)。Bucket 和 value 都是位元組字串。

匯總鍵的實際操作

匯總鍵 (值區) 是由廣告技術公司定義，通常分為兩個步驟：點按或觀看廣告，以及使用者完成轉換。

金鑰結構

我們會使用「鍵結構」一詞，指派編碼為鍵的維度組合。

舉例來說，廣告活動 ID × 地理區域 ID × 產品類別是一種主要結構，

金鑰類型

系統會在多個使用者/瀏覽器中，為指定的鍵加總可匯總值。但我們發現可匯總的價值能夠追蹤不同的成效評估目標，例如購物價值或購買次數。您想確保匯總服務將相同類型的可匯總值加總。

方法是在每個鍵中為一段資料編碼，藉此瞭解摘要值代表的意義 (也就是這個鍵所代表的評估目標)。其中一種方法是為鍵建立其他維度，用來代表評估目標類型。

以前述的例子來說，這個評估目標類型會有兩個不同的可能值：

「購買次數」是第一種評估目標，
「購買價值」是第二類評估目標，

如果您的評估目標為「n」n個，評估目標類型就會有「n」n個不同類型的值。

您可以將鍵的維度視為指標，例如「每個地理位置每個廣告活動的特定產品購買次數」。

鍵大小、尺寸

金鑰大小上限以位元為單位，也就是要建立完整索引鍵的零個數和二元數。這個 API 的金鑰長度為 128 位元。

這種大小的鍵可以相當精細，但越精細的鍵就越有可能產生雜訊。如要進一步瞭解雜訊，請參閱瞭解雜訊。

如先前所述，維度會編碼為匯總鍵。每個維度都有特定基數，也就是該維度能夠包含的不重複值數量。視基數而定，每個維度都必須以特定位元表示。在 n 位元中，您可以呈現 2ⁿ 個不同選項。

舉例來說，全球大約有 200 個國家/地區，「國家/地區」維度的基數可能會是 200。需要多少位元才能編碼這個維度？

7 位元只會儲存 2⁷ = 128 個不同選項，但低於必要的 200。

8 位元會儲存 256 個不同選項 (超過必要 200 個)，因此您可以使用 n=8 位元來編碼這個維度。⁸

金鑰編碼

在瀏覽器中設定鍵時，這些鍵應以十六進位編碼。在摘要報表中，鍵會以二進位檔案顯示 (也稱為值區)。

注意：十六進位資料的前置字元通常是 0x。舉例來說，0x19 是十六進位數字的 19，也就是十進位的 25，而不是 19。二進位數字通常以 0b 開頭，例如，0b11001 在二進位中是 11001，也就是十進位數字 25，而不是 11,001。

設定兩個關鍵組件來取得完整的鑰匙

假設您使用鍵追蹤下列維度：

廣告活動 ID
地理位置 ID
產品類別

雖然「廣告活動 ID」和「地理位置 ID」維度會在廣告放送 (廣告放送時間) 時得知，但使用者透過觸發事件完成轉換 (轉換時間) 就會得知產品類別。

在實務上，您將透過兩個步驟設定金鑰：

您必須在點擊或瀏覽時間設定鍵的其中一個部分：廣告活動 ID × 地理位置 ID。
您將在轉換時設定「主要」鍵的第二部分：產品類別。

這些鍵的不同部分就稱為「鍵組」。

索引鍵的計算方法是採用其索引鍵的 XOR (^)。

示例：

來源端鍵 = 0x159
觸發事件端鍵 = 0x400
鍵 = 0x159 ^ 0x400 = 0x559

對齊重點

使用兩個 64 位元金鑰，分段將 64 位元的填色器/偏移量 (十六個零) 巧妙地放置在 128 位元中，XOR 的鍵相當於串連它們，因此更容易進行推理和驗證：

來源端鍵 = 0xa7e297e7c8c8d0540000000000000000
觸發事件端鍵 = 0x0000000000000000674fbe308a597271
鍵 = 0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

每次廣告點擊或觀看包含多個鍵

實際上，您可以為每個歸因來源事件 (廣告點擊或觀看) 設定多個鍵。舉例來說，您可以設定：

追蹤地理位置 ID × 廣告活動 ID 的鍵。
追蹤「廣告素材類型 × 廣告活動 ID」的另一個鍵。

如需其他範例，請參閱策略 B。

將維度編碼為鍵

要求摘要報表時，您需要要求一組特定匯總鍵的摘要報表，藉此告知匯總服務您想存取哪些指標。

摘要報表包含原始 {key,summary value} 組合，沒有鍵的其他資訊。這表示：

將鍵設為使用者觀看或點擊廣告後完成轉換時，您必須以鍵所代表的維度值可靠的設定鍵。
定義您要求摘要報表的鍵時，您必須根據要查看匯總資料的維度值，穩定地產生或存取使用者觀看或點擊廣告並完成轉換時設定的鍵。

使用鍵結構對應表編碼維度

如要將維度編碼為鍵，您可以在定義鍵時 (在廣告放送時間之前)，預先建立並維護鍵結構對應關係。

機碼結構圖代表每個維度及其在鍵中的位置。

在實務上，建立及維護主要的結構對應意味著您必須實作及維護解碼器邏輯。如果您想要尋找不需要執行此操作的方法，請考慮改用雜湊型方法。

範例如下：

假設您打算追蹤特定廣告活動、地理區域和產品的購買和購買價值，

產品類別、地理位置 ID 和廣告活動 ID 必須是鍵中的維度。此外，由於想追蹤兩個不同的評估目標 (購買次數和購買價值)，您必須在鍵中加入一個維度，以追蹤鍵類型。如此一來，您就能在摘要報表中定義接收到的{鍵、可匯總值}組合時，實際代表的可匯總值。

根據這些評估目標，您的鍵具有下列維度：

產品類別
評估目標類型
地理位置 ID
廣告活動 ID

現在，看看每個維度，假設您需要追蹤下列項目：

29 種不同的產品類別。
8 個不同的地理區域：北美洲、中美洲、南美洲、歐洲、非洲、亞洲、加勒比海和大洋洲。
16 個不同的廣告活動。

以下是對鍵中每個維度進行編碼所需的位元數：

產品類別：5 位元 (2⁵ = 32 > 29)。
評估目標類型：1 位元。評估目標可以是購買次數或購買價值，代表兩者可能具有兩種不同可能性，因此只要一部分就能保存。

地理位置 ID：3 位元 (2³ = 8)。此外，您也可以定義地理區域 ID 的維度地圖，以便瞭解每個二進位值代表的地理區域。地理位置 ID 維度的維度地圖可能如下所示：

金鑰中的二進位值	地理位置
000	北美洲
001	中美洲
010	南美洲
011	歐洲
100	非洲
101	亞洲
110	加勒比海人
111	大洋洲

廣告活動 ID：4 位元 (2⁴ = 16)

遵循這個結構的鍵長度將為 13 位元 (5 + 1 + 3 + 4)。

在這個範例中，這些鍵的鍵結構對應如下所示：

鍵中的維度順序由您決定。

為說明維度組成鍵結構的方式，我們會使用二進位表示法，因此廣告活動 ID (第一部分) 位於最右側，產品類別 (最後部分) 位於最左側的位置。

在每個維度中，最重要的位元 (含有最大數值的位元) 就是最左側的位元。最小顯著性 (具有最小數值的位元) 是最右側的位元。

我們來看看如何使用鍵結構對應將鍵解碼。

讓我們以 0b1100100111100 做為任意範例金鑰，假設您能夠知道，此金鑰遵循上一例中的金鑰結構對應。

根據金鑰結構對應，這個索引鍵會解碼為 11001 0 011 1100。

因此，鍵 0b1100100111100 代表產品類別 25 的購買次數，針對在歐洲推出的廣告活動 ID 12。

使用雜湊函式編碼維度

除了使用鍵結構對應，您也可以不使用索引鍵結構，以一致且可靠的方式動態產生索引鍵。

運作方式如下：

選取雜湊演算法。
在廣告放送時產生一個字串，當中包含您要追蹤的所有維度及其值。如要產生來源端的金鑰，請對這個字串進行雜湊處理，並考慮新增 64 位元後置字串，以便對齊該字串與觸發事件端金鑰，讓 XOR 更容易理解。
- 來源端索引鍵
  = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
- 請注意，COUNT 編碼的項目與主要結構對應方法中的 measurementGoalType=0 相同。COUNT 是較為精簡且更明確的文字。
在轉換時產生字串，當中包含您要追蹤的所有維度及其值。如要產生觸發事件端鍵，請對這個字串進行雜湊處理，並加入 64 位元前置字串 (零)：
- 觸發事件端鍵 = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
瀏覽器 XOR 這些金鑰會產生金鑰。
- 128 位元匯總鍵
  = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
之後準備好索取這個金鑰的摘要報表時，請即時產生：
- 按照您感興趣的維度，按照先前的方式產生來源端和觸發端鍵。
  - 來源端索引鍵
    = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
  - 觸發事件端鍵
    = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
  - 觸發事件端鍵 = toHex(hash("productCategory=25"))
- 和瀏覽器一樣，透過 XOR 這些金鑰產生瀏覽器先前產生的金鑰。
  - 128 位元匯總鍵
    = <64-bit source-side key piece hash><64-bit source-side key piece hash>

如果您使用的是雜湊型方法，可以參考以下幾個實用提示：

請一律採用與維度相同的順序。這可確保系統能夠可靠地重新產生雜湊。("COUNT, CampaignID=12, GeoID=7" 不會產生與 "COUNT, GeoID=7, CampaignID=12" 相同的雜湊)，最簡單的方法就是將維度 (英數字元) 排序。這就是我們會在範例中採取的做法，但因為我們一律將 COUNT 或 VALUE 設為維度中的第一個項目，因為 COUNT 或 VALUE 編碼的資訊概念略有不同。
追蹤您在鍵中使用的維度組合。您不會想要根據從未使用過的一組維度產生鍵。
如果使用合適的雜湊函式，雜湊衝突很少發生，但如果與先前使用的雜湊 (應儲存以解讀匯總服務的結果) 進行比對，可避免產生與舊鍵衝突的新鍵。

如要瞭解如何使用雜湊鍵，請參閱「單次點擊單次轉換或查看一次轉換範例」一文。

可匯總值的實際應用方式

廣告技術公司會在使用者完成轉換時設定可匯總值。

為保護使用者隱私，每位使用者的貢獻內容設有上限。凡是與單一來源 (廣告點擊或瀏覽) 相關聯的所有可匯總值，值都不得超過特定貢獻上限。

我們會將這項限制稱為「CONTRIBUTION_BUDGET」。在說明中，這項限制稱為 L1 預算，但與 CONTRIBUTION_BUDGET 相同。

如要深入瞭解貢獻預算，請參閱「摘要報表的貢獻預算」一文。

範例：每次點擊或觀看一次轉換

在這個範例中，假設您想回答以下問題：

哪些產品類別對各區域最有價值？
請問哪些廣告活動策略對每個區域最有效？

並假設您的用途需要每週深入分析資訊。

您也必須追蹤下列項目：

16 個不同的廣告活動。
8 個不同的地理區域：北美洲、中美洲、南美洲、歐洲、非洲、亞洲、加勒比海和大洋洲。
29 種不同的產品類別。

評估內容

雖然許多廣告技術公司都鼓勵廣告客戶設定各種轉換類型，但想要確保這些重要轉換事件的匯總結果準確且準確，就應該將重點放在最重要的轉換 (例如購買)。事實上，評估的指標越多，每項指標的貢獻預算也越少，因此每個值可能都較雜亂。因此，您必須仔細選取要測量的項目。

在本範例中，我們會將重點放在評估每次點擊或瀏覽只計算一次轉換的廣告活動設定：購買。

您還是可以評估購買次數和購買價值，還可存取各種重要匯總統計資料，例如總購物價值和地理區域細目。這樣可以確保雜訊在合理範圍內，並針對捐款預算設定簡單的調整比例。

那貨幣呢？

如果您在不同地區放送廣告活動，必須將貨幣列入考量。您可以採取以下做法：

在匯總鍵中將貨幣設為專屬維度。
也可以根據廣告活動 ID 推斷出貨幣，然後將所有幣別轉換為參考貨幣。

在本範例中，我們假設您可以透過廣告活動 ID 推斷貨幣。這樣您就可以將使用者的當地幣別換算成您選擇的參考貨幣。此外，您也可以在使用者購買商品時即時執行該項轉換。

使用這項技巧時，所有可匯總值都採用相同的參考貨幣，因此可以加總以產生總購物總價值 (匯總購物價值)。

將目標轉換為鍵

評估目標和指標時，有多種重要策略選項可供選擇。讓我們來看看這兩種策略：

策略 A：一種精細的鍵結構。
策略 B：兩種粗略的結構。

策略 A：一棵深的樹狀結構 (單一精細的鍵結構)

在策略 A 中，您會使用一個精細的鍵結構，其中包含您需要的所有維度：

所有金鑰都會使用這個結構。

您可以將這個鍵結構分為兩種主要類型，支援兩個評估目標。

鍵類型 0：評估目標類型 = 0，您決定將這項指標定義為購買次數。
鍵類型 1：評估目標類型 = 1，您決定將其定義為「購買價值」。

摘要報表如下：

您可以將策略 A 視為「一根深層」策略：

摘要報表中的每個摘要值都與您追蹤的所有維度相關聯。
您可以將這些匯總值與各個維度匯總，以便這些匯總值與您有的維度數量相近。

採用策略 A 時，您可以透過下列方式回答問題：

問題	回覆
哪些產品類別對各區域最有價值？	加總所有廣告活動的摘要報表中的購買次數和值總和。算出每個地理區域 ID × 產品類別的購買計數和價值。比較各個區域的購買價值和不同產品類別的數量。
請問哪些廣告活動策略對每個區域最有效？	針對所有產品類別，加總摘要報表中的購買次數和值總和。取得每個廣告活動 ID × 地理區域 ID 的購買計數和價值。針對各個地區，比較不同廣告活動的購物價值和數量。

使用策略 A 時，您也可以直接回答以下第三個問題：

「每個地理區域的每個廣告活動分別產生了多少收益？」

雖然摘要值很雜訊，但您可以判斷每次廣告活動之間評估的值差異，並非由雜訊造成。請參閱「瞭解雜訊」一文，瞭解如何完成這項操作。

策略 B：兩棵淺樹 (兩種粗略的結構物)

在策略 B 中，您會使用兩種粗略的鍵結構，每個主要結構都包含您需要的維度子集：

您可將上述每個主要結構分為兩種主要類型，以支援兩個評估目標。

評估目標類型 = 0，您決定將這種目標定義為購買次數。
評估目標類型 = 1，您決定將這種目標定義為「購買價值」。

共有四種金鑰類型：

金鑰類型 I-0：金鑰結構 I、購買次數。
金鑰類型 I-1：鍵結構 I、購買價值。
金鑰類型 II-0：金鑰結構 2、購買次數。
第 II-1 金鑰：主要結構 2、購買價值。

摘要報表如下：

您可以將 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 個字元¹)	附加零的十六進位雜湊，簡化 XOR-ing。這是來源端的鍵。
`key_purchaseCount`	`COUNT, CampaignID=12, GeoID=7`	0x3cf867903fbb73ec	0x3cf867903fbb73ec0000000000000000
`key_purchaseValue`	`VALUE, CampaignID=12, GeoID=7`	0x245265f432f16e73	0x245265f432f16e730000000000000000

¹每個十六進位數字代表 4 位元 (二進位數字)。

現在讓我們設定主要部分：

// 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 個字元¹)	附加零的十六進位雜湊，用於 simplify XOR-ing。這是來源端的鍵。
`key_purchaseCount`	`ProductCategory=25`	0x1c7ce88c4904bbe2	0x0000000000000000f9e491fe37e55a0c
`key_purchaseValue`	(相同)	(相同)	(相同)

¹每個十六進位數字代表 4 位元 (二進位數字)。

現在讓我們設定主要部分：

// 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，即可將同一個索引鍵新增至多個鍵。您要將金鑰新增至兩個金鑰中。

設定可匯總值

設定可匯總的值之前，需要先向上擴充，以減少雜訊。

假設某次購買類型 25 的產品，只要 $52 美元。

請勿直接將這些元素設為可匯總值：

~~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 × 32,768 = 32,768
key_purchaseValue：52 × 22 = 1,144

實際操作時，會使用專屬標頭 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 × 地理位置 ID 7 × 產品類別 25 的 COUNT (總購買次數) 和 VALUE (總購物價值) 的摘要資料，請按照下列步驟操作：
- 產生來源端金鑰，步驟與在瀏覽器中設定時相同。
- 產生觸發事件端鍵，方法與在瀏覽器中設定時相同。

您想要要求的指標¹	來源端金鑰	觸發事件端按鍵	要求匯總服務金鑰²
總購買次數 (`COUNT`)	0x3cf867903fbb73ec 0000000000000000	0x00000000000000 00f9e491fe37e55a0c	0x3cf867903fbb73 ecf9e491fe37e55a0c
總購物價值 (`VALUE`)	0x245265f432f16e73 0000000000000000	0x0000000000000000 f9e491fe37e55a0c	0x245265f432f16e73 f9e491fe37e55a0c

¹ 想索取的指標 (適用於廣告活動 ID 12 × 地理位置 ID 7 × 產品類別 25)。 ²要求匯總服務的鍵 = 來源端鍵 XOR 觸發事件端鍵。

向這些鍵的匯總服務要求摘要資料。

處理摘要報表

最後，您看到的摘要報表可能如下所示：

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

第一個值區是二進位中的 COUNT 金鑰。第二個值區是二進位中的 VALUE 金鑰。請注意，雖然這些鍵是異質 (COUNT 與 VALUE) 的，但包含在同一份報表中。

注意：在實務上，摘要報表編碼的方式會使值區和值看起來與您剛才看到的不同 (即值區看起來可能會像是 \u0000\u0000\x80\u0000)。「Bucket」和「value」都是位元組字串。如要查看範例，請按這裡。

縮減值

2,558,500 代表這個鍵的購買次數，由先前計算的縮放比例係數擴充。購買次數的縮放比例係數為 32,768。將 2,558,500 除以目標貢獻預算：2,558,500/32,768 = 156.15 次購買。
687,060 → 687,060/22 = $31,230 美元的總購買價值。

因此，摘要報表提供您以下洞察資訊：

在報表時間範圍內，廣告活動 #12 在歐洲放送，產品類別 #25 的購買次數 (± 噪音) 約 156 次。
在報表時間範圍內，廣告活動 12 在歐洲放送的廣告活動，為產品類別 #25 帶來了 $31,230 美元的購買次數 (± 噪音)。