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)：在進行 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 比對網址，以便在 %%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 的端點整合，除了像素比對參數，還需要預先設定出價方定義的參數，依序為 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 代管比對表的區域。因此，這個回應不會包含 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，並找出與 Jane 相關聯的 Cookie，該 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

Google 會收到重新導向，其中包含您指定的參數，以及 HTTP 標頭中的 Google Cookie。

步驟 4：如果指定回報網址，Google 會在成功或錯誤重新導向時放送像素

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

否則，如果發生錯誤，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 伺服器的雙向像素比對要求中，傳遞了無效的 google_push 參數。您的重新導向必須將 google_push 設為初始像素要求傳遞給您的相同值。
  • 6：比對標記中提供的 NID 無效。
  • 7：偵測到無效的 Cookie。
  • 8：已淘汰。找不到 Cookie。
  • 9：找不到 Cookie，嘗試設定測試 Cookie。
  • 10：使用 google_redir 參數時未指定 google_hm，或與 google_cm 一併使用。
  • 15：要求來自 Google 要求由 Google 代管比對表的區域。因此，這個回應不會包含 Google 使用者 ID。目前只有一小部分流量啟用這項功能，但預計將於 2020 年 6 月全面啟用。

Google 發起：雙向像素比對

雙向像素比對是 Google 的 Cookie 比對服務工作流程，Google 會嘗試將 Google 使用者 ID 與透過演算法選出的出價方比對，而非即時出價競價勝出者。廣告放送時，Google 會放置比對代碼，引導使用者的瀏覽器從所選出價方 Cookie 比對網址載入透明像素。這樣一來，Google 和出價方就能為特定使用者填入對照表。以下是這個工作流程的簡單範例。

步驟 1：Google 放置比對代碼

當參與計畫的發布商網頁在使用者瀏覽器中載入，且 Google 填入該網頁上的廣告位址時，系統可能會放置比對代碼，向以演算法選出的出價方要求像素。Google 放置的像素比對代碼會將出價方 Cookie 比對網址與其他參數結合，出價方可用這些參數填入對照表。如果 Cookie 比對網址指定為 https://ad.network.com/pixel，其結構如下：

<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 比對工作流程中比對代碼使用的網址相似。在像素比對中，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

Google 會收到重新導向，其中包含您指定的參數，以及 HTTP 標頭中的 Google Cookie。如果作業成功，後續出價要求中這個使用者的曝光次數，就會包含出價方在 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 天後過期，屆時即可進行重新整理。

回應所有像素比對要求

使用像素比對工作流程的出價方，應對所有傳入的像素比對要求做出回應，並在回應中加入 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

如果使用者沒有 Google Cookie，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_cm，且成功回應中未包含 google_hm，因此 google_gid 參數不在重新導向中。在日後針對此使用者曝光的出價要求中，出價方會在 BidRequest.user.buyeruid (OpenRTB) 或 BidRequest.hosted_match_data (已淘汰的 Google RTB 通訊協定) 中，收到其代管比對資料。

如果出價方使用比對標記，但 google_hm 的值並未採用 base64 編碼 (例如 chocolate_chunk!)，則重新導向網址可能會如下所示：

https://cookie-monster.com/pixel?google_hm=2

上述重新導向網址包含 google_hm 值 2，表示無法解碼值，因此作業失敗。

出價方和 Google 代管的媒合表格，含有使用者名單

如果出價方除了託管 Google 的使用者名單，也託管自己的使用者名單，且希望使用單一比對代碼比對這兩個資料表，並將使用者加入特定使用者名單，則其比對代碼必須包含 google_cm、google_hm 和 google_ula 參數。如果出價方使用的是 Cookie number 1! 的 Cookie 資料，則編碼值會是 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 通訊協定) 中，收到代管的比對資料。