Cookie 比對

Cookie 比對功能可讓您將 Cookie (例如瀏覽您網站的使用者 ID) 與對應的出價工具專屬 Google 使用者 ID 進行比對，以及建構使用者名單，協助您做出更有效的出價選擇。本指南將說明 Cookie 比對中使用的概念，以及不同的 Cookie 比對工作流程，以及這些工作流程在特定用途下可能有的變化。

概念

網域擁有者通常會為瀏覽網站的使用者設定 Cookie 內容，用於識別該網域中的使用者。即使兩位網域擁有者同意交換這類資料，網路瀏覽器的安全性模型仍會限制讀取其他網域設定的 Cookie。

在數位廣告方面，Google 會使用屬於 doubleclick.net 網域的 Cookie 來識別使用者，而參與即時出價的出價方則可能擁有自己的網域，可在其中識別想放送廣告的一組使用者。透過 Cookie 比對功能，出價方可以將自己的 Cookie 與 Google 的 Cookie 進行比對，藉此判斷出價要求中傳送的曝光是否與指定的使用者相關聯。他們會收到自己的 Cookie 資料，或是出價方專屬的 Google 使用者 ID，這是出價要求中 doubleclick.net Cookie 的加密形式。

本指南所述的 Cookie 比對服務可協助建立及維護出價方 Cookie 與 Google 使用者 ID 之間的關聯，並可填入使用者名單。

對照表

比對表可用於將 ID 或其他資料從一個網域對應至另一個網域。出價方可以使用 Cookie 比對服務來填入自己的對照表，方法是將特定使用者的 Cookie 對應至使用者的 Google 使用者 ID，或是填入 Google 代管的對照表。比對表是出價方應用程式存取曝光使用者 Cookie 資料的必要條件。

Google 代管的比對表

為方便維護、改善延遲情形，以及為特定地區的使用者存取比對資料，建議您允許 Google 代管比對資料表。這可讓您指定網路安全 Base64 編碼字串 (以下稱為代管比對資料)，並將其對應至特定使用者的 Google 使用者 ID。比對完成後，您可以透過下列方式使用比對結果：

  • 即時出價：在後續與使用者相關聯的曝光出價要求中，Google 會傳送您與 Google 使用者 ID 比對的代管比對資料。在 Google 的 OpenRTB 實作中，BidRequest.user.buyeruid 會將此指定為網路安全的 base64 編碼字串。如果出價端點已設定為使用已淘汰的 Google RTB 通訊協定，您會透過 BidRequest.hosted_match_data 欄位收到已解碼的位元組。

  • 使用者名單：可填入 Google 使用者 ID 或代管比對資料。

  • 預先指定：您可以設定預先指定，僅接收包含代管比對資料的出價要求。這可用於排除 Cookie 空間以外使用者的不相關曝光。

使用者名單

您可以使用即時出價 API 建立及管理使用者名單。建立完成後，您可以使用如下所述的 Cookie 比對工作流程，或透過大量上傳工具服務為這些名單填入資料。

開始使用

如要開始使用 Cookie 比對功能，您必須與客戶技術顧問聯絡，他們可以啟用特定工作流程，並協助您設定下列項目：

  • Cookie 比對聯播網 ID (NID)：這是用來識別出價方帳戶的專屬字串 ID，用於進行 Cookie 比對和其他相關作業。
  • Cookie 比對網址：可接受傳入要求的端點基準網址，也是 Cookie 比對工作流程的一部分。出價方可以在這個網址中嵌入巨集，藉此控管在 Cookie 比對工作流程中傳遞至該網址的參數順序。
  • 比對標記：您必須在使用者的瀏覽器中放置此標記，才能啟動出價方啟動的 Cookie 比對工作流程。可與廣告一併放送，或放置在廣告以外的網站資源。
  • Cookie 比對報表網址 (選用)：在單向 Cookie 比對工作流程中，這是一個可提供的選用網址，可用來指定 Cookie 比對失敗時接收錯誤詳情的端點，透過 HTTP 302 重新導向。根據預設，只有在 Cookie 比對作業發生錯誤時，回應才會傳送至這個網址，但出價方可能會要求一律傳送重新導向。
  • Cookie Match Assist 網址：如果廣告交易導入Cookie Match Assist 工作流程，這就是用於回應傳入要求的端點基準網址。
  • Cookie 比對輔助配額：對於導入 Cookie 比對輔助工作流程的廣告交易平台，這是其 Cookie 比對網址每秒可接收的要求數量上限。這是為了防止 CMA 要求因要求造成交換伺服器超載。

