RTB bidder development: the bid path, the deadline and the tail

What happens to a bid request inside the bidder?

Several of these steps are defined by the protocol. OpenRTB's best practice reads: "One of the simplest and most effective ways of improving connection performance is to enable HTTP Persistent Connections, also known as Keep-Alive"^[1]. The request carries the filters for step 4: bcat, "Blocked advertiser categories using the specified category taxonomy"; badv, a "Block list of advertisers by their domains"; and bidfloor, the "Minimum bid for this impression expressed in CPM"^[1]. A no-bid can be "an empty response with HTTP 204"^[1]. The win notice URL is called "if the bid wins (not necessarily indicative of a delivered, viewed, or billable ad)", which is why spend is counted on the separate billing notice^[1].

How much of the deadline does the bidder actually get?

OpenRTB defines tmax as the "Maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout"^[1]. The bidder's own budget is what is left after the round trip.

On Google's Authorized Buyers, "The deadline typically ranges from 80 to 1000 ms"^[2].

Google states: "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"^[2].

Google recommends "targeting a total time well below the deadline" to leave a buffer for changes in network latency between the bidder and the trading location, and lists its trading locations as Northern Virginia, the San Francisco Bay Area, Amsterdam and Singapore^[2].

In practice this means one internal deadline per exchange connection, derived from that connection's measured round trip, and admission control that answers a no-bid when the queue already makes the deadline impossible. A fast no-bid counts as an answer; a late bid counts as a timeout.

How is capacity planned?

• The request rate sets the bill. Servers and bandwidth scale with every request answered, including the auctions you lose. Pre-filtering is the first capacity lever.
• Stateless bidders, replicated state. Bidder instances behind a load balancer hold read-only campaign indexes and local counters; budgets and frequency are reconciled in the background.
• Regions follow supply. A bidder near the trading location spends less of the deadline on the wire^[2].
• Shed load deliberately. Under overload, answering no-bid early is cheaper than timing out, and repeated timeouts invite throttling^[2].
• Measure per core with your own traffic. Throughput depends on request size, campaign count and pricing work; a figure measured on someone else's workload does not transfer.

How is the tail measured?

• Per exchange connection, not per fleet. A timeout problem usually shows on the connection with the tightest tmax and the heaviest requests first.
• Split the time. Handler time, time waiting to be scheduled, and time on the wire each have different fixes; Go GC pauses in an RTB bidder shows how to separate them.
• Open-loop load. A generator that waits for replies stops sending during a stall and hides it; send at a fixed rate and count latency from the intended send time.
• Percentiles, not averages. p99 and p99.9 per connection, checked against that connection's internal deadline.

Which language for the bid path?

A rewrite pays when the measured milliseconds are in the handler and the collector; it returns nothing when they are on the wire or in the scheduler. Moving the smallest piece that owns the allocations, candidate selection, targeting or pricing, is often enough.

Start from open source or from a bidder-as-a-service?

RTB4FREE describes its bidder as "The OpenRTB 2.0 compliant bidder for RTB4FREE, the open source bidder / DSP"; it is written in Java under Apache-2.0, and its repository was last pushed on 16 November 2022^[3].

Beeswax, described by AdExchanger in December 2020 as "the 'bidder-as-a-service'" when FreeWheel bought it, was a product where "users can install their own algorithms"^[4].

An open-source bidder is a reading reference and a test harness more than a starting point when it is no longer maintained. A bidder-as-a-service keeps infrastructure rented and puts your logic inside it. A bidder of your own makes sense when the logic, the data and the infrastructure cost are all yours to change; the rest of the platform around it is on DSP development company, and the rented DSPs are compared on white-label DSP vs own DSP.

How does a bidder build or rebuild run?

1. 1.Measure first. Per-exchange timeout rates, tmax distributions and a timing split of the current bidder, if there is one.
2. 2.Design the budget. Internal deadline per connection, admission rule, what runs on the bid path and what runs beside it.
3. 3.Build against recorded traffic. A replay of real requests at a fixed rate is the acceptance test from the first week.
4. 4.Shadow. The new bidder receives mirrored traffic on separate instances and its decisions are compared with the old one's, without bidding.
5. 5.Ramp by connection. One exchange connection at a time, with automatic rollback on a timeout threshold agreed in advance.

What should you ask an RTB bidder developer?

1. 1.Which bidder of yours is live, at what request rates, and on which exchanges?
2. 2.Before proposing a language, how will you find where the milliseconds go today?
3. 3.Which load generator do you use, and does it correct for coordinated omission?
4. 4.What is the acceptance criterion: which connection, which percentile, what margin below tmax?
5. 5.Who is on call for the bid path after launch?
6. 6.What do we receive at the end, and does anything stay yours?

Who should not build a custom bidder?

• Buyers without their own supply connections; a DSP seat covers them.
• Teams whose timeouts come from geography rather than code: moving the bidder closer to the exchange is cheaper than rewriting it^[2].
• Anyone who cannot staff the bid path after launch. A bidder nobody watches drifts out of spec as exchanges change theirs.

Related on this site: DSP case study and real-time bidding infrastructure.

Product and company names are trademarks of their respective owners and are used only to identify their products. No vendor named here reviewed or endorsed this page.