概括而言，Cookie 比對是指廣告客戶或供應商將自身網域中的 Cookie，與 Google 網域中的 Cookie 建立關聯的程序。您可以透過比對這些 Cookie，連結自有的第一方資料與同一位使用者的 Google 廣告資料 (透過 Display & Video 360 和 Campaign Manager 360 追蹤)，以便納入客戶關係管理系統的資料，並進一步瞭解使用者行為。透過注重隱私權的彙整作業來結合這些資料後，您就可以：
- 根據購物車中遭放棄的特定商品指定目標對象 (如果這些使用者曾與您的廣告和網域互動)。
- 判定哪些廣告有助於拉長您網域上的工作階段時間。
- 分析與廣告活動放送後資料彙整的購買記錄。
限制和使用者隱私
Cookie 比對功能雖然強大，但有一些限制：
- 禁止彙整
*_match和非*_match資料表。 - 您和 Google 都必須完成工程作業。
- 您可能只能比對部分 Google 廣告資料。媒合率會受到許多因素影響，且因用途和用戶端設定而異。媒合率通常會低於使用者預期。使用者必須與您的網域「和」廣告互動，才符合加入 Cookie 比對的資格。
- 設定完畢後，Google 就會開始為對照表填入資料。視使用者造訪網站並收到相符像素的頻率而定，對照表可能要過數個月才能呈現全面且穩定的使用者資料。
- 您無法將個別使用者與多部裝置建立關聯，除非他們處於登入狀態，或是您有某些方式可以跨裝置連結使用者。
- 您無法使用多個 Cookie 比對單一使用者，使用者清除 Cookie 時就會出現這種情況。
- 在對照表上執行的工作，必須符合與廣告資料中心其他工作相同的匯總需求條件。媒合率和網域造訪頻率偏低，可能會導致資料取得不易，這是因為媒合率和匯總需求條件會共同產生影響1。
- 根據 Google 使用者隱私政策，您：
- 不得比對特定使用者的登入和登出資料。
- 無法比對多個帳戶的登入資料。
- 無法將資料與已停用廣告個人化功能的使用者進行比對。
- 如果是 iOS 事件，比對資料只能來自 iOS 14.5 以上版本的應用程式，且使用者必須已根據 Apple 的「App 追蹤透明度」架構授予相關權限。
Cookie 比對的運作方式
如要讓 Google 為對照表填入資料，您必須找出要比對廣告資料的網域，並在每個網頁上加入比對代碼。加入像素的位置取決於廣告目標。舉例來說，您可以嘗試比對每位造訪網域的使用者 (幾乎所有網頁都必須加入像素)，也可以比對已轉換的使用者 (轉換頁必須加入像素)。一般來說，像素的涵蓋範圍越廣，媒合率就會越高。
比對代碼是透明的 1x1 像素，內含 Cookie 比對設定檔 ID，以及經過編碼的使用者或 Cookie ID：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm=Q29va2llIG51bWJlciAxIQ" />
您可以透過這個比對代碼與 Google Cookie 比對服務展開通訊。
逐步簡介
- 使用者造訪含有比對代碼的網頁。
- 比對代碼會展開一系列重新導向，目的地為 Google Marketing Platform、Google Ads 和 YouTube 比對服務。這些要求包含該使用者在網站上的 ID 或 Cookie，以及每個比對服務 ID 空間中的 Google Cookie。
- 透明的 1x1 像素會傳回瀏覽器，確認是否已執行要求。
這項程序如下圖所示：
設定
在廣告資料中心設定 Cookie 比對的程序如下：
- 請與帳戶代表聯絡，表明您有意使用 Cookie 比對功能。他們會討論您的目標，並進一步說明如何在網域上部署追蹤像素。
- 廣告資料中心專家會另外展開對話，討論技術相關規定和用途。
- 在您部署追蹤像素和錯誤端點時，Google 會建立對照表。
完成上述步驟後，您無須立即採取任何行動。Google 每天都會為對照表2填入資料，因此請預留充裕的時間，讓資料表能累積足夠的資料來提供有意義的比對結果，並滿足匯總需求條件。這取決於使用者造訪網站的頻率。因此，相較於每月都有訪客的網站，每日都有訪客的網站會更快達成這個目標。隨著出現全新相符項目的速度趨緩，對照表也會納入更完整的資料。
查詢對照表
如果對照表包含足夠的資料，可以滿足隱私權檢查的條件，您就能針對資料表執行查詢。
廣告資料中心結構定義中每個包含 user_id 欄位的資料表，都會附帶一個 *_match 資料表。舉例來說，廣告資料中心也會為 adh.google_ads_impressions 資料表，產生名為 adh.google_ads_impressions_match 的對照表，其中包含 User-ID。
這些資料表包含原始資料表的一部分使用者，而 user_id 都有一個相符項目。舉例來說，如果原始資料表包含使用者 A 和使用者 B 的資料，但只有使用者 A 成功比對，那麼使用者 B 就不會出現在對照表中。
對照表包含另一個名為 external_cookie 的資料欄，該欄會以位元組形式儲存 Cookie。
編寫查詢時，請務必考慮欄位的類型。SQL 比較運算子會認為您要比較的常值類型相同。視第一方資料表儲存 user_id 的方式而定，您可能需要先為資料表中的值編碼，才能比對資料。您必須將彙整鍵轉換為位元組，才能成功比對。
JOIN ON
google_data_imp.external_cookie = CAST(my_data.user_id AS BYTES)
另外，在 SQL 中比較字串時會區分大小寫，因此您可能需要為比較兩方的字串編碼來提高比較準確度。
為 User-ID 編碼
在用戶端為 User-ID 編碼
為確保各種 ID 格式都能安全地透過網址傳送，所有 ID 都必須經過網址安全 Base64 編碼才能傳送。網址安全 Base64 解碼 ID 會顯示在廣告資料中心的 external_cookie 欄位中，因此您必須復原在編碼前套用的所有轉換作業，才能擷取原始 ID。
如果 ID 一律不超過 24 個半形字元 (或位元組)，您便可在像素中加入網址安全 Base64 編碼 ID，如範例 1 所示。如果 ID 超過 24 個半形字元 (或位元組)，則必須轉換為不超過 24 個位元組的表示法。在某些情況下 (例如範例 2 中的 GUID)，需要轉換為位元組表示法。在其他情況下，您可能需要將部分 ID (或雜湊值) 傳送給 Google。請注意，無論是哪種情況，您都必須確保自己編寫的 SQL JOIN，能以相同方式轉換第一方資料表中的 ID。
範例 1
User-ID 值一律不超過 24 個位元組的長度限制。廣告資料中心建議您直接將 User-ID 傳送至廣告資料中心 (基於傳送網址的目的，編碼為網址安全 Base64 後)。
var userId = 'abcdef123456789';
// Encode the string (or number) in normal base64.
var userIdBase64 = btoa(userId);
// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_')
.replace(/=+$/, '');
// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
+ userIdBase64;
document.body.appendChild(imgElement);
範例 2
您將通用專屬 ID (UUID) 值指派為 User-ID，例如：123e4567-e89b-12d3-a456-426655440000。
廣告資料中心建議在比對時進行下列轉換：
- 將 UUID 格式調整為 36 個半形字元的字串。
- 為 UUID 進行十六進位解碼。
- 將 UUID 格式調整為位元組。
- 網址安全 Base64 編碼位元組。
- 將 UUID 格式調整為字串。
您可以使用下列程式碼導入這個 ID：
JavaScript
var userId = '123e4567-e89b-12d3-a456-426655440000';
// A helper function for converting a hex string to a byte array.
function strToBytes(str) {
for (var bytes = [], i = 0; i < str.length; i += 2) {
bytes.push(parseInt(str.substr(i, 2), 16));
}
return bytes;
}
// Remove the formatting dashes from the UUID.
userId = userId.replace(/-/g, '');
// Encode the hex string as a byte array.
var userIdBytes = strToBytes(userId);
// Encode the byte array in normal base64.
var userIdBase64 = btoa(String.fromCharCode(...new Uint8Array(userIdBytes)));
// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_').replace(
/=+$/, '');
// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
+ userIdBase64;
document.body.appendChild(imgElement);
Python
import base64
user_id = '123e4567-e89b-12d3-a456-426655440000'
user_id_as_bytes = bytes.fromhex(user_id.replace('-', ''))
base64.urlsafe_b64encode(user_id_as_bytes)
如果找到與 Google User-ID 相符的項目，external_cookie 欄位就會包含以位元組值表示的 ID。如要重建原始 ID，必須進行以下轉換：
- 將
external_cookie格式調整為位元組。 - 為
external_cookie進行十六進位編碼。 - 將
external_cookie格式調整為字串。
在廣告資料中心為 User-ID 編碼
如果您將 UUID 字串儲存在第一方資料的欄位中，就必須將字串轉換為位元組 (如上例所示)，才能成功彙整資料。
下例顯示如何為 UUID 編碼並彙整到外部 Cookie 欄位中：
JOIN my_data ON imp.external_cookie = FROM_HEX(REPLACE(my_data.uuid, '-', ''))
請注意，您無法將整數轉換成位元組。如果您的 User-ID 是整數 (如上方範例 1 所示)，就必須先轉換為字串：
JOIN my_data ON imp.external_cookie = CAST(CAST(my_data.user_id AS STRING) AS BYTES)
提醒您，比對資料所需的編碼取決於儲存資料的方式，以及資料傳送至廣告資料中心前的編碼方式。
查詢範例
下例會將第一方資料與 google_ads_impressions_match 彙整，並在第二次查詢中將這些結果與 adh_google_ads_impressions 彙整。
SELECT
imp.campaign_id as campaign_id,
sum(my_data.recent_orders) as orders,
average(my_data.lifetime_value) as ltv
FROM
adh.google_ads_impressions_match as imp
LEFT JOIN
my_data ON imp.external_cookie = my_data.company_guest_id_bytes
GROUP BY
campaign_id
將前一項查詢的結果儲存為 previous_results 後，您現在可以彙整 google_ads_impressions，這樣零曝光廣告活動的資料就會加到結果中。
SELECT
campaign_id,
COALESCE(orders, 0) as orders,
COALESCE(ltv, 0) as ltv,
FROM (SELECT DISTINCT campaign_id
FROM adhgoogle_ads_impressions)
LEFT JOIN previous_results USING (campaign_id)