在任何支援的 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

巨集範例

出價方與 https://user.bidder.com.cookies 代管的端點整合 Cookie 比對功能，除了像素比對參數外，還需要預先設定出價方定義的參數，參數順序如下：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

Google 的 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。實際上，如果 Cookie 比對網址指定為 https://ad.network.com/pixel，簡式比對代碼的重新導向網址可能會如下所示：

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

透過 google_gid 參數傳遞的 Google 使用者 ID 是未填充的網路安全 base64 編碼字串。如果出價方選擇代管比對表，建議儲存 Cookie 比對服務傳回的確切字串。在後續出價要求中，這會對應至透過 OpenRTB 的 BidRequest.user.id 或已淘汰 Google RTB 通訊協定中的 BidRequest.google_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「無內容」回應。

此工作流程如下圖所示，要求和回應以箭頭表示，其隨附的資料項目則列於括號中。

比對代碼網址參數

參數 說明
google_nid 出價工具帳戶的聯播網 ID (NID)。您可以透過 Bidders 資源擷取這個 ID。
google_cm 向 Google 的 Cookie 比對服務表示應執行 Cookie 比對。此參數的值將遭忽略，並可省略。
google_sc 此參數已淘汰。如果使用者沒有 Google Cookie，就會設定。系統會忽略參數的值，並可能省略該值。如果沒有 Cookie，則省略參數會導致錯誤。
google_no_sc 此參數已淘汰。這會向 Google 的 Cookie 比對服務表明，在沒有 Cookie 的情況下，不應為使用者設定 Cookie。此參數的值將遭忽略，並可省略。
google_hm

出價方要在 Google 代管的比對資料表中儲存的資料。

這個值是網路安全的 Base64 編碼字串 (可選填填充)。原始資料不得超過 40 個位元組。例如 Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u。
google_redir 出價方可指定的網址編碼字串，可用於指示 Google 將 HTTP 302 重新導向至這個比對代碼的已編碼網址。這可讓 Google 站在對合作夥伴的鏈結呼叫前方。如果未指定 google_hm 或指定 google_cm，則會導致錯誤。
google_ula 用於將使用者新增至現有使用者名單的字串。值的預期格式為 userlistid[,timestamp]：
  • userlistid：單一數值型使用者名單 ID。
  • timestamp：選用的 POSIX 格式時間戳記，用於指出使用者何時加入使用者名單。

這個網址參數可重複使用，將使用者加入多個名單。
gdpr 表示要求受 GDPR 資料使用限制的約束。詳情請參閱下方的 歐盟使用者同意聲明規定，或 授權買方資訊公開和同意聲明架構第 2.0 版說明文件中的「對 Cookie 比對資格的影響」。

範例：gdpr=1
gdpr_consent 代表使用者同意聲明的資訊公開和同意聲明字串。如需更多詳細資訊，請參閱下方的「歐盟使用者同意聲明規定」或「 授權買方 IAB 資訊公開和同意聲明架構第 2.0 版說明文件」中的「如何傳送資訊公開和同意聲明 (TC) 字串？」。
process_consent 表示出價方已取得使用者同意，可使用 Google 的歐盟地區使用者同意授權政策中指定的資料。

如果要求不受《歐盟地區使用者同意授權政策》規範，或是要求中提供其他同意參數 (gdpr_consent)，系統就會忽略這個參數。

範例：process_consent=T

