瞭解 Attribution Reporting 的匯總鍵

bookmark_border 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

匯總鍵的定義、在 Attribution Reporting API 中的用途，以及如何將目標轉換為鍵。

做為廣告技術公司，您在多個地區為各種產品類別放送廣告活動，因此想協助廣告主回答下列問題：

1. 每個地理區域的廣告活動為每個產品類別帶來多少購買次數？
2. 每個地理區域的廣告活動為每個產品類別帶來多少收益？

雖然許多廣告技術公司鼓勵廣告客戶設定各種轉換類型，但建議您著重於最重要的轉換 (例如購買)，確保摘要結果能針對這些重要事件提供詳細且準確的資料。

為此，您必須先思考在收集資料前要回答哪些問題。

維度、鍵和值

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

尺寸

如要瞭解廣告活動如何產生收益，請按照下方說明追蹤下列維度：

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

廣告活動 ID 和地理區 ID 維度會在廣告放送時 (廣告放送時間) 顯示，而產品類別則會在使用者完成轉換 (轉換時間) 時透過觸發事件顯示。

您在這個範例中要追蹤的維度如下圖所示：

什麼是匯總鍵 (桶)？

匯總鍵和值區這兩個詞彙指的是同一個項目。匯總鍵會用於用來設定報表的瀏覽器 API。在可匯總報表和摘要報表，以及匯總服務 API 中，會使用「bucket」一詞。

匯總鍵 (簡稱「鍵」) 是代表所追蹤維度值的資料片段。資料稍後會按每個匯總鍵匯總。

舉例來說，假設您追蹤的維度是產品類別、地理位置 ID 和廣告活動 ID。

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

您稍後會發現，實際上匯總鍵並非完全像這樣，但我們先專注於鍵中包含的資訊。

什麼是可匯總的值？

如要解答您對上述維度的問題，請參考以下說明：

• 購買次數 (購買次數)。匯總後，摘要報表就會顯示總購買次數 (摘要值)。
• 每筆交易的收益 (購買價值)。匯總後，這項資料會顯示在摘要報表中，並列為總收益 (摘要值)。

每個值 (一次轉換的購買次數和購買價值) 都是可匯總的值。您可以將可匯總的值視為評估目標的值。

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

系統會將許多使用者的每個鍵值加總起來，產生匯總洞察資料，並在摘要報表中以摘要值的形式呈現。

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

請注意，此圖表省略解密程序，並以不含雜訊的簡化範例呈現。在下一節中，我們將以此示例說明雜訊。

從鍵和值到報表

接下來，我們來討論可匯總的鍵和值與報表的關聯。

可匯總報表

當使用者點按或瀏覽廣告後完成轉換時，您可以指示瀏覽器儲存 {aggregation key, aggregatable value} 組合。

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

稍後您會看到 {aggregation key, aggregatable value} 匯總報表的樣式不完全相同，但我們先專注於報表內含的資訊。

當您指示瀏覽器產生兩個貢獻時，瀏覽器會產生可匯總報表 (如果可以比對先前的瀏覽或點擊轉換)。

可匯總報表包含：

• 您設定的貢獻。
• 點擊或瀏覽事件和轉換事件的結構描述：發生轉換的網站等。查看可匯總報表中的所有欄位。

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

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

• bucket：匯總鍵，以位元組字串編碼。
• value：該評估目標的可匯總值，已編碼為位元組字串。

範例如下：

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

實際上，可匯總的報表會以不同的方式編碼，因此值區和值的顯示方式會與前述範例不同 (也就是說，值區可能會顯示為 \u0000\u0000\x80\u0000)。值區和值都是位元組字串。

摘要報表

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

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

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

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

• bucket：匯總鍵，以位元組字串編碼。
• value：指定評估目標的摘要值，以小數表示，由所有可匯總的報表匯總而來，並加入一定程度的雜訊。

範例：

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

實際上，摘要報表的編碼方式會使值和值區塊的顯示方式與範例中所述不同 (也就是值區塊可能會顯示為 \u0000\u0000\x80\u0000)。值區塊和值都是位元組字串。

匯總鍵的實際應用

廣告技術公司會定義匯總鍵 (分組)，通常會在使用者點閱或觀看廣告，以及完成轉換時執行這兩個步驟。

鍵結構

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

舉例來說，廣告活動 ID × 地理 ID × 產品類別是重要的結構。

金鑰類型

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

為此，請在每個鍵中編碼一組資料，說明摘要值代表的內容，也就是這個鍵所參照的評估目標。其中一種做法是為代表評估目標類型的鍵建立額外維度。

以上述範例為例，這個評估目標類型會有兩個可能的值：

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

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

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

索引鍵大小、維度大小

最大金鑰大小是以位元定義，也就是用二進位制中的零和一來建立完整金鑰的數量。API 允許的金鑰長度為 128 位元。

這個大小可用於非常精細的鍵，但精細的鍵更可能導致值雜訊過多。如要進一步瞭解噪音，請參閱「瞭解噪音」一文。

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

舉例來說，國家/地區維度的基數可能為 200，因為世界上約有 200 個國家/地區。編碼這個維度需要多少位元？

7 位元只能儲存 2⁷ = 128 個獨特選項，低於所需的 200 個。

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

鍵編碼

在瀏覽器中設定金鑰時，應以十六進位編碼。在摘要報表中，按鈕會以二進位顯示 (並命名為「桶」)。

