Cookie 匹配

Cookie 匹配是一项功能，通过它您可以匹配自己的 Cookie， 例如浏览您网站的用户的 ID，其中包含相应的 出价工具专有的 Google 用户 ID，并构建用户名单，帮助您 更有效的出价选择。本指南介绍了 Cookie 中使用的概念， 以及不同的 Cookie 匹配工作流程 它们可能在某些用例中具有的一些特性。

概念

什么是 Cookie 匹配？

域所有者通常为浏览网站的用户设置 Cookie 内容 网站，用于标识相应网域中的用户。即使两个 否则，网域所有者会同意交换这些数据， 的互联网浏览器限制浏览器读取由另一个浏览器设置的 Cookie， 网域。

对于数字广告，Google 使用 Cookie 识别用户 属于 doubleclick.net 网域，而出价方 参与实时出价的买方可能拥有自己的网域， 确定他们希望展示广告的一组用户。Cookie 匹配 可让出价方将其 Cookie 与 Google 的 Cookie 进行匹配，以便 确定出价请求中发送的展示是否与 用户，他们会收到自己的 Cookie 数据或 即相应出价方专属的 Google 用户 ID， doubleclick.net Cookie。

本指南中介绍的 Cookie 匹配服务可帮助您创建 以及维护出价方的 Cookie 与 Google User-ID），并且还允许填充用户名单。

匹配表

匹配表可用于将一个网域的 ID 或其他数据映射到 另一个。出价方可以使用 Cookie 匹配服务填充自己的 通过将指定用户的 Cookie 映射到该用户的 Google 来匹配表 用户 ID，或填充由 Google 托管的匹配表。匹配表 出价方的出价方应用必须获取相应用户 Cookie 数据 相应展示

Google 托管的匹配表

为了更轻松地进行维护、缩短延迟时间以及访问 建议您允许 Google 托管您的 匹配表。这样，您就可以指定一个网络安全 base64 编码字符串： 下文称为托管匹配数据，这些数据将映射到 指定用户的 Google 用户 ID。匹配成功后 具体方式如下：

• 实时出价：在针对展示机会的后续出价请求中 之后，Google 会向您发送您在 与其 Google 用户 ID 相匹配。如果您配置了出价端点 使用 Google 的实时出价协议，您将通过 BidRequest.hosted_match_data 字段中的值。在 Google 的 OpenRTB 中 实现，BidRequest.user.buyeruid 会返回此 形式为网络安全 base64 编码字符串。

  <ph type="x-smartling-placeholder">

• 用户名单：可以填充用户名单 与 Google 用户 ID 或托管的匹配数据相关联。

  <ph type="x-smartling-placeholder">
• 预定位： 您可以将预定位配置为仅接收出价请求 包含托管的匹配数据。这一指标可用于排除 展示次数。

用户名单

您可以通过 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 匹配网址中， 。

支持的宏

出价方可以选择将 Cookie 匹配网址配置为包含一个或 %%GOOGLE_<PARAM_NAME>%% 或 %%GOOGLE_<PARAM_NAME>_PAIR%%。支持的宏及其 扩展值包括：

宏示例

出价工具将 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

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 为 未填充的 Web 安全 base64 编码 字符串。对于选择托管匹配表的出价方，建议： 请存储 Cookie 匹配服务返回的确切字符串。在随后 出价请求，这对应于通过 BidRequest.google_user_id 指定的值 或者 Google 的 RTB 协议中的 BidRequest.user.id OpenRTB 实施。

google_cver 中指定的版本表示 Google 用户 ID 对应的版本号。指定用户的 Google 用户 ID 不经常更改，之后此数字将递增。

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

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

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

如果操作失败，出价方将收到 google_error 参数。这是一个数值，对应不同的 错误状态，用于标识所发生的具体错误。您可以了解 此处详细了解可能的错误值。 如果收到错误，您可以再次尝试匹配该用户，方法是 放置新的匹配标记。

出价工具必须始终通过提供 1x1 隐形像素图片来做出响应，或 也可以返回 HTTP 204 No Content 响应。

