Cookie 匹配

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 托管您的比赛表。这样一来，您就可以指定一个可在网络中安全使用的 base64 编码字符串（以下称为托管匹配数据），该字符串将映射到指定用户的 Google 用户 ID。建立匹配关系后，可以按以下方式使用：

• 实时出价：在后续针对与用户相关联的展示机会的出价请求中，Google 会向您发送您与用户的 Google 用户 ID 相匹配的托管匹配数据。Google 会将 BidRequest.user.buyeruid 指定为网络安全的 base64 编码字符串。

  要点：如果检测到用户来自有隐私权限制的美国州，则出价请求中不会指定 Google 用户 ID。您仍会收到托管的匹配数据，这些数据可用于指导出价逻辑。
  注意：默认情况下，buyeruid 中的值是网络安全的 base64 编码字符串，应与您在 google_hm 中发送的值相同。如果您在出价请求中收到意外的 buyeruid 值，可能表明您发送的是未编码的 google_hm 值。如需在出价请求中停用编码，请与您的技术支持客户经理联系。

• 用户名单：用户名单可以使用 Google 用户 ID 或托管的匹配数据进行填充。

  注意：如果检测到用户来自有隐私权限制的美国州，则使用 Google 用户 ID 填充用户名单的做法已被弃用，最终会被淘汰。建议出价方使用这些用户的托管匹配数据填充用户列表。
• 预定位： 您可以配置预定位，以便只接收包含托管匹配数据的出价请求。这可用于为 Cookie 空间外的用户排除相关性较低的展示。

用户名单

您可以使用实时出价 API 创建和管理用户列表。创建这些列表后，您可以使用以下 Cookie 匹配工作流或通过批量上传器服务来填充这些列表。

要点：用户名单可以包含 Google 用户 ID 和托管的匹配数据，并且可以混合使用这些数据。请注意，指定后者时，这些媒体必须已添加到 Google 托管的匹配表中。对于来自有隐私权限制的美国州的用户，您必须使用修改后的工作流程，将托管的匹配数据添加到用户名单，而不是 Google 用户 ID。

使用入门

如需开始使用 Cookie 匹配，您必须与您的技术支持客户经理联系，他们可以启用特定工作流并帮助您配置以下内容：

• Cookie 匹配广告联盟 ID (NID)：字符串 ID，用于在 Cookie 匹配和其他相关操作中唯一标识出价方账号。
• Cookie 匹配网址：以下端点的基本网址：作为 Cookie 匹配工作流的一部分接受和处理传入请求的端点。 出价方可以在此网址中嵌入宏，以控制在 Cookie 匹配工作流中传递给该网址的参数的顺序。
• 匹配代码：您必须放置在用户浏览器中的代码，用于启动出价方发起的 Cookie 匹配工作流程。此内容可与广告一起投放， 也可放置在广告之外的网络媒体资源上。
• Cookie 匹配报告网址（可选）：在单向 Cookie 匹配工作流中，这是一个可选网址，您可以提供该网址，以便指定在 Cookie 匹配因 HTTP 302 重定向而失败时，用于接收错误详情的端点。默认情况下，只有在 Cookie 匹配操作出错时，才会向此网址发送响应，但出价方可以请求始终发送重定向。
• Cookie 匹配辅助网址：对于实现 Cookie 匹配辅助工作流的交易平台，这是旨在响应传入请求的端点的基本网址。
• Cookie 匹配辅助配额：对于实现 Cookie 匹配辅助工作流的交易平台，这是其 Cookie 匹配网址每秒可接收的请求数上限。此设置旨在防止 CMA 请求导致交易平台的服务器请求过载。

注意：Authorized Buyers 可以使用 Bidders 资源查看为其账号配置的 Cookie 匹配 NID 和网址。

Cookie 匹配宏

在任何受支持的 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 匹配集成，并且其实现除了 Pixel Matching 参数之外，还需要预设的出价方定义的参数，顺序如下：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_error 参数未在 Google 的匹配代码中针对 Pixel 匹配工作流程进行填充，因此被排除。

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

