Latency Restrictions and Peering

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, 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
Europe Amsterdam, Netherlands rtb-europe.g.doubleclick.net
Asia Pacific Hong Kong, China 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, 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 tmax or 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.

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.

다음에 대한 의견 보내기...

Real-Time Bidding
Real-Time Bidding