瞭解匯總鍵的用途、在 Attribution Reporting API 中的使用方式,以及如何將目標轉換為鍵。
您是廣告技術公司,為各種產品類別在多個地點放送廣告活動,因此希望協助廣告主解答下列問題:
- 在每個地理區域中,我的每個廣告活動分別為各產品類別帶來多少購買次數?
- 每個廣告活動在每個地理區域中,為各個產品類別帶來多少收益?
許多廣告技術公司會鼓勵廣告主設定各種轉換類型,但專注於最重要的轉換 (例如購買) 也是不錯的做法,可確保這些重要事件的摘要結果詳細且準確。
為此,您需要先思考要回答哪些問題,再開始收集資料。
維度、鍵和值
如要回答這些問題,請先瞭解維度、鍵和值。
尺寸
如要瞭解廣告活動的收益情況,請按照本文說明追蹤下列維度:
- 廣告活動 ID:特定廣告活動的 ID。
- 地理位置 ID:放送廣告的地理區域。
- 產品類別:你定義的產品類型。
廣告放送時 (廣告放送時間),系統會知道廣告活動 ID 和地理位置 ID 維度,但使用者完成轉換時 (轉換時間),系統才會從觸發事件得知產品類別。
本範例要追蹤的維度如下圖所示:
什麼是匯總鍵 (buckets)?
字詞匯總鍵和 bucket 是指同一件事。匯總鍵用於設定報表的瀏覽器 API。可匯總報表、摘要報表和匯總服務 API 中都會使用「bucket」一詞。
匯總鍵 (簡稱「鍵」) 是代表所追蹤維度值的資料片段。之後,系統會根據每個匯總鍵匯總資料。
舉例來說,假設您要追蹤「產品類別」、「地理位置 ID」和「廣告活動 ID」維度。
如果位於地理位置 ID 7 的使用者看到廣告活動 ID 12 的廣告,之後購買產品類別 25 中的產品而完成轉換,您可以設定類似下圖的匯總鍵:
稍後您會發現,實際的匯總鍵並非完全如此,但目前請先著重於鍵中包含的資訊。
什麼是可匯總的值?
如要回答上述維度的問題,您需要瞭解:
- 購買次數 (購買次數)。匯總後,摘要報表會顯示總購買次數 (摘要值)。
- 每筆交易的收益 (購物價值)。匯總後,這項資料會顯示在摘要報表中,做為總收益 (摘要值)。
這兩項 (單次轉換的購買次數和單次轉換的購買價值) 都是可彙整的值。可匯總的值可視為評估目標的值。
| 問題 | 可匯總值 = 評估目標 |
|---|---|
| How many purchases… | 購買次數 |
| 收益金額… | 購物價值 |
假設位於地理位置 ID 7 的使用者看到廣告活動 ID 12 的廣告,之後購買產品類別 25 的產品,並轉換價值 $120 美元 (假設您的幣別為美元),您可能會設定如下的匯總鍵和可匯總值:
系統會將多位使用者各個鍵的可匯總值加總,產生匯總深入分析資料,並以摘要報表中的摘要值形式呈現。
系統會加總可匯總的值,為評估目標產生匯總洞察資料。
請注意,這張圖表省略瞭解密程序,並以簡化範例呈現,未套用雜訊。下一節將說明這個含有雜訊的範例。
從鍵/值到報表
現在來討論可匯總的鍵和值與報表的關係。
可匯總報表
當使用者點按或瀏覽廣告,然後完成轉換時,您會指示瀏覽器儲存 {匯總鍵, 可匯總值} 組合。
以我們的範例來說,當使用者點按或觀看廣告,然後完成轉換時,您會指示瀏覽器產生兩項貢獻 (每個評估目標各一項)。
稍後您會發現,{匯總鍵、可匯總值} 可匯總報表並非完全如此,但目前請先著重於報表所含資訊。
如果您指示瀏覽器產生兩項貢獻,瀏覽器就會產生可匯總報表 (如果可以比對轉換與先前的瀏覽或點擊)。
可匯總報表包含:
- 您設定的貢獻。
- 點擊或觀看事件和轉換事件的相關中繼資料:發生轉換的網站等。查看可匯總報表中的所有欄位。
可匯總的報表採用 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"},
{...}
]
在實際情況中,摘要報表的編碼方式會導致 bucket 和值與範例中顯示的不同 (也就是 bucket 可能看起來像 \u0000\u0000\x80\u0000)。Bucket 和值都是位元組字串。
匯總鍵的實際應用
廣告技術公司通常會分兩步驟定義匯總鍵 (值區):廣告獲得點擊或瀏覽時,以及使用者轉換時。
金鑰結構
我們會使用「索引鍵結構」一詞,指派編碼到索引鍵中的維度集。
舉例來說,廣告活動 ID × 地理區域 ID × 產品類別就是重要的結構。
金鑰類型
系統會針對多位使用者/瀏覽器,加總特定鍵的可匯總值。但我們發現,可匯總的值可以追蹤不同的評估目標,例如購買價值或購買次數。您想確認匯總服務會加總相同類型的可匯總值。
如要這麼做,請在每個鍵中編碼一筆資料,說明摘要值代表的內容,也就是這個鍵參照的評估目標。其中一種做法是為代表評估目標類型的鍵建立額外維度。
以先前的範例來說,這類評估目標有兩種可能的值:
- 購買次數是第一種評估目標。
- 購買價值是第二種評估目標。
如果您有 n 個評估目標,評估目標類型就會有 n 種不同的值。
您可以將鍵的維度視為指標。舉例來說,「每個廣告活動在每個地理區域中,特定產品的購買次數」。
金鑰大小、維度大小
金鑰大小上限以位元定義,也就是建立完整金鑰的二進位數字中,零和一的數量。這個 API 支援 128 位元的金鑰長度。
這個大小可提供非常精細的鍵,但鍵越精細,越可能產生雜訊值。如要進一步瞭解雜訊,請參閱「瞭解雜訊」。
如先前所述,維度會編碼至匯總鍵。每個維度都有特定基數,也就是維度可採用的不同值數量。每個維度都需要以特定位元數表示,具體取決於基數。使用 n 位元時,可以表示 2n 個不同的選項。
舉例來說,由於全球約有 200 個國家/地區,因此「國家/地區」維度的基數可能為 200。編碼這個維度需要多少位元?
7 位元只能儲存 27 = 128 個不同的選項,少於必要的 200 個。
8 位元可儲存 28 = 256 個不同的選項,超過必要的 200 個,因此您可以使用 n=8 位元來編碼這個維度。
金鑰編碼
在瀏覽器中設定金鑰時,金鑰應以十六進位編碼。在摘要報表中,鍵會以二進位形式顯示 (並命名為 buckets)。
設定完整金鑰的兩個金鑰片段
假設您使用金鑰追蹤下列維度:
- 廣告活動 ID
- 地理位置 ID
- 產品類別
廣告放送時 (廣告放送時間),系統會知道廣告活動 ID 和地理位置 ID 維度,但使用者完成轉換時 (轉換時間),系統才會從觸發事件得知產品類別。
在實務上,這表示您會分兩個步驟設定金鑰:
- 您會在點擊或觀看時設定金鑰的一部分,也就是廣告活動 ID × 地理位置 ID。
- 您會在轉換時設定鍵的第二部分 (產品類別)。
這些不同的金鑰部分稱為「金鑰片段」。
系統會對金鑰片段執行 OR 運算 (v),計算出金鑰。
範例:
- 來源端金鑰片段 =
0x159 - 觸發事件端鍵 =
0x400 - 鍵 =
0x159 v 0x400 = 0x559
對齊重要部分
使用精心放置的 64 位元填補或偏移 (十六個零),將兩個 64 位元金鑰片段擴充為 128 位元後,OR 運算金鑰片段就等同於串連金鑰片段,更容易推論和驗證:
- 來源端金鑰片段 =
0xa7e297e7c8c8d0540000000000000000 - 觸發事件端鍵 =
0x0000000000000000674fbe308a597271 - 鍵 =
0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271
每次廣告點擊或觀看可有多個鍵
在實務上,您可能會為每個歸因來源事件 (廣告點擊或瀏覽) 設定多個鍵。舉例來說,您可以設定:
- 追蹤地理區域 ID × 廣告活動 ID 的鍵。
- 另一個追蹤廣告素材類型 × 廣告活動 ID 的索引鍵。
如需其他範例,請參閱策略 B。
將維度編碼為鍵
要求摘要報表時,您需要為特定匯總鍵組合要求摘要報表,告知匯總服務您想存取哪些指標。
摘要報表包含原始的 {鍵, 摘要值} 配對,且不含鍵的其他資訊。這表示:
- 當使用者瀏覽或點按廣告,然後完成轉換時,您需要根據維度代表的值,可靠地設定鍵。
- 定義要索取摘要報表的鍵時,您需要根據要查看匯總資料的維度值,即時產生或存取與使用者查看或點擊廣告並完成轉換時設定的鍵相同的鍵。
使用鍵結構對應編碼維度
如要將維度編碼為鍵,您可以在定義鍵時 (廣告放送前) 預先建立及維護鍵結構對應。
索引鍵結構對應表代表每個維度及其在索引鍵中的位置。
在實務上,建立及維護鍵結構對應表,表示您必須實作及維護解碼器邏輯。如果您想尋找不需要這麼做的做法,請考慮改用以雜湊為基礎的方法。
範例如下:
假設您打算追蹤特定廣告活動、地理區域和產品的購買次數和購買價值。
產品類別、地理區域 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 (第一個位元) 是最右側的位元,產品類別 (最後一個位元) 則是位於最左側。
在每個維度中,最重要的位元 (即帶有最大數值的位元) 是最左邊的位元。最不顯著位元 (攜帶最小數值的位元) 是最右側的位元。
讓我們看看如何使用鍵結構對應解碼鍵。
假設 0b1100100111100 是任意範例金鑰,且您知道這個金鑰遵循上圖的金鑰結構對應。
根據金鑰結構對應表,這個金鑰會解碼為:
`11001 0 011 1100`
因此,金鑰 0b1100100111100 代表在歐洲推出的廣告活動 ID 12 中,產品類別 25 的購買次數。
使用雜湊函式編碼維度
您可以使用雜湊函式,以一致且可靠的方式動態產生金鑰,而不必使用金鑰結構對應。
運作方式如下:
- 選取雜湊演算法。
- 在放送廣告時,產生包含所有要追蹤的維度和值字串。如要產生來源端金鑰片段,請雜湊處理這個字串,並考慮新增 64 位元的零尾碼,以便與觸發端金鑰片段對齊,並簡化 OR 的推論程序。
- 來源端金鑰片段
=<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")>
- 觸發事件端鍵
=
- 瀏覽器會對這些金鑰片段執行 OR 運算,產生金鑰。
- 128 位元匯總金鑰
=<64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
- 128 位元匯總金鑰
- 稍後,當您準備好要求這項金鑰的摘要報告時,請即時產生:
- 根據您感興趣的維度,產生來源端和觸發端的重要部分,做法與先前相同。
- 來源端金鑰片段
=<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>
- 128 位元匯總金鑰
- 根據您感興趣的維度,產生來源端和觸發端的重要部分,做法與先前相同。
如果您使用這個以雜湊為基礎的方法,請參考以下幾項實用訣竅:
- 請務必一律使用相同的維度順序。確保雜湊值可以穩定地重新產生。(
"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:金鑰結構 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) | 附加零的十六進位雜湊,可簡化 OR 運算。這是來源端的鍵片段。 |
|---|---|---|---|
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) | 附加零的十六進位雜湊,用於簡化 OR 運算。這是來源端的鍵。 |
|---|---|---|---|
key_purchaseCount |
ProductCategory=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 × 32,768 = 32,768key_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(購買總價值) 摘要資料,請執行下列操作:- 產生來源端金鑰片段,就像在瀏覽器中設定金鑰片段時一樣。
- 產生觸發端金鑰片段,就像在瀏覽器中設定時一樣。
| 您要要求的指標1 | 來源端金鑰片段 | 觸發事件端鍵片段 | 向匯總服務提出要求的金鑰2 |
|---|---|---|---|
購買總次數 (COUNT) |
0x3cf867903fbb73ec 0000000000000000 |
0x00000000000000 00f9e491fe37e55a0c |
0x3cf867903fbb73 ecf9e491fe37e55a0c |
總購買價值 (VALUE) |
0x245265f432f16e73 0000000000000000 |
0x0000000000000000 f9e491fe37e55a0c |
0x245265f432f16e73 f9e491fe37e55a0c |
- 向匯總服務要求這些金鑰的摘要資料。
處理摘要報表
最終您會收到摘要報表,內容可能如下所示:
[
{"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
"value": "2558500"},
{"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
"value": "687060"},
…
]
第一個 bucket 是二進位檔中的 COUNT 鍵。第二個 bucket 是二進位檔中的 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.