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.
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, Hong Kong 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|
|Asia Pacific (after October 2019)||Singapore||rtb-singapore.g.doubleclick.net|
|Asia Pacific (until end of October 2019)||Hong Kong, China||rtb-asia.g.doubleclick.net|
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, as measured from the trading location, for a response to be
received once a bid request is sent is 120 to 300 ms (check the
response_deadline_ms field in the bid request for the exact value).
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.
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.