設定完整金鑰的兩個鍵片

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

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

廣告放送時 (廣告放送時間)，系統會知道廣告活動 ID 和地理 ID 維度，但只有在使用者完成轉換 (轉換時間) 時，系統才會知道產品類別。

在實務上，這表示您會在兩個步驟中設定鍵：

1. 您會在點擊或觀看時設定金鑰的一部分：廣告活動 ID × 地理區 ID。
2. 您會在轉換時設定鍵的第二部分 (產品類別)。

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

計算鍵時，會取代鍵片的 OR (v)。

範例：

• 來源端鍵片段 = 0x159
• 觸發事件端鍵 = 0x400
• 鍵 = 0x159 v 0x400 = 0x559

對齊關鍵元件

使用兩個 64 位元金鑰片段，並透過精心安排的 64 位元填充字元/偏移量 (十六個零) 將其擴展至 128 位元，將金鑰片段連結起來等同於將兩個金鑰片段連結起來，這樣更容易推理及驗證：

• 來源端鍵片段 = 0xa7e297e7c8c8d0540000000000000000
• 觸發事件端鍵 = 0x0000000000000000674fbe308a597271
• 鍵 = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

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

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

• 用於追蹤地理區域 ID × 廣告活動 ID 的鍵。
• 另一個用於追蹤廣告素材類型 × 廣告活動 ID 的鍵。

請參閱策略 B 瞭解另一個範例。

將維度編碼為鍵

請記得在要求摘要報表時，針對特定一組匯總鍵要求摘要報表，告訴匯總服務您要存取哪些指標。

摘要報表包含原始的 {鍵、摘要值} 組合，但沒有關於鍵的其他資訊。這表示：

• 在使用者查看或點按廣告後完成轉換時設定鍵時，您必須根據代表維度的值設定可靠的鍵。
• 定義要為其要求摘要報表的鍵時，您必須根據要查看匯總資料的維度值，可靠地產生或即時存取與使用者查看或點擊廣告並完成轉換時設定的鍵相同的鍵。

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

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

鍵結構對應表會代表每個維度，以及它們在鍵中的相對位置。

在實際操作中，建立及維護關鍵結構對應表，就表示您必須實作及維護解碼器邏輯。如果您想使用不需要執行這項操作的方法，請考慮改用以雜湊為基礎的方法。

範例如下：

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

產品類別、地理區域 ID 和廣告活動 ID 必須是鍵中的維度。此外，由於您想追蹤兩個不同的評估目標 (購買次數和購買價值)，因此需要在鍵中新增一個維度，以便追蹤鍵類型。這樣一來，您就能在摘要報表中收到 {key, aggregatable value} 組合時，定義匯總值實際代表的內容。

在這些評估目標中，您的鍵會包含下列維度：

• 產品類別
• 評估目標類型
• 地理位置 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 這個鍵代表在歐洲推出的廣告活動 ID 12 中，產品類別 25 的購買次數。

使用雜湊函式編碼維度

您可以使用雜湊函式，以一致且可靠的方式動態產生鍵，而非使用鍵結構對應項目。

運作方式如下：

1. 選取雜湊演算法。
2. 在廣告放送時，產生包含所有要追蹤的維度和其值的字串。如要產生來源端金鑰片段，請對這個字串進行雜湊處理，並考慮加入 64 位元零結尾，以便對齊觸發器端金鑰片段，並讓 OR 更容易推理。
   • 來源端鍵片
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • 請注意，COUNT 在索引鍵結構對應方法中，與 measurementGoalType=0 編碼相同。COUNT 則較精簡且明確。
3. 在轉換時刻產生字串，其中包含您要追蹤的所有維度和其值。如要產生觸發器端金鑰片段，請對這個字串進行雜湊處理，並加上 64 位元零字首：
   • 觸發事件端鍵片段 = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. 瀏覽器會將這些金鑰片段連結起來產生金鑰。
   • 128 位元匯總鍵
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. 之後，當您準備好要求此鍵的摘要報表時，請即時產生報表：
   • 根據您感興趣的維度，按照先前的做法產生來源方和觸發方關鍵片段。
     • 來源端鍵片
       = <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"))
   • 就像瀏覽器一樣，將這些金鑰片段 OR 起來，即可產生瀏覽器先前產生的相同金鑰。
     • 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 時，您會回答以下問題：

使用策略 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 標頭中設定匯總鍵。在這個階段，您只能為每個鍵設定廣告放送時已知的鍵部分或鍵片。

讓我們產生關鍵元件：

接下來，我們來設定關鍵元件：

// 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 設定該轉換的可匯總價值。

設定觸發事件端鍵片，完成鍵

讓我們產生關鍵元件：

接下來，我們來設定關鍵元件：

// 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，藉此將相同的鍵片段新增至多個鍵。鍵片段會新增至兩個鍵。

設定可匯總的值

設定可匯總的值前，您需要將這些值放大，以減少雜訊。

假設有 1 筆購買交易，購買產品類型 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 OR 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 OR 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 (購買總價值) 摘要資料：
  • 產生來源端金鑰片段，就像在瀏覽器中設定時一樣。
  • 產生觸發端金鑰片段，就像在瀏覽器中設定時一樣。

• 針對這些鍵向匯總服務要求摘要資料。

處理摘要報表

最後，您會收到摘要報表，可能會像這樣：

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

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.