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 do not guarantee that bid requests for a given user's impressions will always be sent through the same 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, or BidRequest.response_deadline_ms
in the deprecated Google RTB protocol. 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.