通过 Cookie 匹配功能，您可以将 Cookie（例如，浏览您网站的用户的 ID）与相应的出价方专用 Google 用户 ID 进行匹配，并可构建有助于您做出更有效出价选择的用户名单。本指南介绍了 Cookie 匹配中使用的概念、不同的 Cookie 匹配工作流程，以及它们针对特定应用场景可能存在的任何变体。
概念
什么是 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 托管您的匹配表。这样，您就可以指定一个可在 web 环境中安全使用 base64 编码的字符串（以下称为托管的匹配数据），该字符串将映射到指定用户的 Google 用户 ID。建立匹配后，可以通过以下方式使用它：
实时出价：在针对与用户关联的展示的后续出价请求中，Google 会向您发送与其 Google 用户 ID 匹配的托管匹配数据。如果您的出价端点配置为使用 Google 的实时出价协议，您将通过
BidRequest.hosted_match_data字段以解码后的字节形式收到该协议。在 Google 的 OpenRTB 实现中，BidRequest.user.buyeruid会将这些数据作为可在 web 环境中安全使用的 base64 编码字符串返回。用户名单：用户名单可以使用 Google 用户 ID 或托管的匹配数据填充。
- 预定位：您可以将预定位配置为仅接收包含托管的匹配数据的出价请求。这可用于避免向 Cookie 空间之外的用户展示相关性较低的展示。
用户名单
您可以使用 Real-Time Bidding API 创建和管理用户列表。创建后，您可以使用下文所述的 Cookie 匹配工作流或通过批量上传工具服务填充这些名单。
使用入门
要开始使用 Cookie 匹配功能，您必须与您的技术支持客户经理联系，他/她可以启用特定的工作流并帮助您配置以下内容：
- Cookie 匹配广告联盟 ID (NID)：一个字符串 ID，可唯一标识用于 Cookie 匹配和其他相关操作的出价工具帐号。
- Cookie 匹配网址：端点的基础网址，该端点将在 Cookie 匹配工作流中接受和处理传入请求。 出价方可以在此网址中嵌入宏，以控制在 Cookie 匹配工作流程中传递给此网址的参数的顺序。
- 匹配代码：在出价工具启动的 Cookie 匹配工作流程中，您必须在用户浏览器中放置的代码。这种素材资源可以随广告一起投放，也可以放置在网站媒体资源中广告之外的位置。
- Cookie 匹配报告网址（可选）：在单向 Cookie 匹配工作流中，您可以提供这个可选网址，以指定在 Cookie 匹配通过 HTTP 302 重定向失败时将收到错误详情的端点。默认情况下，只有在 Cookie 匹配操作出错时，系统才会将响应发送到此网址，但出价方可能会要求始终发送重定向。
- Cookie 匹配辅助网址：对于实现 Cookie 匹配辅助工作流程的广告交易平台，这是指用于响应传入请求的端点的基准网址。
- Cookie 匹配辅助配额：对于实现 Cookie 匹配辅助工作流程的广告交易平台，此为其 Cookie 匹配网址每秒可以接收的请求数量上限。这是为了防止 CMA 请求因请求而使广告交易平台的服务器过载。
Cookie 匹配宏
在任何受支持的 Cookie 匹配工作流程中，出价方的 Cookie 匹配网址通常都会附加采用无保证排序的参数。如果集成的出价方需要采用一致的参数排序方式，则可将宏放置在其 Cookie 匹配网址中以保证其展示位置。
Supported macros
出价方可以选择将其 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
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 实时出价协议中的 BidRequest.google_user_id 或 Google 的 OpenRTB 实现中的 BidRequest.user.id 指定的值。
google_cver 中指定的版本表示 Google 用户 ID 的数字版本号。指定用户的 Google 用户 ID 不经常更改，之后会递增。
如果 Google 在处理您的匹配请求时遇到错误，系统会改为指定 google_error 参数。
第 3 步：出价工具处理重定向并使用像素进行响应
出价方会收到指向其 Cookie 匹配网址的重定向请求，其中包括他们在第 1 步中指定的参数，以及 Google 在第二步中提供的参数。此外，它们还会在 HTTP 标头中收到其 Cookie。如果操作成功，托管自己的匹配表的出价方可以将其 Cookie 与响应中包含的 Google 用户 ID 进行匹配。建议出价工具存储由 Cookie 匹配服务返回的确切字符串。
如果操作失败，出价工具将在重定向中收到 google_error 参数。这是一个与不同错误状态相对应的数值，用于标识发生的特定错误。您可以点击此处详细了解可能的错误值。如果您收到错误，可以通过放置新的匹配标记来尝试再次匹配该用户。
出价方必须始终通过投放 1x1 不可见像素图片进行响应，或者返回 HTTP 204 No Content 响应。
Cookie 匹配工作流程示意图
下图展示了此工作流，其中请求和响应用箭头表示，附带的数据项列在括号中。
匹配代码网址参数
| 参数 | 说明 |
|---|---|
google_nid |
出价方账号的广告联盟 ID (NID)。此 ID 可通过 Bidders 资源检索。 |
google_cm |
向 Google 的 Cookie 匹配服务表明应执行 Cookie 匹配。该参数的值将被忽略，可以省略。 |
google_sc |
此参数已废弃。为用户设置 Google Cookie（如果不存在）。该参数的值将被忽略，可以省略。如果不存在 Cookie，省略此参数会导致错误。 |
google_no_sc |
此参数已废弃。这会向 Google 的 Cookie 匹配服务表明，在没有 Cookie 的情况下，不应为用户设置 Cookie。该参数的值将被忽略，可以省略。 |
google_hm |
出价方想要存储在 Google 托管的匹配表中的数据。
该值是一个可在 web 环境中安全使用的 base64 编码字符串（填充可选）。原始数据不得超过 40 个字节。例如 |
google_redir |
一个网址编码字符串，出价方如果需要引导 Google 将 HTTP 302 重定向发送到此匹配代码的编码网址，则可以指定该字符串。这样，在向合作伙伴发出的链式调用中，Google 就可以置于前面。如果指定时未指定 google_hm 或 google_cm，则会导致错误。 |
google_ula |
用于将用户添加到现有用户列表的字符串。值的预期格式为 userlistid[,timestamp]：
可以重复使用此网址参数，以便将用户添加到多个列表中。 |
gdpr |
表示请求受 GDPR 中有关数据使用的限制。如需了解详情，请参阅下文中的
欧盟地区用户意见征求要求，或
Authorized Buyers IAB TCF v2.0 文档中的对 Cookie 匹配资格条件的影响。
示例： |
gdpr_consent |
表示最终用户同意情况的 TC 字符串。如需了解详情，请参阅下文中的欧盟地区用户意见征求要求，或 Authorized Buyers IAB TCF v2.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 并浏览网站
小洁清除了缓存中的所有 Cookie。然后，他们访问了 ExampleNews.com 的首页。
变化如下：
- ExampleNews.com 会呈现并调用来自 Google (Ad Manager) 的广告。
- 由于广告单元符合动态分配资格，因此 Google 会通过实时出价服务向 FinestDSP 和其他出价方发送出价请求。
- FinestDSP 的出价工具应用接收和处理出价请求，然后发送其出价响应。
- Google 从出价方收到出价响应，包括 FinestDSP 使用匹配标记（像素）指定广告的响应。
- FinestDSP 赢得竞价。Google 向 Jane 投放 FinestDSP 的广告和匹配代码。
- 匹配标记会调用 Google 的 Cookie 匹配服务，并指定
google_nid和google_cm参数。 - Cookie 匹配服务读取 Jane 的 Google Cookie，并向 Jane 的浏览器发送一个重定向网址，指向已设置
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 发生一周后，Jane 再次访问 ExampleNews.com。现在，Jane 的机器上已经既有出价方 Cookie，又有 Ad Manager Cookie。以下是匹配的运作方式。
- 网页会呈现，这会致使 Google (Ad Manager) 请求将在该网页上呈现的广告。
- 在广告竞价期间，Google 会向适用的出价方（包括 FinestDSP）发送出价请求。
- FinestDSP 接收出价请求，包括
google_user_id等信号。 - FinestDSP 在其匹配表中查找
google_user_id，并找到一周前创建的与 Jane 关联的 Cookie（在场景 1 中）。 - FinestDSP 的出价逻辑根据与 Cookie 关联的信息对展示进行出价，并赢得竞价。
- FinestDSP 根据所掌握的信息向小丽投放与其兴趣相符的广告。
出价方启动：单向 Cookie 匹配
单向 Cookie 匹配与双向工作流类似，只不过它有所改变，使只有 Google 托管和填充匹配表。如果出价方无权在自己的匹配表中托管 Google 用户 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 匹配网址请求像素。此请求将在 HTTP 标头中包含其 Cookie，应为下一步提取该 Cookie。
第 2 步：重定向至 Google 的 Cookie 匹配服务
出价方的 Cookie 匹配端点必须重定向到 Google 的 Cookie 匹配服务，包括使用可在 web 环境中安全使用的 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 协议）或 BidRequest.user.buyeruid（对于 Google 的 OpenRTB 实现）中纳入出价方的托管匹配数据。出价方还可以使用指定的托管匹配数据填充用户名单。
否则，如果发生错误，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 可通过 Bidders 资源检索。 |
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 TCF v2.0 文档中的对 Cookie 匹配资格条件的影响。
示例： |
gdpr_consent |
表示最终用户同意情况的 TC 字符串。如需了解详情，请参阅下文中的欧盟地区用户意见征求要求，或 Authorized Buyers IAB TCF v2.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 匹配工作流程的匹配代码中使用的网址类似。
在像素匹配中，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 可通过 Bidders 资源检索。 |
google_push |
表示此重定向正在完成像素匹配工作流。必须在此处指定相应 Google 匹配标记中的值。 |
google_hm |
包含出价方想要存储在 Google 托管的匹配表中的数据。 |
google_ula |
用于将用户添加到现有用户列表的字符串。值的预期格式为 userlistid[,timestamp]：
可以重复使用此网址参数，以便将用户添加到多个列表中。 |
Google 发起的：单向像素匹配
单向像素匹配与双向工作流程的不同之处在于，Google 的匹配代码不包含指定 Google 用户 ID 的参数，但会继续填充 Google 托管的匹配表。如果出价方无权在其匹配表中托管 Google 用户 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 匹配服务，包括使用可在 web 环境中安全使用的 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.user.buyeruid（对于 Google 的 OpenRTB 实现）。BidRequest.hosted_match_data出价方还可以使用指定的托管匹配数据填充用户列表。
最后，Google 将 1x1 透明像素返回给用户浏览器。
Cookie 匹配辅助
公开出价允许广告交易平台使用出价方启动和 Google 启动的 Cookie 匹配工作流程，将 Google 用户 ID 与其 Cookie 进行匹配。Cookie 匹配辅助 (CMA) 是广告交易平台的一项附加功能，使它们能够使用自己的出价方构建匹配表。
Cookie 匹配辅助功能的运作方式
投放广告时，Google 会通过算法选择一个参与的广告交易平台，然后放置具有以下结构的 Cookie 匹配辅助代码：
<img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
Google 的 CMA 匹配代码会导致广告交易平台的 Cookie 匹配网址收到像素请求。
- 广告交易平台的 Cookie 匹配端点收到该请求，其 Cookie 匹配服务负责将用户 ID 与其其中一个出价方进行匹配。在下图中，广告交易平台的 Cookie 匹配服务以重定向到其出价方的其中一个端点来响应用户的浏览器。
- 出价方会收到该请求以及广告交易平台指定的用于将用户 ID 与其 Cookie 进行匹配的任何参数。
限制
针对新匹配的请求的频率上限
对于在 Google 托管的匹配表中有新条目的用户，出价方负责限制其调用 Cookie 匹配服务的次数。托管匹配表中的条目可能会在 14 天后被视为过期，14 天后可以刷新。
响应所有像素匹配请求
使用像素匹配工作流程的出价方应通过包含 google_push 参数的响应来响应所有传入的像素匹配请求。这样一来，Google 便可以通过监控使用情况来强制执行政策。如果出价方的响应率降至 90% 以下，Google 将限制发送到其帐号的像素匹配请求数。
使用 HTTPS 端点
所有 Cookie 匹配工作流中使用的端点都必须使用 HTTPS。
在响应通过 HTTPS 向您发送的像素匹配请求时，您需要通过 HTTPS 重定向到 Cookie 匹配服务。同样，重定向到出价方的 Cookie 匹配辅助端点也必须使用 HTTPS。如果您通过 HTTP 向 Google 发送请求超过每 2 分钟一次，那么发送到您帐号的匹配请求数会受到限制。
欧盟地区用户意见征求要求
受 Google 的《欧盟地区用户意见征求政策》约束的 Cookie 匹配请求应表明已征得最终用户的同意。此类请求必须用于表明已通过以下方式之一征求用户意见：
- TCFv2：这包括
gdpr和gdpr_consent参数。如需了解详情，请参阅 Authorized Buyers IAB TCF v2.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 参数，该参数的值必须是可在 web 环境中安全使用的 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.hosted_match_data（对于 Google 的实时出价协议）或 BidRequest.user.buyeruid（对于 Google 的 OpenRTB 实现）接收托管的匹配数据。
如果出价工具改用了匹配标记（其中 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 数据为 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.hosted_match_data（对于 Google 的实时出价协议）或 BidRequest.user.buyeruid（对于 Google 的 OpenRTB 实现）接收托管的匹配数据。