除了上述參數外，出價方可以指定自己的參數，這些參數會以參數的形式附加到重新導向網址。請注意，系統會忽略以 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_ 回應參數。支援的錯誤值包括：

  • 1：使用者有 Google Cookie，但選擇不使用此 Cookie 進行任何追蹤。
  • 2：未指定有效的作業。例如，收到了無操作要求。
  • 3：使用者沒有 Google Cookie。Google 不會透過 Cookie 比對服務設定 Cookie。
  • 4：指定的操作有衝突。由於 google_push 和 google_cm 旗標的用途相衝突，因此您無法在同一項要求中同時指定這兩個旗標。
  • 5：在重新導向至 Google 伺服器的雙向像素比對要求中，傳遞了無效的 google_push 參數。您的重新導向必須將 google_push 設為初始像素要求傳遞給您的相同值。
  • 6：比對標記中提供的 NID 無效。
  • 7：偵測到無效的 Cookie。
  • 8：已淘汰，找不到 Cookie。
  • 9：找不到 Cookie，嘗試設定測試 Cookie。
  • 10：使用 google_redir 參數時未指定 google_hm，或與 google_cm 一併使用。
  • 15：要求來自 Google 規定對照表於特定區域。因此，這個回應不會包含 Google 使用者 ID。這項功能目前僅適用於一小部分的流量，但預計於 2020 年 6 月全面啟用。
google_hm

只有在嘗試寫入 Google 代管的比對表時失敗時，才會顯示。此時，其值會是下列其中一個狀態碼：

  • 1 - 禁止：客戶尚未列入可寫入代管對照表項目的許可清單。
  • 2 - 解碼錯誤：無法解碼參數值。
  • 3 - 酬載過長：參數值解碼後的資料超過 24 個位元組。
  • 4 - 內部錯誤：儲存資料時發生內部錯誤。
  • 5 - 受到限制：由於節流，系統無法處理這項寫入作業。
google_ula

使用者名單新增作業的狀態。如果在要求中指定了多個 google_ula，則會重複列出。格式如下：
userlistid,status code

例如：google_ula=1234567890,0

google_ula 作業可傳回下列任一狀態碼：

  • 0 - 未發生錯誤。已將使用者新增至使用者清單。
  • 2 - 權限遭拒。您的權限不足，無法將使用者新增至指定的使用者名單。
  • 5 - 使用者名單 ID 無效。提供的使用者清單 ID 無效。
  • 6：已關閉的屬性 ID。您提供的使用者清單 ID 已關閉。
  • 10 - 內部錯誤。Cookie 比對服務發生內部錯誤，您可以嘗試重新比對使用者。

以下情境說明一般使用者瀏覽網頁時的 Cookie 比對方式。

情境 1：使用者清除 Cookie 並瀏覽網站

Jane 清除所有 Cookie 的快取。然後造訪 ExampleNews.com 的首頁。

接下來會發生的情況是：

  1. ExampleNews.com 會算繪並呼叫 Google (Ad Manager) 的廣告。
  2. 由於廣告單元符合動態分配資格，Google 會透過即時出價服務，將出價要求傳送給 FinestDSP 和其他出價方。
  3. FinestDSP 的出價方應用程式會接收及處理出價要求，並傳送出價回應。
  4. Google 會收到出價方傳送的出價回應，包括 FinestDSP 的回應，其中指定含有比對代碼 (像素) 的廣告。
  5. FinestDSP 贏得競價。Google 向 Jane 放送 FinestDSP 的廣告和比對標記。
  6. 比對代碼會呼叫 Google 的 Cookie 比對服務，並指定 google_nid 和 google_cm 參數。
  7. Cookie 比對服務會讀取 Jane 的 Google Cookie，並將 Jane 的瀏覽器重新導向至 FinestDSP 的 Cookie 比對網址，並設定 google_gid 和 google_cver 參數。
  8. 阿珍的瀏覽器會載入重新導向至 FinestDSP 的 Cookie 比對網址。
  9. FinestDSP 的 Cookie 比對端點會處理重新導向要求 (包括 Google 設定的網址參數，以及在 HTTP 標頭中為 Jane 設定的 Cookie)。FinestDSP 現在可以將 Cookie 對應至比對表中的 google_gid。
  10. FinestDSP 會以不可見的 1x1 像素回應重新導向。
情境 2：使用者已對應

