Cookie 比對功能可用來比對 Cookie (例如瀏覽網站使用者的 ID) 與對應的出價工具專屬 Google 使用者 ID，並建立使用者名單，協助您做出更有效的出價選擇。本指南說明 Cookie 比對使用的概念、不同的 Cookie 比對工作流程，以及它們在特定用途中可能產生的任何變化。
概念
什麼是 Cookie 比對？
網域擁有者通常會針對瀏覽網站的使用者設定 Cookie 內容，並用於識別該網域內的使用者。即使兩個網域擁有者另有同意交換這項資料，網路瀏覽器的安全模型也會限制一個網域無法讀取另一個網域設定的 Cookie。
在數位廣告方面，Google 會使用屬於 doubleclick.net 網域的 Cookie 識別使用者，而參與即時出價的出價方可能擁有專屬網域，用於識別想向哪一組使用者顯示廣告。Cookie 比對可讓出價方將 Cookie 與 Google 的 Cookie 進行比對，以便廣告客戶在出價要求中判定傳送的曝光是否與您指定的使用者相關聯。這樣一來，他們會收到自己的 Cookie 資料，或是出價方專用的 Google 使用者 ID，這種 ID 是出價要求中的 doubleclick.net Cookie 加密形式。
本指南所述的 Cookie 比對服務可協助您建立及維護出價方 Cookie 和 Google 使用者 ID 之間的關聯，並允許為使用者名單填入資料。
對照表
對照表可用來將不同網域中的 ID 或其他資料對應至另一個網域。出價方可以使用 Cookie 比對服務，將特定使用者的 Cookie 對應至使用者的 Google 使用者 ID，或填入 Google 代管的對照表，藉此填入專屬的對照表。出價方的應用程式需要對照表，才能存取看到曝光的使用者 Cookie 資料。
Google 代管的對照表
為簡化維護作業、改善延遲，以及存取特定區域中使用者比對資料的權限，建議您允許 Google 託管您的對照表。這樣可讓您指定要對應至特定使用者 Google 使用者 ID 的網頁安全 Base64 編碼字串 (以下稱為代管比對資料)。建立比對項目後，可以透過下列方式使用：
即時出價：在後續與使用者相關曝光的出價要求中，Google 會傳送您與其 Google 使用者 ID 相符的代管比對資料給您。如果出價端點已設為使用 Google 的 RTB 通訊協定，您會透過
BidRequest.hosted_match_data欄位收到以解碼的位元組形式傳送此訊息。在 Google 的 OpenRTB 導入作業中，BidRequest.user.buyeruid會以網路安全 base64 編碼字串傳回這項資料。使用者名單：使用者名單可填入 Google 使用者 ID 或代管比對資料。
- 預先指定：您可以設定預先指定，只接收包含代管比對資料的出價要求。您可以利用這項功能，對 Cookie 空間外的使用者移除關聯性較低的曝光。
使用者名單
您可以透過 Real-Time 出價 API 建立及管理使用者名單。建立完成後，您可以使用下述的 Cookie 比對工作流程，或透過大量上傳上傳者服務，填入這些名單。
入門課程
要開始使用 Cookie 比對，您必須與客戶技術顧問聯絡，他們可以啟用特定工作流程並協助您設定下列項目：
- Cookie 比對聯播網 ID (NID)：專門用來識別出價方帳戶，進行 Cookie 比對和其他相關作業的字串 ID。
- Cookie 比對網址：端點的基準網址，會在 Cookie 比對工作流程中接受及處理傳入的要求。出價方可將巨集嵌入這個網址，藉此控制傳送至 Cookie 比對工作流程的參數順序。
- 比對代碼：在出價工具啟動的 Cookie 比對工作流程中，您必須加入使用者的瀏覽器代碼。這類廣告可以與廣告一併放送，也可以刊登在廣告以外的網站資源上。
- Cookie 比對報表網址 (選填)：在單向 Cookie 比對工作流程中，您可以提供一個選用網址，以便在 Cookie 比對失敗透過 HTTP 302 重新導向時收到錯誤詳細資料。根據預設，只有在 Cookie 比對作業發生錯誤時，系統才會將回應傳送至這個網址，但出價方可能會要求一律傳送重新導向。
- Cookie Match Assist 網址：如果廣告交易平台導入 Cookie Match Assist 工作流程，這是用於回應傳入要求的端點基準網址。
- Cookie 比對輔助配額：如果是導入 Cookie 比對輔助工作流程的廣告交易平台，這是指其 Cookie 比對網址每秒可接收的請求數量上限。這是為了避免 CMA 要求因要求超載。
Cookie 比對巨集
在任何支援的 Cookie 比對工作流程中，出價方的 Cookie 比對網址通常會附加參數在無保證的排序中。如果出價方的整合需要一致的參數順序，可以在 Cookie 比對網址中加入巨集，以確保刊登位置能正常顯示。
支援的巨集
出價方可以視需要設定 Cookie 比對網址，以 %%GOOGLE_<PARAM_NAME>%% 或 %%GOOGLE_<PARAM_NAME>_PAIR%% 的形式加入一或多個巨集。支援的巨集及其展開值如下：
| 巨集 | 擴充值 |
|---|---|
| GOOGLE_GID | GOOGLE_USER_ID |
| GOOGLE_GID_PAIR | &google_gid=GOOGLE_USER_ID |
| GOOGLE_CVER | COOKIE_VERSION_NUMBER |
| GOOGLE_CVER_PAIR | &cver=COOKIE_VERSION_NUMBER |
| GOOGLE_ERROR | ERROR_ID |
| GOOGLE_ERROR_PAIR | &google_error=ERROR_ID |
| GOOGLE_PUSH | PIXEL_MATCH_DATA |
| GOOGLE_PUSH_PAIR | &google_push=PIXEL_MATCH_DATA |
| GOOGLE_ALL_PARAMS | google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID |
巨集範例
出價方提供 Cookie 比對和託管於 https://user.bidder.com.cookies 的端點，因此在導入時，除了 Pixel 比對參數外，出價工具定義的參數還需按照以下順序排列：google_push、google_gid、google_cver 和 google_error。出價方可將 Cookie 比對網址設為以下項目：
https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%
當 Google 稍後傳送比對要求給這個出價方時，會展開為如下所示的結構：
https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3
Cookie 比對服務工作流程
針對下列不同用途，Google 的 Cookie 比對服務目前支援三種工作流程。
出價方發起：雙向 Cookie 比對
雙向 Cookie 比對是指出價方發起的工作流程，會在使用者的瀏覽器中放置比對代碼，藉此將代碼導向 Google。這個工作流程可讓 Google 和出價工具為對照表填入資料。以下是此工作流程的簡單範例。
步驟 1：放置比對代碼
為了啟動這個流程，出價方必須放置比對代碼，使其會在使用者的瀏覽器中顯示。只要將 Google 使用者 ID 只傳回出價工具的簡易比對代碼，結構可能如下：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />
您可以在比對標記中加入其他參數，滿足不同的用途。如要進一步瞭解這些參數，請參閱「比對代碼網址參數」一文。
步驟 2：Google 回應，包括比對資料
比對標記會導致 Google 的 Cookie 比對服務接收使用者瀏覽器發出的要求，接著發出 HTTP 302 重新導向，指向出價方的 Cookie 比對網址。重新導向會包含在網址中指定 Google 使用者 ID 及其版本號碼的查詢參數，而出價工具也會收到要求標頭中的 Cookie。實際上，指定為 https://ad.network.com/pixel 的 Cookie 比對網址時，上述簡易比對標記的重新導向網址可能會如下所示：
https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
透過 google_gid 參數傳遞的 Google 使用者 ID 是未填充的網路安全 base64 編碼字串。對於選擇代管對照表的出價方，建議他們儲存 Cookie 比對服務傳回的確切字串。在後續的出價要求中，這個值會對應至 Google RTB 通訊協定中透過 BidRequest.google_user_id 指定的值，或是 Google 的 OpenRTB 導入中的 BidRequest.user.id。
google_cver 中指定的版本代表 Google 使用者 ID 的數字版本號碼。特定使用者的 Google 使用者 ID 不會頻繁變更，之後將增加。
如果 Google 在處理比對要求時發生錯誤，則會改為指定 google_error 參數。
步驟 3：出價工具處理重新導向並回應包含像素
出價方會收到重新導向至其 Cookie 比對網址的重新導向，其中包含在第一個步驟中指定的參數，以及 Google 在第二個步驟中提供的參數。此外，使用者也會在 HTTP 標頭中收到 Cookie。如果作業成功，代管自有對照表的出價方可以將其 Cookie 與回應中包含的 Google 使用者 ID 進行比對。建議出價工具儲存 Cookie 比對服務傳回的確切字串。
如果作業失敗，出價方會在重新導向中收到 google_error 參數。這是對應不同錯誤狀態的數值，用於識別發生的特定錯誤。如要進一步瞭解可能的錯誤值，請參閱這篇文章。如果出現錯誤，您可以加上新的比對標記，嘗試再次比對該使用者。
出價工具必須一律顯示 1x1 的隱藏像素圖片來回應，或改為傳回 HTTP 204「無內容」回應。
Cookie 比對工作流程圖
此工作流程如下圖所示，其中要求和回應以箭頭表示，而隨附的資料項目則列在括號中。
比對代碼網址參數
| 參數 | 說明 |
|---|---|
google_nid |
出價方帳戶的聯播網 ID (NID)。這個 ID 可透過出價方資源擷取。 |
google_cm |
向 Google 的 Cookie 比對服務指明應執行 Cookie 比對作業。系統會忽略這個參數的值，並可以省略。 |
google_sc |
此參數已淘汰。在沒有使用者的情況下，為使用者設定 Google 的 Cookie。系統會忽略這個參數的值，並可以省略。如果沒有 Cookie，則省略參數會導致錯誤發生。 |
google_no_sc |
此參數已淘汰。這代表 Google 的 Cookie 比對服務在沒有使用者的 Cookie 時，不應為使用者設定 Cookie。系統會忽略這個參數的值，並可以省略。 |
google_hm |
出價方想要儲存在 Google 代管對照表中的資料。
此值是採用網路安全 Base64 編碼的字串 (可加上邊框間距)。原始資料不得超過 40 個位元組。例如 |
google_redir |
出價方可以指定網址編碼字串，用來指示 Google 是否要將 HTTP 302 重新導向傳送到這個比對代碼的編碼網址。如此一來，Google 就能放在與合作夥伴的鏈結呼叫前方。如果指定時沒有 google_hm 或 google_cm，這會導致錯誤。 |
google_ula |
用於將使用者加入現有使用者名單的字串。值的格式為 userlistid[,timestamp]：
若要將使用者加入多份清單，您可以重複使用這個網址參數。 |
gdpr |
表示該要求受到 GDPR 對數據用量的限制。詳情請參閱下方的「
歐盟地區使用者同意聲明規定」一文，或是
Authorized Buyers IAB「資訊公開和同意聲明架構第 2.0 版」說明文件中的對 Cookie 比對資格的影響。 範例： |
gdpr_consent |
代表使用者同意聲明的資訊公開和同意聲明字串。詳情請參閱下方的「歐盟使用者同意聲明規定」或 Authorized Buyers IAB 資訊公開和同意聲明架構第 2.0 版說明文件中的「資訊公開和同意聲明 (TC) 字串的傳送方式」。 |
process_consent |
表示出價方已針對
Google 的《歐盟地區使用者同意授權政策》中指定的資料用途取得使用者同意聲明。 如果要求不適用《歐盟地區使用者同意授權政策》，或是該要求中還有其他同意聲明參數 ( 範例： |
除了上述參數外，出價方也可以自行指定這些參數，以做為網址參數的參數附加在重新導向網址中。請注意，系統會忽略名稱前置字串為 google_ 的出價方定義參數，因為這些參數由 Google 保留用於日後的開發作業，且不保證會保留參數的排序。包含出價工具定義參數的比對代碼看起來可能像這樣：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />
重新導向網址參數
重新導向網址的建構基礎是為出價方帳戶所設定的基本 Cookie 比對網址，包括 google_ 和出價工具定義的參數，視比對代碼中指定的參數而定。以下 google_ 回應參數已定義：
| 參數 | 說明 |
|---|---|
google_gid |
Google 使用者 ID。如果要求中指定了 google_cm，且要求執行成功，則設定此屬性。 |
google_cver |
Cookie 版本。如果要求中指定了 google_cm，且要求執行成功，則設定此屬性。 |
google_error |
代表整體要求錯誤的整數值。收到訊息時，代表未執行任何作業，且不會設定其他
|
google_hm |
只有在嘗試寫入 Google 代管對照表失敗時，才會出現。在這種情況下，其值會是下列其中一個狀態碼：
|
google_ula |
使用者名單新增作業的狀態。如果要求中指定了多個 例如：
|
Cookie 比對工作流程範例
以下情境說明在瀏覽網頁的一般使用者中，Cookie 比對可能呈現的樣子。
情境 1：使用者清除 Cookie 並瀏覽網站
Jane 會清除所有 Cookie 的快取。然後造訪 ExampleNews.com 首頁。
接下來會發生的情況是：
- ExampleNews.com 會顯示，並呼叫 Google (Ad Manager) 提供的廣告。
- 由於廣告單元符合動態分配資格，Google 會透過即時出價服務，將出價要求傳送給 FinestDSP 和其他出價方。
- FinestDSP 的出價工具應用程式接收及處理出價要求，並傳送出價回應。
- Google 會收到出價方的出價回應，包括 FinestDSP 回應 (指定了比對代碼 (像素)) 的廣告。
- FinestDSP 贏得競價。Google 向 Jane 放送 FinestDSP 的廣告和比對代碼。
- 比對代碼呼叫 Google 的 Cookie 比對服務，並指定
google_nid和google_cm參數。 - Cookie 比對服務讀取阿珍的 Google Cookie，然後將已設定
google_user_id和google_cver參數的阿珍瀏覽器重新導向至 FinestDSP 的 Cookie 比對網址。 - Jane 的瀏覽器會載入重新導向至 FinestDSP 的 Cookie 比對網址。
- FinestDSP 的 Cookie 比對端點會處理重新導向要求，其中包括 Google 設定的網址參數，以及在 HTTP 標頭中為 Jane 設定的 Cookie。FinestDSP 現在可以在對照表中儲存其 Cookie 與
google_user_id的對應關係。 - FinestDSP 以隱藏的 1x1 像素回應重新導向。
情境 2：已進行對應的使用者
在情境 1 結束後，小珍再次造訪 ExampleNews.com。現在，Jane 的電腦上同時有出價工具和 Ad Manager Cookie，比對運作方式如下。
- 網頁會顯示，導致 Google (Ad Manager) 要求在網頁上顯示的廣告。
- 在廣告競價期間，Google 會傳送出價要求給適用的出價方，包括 FinestDSP。
- FinestDSP 接收出價要求，包括
google_user_id等信號。 - FinestDSP 在其對照表中查詢
google_user_id，並找出與 Jane 一週前建立的 Cookie (在情境 1 中)。 - FinestDSP 的出價邏輯會根據 Cookie 相關資訊相關資訊，對曝光出價並勝出。
- FinestDSP 依據所提供的資訊，向 Jane 放送符合他們興趣的廣告。
出價方發起：單向 Cookie 比對
單向 Cookie 比對與雙向工作流程類似，但差別在於，這項功能已經過變更，只會由 Google 代管及填入對照表。如果出價工具不允許出價工具在自己的對照表中代管 Google 使用者 ID，就可以使用此 ID。為了使用這個流程，出價方必須允許 Google 代管對照表，且無法再於向 Google 的 Cookie 比對服務發出的要求中指定 google_cm，因此也不會收到 google_gid 來填入自己的對照表。Google 為使用者建立比對項目後，出價方就能使用自己的 Cookie 資料，將對方加進使用者名單。同樣地，這些使用者的出價要求會排除 Google 使用者 ID，但包含代管比對資料。下列步驟概述修改後的工作流程。
步驟 1：將比對代碼置入出價方的 Cookie 比對網址
為了啟動這個流程，出價方必須放置比對代碼，以便在使用者的瀏覽器中顯示。不同於受隱私權限制的美國州別使用者的工作流程，比對標記必須將使用者的瀏覽器導向您的 Cookie 比對網址。舉例來說，如果 Cookie 比對網址設為 https://ad.network.com/pixel，則網址看起來會像這樣：
<img src="https://ad.network.com/pixel" />
在使用者的瀏覽器載入時，系統會向出價方的 Cookie 比對網址要求像素。這項要求會包含其 Cookie 的 HTTP 標頭中，系統應擷取這個 Cookie 供下一個步驟使用。
步驟 2：重新導向至 Google 的 Cookie 比對服務
出價方的 Cookie 比對端點必須重新導向至 Google 的 Cookie 比對服務，包括已填入網路安全 Base64 編碼 Cookie 資料的 google_hm 參數。重新導向網址可能如下所示：
https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA
步驟 3：使用者瀏覽器被重新導向至 Google 的 Cookie 比對服務
除了 HTTP 標頭中的 Google Cookie 之外，Google 還會收到包含您指定的參數的重新導向。
步驟 4：如果指定了報表網址，Google 會在執行成功或錯誤重新導向時放送像素
如果 Cookie 比對作業成功，或者出價方帳戶未指定 Cookie 比對報表網址，Google 預設會放送 1x1 的透明像素，並在此結束工作流程。
在後續出價要求中，這位使用者的曝光次數會在 BidRequest.hosted_match_data (Google 通訊協定) 中納入出價方代管的比對資料，或針對 Google 的 OpenRTB 導入，加入 BidRequest.user.buyeruid。出價方也可以用指定的代管比對資料填入使用者名單。
如果發生錯誤，Google 會將重新導向傳送到出價方的 Cookie 比對報表網址，原因是發生 google_error 參數中指定的錯誤。如果出價方的 Cookie 比對報表網址為 https://ad.network.com/report，重新導向網址看起來會像這樣：
<img src="https://ad.network.com/report?google_error=ERROR_ID" />
步驟 5：使用者瀏覽器重新導向至出價方的 Cookie 比對報表網址
使用者瀏覽器會重新導向至出價方的 Cookie 比對報表網址，包括 Google 在 google_error 參數中指定的錯誤原因 (如有)。如要進一步瞭解如何解讀錯誤代碼，請參閱參數說明。
步驟 6：出價工具放送 1x1 的透明像素
出價工具必須在使用者的瀏覽器上顯示 1x1 的透明像素，藉此做出回應。
為美國各州境內使用者提供隱私權限制的 Cookie 比對工作流程圖表
以下圖表為受隱私權限制的美國各州使用者預設工作流程，其中以箭頭表示要求和回應，其隨附的資料項目則列在括號中。
出價方的網址參數會重新導向至 Google 的 Cookie 比對服務
| 參數 | 說明 |
|---|---|
google_nid |
出價方帳戶的聯播網 ID (NID)。這個 ID 可透過出價方資源擷取。 |
google_sc |
此參數已淘汰。在沒有使用者的情況下，為使用者設定 Google 的 Cookie。系統會忽略這個參數的值，並可以省略。如果沒有 Cookie，則省略參數會導致錯誤發生。 |
google_no_sc |
此參數已淘汰。這代表 Google 的 Cookie 比對服務在沒有使用者的 Cookie 時，不應為使用者設定 Cookie。系統會忽略這個參數的值，並可以省略。 |
google_hm |
包含出價方想要儲存在 Google 代管對照表中的資料。 |
google_redir |
您希望 Google 傳送 HTTP 302 重新導向的已編碼網址。指定的網址會收到含有 google_error 參數的重新導向，包括錯誤和成功的作業。 |
google_ula |
用於將使用者加入現有使用者名單的字串。值的格式為 userlistid[,timestamp]：
若要將使用者加入多份清單，您可以重複使用這個網址參數。 |
gdpr |
表示該要求受到 GDPR 對數據用量的限制。詳情請參閱下方的「
歐盟地區使用者同意聲明規定」一文，或是
Authorized Buyers IAB「資訊公開和同意聲明架構第 2.0 版」說明文件中的對 Cookie 比對資格的影響。 範例： |
gdpr_consent |
代表使用者同意聲明的資訊公開和同意聲明字串。詳情請參閱下方的「歐盟使用者同意聲明規定」或 Authorized Buyers IAB 資訊公開和同意聲明架構第 2.0 版說明文件中的「資訊公開和同意聲明 (TC) 字串的傳送方式」。 |
process_consent |
表示出價方已針對
Google 的《歐盟地區使用者同意授權政策》中指定的資料用途取得使用者同意聲明。 如果要求不適用《歐盟地區使用者同意授權政策》，或是該要求中還有其他同意聲明參數 ( 範例： |
Google 的網址參數會重新導向至出價方的 Cookie 比對報表網址
| 參數 | 說明 |
|---|---|
google_error |
代表整體要求錯誤的整數值。收到訊息時，代表未執行任何作業，且不會設定其他
|
Google 發起：雙向像素比對
雙向像素比對是 Google 的 Cookie 比對服務的工作流程。在這個流程中，Google 會嘗試比對 Google 使用者 ID 與演算法選擇的出價方 (而不是「即時出價」競價得標者)。刊登廣告時，Google 會加入比對代碼，引導使用者的瀏覽器從所選出價方的 Cookie 比對網址載入透明像素。之後，Google 和出價方就能在對照表中為特定使用者填入資料。以下是此工作流程的簡單範例。
步驟 1：Google 置入比對標記
當參與的發布商在使用者瀏覽器中載入頁面，且該網頁上的廣告版位由 Google 填入時，可能就會放置比對代碼，向演算法選擇的出價方要求像素。Google 放置的像素比對標記會結合出價方的 Cookie 比對網址和出價方可用來填入對照表的其他參數。如為 https://ad.network.com/pixel 的 Cookie 比對網址，其結構如下：
<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />
步驟 2：出價方必須在回應中重新導向 Google 的 Cookie 比對服務網址
接收像素比對要求的出價方需要以重新導向的方式回應 Google 的 Cookie 比對服務，其結構如下：
https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA
請注意，上述重新導向網址類似於出價方啟動的 Cookie 比對工作流程比對標記中使用的網址。在 Pixel 比對中，google_cm 參數會替換為 google_push 參數，而且其值必須等於 Google 在要求中提供的值。此外，與出價工具啟動的工作流程類似，您也可以指定其他參數，以完成其他用途。
步驟 3：Google 處理重新導向及回應像素
Google 會記錄使用者建立的相符項目，並處理透過查詢參數要求的任何其他作業。最後，Google 會以 1x1 的透明像素做為回應。
像素比對工作流程圖
此工作流程如下圖所示，其中要求和回應以箭頭表示，而隨附的資料項目則列在括號中。
Google 比對代碼請求參數
| 參數 | 說明 |
|---|---|
google_gid |
Google 使用者 ID。如果使用者並非居住在設有隱私權限制的美國州別，一律在 Google 的比對標記中指定。 |
google_cver |
Cookie 版本。Google 的比對標記一律會指定這個值。 |
google_push |
表示這項要求正在啟動像素比對工作流程。這個值必須透過出價工具重新導向回應中的對應參數傳回。 |
出價方像素比對重新導向參數
| 參數 | 說明 |
|---|---|
google_nid |
出價方帳戶的聯播網 ID (NID)。這個 ID 可透過出價方資源擷取。 |
google_push |
表示這項重新導向正在完成像素比對工作流程。您必須在此指定對應 Google 比對標記的值。 |
google_hm |
包含出價方想要儲存在 Google 代管對照表中的資料。 |
google_ula |
用於將使用者加入現有使用者名單的字串。值的格式為 userlistid[,timestamp]：
若要將使用者加入多份清單，您可以重複使用這個網址參數。 |
Google 發起：單向像素比對
單向像素比對與雙向工作流程不同，Google 比對標記不包含指定 Google 使用者 ID 的參數，但會繼續為 Google 代管的對照表填入資料。如果出價工具不允許出價工具在自己的對照表中代管 Google 使用者 ID，就可以使用此 ID。下方步驟概述修改後的工作流程。
步驟 1：Google 置入比對標記
Google 會為演算法選擇的出價方放置比對代碼。比對代碼包含 google_push 參數。範例如下：
<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />
步驟 2：使用者的瀏覽器向出價方的烹飪比對網址要求像素
使用者的瀏覽器向出價方的 Cookie 比對網址提出像素要求，包括 HTTP 標頭中的出價方 Cookie。
步驟 3：重新導向至 Google 的 Cookie 比對服務
出價方的 Cookie 比對端點必須重新導向至 Google 的 Cookie 比對服務，包括已填入網路安全 Base64 編碼 Cookie 資料的 google_hm 參數。重新導向網址可能如下所示：
https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA
步驟 4：使用者瀏覽器被重新導向至 Google 的 Cookie 比對服務
除了 HTTP 標頭中的 Google Cookie 之外，Google 還會收到包含您指定的參數的重新導向。如果作業執行成功，在後續的出價要求中，這位使用者在後續出價要求中的曝光次數會包含出價方代管的比對資料 (位於 Google 通訊協定的 BidRequest.hosted_match_data)；或 BidRequest.user.buyeruid Google 的 OpenRTB 導入。出價方也可以運用指定的代管比對資料，在使用者名單填入資料。
最後，Google 會將 1x1 的透明像素傳回使用者的瀏覽器。
Cookie 比對輔助
公開出價可讓廣告交易平台使用出價工具啟動和 Google 發起的 Cookie 比對工作流程，將 Google 使用者 ID 與 Cookie 進行比對。Cookie 比對輔助 (CMA) 是廣告交易平台的一項額外功能，可讓廣告交易平台與自己的出價方建立對照表。
Cookie 比對輔助功能的運作方式
刊登廣告時，Google 會透過演算法選取參與的廣告交易平台，並放置具有下列結構的 Cookie Match Assist 標記：
<img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
Google 的 CMA 比對標記會使廣告交易平台的 Cookie 比對網址收到像素要求。
- 廣告交易平台的 Cookie 比對端點收到要求，而其專屬的 Cookie 比對服務會負責將使用者 ID 與其中一個出價方進行比對。在下圖中，交換的 Cookie 比對服務透過重新導向到其中一個出價方的端點，回應使用者的瀏覽器。
- 出價方收到要求以及廣告交易平台指定的所有參數，以便將使用者 ID 與其 Cookie 進行比對。
限制
新相符項目的要求頻率上限
出價方負責限制 Cookie 比對服務對 Google 代管對照表中有更新項目的使用者呼叫數。代管對照表中的項目可能會在 14 天內視為過期，期限過後可以重新整理。
回應所有像素比對請求
使用像素比對工作流程的出價方應以包含 google_push 參數的回應，回應所有收到的 Pixel Match 要求。這可讓 Google 監控使用情形，藉此強制執行政策。如果出價方的回應率降到低於 90%，Google 就會限制傳送到該帳戶的 Pixel Match 請求數量。
使用 HTTPS 端點
所有 Cookie 比對工作流程中使用的端點都必須使用 HTTPS。
回應透過 HTTPS 傳送給您的 Pixel Match 要求時，您必須透過 HTTPS 重新導向至 Cookie 比對服務。同樣地，重新導向至出價方的 Cookie Match Assist 端點也必須使用 HTTPS。如果您超過 2 分鐘超過每 2 分鐘傳送一次 HTTP 要求給 Google 一次，傳送到帳戶的比對要求數量就會受到限制。
歐盟地區使用者同意聲明規定
必須遵守 Google 的《歐盟地區使用者同意授權政策》規定的 Cookie 比對要求應指出使用者同意。這類要求必須透過下列其中一種方式來表示同意聲明：
- 資訊公開和同意聲明架構第 2 版：包含
gdpr和gdpr_consent參數。詳情請參閱 Authorized Buyers IAB 資訊公開和同意聲明架構第 2.0 版說明文件。 process_consent：出價方已取得必要的使用者同意聲明的宣告。
範例
以下範例說明如何使用 Cookie 比對服務達成特定目標。請注意，除非另有規定，否則系統會假設執行的使用者並非來自設有隱私權限制的美國州。
填入出價方代管的對照表
出價方可在比對代碼中提供 google_nid 和 google_cm 參數，藉此使用 Cookie 比對工作流程填入自己的對照表。看起來可能會像這樣：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />
如果出價方的 Cookie 比對網址設為 https://ad.network.com/pixel?id=1，且 Cookie 比對作業成功，則 Google 為了回應出價方比對代碼而傳送的重新導向可能如下所示：
https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
如果 Cookie 比對作業因使用者沒有 Google Cookie 而失敗，回應會如下所示：
https://ad.network.com/pixel?id=1&google_error=3
錯誤代碼取決於錯誤的基礎原因。如要進一步瞭解 Cookie 比對工作流程可能出現的錯誤代碼，請參閱重新導向網址參數。
新增至單一使用者名單
您可以在出價方的比對標記中指定 google_ula 參數，將使用者新增至具有指定 ID 的使用者名單。如果 Google 或出價工具代管的對照表已為使用者更新新項目，出價方可以放置包含 google_nid 和 google_ula 參數的比對標記，以便將使用者新增至指定清單，而不必啟動完整的 Cookie 比對工作流程。如需更多詳細資訊，請參閱叫用 Cookie 比對服務的限制。對應的比對標記可能如下所示：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />
如果回應成功，且出價方的 Cookie 比對網址為 https://ad.network.com/pixel，Google 的重新導向網址會是：
https://ad.network.com/pixel?google_ula=12345,0
如果出現整體錯誤 (例如使用者沒有 Google Cookie)，重新導向網址將包含 google_error 參數：
https://ad.network.com/pixel?google_error=3
如果明確地將使用者新增至清單時發生錯誤，您會在重新導向中收到 google_ula。與對應的比對標記參數不同，這會將時間戳記替換為狀態碼，表示作業成功。舉例來說，如果出價工具帳戶無法存取指定使用者名單，導致要求失敗，重新導向網址為：
https://ad.network.com/pixel?google_ula=12345,2
加進多份使用者名單
出價方可以在比對代碼中加入多個 google_ula 參數，指定應將使用者新增至多份使用者名單。在實際操作時，這可能如下所示：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />
同樣地，系統也會透過重新導向中不同的 google_ula 參數，回報每份使用者名單的作業狀態：
https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0
在上方的重新導向中，我們可以看到 ID 為 45678 的使用者名單作業成功，但使用者名單 ID 為 12345 的作業失敗，因為出價方沒有存取該清單的權限。
逐步完成 Cookie 比對工作流程，並加進使用者名單
如要執行 Cookie 比對作業，並將使用者加進單一要求中的使用者名單，出價方的比對標記應包含 google_cm 和 google_ula：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />
Google 指定的重新導向網址會包含 google_gid、google_cver 和 google_ula。如下所示：
https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0
將相符項目儲存在 Google 代管的對照表中
如果出價方想要將 Cookie 資料儲存在 Google 代管的對照表中，且不想將與 Google 使用者 ID 儲存在自己的對照表中，則比對代碼必須包含 google_hm 參數，且該參數的值必須為具網路安全性的 Base64 編碼字串。如果使用者的未編碼 Cookie 資料為 Cookie number 1!，編碼的值會是 Q29va2llIG51bWJlciAxIQ==，並用於比對標記，如下所示：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />
如果回應成功，且出價方的 Cookie 比對網址為 https://cookie-monster.com/pixel，Google 的重新導向網址會是：
https://cookie-monster.com/pixel
由於比對標記不包含 google_cm，以及 google_hm 未包含在成功回應中，因此 google_gid 未包含在重新導向中。在日後針對這位使用者的曝光出價要求時，出價方會在 BidRequest.hosted_match_data 中收到代管比對資料 (Google RTB 通訊協定) 或 BidRequest.user.buyeruid (適用於 Google 的 OpenRTB 導入)。
如果出價工具改用比對標記，而 google_hm 的值並非採用 Base64 編碼 (例如 chocolate_chunk!)，則重新導向網址可能如下所示：
https://cookie-monster.com/pixel?google_hm=2
上述重新導向網址包含 2 的 google_hm 值，表示作業失敗，因為該值無法解碼。
內含使用者名單的出價方和 Google 代管對照表
如果出價方除了 Google 代管使用者名單外，也代管自己的使用清單，且希望使用單一比對代碼來比對兩份資料表，並將使用者加進指定使用者名單，他們的比對代碼必須包含 google_cm、google_hm 和 google_ula 參數。如果出價方的 Cookie 資料是 Cookie number 1!，則編碼值會是 Q29va2llIG51bWJlciAxIQ==，進而產生如下所示的比對標記：
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />
如果回應成功，且出價方的 Cookie 比對網址為 https://cookie-monster.com/pixel，Google 的重新導向網址看起來會像這樣：
https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0
收到重新導向時，出價方可將 google_gid 中指定的 Google 使用者 ID 與對照表中的 Cookie 資料進行比對。此外，他們也可以判斷 Google 代管的對照表和使用者名單作業是否成功。因此，如果預先指定的出價工具指定了指定使用者名單 ID，之後出價工具就會收到來自使用者曝光的出價要求。同樣地，在這些出價要求中，出價方會收到代管比對資料 (取決於 Google 的 RTB 通訊協定) 或 BidRequest.user.buyeruid (Google 的 OpenRTB 導入)。BidRequest.hosted_match_data