注意：BIDDER_ACCOUNT_NID 应替换为出价方账号的 NID。技术支持客户经理会在为出价方账号配置 Cookie 匹配时提供此信息，您也可以通过实时出价 API 的出价方资源查看此信息。

您可以在匹配代码中添加其他参数，以满足不同的使用情形。如需详细了解这些参数，请参阅匹配标记网址参数。

第 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 匹配服务返回的确切字符串。在后续出价请求中，此值将与通过 BidRequest.user.id 指定的值相对应。

google_cver 中指定的版本表示 Google 用户 ID 的数字版本号。给定用户的 Google 用户 ID 很少会发生变化，发生变化后，该值会递增。

如果 Google 在处理您的匹配请求时遇到错误，则会改为指定 google_error 参数。

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

出价方会收到重定向到其 Cookie 匹配网址的请求，其中包含出价方在第一步中指定的参数，以及 Google 在第二步中提供的参数。此外，它们还会在 HTTP 标头中收到其 Cookie。如果操作成功，自行托管匹配表的出价方可以将自己的 Cookie 与响应中包含的 Google 用户 ID 进行匹配。建议出价方存储 Cookie 匹配服务返回的确切字符串。

如果操作失败，出价方将在重定向中收到 google_error 参数。这是一个数值，对应于不同的错误状态，用于标识发生的特定错误。您可以在 google_error 网址参数的说明中详细了解可能的错误值。如果您收到错误，可以放置新的匹配标记，尝试再次为该用户进行匹配。

出价方必须始终通过投放 1x1 的不可见像素图片进行响应，或者返回 HTTP 204 No Content 响应。

Cookie 匹配工作流程示意图

下图展示了此工作流，其中箭头表示请求和响应，括号中列出了随附的数据项。

匹配代码网址参数

参数	说明
google_nid	出价方账号的网络 ID (NID)。可以通过 Bidders 资源检索此 ID。
google_cm	向 Google 的 Cookie 匹配服务表明应执行 Cookie 匹配。系统会忽略该参数的值，因此可以省略该参数。
google_sc	此参数已被弃用。如果用户没有 Google 的 Cookie，则设置该 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 字符串。如需了解详情，请参阅欧盟地区用户意见征求要求或 TC 字符串将如何传递？（位于 Authorized Buyers IAB TCF v2.0 文档中）。
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 服务器的过程中，作为双向 Pixel 匹配请求的一部分，传递了无效的 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。
google_hm	仅在尝试写入 Google 托管的匹配表失败时显示。发生这种情况时，其值是以下状态代码之一： 1 - Forbidden：客户无权写入托管的匹配表条目。 2 - 解码错误：无法解码参数值。 3 - 载荷过长：解码后的参数值包含的数据超过 40 字节。 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 匹配工作流示例场景

以下场景描述了典型用户浏览网页时 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 中，该 Cookie 是在一周前创建的）。
5. 根据与 Cookie 相关联的信息，FinestDSP 的出价逻辑会针对展示机会出价，并赢得竞价。
6. 根据 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 匹配服务

Google 将收到一个重定向，其中包含您指定的参数以及 HTTP 标头中的 Google Cookie。

第 4 步：如果指定了报告网址，Google 会在成功或出错时投放像素

如果 Cookie 匹配操作成功，或者出价方账号未指定任何 Cookie 匹配报告网址，Google 默认会投放 1x1 透明像素，工作流到此结束。后续出价请求中针对此用户的展示将包含出价方在 BidRequest.user.buyeruid 中的托管匹配数据。出价方还可以使用其指定的托管匹配数据填充用户名单。

否则，如果发生错误，Google 会将出价方重定向到其 Cookie 匹配报告网址，并在 google_error 参数中指定错误原因。如果出价方的 Cookie 匹配报告网址为 https://ad.network.com/report，则重定向网址将如下所示：

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

