本頁面由 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 的廣告，在之後以 NT $3,600 元購買產品類別 25 的產品 (假設貨幣為美元) 完成轉換，您就可以設定一組匯總鍵和可匯總值，如下所示：

系統會將多位使用者的各鍵匯總值加總，以摘要報表中的摘要值形式產生匯總洞察資料。

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

請注意，此圖略過解密作業，代表沒有套用雜訊的簡化範例。在下一節中，我們會用雜訊概述此範例。

從鍵/值到報表

現在來談談可匯總鍵/值與報表之間的關係。

可匯總報表

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

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

稍後您會發現，{aggregate key, aggregatable value} 可匯總報表看起來不完全相同，但現在我們先來看報表中的資訊。

您指示瀏覽器產生兩項貢獻內容後，瀏覽器就會產生可匯總報表 (前提是轉換可以與先前的瀏覽或點擊比對轉換)。

可匯總報表包含以下內容：

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

可匯總報表採用 JSON 格式，包含做為最終摘要報表資料輸入的酬載欄位。

酬載包含貢獻清單，每個貢獻項目都是 {aggregate key, aggregatable value} 組合：

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

範例如下：

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

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

摘要報表

可匯總報表涵蓋許多瀏覽器和裝置 (使用者) 的資料，如下所示：

廣告技術要求取得指定鍵的摘要報表，以及來自不同瀏覽器 (使用者) 的一組可匯總報表。
可匯總報表會由匯總服務解密。
針對每個鍵，系統會加總可匯總報表中的可匯總值。
摘要值會加入雜訊。

結果是一份摘要報表，內含一組 {aggregate key, summary value} 組合。

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

值區：以位元組字串編碼的匯總鍵。
值：指定評估目標的小數數值 (以小數點表示)，從所有可匯總報表中加總，然後加入多餘的雜訊。

示例：

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

在實際操作時，摘要報表的編碼方式使得值區和值看起來與範例中所述的不同 (也就是值區看起來可能像 \u0000\u0000\x80\u0000)。值區和 value 都是位元組字串。

匯總鍵實務

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

金鑰結構

我們會使用「鍵結構」一詞來指定編碼至鍵的維度組合。

舉例來說，「廣告活動 ID x 地理區域 ID x 產品類別」就是主要結構，

金鑰類型

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

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

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

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

如果您設定了「n」n個評估目標，評估目標類型會有「n」n幾種不同的值。

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

鍵大小、尺寸大小

索引鍵大小的上限是以位元定義，也就是要建立完整索引鍵的零和零數在二進位制中的數字。API 允許金鑰長度為 128 位元。

這個大小可讓您使用非常精細的鍵，但更精細的鍵較有可能產生雜訊過多。如要進一步瞭解雜訊，請參閱「瞭解雜訊」一文。

如先前所述，維度會編碼至匯總鍵。每個維度都有特定基數，也就是維度可用的不重複值數量。根據基數的不同，每個維度都必須以特定數值表示。如果使用 n 位元，可以表達 2n 個不同的選項。

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

7 位元只會儲存 27 =128 個不同的選項，這小於必要的 200。

8 位元將會儲存 28 =256 個不同的選項，這比必要的 200 多，所以您可以使用 n=8 位元對這個維度進行編碼。

金鑰編碼

在瀏覽器中設定金鑰時，金鑰應以十六進位編碼。在摘要報表中，鍵會以二進位 (且為已命名的值區) 顯示。

設定兩個重點的完整鍵

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

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

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

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

您要在點擊或觀看時設定鍵的一部分：廣告活動 ID x 地理位置 ID。
您將在轉換時間設定「產品類別」的第二部分。

而鍵的不同部分稱為關鍵片段。

關鍵是取其關鍵零件的 XOR (^)。

示例：

來源端索引鍵 = 0x159
觸發端鍵 = 0x400
鍵 = 0x159 ^ 0x400 = 0x559

對齊關鍵片段

兩個 64 位元關鍵片段，使用謹慎地放置的 64 位元填補器/偏移 (160 個零) 將兩個 64 位元金鑰延伸至 128 位元；XOR 處理鍵就相當於串連這些元素，並方便推理和驗證：

來源端索引鍵 = 0xa7e297e7c8c8d0540000000000000000
觸發端鍵 = 0x0000000000000000674fbe308a597271
鍵 =
- 0xa7e297e7c8c8d0540000000000000000 ^ 0x0000000000000000674fbe308a597271 =
- 0xa7e297e7c8c8d054674fbe308a597271

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

在這種情況下，您可以為每個歸因來源事件 (廣告點擊或觀看) 設定多個鍵。舉例來說，您可以設定：

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

讓我們看看策略 B 的其他範例。

將維度編碼為鍵

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

摘要報告包含原始的 {key,summary value} 組合，且沒有有關鍵的額外資訊。這表示：

將鍵設為在使用者查看或點擊廣告後完成轉換時，您必須根據這些鍵所代表的維度值，穩定地設定鍵。
定義要索取摘要報表的鍵時，您必須根據使用者查看或點擊廣告並轉換時設定的鍵，穩定產生或存取與您想要查看匯總資料的維度值相同的鍵。

使用索引鍵結構對應的編碼維度

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

主要結構圖代表您的每個維度及其在鍵中的位置。

實際上，建立和維護鍵結構對應表示必須實作及維護解碼器邏輯。如果想瞭解不需要這麼做的方法，建議改用雜湊式方法。

範例如下：

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

