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](https://developers.google.com/authorized-buyers/rtb/get-started/peer-guide#bidder-location) 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 |

**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.

## 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](https://www.peeringdb.com/view.php?asn=15169) for
more details. Note that the traffic requirement is waived for RTB clients. See
Google's [Peering Policy](https://peering.google.com/#/options/peering)
for additional information.

To initiate a peering request, fill out our [peering request form](https://isp.google.com/iwantpeering). We will then
email you a ticket number which you can use in any followups with your
technical account manager.