注意：出价方可以请求其账号始终接收重定向到其 Cookie 匹配报告网址的请求，即使操作成功也是如此。如需启用此功能，他们可以与自己的技术支持客户经理联系。

第 5 步：用户的浏览器重定向到出价方的 Cookie 匹配报告网址

用户的浏览器将重定向到出价方的 Cookie 匹配报告网址，其中包含 Google 在 google_error 参数中指定的错误原因（如有）。如需详细了解如何解读错误代码，请参阅参数说明。

注意：只有当出价方的账号配置为向 Cookie 匹配报告网址发送有关操作失败或成功的信息时，才会执行此步骤。

第 6 步：出价方投放 1x1 透明像素

出价方必须通过向用户的浏览器投放 1x1 透明像素来做出响应。

注意：只有当出价方的账号配置为向 Cookie 匹配报告网址发送有关操作失败或成功的信息时，才会执行此步骤。

针对美国各州（有隐私权限制）用户的 Cookie 匹配工作流图

以下图表展示了美国境内有隐私权限制的州的用户所使用的默认工作流程，其中请求和响应用箭头表示，随附的数据项列在括号中。

竞价方重定向到 Google 的 Cookie 匹配服务的网址参数

参数	说明
google_nid	出价方账号的网络 ID (NID)。可以通过 Bidders 资源检索此 ID。
google_sc	此参数已被弃用。如果用户没有 Google 的 Cookie，则设置该 Cookie。系统会忽略该参数的值，因此可以省略该参数。如果不存在任何 Cookie，省略该参数会导致错误。
google_no_sc	此参数已被弃用。这会向 Google 的 Cookie 匹配服务表明，如果用户没有 Cookie，则不应为用户设置 Cookie。系统会忽略该参数的值，因此可以省略该参数。
google_hm	包含出价方希望存储在 Google 托管的匹配表中的数据。 注意：该值是一个网络安全的 Base64 编码字符串（填充可选），不得超过 40 字节。例如，这可能如下所示：Q29va2llIG51bWJlciAxIQ==。
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 字符串。如需了解详情，请参阅欧盟地区用户意见征求要求或 TC 字符串将如何传递？（位于 Authorized Buyers IAB TCF v2.0 文档中）。
process_consent	表示出价方已就 Google 的《欧盟地区用户意见征求政策》中指定的数据使用征得最终用户的同意。 如果相应请求不受《欧盟地区用户意见征求政策》的约束，或者相应请求中包含其他意见征求参数 (gdpr_consent)，则系统会忽略此参数。 示例：process_consent=T

Google 重定向到出价方 Cookie 匹配报告网址的网址参数

参数

说明

google_error

一个整数值，用于指示总体请求错误。收到此值时，表示未执行任何操作，并且不会设置任何其他 google_ 响应参数。支持的错误值包括： 1：用户拥有 Google Cookie，但已选择不使用此 Cookie 进行任何跟踪。 2：未指定任何有效操作。例如，收到了空操作请求。 3：用户没有 Google Cookie。Google 不会通过 Cookie 匹配服务设置 Cookie。 4：指定了冲突的操作。您不得在同一请求中同时指定 google_push 和 google_cm 标志，因为这两个标志的用途相互冲突。 5：在重定向到 Google 服务器的过程中，作为双向 Pixel 匹配请求的一部分，传递了无效的 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。

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 在请求中提供的值。与出价方发起的工作流类似，您还可以指定其他参数来满足其他使用情形。

警告：google_cm 和 google_push 参数绝不应在向 Google 的 Cookie 匹配服务发送的同一请求中出现。

第 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 托管的匹配表中的数据。 注意：该值是一个网络安全的 Base64 编码字符串（填充可选），不得超过 40 字节。例如，这可能如下所示：Q29va2llIG51bWJlciAxIQ==。
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 匹配网址请求像素

用户的浏览器会向出价方的 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 匹配服务

Google 将收到一个重定向，其中包含您指定的参数以及 HTTP 标头中的 Google Cookie。如果操作成功，则后续出价请求中针对相应用户的展示次数将包含出价方在 BidRequest.user.buyeruid 中的托管匹配数据。出价方还可以使用其指定的主托管匹配数据填充用户名单。

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