Cookie 匹配工作流程示意图

该工作流如下图所示，其中请求和 以箭头表示这些响应及其随附的数据项， 列于括号中。

匹配代码网址参数

除上述参数外，出价方还可以指定自己的参数，即 将作为参数附加到重定向网址。请注意，由出价方定义的 以 google_ 前缀命名的参数将被忽略，因为 它们是 Google 为将来开发和保留 参数的顺序。匹配代码（包含出价方定义的代码） 参数可能如下所示：

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

重定向网址参数

重定向网址是根据所配置的基本 Cookie 匹配网址构建的，而该网址针对 出价方的账号，包括 google_ 和出价方定义的参数 具体取决于匹配标记中指定的参数。以下google_ 响应参数的定义如下：

Cookie 匹配工作流程示例场景

以下情形介绍了对于一个 通常是用户在浏览网页时遇到的情况。

场景 1：用户清除 Cookie 并浏览网站

Jane 清除了缓存中的所有 Cookie。然后访问 ExampleNews.com 的首页。

对整个过程的说明如下：

1. ExampleNews.com 呈现并调用 Google (Ad Manager) 的广告。
2. 由于该广告单元符合动态分配条件，因此 Google 向该广告单元发送出价 向 FinestDSP 和其他出价工具发出广告请求。
3. FinestDSP 的出价工具应用接收并处理出价请求， 并发送其出价响应。
4. Google 会收到出价方的出价响应，包括 FinestDSP 的响应 ，用于指定带有匹配代码（像素）的广告。
5. FinestDSP 赢得竞价。Google 将 FinestDSP 的广告和匹配代码投放至 Jane。
6. 匹配代码调用 Google 的 Cookie 匹配服务，指定 google_nid 和 google_cm 参数。
7. Cookie 匹配服务读取小丽的 Google Cookie，并将小丽的 浏览器会重定向到 FinestDSP 的 Cookie 匹配网址，并使用 已设置 google_user_id 和 google_cver 参数。
8. 小洁的浏览器加载了指向 FinestDSP 的 Cookie 匹配网址的重定向。
9. FinestDSP 的 Cookie 匹配端点处理重定向请求， 其中包括 Google 设置的网址参数，以及 Google 在 HTTP 标头。FinestDSP 现在可以存储其 Cookie 与 google_user_id。
10. FinestDSP 使用不可见的 1x1 像素响应重定向。

场景 2：已有映射的用户

在场景 1 一周后，Jane 再次访问 ExampleNews.com。现在，Jane 其机器上同时存有出价工具和 Ad Manager Cookie，以下是如何匹配 工作。

1. 网页会呈现，导致 Google (Ad Manager) 请求 将在网页上呈现
2. 在广告竞价期间，Google 会向适用的出价方发送出价请求， 包括 FinestDSP。
3. FinestDSP 接收出价请求，包括 google_user_id。
4. FinestDSP 在其匹配表中查找 google_user_id， 并找到一周前与小珍关联的 Cookie （在情景 1 中）。
5. 根据与 Cookie 相关的信息，FinestDSP 的出价 逻辑会对展示机会出价，并在竞价中胜出。
6. 根据 Google 上提供的信息，小珍可能会看到与其兴趣相符的广告 FinestDSP 所有的功能。

出价方启动：单向 Cookie 匹配

单向 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 以供下一步使用。

第 2 步：重定向到 Google 的 Cookie 匹配服务

出价方的 Cookie 匹配端点必须重定向到 Google 的 Cookie 匹配服务，包括填充了 google_hm 参数的 可在网络上安全使用的 Base64 编码 Cookie 数据中。重定向网址可能类似于 以下：

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 匹配操作成功或 已为出价方的账号指定匹配报告网址：Google 将默认投放 1x1 透明像素，工作流程到此结束。 在后续出价请求中，此用户的展示次数将包括出价方的 BidRequest.hosted_match_data 中针对 Google 托管的匹配数据 协议，对于 Google OpenRTB，则为 BidRequest.user.buyeruid 实施。出价方还可以使用托管的匹配数据填充用户名单 。

