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 覆盖范围之外的用户获得的相关性较低的展示。

用户名单

您可以通过 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 匹配网址，以包含一个或多个 %%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 匹配服务接收来自用户浏览器的请求，从而向出价方的 Cookie 匹配网址发出 HTTP 302 重定向。重定向将在网址中包括指定 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 匹配服务返回的确切字符串。在后续出价请求中，此值将与 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 No Content 响应。

此工作流如下图所示，请求和响应以箭头表示，附带的数据项列在括号中。

匹配代码网址参数

参数 说明
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 对数据使用行为的限制。如需了解详情，请参阅下文中的 欧盟用户意见征求要求，或参阅 Authorized Buyers IAB TCF v2.0 文档中的对 Cookie 匹配资格的影响。

示例：gdpr=1
gdpr_consent 表示最终用户意见的 TC 字符串。如需了解详情，请参阅下面的欧盟地区用户意见征求要求或 Authorized Buyers IAB TCF v2.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 匹配服务读取小丽的 Google Cookie，然后向小丽的浏览器发送一个重定向到 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（在第 1 种情况下）。
  5. 根据与 Cookie 关联的信息，FinestDSP 的出价逻辑会对展示机会出价，并赢得竞价。
  6. 系统可能会根据 FinestDSP 掌握的信息，向简洁展示一则契合其兴趣的广告。

单向 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 透明像素，工作流程到此结束。后续出价请求中针对此用户的展示次数将包含出价方的托管匹配数据（对于 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，则为用户设置 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 对数据使用行为的限制。如需了解详情，请参阅下文中的 欧盟用户意见征求要求，或参阅 Authorized Buyers IAB TCF v2.0 文档中的对 Cookie 匹配资格的影响。

示例：gdpr=1
gdpr_consent 表示最终用户意见的 TC 字符串。如需了解详情，请参阅下面的欧盟地区用户意见征求要求或 Authorized Buyers IAB TCF v2.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 匹配网址与出价方可用于填充匹配表的其他参数组合在一起。对于指定为 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 匹配工作流程的匹配标记中使用的网址类似。在像素匹配中，google_cm 参数会替换为 google_push 参数，并且其值必须等于 Google 在请求中提供的值。此外，与出价方启动的工作流程类似，您也可以指定其他参数来实现其他用例。

第 3 步：Google 处理重定向并使用像素进行响应

Google 会记录已为用户创建匹配项，并处理通过查询参数请求的任何其他操作。最后，Google 会返回 1x1 透明像素。

像素匹配工作流程示意图

下图展示了此工作流程，其中请求和响应由箭头表示，相应的数据项则列在括号中。

Google 匹配代码请求参数

参数 说明
google_gid Google 用户 ID。对于不来自有隐私权限制的美国各州的用户，Google 的匹配代码中始终会指定此值。
google_cver Cookie 版本。这始终会在 Google 的匹配标记中指定。
google_push 表示此请求正在启动像素匹配工作流。该值必须通过出价方的重定向响应中的相应参数返回。
gdpr_consent 表示最终用户意见的 TC 字符串。如需了解更多详情，请参阅下文中的 [欧盟用户意见征求要求](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements)，或参阅 [Authorized Buyers IAB TCF v2.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 表示最终用户意见的 TC 字符串。如需了解更多详情，请参阅下文中的 [欧盟用户意见征求要求](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements)，或参阅 [Authorized Buyers IAB TCF v2.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 步：用户的浏览器从出价方的烹饪匹配网址中请求像素

用户的浏览器向出价方的 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 还会收到包含您指定的参数的重定向。如果操作成功，后续出价请求中针对此用户的展示次数将包含出价方的托管匹配数据（对于 OpenRTB，为 BidRequest.user.buyeruid；对于已废弃的 Google RTB 协议，为 BidRequest.hosted_match_data）。出价方还可以使用他们指定的托管匹配数据填充用户名单。

最后，Google 会向用户的浏览器返回一个 1x1 透明像素。

借助公开出价，广告交易平台可以使用由出价方发起和由 Google 发起的 Cookie 匹配工作流，将 Google 用户 ID 与其 Cookie 进行匹配。Cookie 匹配辅助 (CMA) 是广告交易平台的额外功能，可让其使用自己的出价方构建匹配表。

  1. 在投放广告时，Google 会根据算法选择参与 Cookie 匹配辅助计划的广告交易平台，并放置 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. 出价工具会收到请求以及广告交易平台指定的所有参数，以将 User-ID 与其 Cookie 进行匹配。

限制

新鲜匹配的请求频率上限

对于在 Google 托管的匹配表中拥有新条目的用户，出价方负责限制对 Cookie 匹配服务的调用次数。托管匹配表中的条目可能会在 14 天后被视为过期，之后可以刷新。

响应所有像素匹配请求

使用像素匹配工作流程的出价方应对所有传入的像素匹配请求做出响应，其中响应应包含 google_push 参数。这样，Google 就可以通过监控使用情况来强制执行政策。如果出价方的响应率低于 90%，Google 会限制向其账号发送的像素匹配请求的数量。

使用 HTTPS 端点

所有 Cookie 匹配工作流中使用的端点都必须使用 HTTPS。

在响应通过 HTTPS 发送给您的像素匹配请求时，您需要通过 HTTPS 重定向到 Cookie 匹配服务。同样，重定向到出价方的 Cookie Match Assist 端点也必须使用 HTTPS。如果您通过 HTTP 向 Google 发送请求的频率高于每 2 分钟一次，系统会限制向您的账号发送的匹配请求数量。

需要遵守 Google 的《欧盟地区用户意见征求政策》的 Cookie 匹配请求应指明已征得最终用户同意。此类请求必须表明已通过以下某种方式征求用户意见：

示例

以下示例说明了如何使用 Cookie 匹配服务来实现特定目标。请注意，除非另有说明，否则假定被操作的用户并非来自设有隐私权限制的美国州。

填充由出价方托管的匹配表

出价方可以使用 Cookie 匹配工作流程填充自己的匹配表，只需在其匹配代码中提供 google_nid 和 google_cm 参数即可。相应版本代码可能类似如下：

<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 用户 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

上述重定向网址包含的 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.user.buyeruid（对于 OpenRTB）或 BidRequest.hosted_match_data（对于已废弃的 Google RTB 协议）中收到其托管的匹配数据。