Stay organized with collections
Save and categorize content based on your preferences.
To help meet the latency restrictions of the RTB service, you should locate
your servers close to the trading locations listed below. See the discussion on
locating your bidders for more information.
Trading locations
A trading location is the optimal point of a geographically dispersed server
cluster where infrastructure hosting a bidder application can benefit most in
terms of latency. Real-time bidding callouts do not necessarily originate at
the trading location, and can come from elsewhere in the cluster. As an
example, Singapore is the trading location for the Asia Pacific cluster
spanning from Australia to Singapore.
The following table lists reference domains that can be used to assess
latency and estimate the best locations for your server.
Server Cluster
Trading Location
Reference Domain
North America (East Coast)
Northern Virginia, United States
rtb-us-east.g.doubleclick.net
North America (West Coast)
San Francisco Bay Area, California, United States
rtb-us-west.g.doubleclick.net
Europe
Amsterdam, Netherlands
rtb-europe.g.doubleclick.net
Asia Pacific
Singapore
rtb-asia.g.doubleclick.net
Bidder location
We attempt to send bid requests to the trading location closest to the user's location. However,
we do not guarantee that bid requests for a given user's impressions will always be sent to the
closest trading location. Therefore, to receive all impressions, you need to have servers reachable
from all locations. If you only want a subset of impressions, it may be sufficient to run servers in
a subset of locations. For example, most, but not all, North American traffic can be received by
running servers reachable from the East and West coasts.
The deadline that you must send a bid response by is indicated in
BidRequest.tmax. The deadline typically ranges from 80 to 1000 ms.
We require that 85 percent of responses be received within the deadline
from the perspective of the trading location and will throttle bidders that
cannot consistently achieve this. This deadline includes both the network time
between the trading location and your bidder, and the time it takes your bidder
to generate a response. We recommend targeting a total time well below the
deadline in order to to leave a buffer for unexpected changes in network
latency between your bidder and the trading location.
Peering
Google recommends that RTB buyers receiving a large volume of requests set
up peering requests with us to reduce latency and latency volatility.
We peer with any network as long as they meet Google's technical
requirements, like having a public ASN. See the technical requirements for
more details. Note that the traffic requirement is waived for RTB clients. See
Google's Peering Policy
for additional information.
To initiate a peering request, fill out our peering request form. We will then
email you a ticket number which you can use in any followups with your
technical account manager.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-18 UTC."],[[["\u003cp\u003eTo minimize latency in the Real-Time Bidding (RTB) service, position your servers near the specified trading locations, such as Northern Virginia, San Francisco Bay Area, Amsterdam, and Singapore.\u003c/p\u003e\n"],["\u003cp\u003eTrading locations serve as optimal points for server clusters to reduce latency, but bid requests can originate from anywhere within the cluster and are not guaranteed to always be sent to the geographically closest location.\u003c/p\u003e\n"],["\u003cp\u003eTo receive all potential impressions, ensure your servers are reachable from all listed trading locations; however, running servers in a subset of locations can suffice if only a specific subset of impressions are desired.\u003c/p\u003e\n"],["\u003cp\u003eBidders must respond to bid requests within a deadline, typically between 80 to 1000 ms, with a requirement that 85 percent of responses meet this deadline.\u003c/p\u003e\n"],["\u003cp\u003eFor high-volume RTB buyers, Google recommends setting up peering to decrease latency and latency volatility, with traffic requirements being waived specifically for RTB clients.\u003c/p\u003e\n"]]],[],null,["# Latency Restrictions and Peering\n\nTo help meet the latency restrictions of the RTB service, you should locate\nyour servers close to the trading locations listed below. See the discussion on\n[locating your bidders](#bidder-location) for more information.\n\nTrading locations\n-----------------\n\nA trading location is the optimal point of a geographically dispersed server\ncluster where infrastructure hosting a bidder application can benefit most in\nterms of latency. Real-time bidding callouts do not necessarily originate at\nthe trading location, and can come from elsewhere in the cluster. As an\nexample, Singapore is the trading location for the Asia Pacific cluster\nspanning from Australia to Singapore.\n\nThe following table lists reference domains that can be used to assess\nlatency and estimate the best locations for your server.\n\n| Server Cluster | Trading Location | Reference Domain |\n|----------------------------|---------------------------------------------------|-------------------------------|\n| North America (East Coast) | Northern Virginia, United States | rtb-us-east.g.doubleclick.net |\n| North America (West Coast) | San Francisco Bay Area, California, United States | rtb-us-west.g.doubleclick.net |\n| Europe | Amsterdam, Netherlands | rtb-europe.g.doubleclick.net |\n| Asia Pacific | Singapore | rtb-asia.g.doubleclick.net |\n\n| **Note:** We provide these domains for approximate estimation of latencies only. Routing outside of Google's network and Google's deployment of the service may change over time. In addition, network congestion or short term maintenance issues may leave these domains unreachable or too distant from a given location for extended periods.\n\nBidder location\n---------------\n\nWe attempt to send bid requests to the trading location closest to the user's location. However,\nwe do not guarantee that bid requests for a given user's impressions will always be sent to the\nclosest trading location. Therefore, to receive all impressions, you need to have servers reachable\nfrom all locations. If you only want a subset of impressions, it may be sufficient to run servers in\na subset of locations. For example, most, but not all, North American traffic can be received by\nrunning servers reachable from the East and West coasts.\n\nThe deadline that you must send a bid response by is indicated in\n`BidRequest.tmax`. The deadline typically ranges from 80 to 1000 ms.\n\nWe require that 85 percent of responses be received within the deadline\nfrom the perspective of the trading location and will throttle bidders that\ncannot consistently achieve this. This deadline includes both the network time\nbetween the trading location and your bidder, and the time it takes your bidder\nto generate a response. We recommend targeting a total time well below the\ndeadline in order to to leave a buffer for unexpected changes in network\nlatency between your bidder and the trading location.\n\nPeering\n-------\n\nGoogle recommends that RTB buyers receiving a large volume of requests set\nup peering requests with us to reduce latency and latency volatility.\n\nWe peer with any network as long as they meet Google's technical\nrequirements, like having a public ASN. See the [technical requirements](//www.peeringdb.com/view.php?asn=15169) for\nmore details. Note that the traffic requirement is waived for RTB clients. See\nGoogle's [Peering Policy](//peering.google.com/#/options/peering)\nfor additional information.\n\nTo initiate a peering request, fill out our [peering request form](//isp.google.com/iwantpeering). We will then\nemail you a ticket number which you can use in any followups with your\ntechnical account manager."]]
