实时出价协议常见问题解答
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
- 实时出价协议的变更如何传达？
- 此网站会及时更新，并通知有效的实时出价客户端。
- 如何传递可用于自定义所呈现广告的额外信息？
- 在 BidResponse 中返回的 HTML 代码段可以直接包含额外信息。
- 如何在预定位中指定 Cookie 列表？
- 目前，有必要构建一个 Boomerang 列表并基于此列表进行定位。未来，我们将支持上传通过 Cookie 匹配服务构建的经过哈希处理的 Cookie 的列表。
- 如果我不使用宏，会出现什么情况？
- 如常，Cookie 匹配参数会按照无保证的顺序附加到末尾。
- 如果我只使用一个不是
GOOGLE_ALL_PARAMS 的宏，会发生什么？
- 只有该宏会进行扩展。其他参数将保持关闭状态。
- 如果我使用多个宏（包括
GOOGLE_ALL_PARAMS），会发生什么情况？
- 所有宏都会展开，包括
GOOGLE_ALL_PARAMS，例如，某些参数会被重复。
- 如果我想使用宏，但不要使用
GOOGLE_ALL_PARAMS，应该使用哪个宏来进行标准 Cookie 匹配？
GOOGLE_GID、GOOGLE_CVER、GOOGLE_ERROR（或 PAIR 变体）。- 如果我想使用宏，但不要使用
GOOGLE_ALL_PARAMS，应该使用哪个宏来推送 Cookie 匹配？
GOOGLE_GID、GOOGLE_CVER、GOOGLE_PUSH、GOOGLE_ERROR（或 PAIR 变体）。- 应如何处理出价服务器的预定停机时间？
- 如果您的休息时间只持续几个小时，则无需执行任何操作。
当您停止响应后，我们的动态限制系统将自动停止发送您的出价工具出价邀约。如果停机时间较长，请与您的客户经理讨论其他方案。
- 如何控制向出价工具发送请求的速率？
- Google 会静态配置最大查询速率配额，当查询数量过多时，会丢弃请求。如需更改配置，请与您的客户经理联系。您还可以通过调整定位条件或暂停广告组来控制流量。
您还可以使用 Buyer API 以编程方式调整配额。
- 如何监控 Google 观察到的错误和超时率？
- 目前，只有高错误率会导致流量受到限制，才能间接推断这一点。我们将来会更直接地公开这些信息。
- 为什么我的某些出价请求不包含 IP 地址？
- 出现这种情况的原因是：
- 发布商已选择禁止发送 IP 地址。
- 展示是在未连接到 WLAN 的移动设备上。
- 如何解读
BidRequest.ip 中的 IP 地址？
- 为了保护我们的用户，所有 IP 地址都会被截断。但是，这些截断的 IP 地址仍然可以提供常规地理区域和 ISP 等信息。
IPv4 地址被截断为 3 个字节的字符串，这些字符串代表 IP 地址的前三个八位字节，因此 172.16.254.1 会变为 {0xAC, 0x10, 0xFE}。
IPv6 地址会被截断为 6 个字节的字符串。买方将获得 IPv6 地址的前 6 个字节。地址 2001:db8:f:1234::1 缩短为 2001:db8:f::/48 并表示为 {0x20,
0x01, 0x0d, 0xb8, 0x00, 0x0f}。
- 如何确定从哪些 IP 地址接收出价请求，以便将这些地址列入白名单？
- 您不应根据用来接收出价请求的 IP 地址来配置防火墙，因为这些地址可能随时发生更改，恕不另行通知。
- 当我落败出价时，是否可以获得确认和其他信息？
- 不可以，目前您只能使用
WINNING_PRICE 宏等方式在竞价中直接获得胜出确认。
- Cookie 匹配服务是否支持 HTTPS？
- 能。如果您在将 HTTPS 网页放置在 HTTPS 网页上时将其与 HTTPS 协议搭配使用。这样就会重定向到协议设置为 HTTPS 的服务器网址。因此，只有当服务器也能够支持 HTTPS 时，您才能在 HTTPS 网页上放置代码。
- 您是否能在多台计算机上实现负载均衡？
- 我们要求您提供单个网址，并自行实现对该网址的请求的所有负载均衡。我们将来会提供更多相关变体。
- 如果预定位广告组的预算用尽，出价工具是否不会再收到出价请求？
- 能。预定位配置的预算仍由旧版 Authorized Buyers 界面管理，并且正常强制执行。确保预算高于平均每日预算，以免出现问题。
- 对预定位广告组或广告系列的更改需要多长时间才会在界面中生效？
- 通常不到 15 分钟。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-21。
[null,null,["最后更新时间 (UTC)：2025-08-21。"],[[["\u003cp\u003eThe Real-time Bidding (RTB) protocol updates are communicated through site updates and notifications to active RTB clients.\u003c/p\u003e\n"],["\u003cp\u003eBidders can customize ads by including extra information directly within the HTML snippet of their BidResponse.\u003c/p\u003e\n"],["\u003cp\u003eCookie matching currently relies on boomerang lists for pretargeting, with future support planned for hashed cookie lists uploaded through a dedicated service.\u003c/p\u003e\n"],["\u003cp\u003eBid requests may not contain IP addresses if disallowed by the publisher or if the impression originates from a mobile device not using WiFi.\u003c/p\u003e\n"],["\u003cp\u003eWhile Google dynamically manages bidder traffic and quotas, adjustments can be requested via account managers, targeting modifications, ad group pausing, or programmatically through the Buyer API.\u003c/p\u003e\n"]]],[],null,["# RTB Protocol FAQs\n\nHow are changes to the RTB protocol communicated?\n: This site is updated with the changes, and active RTB clients are\n notified.\n\nHow do I pass extra information that can be used to customize the\nrendered ads?\n: Extra information can included directly in the html snippet returned in a\n BidResponse.\n\nHow do I specify a list of cookies in pretargeting?\n: Currently, it is necessary to build a boomerang list and target against\n that. In the future, we will support uploading lists of hashed cookies built\n through the cookie matching service.\n\nWhat happens if I don't use macros?\n: The cookie match parameters will be appended to the end in a\n non-guaranteed order, as per usual.\n\nWhat happens if I use just one macro, that is not\n`GOOGLE_ALL_PARAMS`?\n: Only that macro will be expanded. The other parameters will be left\n off.\n\nWhat happens if I use multiple macros, including\n`GOOGLE_ALL_PARAMS`?\n: All macros will be expanded, including `GOOGLE_ALL_PARAMS`,\n for example, some parameters will be repeated.\n\nIf I want to use macros but not `GOOGLE_ALL_PARAMS`, which\nshould I use for standard cookie matching?\n: `GOOGLE_GID`, `GOOGLE_CVER`,\n `GOOGLE_ERROR` (or the PAIR variants).\n\nIf I want to use macros but not `GOOGLE_ALL_PARAMS`, which\nshould I use for push cookie matching?\n: `GOOGLE_GID`, `GOOGLE_CVER`,\n `GOOGLE_PUSH`, `GOOGLE_ERROR` (or the PAIR\n variants).\n\nHow should scheduled downtime of a bidding server be handled?\n: If your downtime will last only a few hours, no action is needed.\n Our dynamic throttling system will automatically stop sending your bidder\n callouts as soon as you stop responding. If the downtime is longer than a\n short period, speak to your account manager to discuss other options.\n\nHow do I control the rate at which requests are sent to my bidder?\n: Maximum query rate quotas are statically configured by Google and\n enforced by dropping requests when there are too many. To change the\n configuration, you should contact your account manager. You can also\n control traffic by adjusting your targeting conditions or pausing ad groups.\n You can also use the [Buyer API](/authorized-buyers/apis)\n to adjust your quota programmatically.\n\nHow can I monitor the error and timeout rate observed by Google?\n: Currently it is only possible to infer this indirectly by the fact that\n high error rates will cause traffic to be throttled back. We will expose this\n information more directly in the future.\n\nWhy do some of my bid requests not include IP addresses?\n: This happens because:\n\n - The publisher has chosen to disallow the sending of IP addresses.\n - The impression is on a mobile device that is not connected to WiFi.\n\nHow should I interpret the IP addresses in\n`BidRequest.ip`?\n\n: All IP addresses are truncated to protect our users. However, these truncated IP addresses can still offer information such as general geographic region and ISP. IPv4 addresses are truncated to 3 byte strings, which represent\n the first three octets of an IP address, so that `172.16.254.1`\n becomes `{0xAC, 0x10, 0xFE}`.\n\n IPv6 addresses are truncated to 6 byte strings. Buyers will get the first\n 6 bytes of IPv6 addresses. The address `2001:db8:f:1234::1` is\n shortened to `2001:db8:f::/48` and represented as `{0x20,\n 0x01, 0x0d, 0xb8, 0x00, 0x0f}`.\n\nHow can I determine the IP addresses from which I will receive bid\nrequests so I can whitelist those addresses?\n: You should not configure your firewall based on the IP addresses from\n which you will receive bid requests because these addresses might change at\n any time without warning.\n\nIs there any way to get a confirmation and additional information when I\nlose a bid?\n: No, you can currently only get direct confirmation for winning auctions\n using, for example, the `WINNING_PRICE` macro.\n\nDoes the cookie matching service support HTTPS?\n: Yes. If you use the Match Tag URL with the HTTPS protocol when placing it\n on an HTTPS page. This will redirect to your server URL with the protocol set\n to HTTPS. Therefore you should only place the tag on HTTPS pages if your\n server is also able to support HTTPS.\n\nCan you load balance over multiple machines?\n: We require that you provide a single URL and implement any load balancing\n for requests to that URL yourself. More variants of this will be provided in\n the future.\n\nIf our pretargeting ad group runs out of budget will our bidder stop\nreceiving bid requests?\n: Yes. Budget for the pretargeting configuration is still managed in the\n old Authorized Buyers UI and enforced normally. Be sure the budget is higher\n than your average daily goal to avoid issues.\n\nWhat is the delay before a change to a pretargeting ad group or campaign\nin the UI takes effect?\n: Usually less than 15 minutes."]]
