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，则为用户设置 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 的同时也使用了 google_redir。
  • 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. Jane 的浏览器会加载重定向到 FinestDSP 的 Cookie 匹配网址。
  9. FinestDSP 的 Cookie 匹配端点会处理重定向请求，其中包括 Google 设置的网址参数，以及 HTTP 标头中针对 Jane 的 Cookie。FinestDSP 现在可以在匹配表中存储其 Cookie 与 google_gid 的映射。
  10. FinestDSP 会使用不可见的 1x1 像素来响应重定向。
场景 2：具有现有映射的用户

在场景 1 发生一周后，Jane 再次访问 ExampleNews.com。现在，Jane 的机器上同时存储了出价方 Cookie 和 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 匹配服务，其中包含填充了可在 Web 环境中安全使用的 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 的同时也使用了 google_redir。
  • 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 步：用户的浏览器向出价方的 Cooking 匹配网址请求像素

用户的浏览器向出价方的 Cookie 匹配网址请求像素，其中包括 HTTP 标头中的出价方的 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

除了 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. 出价方会收到该请求，以及广告交易平台指定的任何参数，以便将用户 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

如果 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 协议）接收其托管的匹配数据。