匯總鍵是什麼、在 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」個不同類型的值。
您可以將鍵的維度視為指標,例如「每個地理位置每個廣告活動的特定產品購買次數」。
鍵大小、尺寸
金鑰大小上限以位元為單位,也就是要建立完整索引鍵的零個數和二元數。這個 API 的金鑰長度為 128 位元。
這種大小的鍵可以相當精細,但越精細的鍵就越有可能產生雜訊。如要進一步瞭解雜訊,請參閱瞭解雜訊。
如先前所述,維度會編碼為匯總鍵。每個維度都有特定基數,也就是該維度能夠包含的不重複值數量。視基數而定,每個維度都必須以特定位元表示。在 n 位元中,您可以呈現 2n 個不同選項。
舉例來說,全球大約有 200 個國家/地區,「國家/地區」維度的基數可能會是 200。需要多少位元才能編碼這個維度?
7 位元只會儲存 27 = 128 個不同選項,但低於必要的 200。
8 位元會儲存 256 個不同選項 (超過必要 200 個),因此您可以使用 n=8 位元來編碼這個維度。8
金鑰編碼
在瀏覽器中設定鍵時,這些鍵應以十六進位編碼。在摘要報表中,鍵會以二進位檔案顯示 (也稱為值區)。
設定兩個關鍵組件來取得完整的鑰匙
假設您使用鍵追蹤下列維度:
- 廣告活動 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 位元 (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 代表產品類別 25 的購買次數,針對在歐洲推出的廣告活動 ID 12。
使用雜湊函式編碼維度
除了使用鍵結構對應,您也可以不使用索引鍵結構,以一致且可靠的方式動態產生索引鍵。
運作方式如下:
- 選取雜湊演算法。
- 在廣告放送時產生一個字串,當中包含您要追蹤的所有維度及其值。如要產生來源端的鍵
請雜湊這個字串,並考慮在 align 中加入 64 位元字尾 (零)
這項作業會觸發事件端鍵,讓 XOR 更容易理解。
- 來源端索引鍵
=<64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
- 請注意,
COUNT
編碼的項目與主要結構對應方法中的measurementGoalType=0
相同。COUNT
是較為精簡且更明確的文字。
- 來源端索引鍵
- 在轉換時產生字串,其中包含您想要追蹤的所有維度,並且
每當某人做出決策
其實就是根據自己價值觀做出選擇如要產生觸發事件端鍵,請對這個字串進行雜湊處理,再加入 0 的 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>
- 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"))
- 來源端索引鍵
- 和瀏覽器一樣,使用 XOR 這些金鑰來產生瀏覽器先前產生的金鑰。
- 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 只能使用 1 個精細的鍵結構 您需要的維度:
所有金鑰都會使用這個結構。
您可以將這個鍵結構分為兩種主要類型,藉此支援兩種評估方式 但縝密健全的倫理程序 也有助於達到產品開發目標
- 鍵類型 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 時,您必須加總 摘要報表,回答一些相關問題這些摘要值 也很吵統整這些資料後 Google 能理解各種雜訊。
但策略 B 的情況與 B 策略不同,後者會在摘要中顯示摘要值 報表原本可提供您所需的資訊。也就是說,出價策略 B 所產生的影響會比策略 A 來得小。
請問你該如何決定要採用的策略?針對現有的廣告客戶 可以參考歷來資料,判斷 轉換較適合策略 A 或策略 B。不過,如果是新的 您可能會決定:
- 使用精細鍵 (策略 A) 收集一個月的資料。 由於您要延長資料收集時間,摘要值 音量就會較高,雜訊則會相對較低
- 以合理的準確度評估每週轉換次數,以及 購物價值
在本例中,假設每週購買次數和消費金額 夠高,策略 A 會產生雜訊百分比 適合您的用途
因為 A 策略比較簡單且容易產生雜訊 會影響制定決策的能力,因此決定採用策略 A。
選取雜湊演算法
您決定採用以雜湊為基礎的方法 以便產生金鑰做法是選取雜湊演算法 支持該做法
假設您已選取 SHA-256。此外,您也可以使用較簡單的 安全演算法,如 MD5
在瀏覽器中:設定鍵和值
決定金鑰結構和雜湊演算法後 當使用者點擊或查看廣告後,便可註冊鍵和值 轉換。
接下來,我們將概略介紹您將設定用來註冊鍵和值的標頭 瀏覽器:
設定來源端的鍵
請在使用者點擊或觀看廣告時,在
Attribution-Reporting-Register-Aggregatable-Source
標頭。
在這個階段,每個鍵都只能設定鍵的部分或
在廣告放送期間得知的鍵。
讓我們產生主要部分:
金鑰 ID 的來源端金鑰... | 包含所要設定的維度值的字串 | 這個字串的雜湊值是十六進位,且已剪輯為前 64 位元 (64/4) = 16 個字元1) | 加上零的十六進位雜湊,簡化 XOR-ing。這是來源端的鍵。 |
---|---|---|---|
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 的作業。 這是來源端的鍵。 |
---|---|---|---|
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"]
},
])
);
請注意,如要將相同索引鍵加入多個索引鍵,請先列出多個索引鍵
金鑰 ID 為 source_keys
,系統會將鍵新增至兩個金鑰。
設定可匯總值
設定可匯總值之前,請先向上擴充 減少雜訊
假設某次購買類型 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,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 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]
},
]
在這個頁面中,你可以在同一張可匯總報表中查看兩個不同貢獻 報表。
索取摘要報表
- 批次處理可匯總報表。請遵循指示: 批次處理。
- 產生您想查看資料的鍵。舉例來說,如要查看摘要
COUNT
(總購物次數) 和VALUE
(總購物價值) 的資料 廣告活動 ID 12 × 地理位置 ID 7 × 產品類別 25:- 產生來源端金鑰,方法與設定原始碼端鍵相同 。
- 產生觸發事件端鍵,方法與在瀏覽器中設定時相同。
您想要要求的指標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 美元的總購買價值。
因此,摘要報表提供您以下洞察資訊:
- 在報表時間範圍內,廣告活動 #12 在歐洲運轉大約 156 次購買 (± 噪音) 做為產品類別 #25
- 在報表時間範圍內,廣告活動 #12 在歐洲購買了 $31,230 美元的購買量 (± 噪音) 做為產品類別 #25