在情境 1 的一週後，Jane 再次造訪 ExampleNews.com。既然 Jane 的電腦上同時有出價方和 Ad Manager 的 Cookie，以下說明比對的運作方式。

  1. 網頁會進行轉譯，導致 Google (Ad Manager) 要求在網頁上顯示的廣告。
  2. 在廣告競價期間，Google 會向適用的出價方 (包括 FinestDSP) 傳送出價要求。
  3. FinestDSP 收到出價要求，包括 google_gid 等信號。
  4. FinestDSP 在其對照表中尋找 google_gid，然後找出與阿珍在一週前建立的 Cookie (在情境 1 中)。
  5. 根據與 cookie 相關聯的資訊，FinestDSP 的出價邏輯會對曝光出價，並贏得競價。
  6. FinestDSP 依據擁有的資訊，向小珍放送符合興趣的廣告。

單向 Cookie 比對與雙向工作流程相似，但差別在於，單向 Cookie 比對會改為由 Google 主機代管並填入比對表格。在出價方無法將 Google 使用者 ID 放在自有比對表中的情況下，可以使用這個選項。為了使用這個流程，出價方必須允許 Google 代管比對表，且無法再在對 Google Cookie 比對服務的請求中指定 google_cm，因此不會收到 google_gid 來填入自己的比對表。Google 為使用者建立比對結果後，出價方就能使用自己的 Cookie 資料，將使用者加入使用者名單。同樣地，針對這些使用者的出價要求會排除 Google 使用者 ID，但會納入代管比對資料。以下步驟簡要說明修訂後的工作流程。

為了啟動這個流程，出價方必須放置比對標記，以便在使用者的瀏覽器中顯示。與非來自隱私權受限美國州的使用者工作流程不同，比對代碼必須將使用者的瀏覽器導向 Cookie 比對網址。舉例來說，如果 Cookie 比對網址設為 https://ad.network.com/pixel，則會如下所示：

<img src="https://ad.network.com/pixel" />

在使用者瀏覽器中載入時，會向出價方 Cookie 比對網址要求像素。這項要求會在 HTTP 標頭中包含 Cookie，您應在下一個步驟中擷取該 Cookie。

出價方 Cookie 比對端點必須重新導向至 Google 的 Cookie 比對服務，包括使用網路安全 Base64 編碼 Cookie 資料填入的 google_hm 參數。重新導向網址可能會像這樣：

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

除了 HTTP 標頭中的 Google Cookie 外，Google 也會收到含有您指定參數的重新導向。

步驟 4：如果已指定報表網址，Google 會在成功或錯誤重新導向時顯示像素

如果 Cookie 比對作業成功，或者未指定出價方帳戶的 Cookie 比對報表網址，Google 預設將放送 1x1 透明像素，工作流程則在此結束。後續出價要求中的此使用者曝光次數，會在 BidRequest.user.buyeruid (OpenRTB) 或 BidRequest.hosted_match_data (已淘汰的 Google RTB 通訊協定) 中，納入出價方代管的比對資料。出價方也可以使用指定的代管比對資料，填入使用者名單。

否則，如果發生錯誤，Google 會傳送重新導向至出價方 Cookie 比對報表網址，並在 google_error 參數中指定錯誤原因。如果出價方 Cookie 比對報表網址為 https://ad.network.com/report，重新導向網址會如下所示：

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

使用者的瀏覽器會重新導向至出價方 Cookie 比對報表網址，其中包含 Google 在 google_error 參數中指定的錯誤原因 (如有)。如要進一步瞭解如何解讀錯誤代碼，請參閱參數說明。

步驟 6：出價方放送 1x1 透明像素

出價方必須回應，向使用者的瀏覽器提供 1x1 透明像素。

如下圖所示，美國各州境內設有隱私權限制的使用者，其預設工作流程是以箭頭表示，其中的資料項目則以括號表示。

參數 說明
google_nid 出價方帳戶的網路 ID (NID)。您可以透過 Bidders 資源擷取這個 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]：
  • userlistid：單一數值型使用者名單 ID。
  • timestamp：選用的 POSIX 格式時間戳記，用於指出使用者何時加入使用者名單。

