Timing

A screen is waiting. Everything in the ad request path is built around a fixed, small budget.

This page is for the engineers who set the timeout on the content management system side.

The budget for one demand partner

A partner under a price list in auction mode has 1700 ms from the moment it is asked, and a partner under waterfall mode has 1500 ms.

What happens to a late answer

An answer that misses the budget is not waited for and is not used. The platform drops that partner from the round and carries on with whoever did answer in time.

From the partner’s point of view nothing distinguishes this from losing: it is sent no loss notice, because as far as the auction is concerned it never answered.

A repeatedly failing partner stops being called for a while, and no operator action is needed to restore it.

Why the wait does not grow with the number of partners

Partners are asked at the same time. This is true within a priority group, across priority groups, and across the whole partner list of a price list in waterfall mode.

Adding a partner to a price list therefore does not add its timeout to what the screen waits for. It does add one more answer to compare, but the wall-clock budget stays the budget of a single round trip.

The budget a content management system should allow

The wait is made of two round trips to demand partners, one after the other:

  1. The bid round — up to 1700 ms under auction mode, 1500 ms under waterfall mode.

  2. The win notice — up to 1500 ms, sent to the winning partner before the answer goes back to the content management system.

Under default settings the two together account for up to 3.2 seconds, plus the platform’s own processing time at either end.

Set the content management system’s timeout above that figure. A content management system that gives up earlier abandons a slot the platform has already sold: the win notice may already have been delivered, the decision may already have been recorded, and the play will simply never be confirmed.

Playout time

The moment supplied in the request has to be within three minutes of server time. A request for a slot further ahead than three minutes is refused however quickly it arrives.

Reporting the outcome

A play is reported against the request identifier afterwards, and the identifier stays resolvable for a limited window, two hours by default. A report that arrives after the window is not found and never becomes billable. See Late and lost plays.