Cookie 匹配辅助工具

公开出价允许广告交易平台使用由出价方发起的和 Google 发起的 Cookie 匹配工作流程，将 Google 用户 ID 与其 Cookie 进行匹配。Cookie Match Assist (CMA) 是一项面向广告交易平台的附加功能，可让广告交易平台与其自己的出价方构建匹配表。

Cookie 匹配辅助功能的工作原理

注意：Cookie 匹配辅助功能将于 2025 年 10 月 28 日起弃用。

1. 在投放广告时，Google 算法会选择参与的广告交易平台，并放置具有以下结构的 Cookie 匹配辅助代码：

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

   注意：对于来自有隐私权限制的美国州的用户，Cookie Match Assist 不会包含 google_gid 参数。

2. Google 的 CMA 匹配代码会导致广告交易平台的 Cookie 匹配网址收到像素请求。

   注意：与 Google 发起的工作流不同，此工作流不包含 google_push 参数。
3. 广告交易平台的 Cookie 匹配端点会收到请求，然后由其自身的 Cookie 匹配服务负责将用户 ID 与其某个出价方进行匹配。在下图中，广告交易平台的 Cookie 匹配服务会向用户的浏览器发送重定向到其某个出价方端点的响应。
4. 出价方会收到请求，以及广告交易平台指定的任何用于将用户 ID 与其 Cookie 相匹配的参数。

注意：根据广告交易平台的实现情况，还可以使用从出价方到广告交易平台的额外重定向，以便在广告交易平台托管的匹配表中设置 Cookie。

限制

限制新匹配项的请求频率

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

警告：Google 不会在投放时强制执行频次上限。 不过，它会定期监控您是否遵守频次上限政策，并保留在您违规时中断服务的权利。

响应所有像素匹配请求

使用 Pixel Matching 工作流的出价方应使用包含 google_push 参数的响应来响应所有传入的 Pixel Match 请求。这样，Google 就可以通过监控使用情况来强制执行政策。如果出价方的响应率低于 90%，Google 将限制发送到其账号的 Pixel Match 请求数量。

使用 HTTPS 端点

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

当您通过 HTTPS 收到 Pixel Match 请求并做出响应时，必须通过 HTTPS 重定向到 Cookie Matching Service。同样，重定向到出价方的 Cookie 匹配辅助端点也必须使用 HTTPS。 如果您通过 HTTP 向 Google 发送请求的频率高于每 2 分钟一次，则发送到您账号的匹配请求数量将会受到限制。

欧盟地区用户意见征求要求

受 Google《欧盟地区用户意见征求政策》约束的 Cookie 匹配请求应指明最终用户同意情况。此类请求必须通过以下方式之一指明已征得用户同意：

• TCFv2：这包括 gdpr 和 gdpr_consent 参数。如需了解详情，请参阅 Authorized Buyers IAB TCF v2.0 文档。
• process_consent：声明出价方已征得必要的用户同意。

示例

以下示例说明了如何使用 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

如果因用户没有 Google Cookie 而导致 Cookie 匹配操作失败，则响应将如下所示：

https://ad.network.com/pixel?id=1&google_error=3

错误代码取决于错误的根本原因。如需详细了解 Cookie 匹配工作流的可能错误代码，请参阅重定向网址参数。

注意：当 Google 重定向到出价方的 Cookie 匹配网址时，匹配代码中显示的出价方定义的参数 id 会按原样传递。

添加到单个用户名单

可以在出价方的匹配标记中指定 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_ula 的值为 12345,0，表示应将用户添加到 ID 为 12345 的用户列表中，在这种情况下，时间戳设置为 0，表示未指定时间戳。或者，也可以只提供用户列表 ID。

如果存在总体错误（例如，用户没有 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 参数，该参数的值必须是网络安全 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 中收到其托管的匹配数据。

如果出价方使用的是 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 中收到其托管的匹配数据。