這個網址參數可重複使用，將使用者加入多個名單。
gdpr 表示要求受 GDPR 資料使用限制的約束。詳情請參閱下方的 歐盟使用者同意聲明規定，或 授權買方資訊公開和同意聲明架構第 2.0 版說明文件中的「影響 cookie 比對資格」。

範例：gdpr=1
gdpr_consent 代表使用者同意聲明的資訊公開和同意聲明字串。如需更多詳細資訊，請參閱下方的「歐盟使用者同意聲明規定」或「 授權買方 IAB 資訊公開和同意聲明架構第 2.0 版說明文件」中的「如何傳送資訊公開和同意聲明 (TC) 字串？」。
process_consent 表示出價工具已就 Google 的《歐盟地區使用者同意授權政策》中指定的資料使用方式徵得使用者同意聲明。

如果要求不適用《歐盟地區使用者同意授權政策》，或是要求中已有其他同意聲明參數 (gdpr_consent)，系統就會忽略這個參數。

範例：process_consent=T
參數 說明
google_error

整數值，表示整體要求錯誤。收到時，表示未執行任何作業，也不會設定其他 google_ 回應參數。支援的錯誤值如下：

  • 1：使用者有 Google Cookie，但選擇不使用此 Cookie 進行任何追蹤。
  • 2：未指定有效的作業。例如，收到了無操作要求。
  • 3：使用者沒有 Google Cookie。Google 不會透過 Cookie 比對服務設定 Cookie。
  • 4：指定的操作有衝突。由於 google_push 和 google_cm 旗標的用途相衝突，因此您無法在同一項要求中同時指定這兩個旗標。
  • 5：在雙向像素比對要求中，將無效的 google_push 參數傳入至 Google 伺服器。您的重新導向必須將 google_push 設為初始像素要求傳遞給您的相同值。
  • 6：比對標記中提供的 NID 無效。
  • 7：偵測到無效的 Cookie。
  • 8：已淘汰，找不到 Cookie。
  • 9：找不到 Cookie，嘗試設定測試 Cookie。
  • 10：使用 google_redir 參數時未指定 google_hm，或與 google_cm 一併使用。
  • 15：要求來自 Google 規定對照表於特定區域。因此，這個回應不會包含 Google 使用者 ID。這項功能目前僅適用於一小部分的流量，但預計於 2020 年 6 月全面啟用。

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" />