產品類別、地理位置 ID 和廣告活動 ID 必須在鍵中設為維度。此外，由於您想要追蹤「購買次數」和「購買價值」這兩個不同的評估目標，因此必須在追蹤鍵類型的鍵中加入一個維度。這樣就能定義可匯總值在摘要報表中收到 {key, aggregatable value} 組合時實際代表的意義。

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

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

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

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

以下是在鍵中為每個尺寸編碼所需的位元數：

產品類別：5 位元 (25 = 32 > 29)。
測量目標類型：1 位元。評估目標可以是購買次數或購買價值，代表兩種可能性，因此只要一個設定就足以儲存這項資料。

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

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

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

按照這個結構建立的索引鍵會是 13 位元長 (5 + 1 + 3 + 4)。

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

您可以自行決定鍵內的維度順序。

為了說明維度組成鍵結構的方式，我們將以二進製表示，因此廣告活動 ID (前位元) 是最右邊的一個，而產品類別 (最後位元) 是最左側的 1。

在每個維度中，最重要的一點 (也就是承載最大數值的) 是最左邊的部分。最小顯著部分是最右側的位元，也就是包含最小數值的。

以下說明如何使用鍵結構對應來解碼鍵。

讓我們以 0b1100100111100 做為任意範例鍵，假設您您有辦法知道此鍵遵循如上圖中的鍵結構對應。

根據鍵結構對應，這個鍵會解碼為：

11001 0 011 1100

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

使用雜湊函式編碼維度

除了使用鍵結構對應，您也可以使用雜湊函式，以一致且可靠的方式動態產生金鑰。

運作方式如下：

選取雜湊演算法。
廣告放送時，請產生含有您要追蹤的所有維度和參數值的字串。如要產生來源端鍵，請雜湊處理這個字串，並考慮加入 64 位元後置字串，以便與觸發事件端鍵對齊，使 XOR 更容易理解。
- 來源端索引鍵
  = <64 位元十六進位 hash("COUNT, campaignID=12, geoID=7"))><64 位元 00000000...>
- 請注意，在主要結構對應方法中，COUNT 編碼的編碼與 measurementGoalType=0 相同。COUNT 比較精簡也比較明確。
在轉換時產生字串，其中包含您想追蹤的所有維度及其值。如要產生觸發事件端鍵，請雜湊處理這個字串，並加入 64 位元的前置字串 (0)：
- 觸發端鍵 = <64 位元 00000000...><64 位元十六進位雜湊 (productCategory=25")>
瀏覽器 XOR 會傳遞這些關鍵片段來產生金鑰。
- 128 位元匯總鍵
  = <64 位元十六進位來源端索引鍵雜湊><64 位元十六進位來源端鍵雜湊>
之後如果準備好索取這組金鑰的摘要報表，可以立即產生：
- 根據自己感興趣的維度，按照先前的做法產生來源端和觸發事件端鍵。
  - 來源端索引鍵
    = <64 位元十六進位 hash("COUNT, campaignID=12, geoID=7"))><64 位元 00000000...>
  - 觸發端鍵
    = <64 位元 00000000...><64 位元十六進位 hash("productCategory=25")>
  - 觸發條件端鍵 = toHex(hash("productCategory=25"))
- 和瀏覽器一樣，使用這些鍵 XOR 可產生瀏覽器先前產生的相同金鑰。
  - 128 位元匯總鍵
    = <64 位元來源端鍵雜湊><64 位元來源端鍵雜湊>

如要採用這種雜湊式方法，以下提供幾個實用訣竅：

尺寸順序一律相同。這樣做可確保系統能夠準確重新產生雜湊。(「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 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 策略 A。

選取雜湊演算法

您決定採用以雜湊為基礎的方法產生金鑰。為此，您需要選取雜湊演算法來支援該方法。

假設您已選取 SHA-256。您也可以使用較簡單、較不安全的演算法，例如 MD5。

在瀏覽器中：設定鍵和值

現在，您已決定鍵結構和雜湊演算法，就能在使用者點按或瀏覽廣告並後續完成轉換時，註冊鍵和值。

接下來，我們將概略介紹您要在瀏覽器中註冊鍵和值的標頭：

設定來源端金鑰

當使用者點按或觀看廣告時，請在 Attribution-Reporting-Register-Aggregatable-Source 標頭中設定匯總鍵。在這個階段，針對每個鍵，您只能設定廣告放送時已知的鍵或「索引鍵」部分。

接著要產生主要部分：

金鑰 ID 的來源端金鑰...	包含要設定維度值的字串	此字串採用十六進位格式，剪輯成前 64 位元 (64/4 = 16 個字元¹)	附帶零的十六進位雜湊碼，可「簡化」 XOR 設定。這是來源端的鍵。
key_purchaseCount	COUNT、CampaignID=12、GeoID=7	0x3cf867903fbb73ec	0x3cf867903fbb73ec0000000000000000
key_purchaseValue	值，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 個字元¹)	附帶零的十六進位雜湊碼，可「簡化」simplifyXOR 處理。這是來源端的鍵。
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；該按鍵會同時新增至這兩個金鑰中。

設定可匯總值

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

假設某個商品為產品類型 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 x 地理位置 ID 7 x 產品類別 25 的 COUNT (購物總數) 和「VALUE」(購物總價值) 的摘要資料：
- 產生來源端金鑰片段，方法與在瀏覽器中設定來源金鑰相同。
- 產生觸發條件端鍵，就像在瀏覽器中設定觸發條件一樣。

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

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

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

處理摘要報表

最後，您會收到一份摘要報表，內容可能如下所示：

[
  {"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.