How Network Latency affects the RTB process for Adtech
Real time bidding (RTB) works by letting DSPs and ad exchanges bid on individual ad impressions as soon as they become available, choosing the highest bid and then serving the ad of the highest bidder to the consumer. This is a very time intensive process where Demand side platforms (DSPs) have to respond to bid requests within 100 ms. This bid response time comprises both the time required for computation as well as the round trip transit time.
How much time do DSPs really have to respond to RTB bids?
To ensure that the ad serving process is as quick as possible Supply side platforms (SSPs) place a very strict time constraint on the RTB process. This time constraint usually hovers between the 80 to 120 ms range. Google, one of the biggest ad exchanges places a timeout restriction of 100 ms on the RTB process. Any bids received later then this timeout limit are not considered in the auction.
This time limit however, is subject to drastic reductions because of network congestion. Google itself recommends targeting a latency well below 100 ms to create a buffer when network congestion leads to delays in bids arriving. It is usually recommended to set aside 20 ms for this buffer to accommodate unexpected increases in Network latency, leaving only 80 ms for bids to arrive at the SSP or ad exchange.
This 80 ms comprises both the computation time as well as the time required for a round trip network transit. Computation time is the time allocated by DSPs to calculating the optimal bid amount by comparing the information contained in the ad cookie id to their own information as well as making calls to third party data providers.
The process of coming up with an optimized bid amount and optimal targeting is essential to increasing the click through rate (CTR) and return on investment (ROI) for advertisers. It is therefore only logical to assume that DSPs would want to allocate as much time as possible to computation (think) time. If a total of 40 ms is allocated to computation time this leaves only 40 ms for the round trip time.
Minimizing Network latency therefore is essential for Adtech companies.
Problems caused by High Network latency for Adtech
High Network latency results in Adtech companies exceeding the time limit of the RTB process which leads to a number of problems. These include losing out on potential bids or ad space and being shunted out of a sales channel because of consistently slow bids. Companies facing high Network latency tend to allocate less and less time to computation time resulting in un-optimized bids, under or over valuing impressions and sub optimal user targeting. Additionally, high Network latency slows the delivery of ad creative from the advertiser ad server to the end user which leads to advertisers being charged for impressions without the user actually having seen the ad. Header bidding which is a new type of programmatic advertising allows SSPs to offer their ad inventory in more than one sales channel at the same time. For header bidding to work publishers have to include tags for every additional SSP that they want to bid on their ad inventory, which leads to higher Network latency and longer page load times.
How Datapath.io reduces Network latency
Datapath.io works like a GPS for the internet. As is the case with most modern GPS devices they not only tell you the quickest way to a destination but also where potential hiccups and traffic bottlenecks can occur. Datapath.io takes this concept and applies it to the public internet. Datapath.io’s proprietary algorithms take a snapshot of the internet every half an hour. It collects the Network latency and congestion information from over 600,000 network nodes and uses this information to compute an optimal path for network traffic with the lowest Network latency. Because Datapath.io knows the latency for every network node it can then re-route internet traffic through the paths with the lowest Network latency.
Take as an example the above snapshot from Datapath.io’s customer backend. It shows the Network latency encountered through the default (Amazon Web Services) AWS route as compared to Datapath.io’s optimized network routes, while sending internet traffic from Frankfurt to Amsterdam. There is an improvement of 3 to 4 times in Network latency. Network traffic which takes 41 ms to get to Amsterdam through the default route from AWS takes only 11 ms when sent through Datapath.io.
This improvement has huge implications for an industry like Adtech which relies heavily on speed and where even a small improvement in latency can spell the difference between winning an auction and not being considered for the auction at all.
Article originally published on the Datapath.io Blog.