收到像素比對要求的出價方必須回應 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 表示這項要求正在啟動像素比對工作流程。 這個值必須透過出價方重導回應中的對應參數傳回。
gdpr_consent 代表使用者同意聲明的資訊公開和同意聲明字串。如需更多詳細資訊，請參閱下方的「[歐盟使用者同意聲明規定](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements)」或「[授權買方 IAB 資訊公開和同意聲明架構第 2.0 版說明文件](//support.google.com/authorizedbuyers/answer/9789378)」中的「如何傳送資訊公開和同意聲明 (TC) 字串？」。

出價方像素比對重新導向參數

參數 說明
google_nid 出價方帳戶的網路 ID (NID)。您可以透過 Bidders 資源擷取這個 ID。
google_push 表示這個重新導向是完成像素比對工作流程。您必須在此處指定對應 Google 比對代碼的值。
google_hm

包含出價方要儲存在 Google 代管比對資料表中的資料。
google_ula 用於將使用者新增至現有使用者名單的字串。值的預期格式為 userlistid[,timestamp]：
  • userlistid：單一數值型使用者名單 ID。
  • timestamp：選用的 POSIX 格式時間戳記，用於指出使用者何時加入使用者名單。

如要將使用者新增至多份名單，可重複使用此網址參數。
gdpr_consent 代表使用者同意聲明的資訊公開和同意聲明字串。如需更多詳細資訊，請參閱下方的「[歐盟使用者同意聲明規定](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements)」或「[授權買方 IAB 資訊公開和同意聲明架構第 2.0 版說明文件](//support.google.com/authorizedbuyers/answer/9789378)」中的「如何傳送資訊公開和同意聲明 (TC) 字串？」。

Google 發起：單向像素比對

單向像素比對與雙向工作流程的差異在於，Google 的對照代碼不包含指定 Google 使用者 ID 的參數，但會繼續填入 Google 代管的對照表。如果出價方無法在自己的對照表中代管 Google 使用者 ID，則可以使用此方法。以下步驟簡要說明修訂後的工作流程。

步驟 1：Google 放置比對代碼

Google 會為演算法選出的出價方放置比對代碼。比對標記包含 google_push 參數。範例如下：

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

步驟 2：使用者的瀏覽器向出價方 Cooking 比對網址要求像素

使用者的瀏覽器會向出價方 Cookie 比對網址要求像素，包括 HTTP 標頭中的出價方 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

除了 HTTP 標頭中的 Google Cookie 外，Google 也會收到含有您指定參數的重新導向。如果作業成功，後續出價要求中此使用者的曝光次數，就會包含出價方在 BidRequest.user.buyeruid 中代管的 OpenRTB 比對資料，或是在 BidRequest.hosted_match_data 中代管的已淘汰的 Google RTB 通訊協定。出價方也可以使用指定的代管比對資料，填入使用者名單。

最後，Google 會將 1x1 透明像素傳回使用者的瀏覽器。

公開出價可讓廣告交易平台使用出價方啟動的和Google 啟動的 Cookie 比對工作流程，將 Google 使用者 ID 與其 Cookie 進行比對。Cookie 比對輔助 (CMA) 是廣告交易平台的額外功能，可讓廣告交易平台使用自家的出價方建立比對表。

  1. 在放送廣告時，Google 會透過演算法選取參與的 Ad Exchange，並放送 Cookie 比對輔助代碼，該代碼的結構如下：

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

  2. Google 的 CMA 比對代碼會導致交易平台的 Cookie 比對網址收到像素要求。

  3. 廣告交易平台的 Cookie 比對端點會收到要求，並由其 Cookie 比對服務負責將使用者 ID 與其中一位出價方進行比對。在下圖中，廣告交易平台的 Cookie 比對服務會回應使用者瀏覽器，並將使用者重新導向至其中一個出價方端點。
  4. 出價工具收到請求，以及廣告交易平台指定的所有參數，以比對使用者 ID 和他們的 Cookie。

限制

限制新比對項目的要求頻率

對於在 Google 代管的比對資料表中擁有新項目的使用者，出價方必須限制 Cookie 比對服務的呼叫次數。代管對照表中的項目可能會在 14 天後過期，屆時即可進行重新整理。

回應所有像素比對要求

使用像素比對工作流程的出價方應回應所有收到的 Pixel Match 要求，並使用包含 google_push 參數的回應。這樣 Google 就能監控使用情形，強制執行政策。如果出價方回應率降至低於 90%，Google 就會限制傳送至其帳戶的像素比對要求數量。

使用 HTTPS 端點

所有 Cookie 比對工作流程中使用的端點都必須使用 HTTPS。

回應透過 HTTPS 傳送給您的像素比對要求時，您必須透過 HTTPS 重新導向至 Cookie 比對服務。同樣地，重新導向到出價工具的 Cookie 比對輔助端點也必須使用 HTTPS。如果您透過 HTTP 傳送至 Google 的要求頻率超過每 2 分鐘一次，系統會限制傳送至帳戶的配對要求數量。

根據 Google 的《歐盟地區使用者同意授權政策》規定，Cookie 比對要求應表明使用者同意聲明。這類要求必須指出同意聲明是透過下列任一方式收集：

範例

以下範例說明如何使用 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 比對，並將使用者加入使用者名單，出價方的比對標記應包含 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 User-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_gid 參數不在重新導向中，因為比對標記未包含 google_cm，且成功回應中未包含 google_hm。在日後針對此使用者曝光的出價要求中，出價方會在 BidRequest.user.buyeruid (OpenRTB) 或 BidRequest.hosted_match_data (已淘汰的 Google RTB 通訊協定) 中，收到其代管比對資料。

如果出價方使用比對標記，但 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，則會收到來自使用者的曝光出價要求。同樣地，在這些出價要求中，出價方會在 BidRequest.user.buyeruid (針對 OpenRTB) 或 BidRequest.hosted_match_data (針對已淘汰的 Google RTB 通訊協定) 中，收到代管的比對資料。