否则，如果发生错误，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 透明像素

出价工具必须在用户的 。

适用于具有隐私权限制的美国各州用户的 Cookie 匹配工作流程示意图

上图显示了在有隐私权限制的美国各州内用户的默认工作流程 图中请求和响应以箭头表示，数据 与之相关的项列在括号中。

出价工具的网址参数会重定向至 Google 的 Cookie 匹配服务

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

Google 发起：双向像素匹配

双向像素匹配是 Google Cookie 匹配的工作流程 Google 尝试通过算法将 Google 用户 ID 与 不是实时出价竞价的胜出者。当广告 之后，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" />

第 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 会记录为该用户创建了匹配项，并处理 通过查询参数请求的其他操作 以及 1x1 透明像素

像素匹配工作流程示意图

该工作流如下图所示，其中请求和 以箭头表示这些响应及其随附的数据项， 列于括号中。

Google 匹配代码请求参数

出价方像素匹配重定向参数

Google 发起：单向像素匹配

单向像素匹配与双向工作流程在 Google 的匹配代码中不包含指定 Google 用户的参数， ID，但会继续填充由 Google 托管的匹配表。这可用于 例如，在不允许出价方的 自己的匹配表。以下简单示例总结了修改后的工作流程 步骤。

第 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 匹配服务，包括填充了 google_hm 参数的 可在网络上安全使用的 Base64 编码 Cookie 数据中。重定向网址可能类似于 以下：

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.hosted_match_data） Google 协议或者BidRequest.user.buyeruid适用于 Google 的 OpenRTB 实施。出价方还可以使用托管的 与指定的数据匹配。

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

Cookie 匹配辅助

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

Cookie Match Assist 的工作原理

1. 投放广告时，Google 会利用算法选择参与竞价的 广告交易平台，并放置包含以下代码的 Cookie Match Assist 代码： 结构：

   <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 进行匹配。

限制

新鲜匹配的请求频率上限

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

响应所有像素匹配请求

使用像素匹配工作流程的出价方预计会在 包含 google_push 的响应的传入像素匹配请求 参数。这样一来，Google 就能通过监控使用情况来强制执行相应政策。如果 出价响应率降至 90% 以下，Google 将限制 发送到其账号的像素匹配请求。

使用 HTTPS 端点

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

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

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

受以下限制的 Cookie 匹配请求： Google 的欧盟用户 意见征求政策应指明最终用户意见征求。此类请求必须 表明已通过以下某种方式征求用户意见：

• TCFv2：包括 gdpr 和 gdpr_consent 参数。有关详情，请参阅 <ph type="x-smartling-placeholder"></ph> 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

如果 Cookie 匹配操作失败，原因是用户没有相关的 Google Cookie，响应将是：

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

错误代码取决于错误的根本原因。学习内容 请参阅 重定向网址参数。

添加到单个用户名单

可以在出价方的匹配内容中指定 google_ula 参数 代码将用户添加到具有指定 ID 的用户列表中。如果 Google 或 出价工具托管的匹配表中有一个关于用户的新条目，出价工具可以将 包含 google_nid 和 google_ula 的匹配标记 参数，可以将用户添加到指定列表中，而无需启动完整的 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 参数，其中 其值必须是一个网络安全 base64 编码字符串。对于 出价方的未编码 Cookie 数据为 Cookie number 1!，即经过编码的 Cookie 值为 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 用户 ID 匹配 在 google_gid 中使用其 Cookie 数据。在 此外，他们还可以确定 Google 托管的匹配表和用户名单 操作成功。因此，该出价方的任何预定位配置 现在，如果配置为定位到指定的用户名单 ID， 收到用户针对展示机会发出的出价请求。同理，在这些出价中 请求，出价方将收到其托管的匹配数据， BidRequest.hosted_match_data（适用于 Google 的实时出价协议），或 BidRequest.user.buyeruid（适用于 Google 的 OpenRTB 实施）。