Programmatic Timeouts Explained
Speed is everything in programmatic advertising, and timeouts keep the ad platforms participating in a real-time auction on time.
Publishers need to minimize the time between a user selecting content and receiving an ad. This seemingly simple task requires carefully coordinating and integrating disparate ad platforms, which must work together in beautiful harmony.
So what are programmatic timeouts, and how do they work? Let's dive in.
What are programmatic timeouts?
Let's quickly review a simplified programmatic ad transaction workflow to understand why timeouts are essential.
Publisher requests an ad from their ad server
Ad server forwards the request to an SSP
SSP initiates bid requests
DSP returns bid response with ad creative
SSP processes bid responses, extracts creatives, and returns winner(s)
Ad server returns the ad
It's not a very exciting auction since only one DSP is participating. But the point is to show the various hops a typical ad request can take.
As you can see, multiple parties and processes are involved, and each step takes time to conduct while the user waits for their content to load. So how can a publisher be sure that everyone will do their job on time?
The answer is they can't, but publishers can boot out anybody not adhering to agreed-upon response times by using timeouts.
Timeouts are configurable time limits established by ad platforms that will cut off a connection with a server if that server takes too long to respond. In our hypothetical scenario above, multiple timeouts could be in play.
I enriched the previous diagram with information on where these timeouts could be. I also added additional sub-steps relevant to programmatic video, where SSPs need to unwrap creatives:
We now have a timeout of 200ms (milliseconds) configured between the SSP and the DSP and a timeout of 100ms imposed on unwrapping a VAST response to find a source file (steps 4a & 4b).
In the above scenario, the DSP has 200ms to find a suitable bid across all eligible buyers and to return a bid response. Once the DSP returns a bid, the SSP gives itself 100 ms to unwrap all VAST wrappers and wait for a creative host server to return a media file. If the DSP takes too long to return a bid or the creative takes too long to return, the SSP invokes the timeout and kills the opportunity for the DSP.
💡 In programmatic video, DSPs will sometimes return a VAST "wrapper" that redirects to an additional VAST URL that you must call again to find the "inline" VAST that contains the actual video file for playback. Wrappers can also contain additional tracking URLs from interested parties, like verification vendors.
Timeouts are typically communicated upfront to partners during integration testing. However, while testing is necessary for OpenRTB integrations, it might not be required for ad server-to-SSP or SSP-to-SSP connections. SSPs may also not test every possible service hosting creative media files delivered in bid responses by DSPs.
The glory of standards like VAST means that you don't necessarily need a direct relationship with every ad tech company to work with them (although it may be a prudent decision). The downside of interoperability is that every platform does not conduct integration testing with every other platform, so some parties are not privy to others' timeout thresholds.
In its infinite collective wisdom, the IAB Tech Lab included the ability for SSPs to inform DSPs of the timeout at play for a given transaction in the "tmax" field of the ORTB spec:
tmax - Maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout. This value supersedes any a priori guidance from the exchange.
So, if it's there, the DSP should pay attention to it. SSPs also sometimes accept incoming tmax signals via key-value parameters appended to VAST tags. Example:
http://adtechexplained.com/vast/1234?tmax=100&page_url=examplepublisher.com&ip=192.168.0.1&height=1080&width=1920
Why do we need programmatic timeouts?
Ad platforms need to respond quickly so the user is not sitting around waiting for an ad. If we didn't have timeouts, users would wait as long as it took the slowest platform participating in an ad transaction to respond.
Even though our simplified workflow above had a single DSP, in reality, multiple DSPs participate in a real-time auction, all submitting bids simultaneously. Platforms don't want to wait for whoever takes the longest, so they impose a timeout to sever a connection with a bidder if it takes too long. Then, they can get the show on the road with everybody who can respond in time.
Publishers can establish internal thresholds of how long they will wait to complete the entire programmatic and ad orchestration process. They can work with their ad server and supply-side ad platform partners to ensure that the time taken to run all the necessary processes doesn't exceed some minimum standard the publisher sets.
A publisher must consider the total time for each step in the process, which includes all the steps outlined in the previous diagrams. Publishers cannot speed up the ad platform processes themselves but do have control over timeout thresholds, so this is where they can make the necessary tweaks to deliver a premium experience for their users.
Subscribe to the Ad Tech Explained Newsletter
Ad Tech Explained provides explainers, insights, and analysis on the latest trends in advertising technology.
Reply