Ad Budgeting Component for Real-Time Bidding (RTB) Auctions

A budget control system to help demand-side platforms (DSPs) reduce budget overspend.

This article examines a distributed budget management component for real-time bidding — referred to here as a banker — designed to help DSP builders prevent budget overspend and reduce the engineering effort involved in implementing reliable campaign spend controls.

The Problem

Controlling an advertiser's media spend is a foundational requirement of any demand-side platform. When it's managed incorrectly, campaigns either underspend or overspend — both of which disadvantage advertisers.

Underspending means a campaign falls short of its intended reach. Overspending, however, creates a more acute problem: the DSP vendor typically absorbs the excess cost, and the advertiser loses the opportunity to show ads to their target audience at the right frequency and scale.

How Impression Tracking Works in Most DSPs

On any given web page, multiple ad slots may be present. Each slot, once loaded, sends an ad request to the publisher's ad server, which forwards it to an SSP or ad exchange, which in turn fans it out to multiple DSPs.

Once a DSP receives a bid request, it must return a bid response — typically within 250ms. This process occurs billions of times per day across the internet.

The tight latency constraints mean that budget management has to function reliably under extreme throughput. The core issue: there is typically a delay of several seconds between the moment a bidder responds to a bid request and when the DSP receives confirmation that the impression was actually displayed. When multiple bidders are simultaneously handling large volumes of traffic, this gap creates a window in which overspending can occur.

Impression Tracking — Step by Step

• The publisher sends an ad request to an SSP/ad exchange.
• The SSP/ad exchange sends a bid request to the DSP's bidder.
• If the bid matches a campaign, the bidder returns a bid (e.g. $1.05 CPM) and ad markup.
• Assuming the DSP wins the impression, the SSP/ad exchange sends the ad markup to the publisher.
• The publisher loads the ad markup and retrieves the creative from the ad server.
• The ad server sends the creative to the publisher, where it is displayed to the user.
• The tracker records data about the impression and click (if applicable).
• The tracker sends information to update frequency capping conditions.
• The tracker sends event data to the campaign reporting database for reporting purposes.

Without a dedicated budget management layer inserted into this flow, overspending is structurally inevitable.

Examples of Budget Overspend in a DSP

Three scenarios illustrate how overspend arises in practice:

1. Broad Targeting

When targeting parameters — location, device type, ad size — are set broadly, the bidder matches a large number of bid requests to a given campaign, often simultaneously or within milliseconds of each other. Without a proper budget management system in place, the bidder will continue placing bids because it hasn't yet been notified about previously won impressions. By the time the impression data arrives, the budget may already be exceeded.

2. Digital Out-of-Home (DOOH) Campaigns

When a DSP is integrated with a DOOH platform — serving ads on digital billboards, for instance — the delay between an ad being displayed and the DSP receiving confirmation can range from 15 minutes to 48 hours. Accurate real-time budget tracking is essentially impossible in these scenarios without a reservation-based spending control.

3. Bidders and Spending Databases in Different Regions

DSP components are sometimes distributed across geographic regions. In some configurations, the bidder and the SSP/ad exchange may be co-located (e.g. in the same AWS region), while the spending database resides elsewhere. The cross-region latency between data centres is enough to produce overspend at scale unless a dedicated budget management layer is present.

The Solution

The budget management component described here — the banker — is based on Edsger W. Dijkstra's banker's algorithm. The algorithm was originally conceived as a deadlock-avoidance mechanism for resource allocation in operating systems; applied to RTB, it serves an analogous purpose: ensuring that a finite resource (campaign budget) is allocated across multiple concurrent processes (bidders) without any single process causing the total to be exceeded.

The banker ensures optimal distribution of limited resources across multiple bidders. It allows several bidders to receive and respond to bid requests simultaneously while preventing collective overspend.

MongoDB was used as the backing database, providing the reliability and throughput characteristics needed to support high-frequency allocation requests.

How the Banker Works

The diagram below shows the role the banker plays within a DSP and how it interacts with other components.

Ad Banker — Step by Step

• The publisher sends an ad request to an SSP/ad exchange.
• The SSP/ad exchange sends a bid request to the DSP's bidder.
• If the bid matches a campaign, the bidder requests resources from the cashier — a subcomponent of the banker — to place a bid (e.g. $1.05 CPM).
• If resources are available for the campaign, the banker allocates them to the bidder. Notably, the banker may allocate slightly more than requested, to cover anticipated future auction activity.
• With resources confirmed, the bidder sends back a bid response and ad markup.
• Assuming the DSP wins, the SSP/ad exchange forwards the ad markup to the publisher.
• The publisher loads the ad markup and requests the creative from the DSP's ad server.
• The ad server delivers the creative to the publisher, where it is shown to the user.
• The ad markup sends a request to the tracker with impression and click data.
• The tracker informs the banker that an impression has been served and the budget is updated accordingly. If the tracker does not confirm the event within a set time window, the allocated resources are treated as unspent and released back into the available pool.
• The tracker updates frequency capping conditions.
• The tracker sends event data to the campaign reporting database.

The key mechanism here is the pre-allocation model: resources are reserved before bid confirmation arrives, rather than updated after impression data is received. This inverts the standard DSP flow and removes the overspend window.

Benchmark Results

To evaluate the approach, several algorithm variants were tested. The results below are from initial benchmark testing.

Algorithm Descriptions

Naive — no banker capabilities: Assumes the entire budget is available for bidding at all times because impression confirmations haven't yet updated the budget. This represents the baseline DSP implementation without spend controls.

Banker with 1-minute reservations: Allocations released by the banker cannot be reused within the first minute of release.

…releasing the earliest reservation on impression and …releasing the reservation from the proper bid time: These variants differ in how impressions are attributed back to the banker's reservations — affecting how quickly freed budget becomes available for reuse.

Note: These tests were conducted using the as-soon-as-possible (ASAP) budget distribution model. A different model — such as a pacing model — would produce different overspend ratios.

Interpreting the Results

Spend ratios represent how much of a campaign's budget was spent by a given algorithm. An ideal spend ratio of 1.0 means exactly 100% of the budget was spent — no more, no less.

The naive algorithm (no banker) produced a maximum overspend ratio of 1.372. On a $10,000 campaign budget, that translates to $3,720 in overspend — a 37.2% excess.

The most optimized banker implementation — Banker5 — achieved a spend ratio of 1.012, representing just 1.2% overspend.

A Note on Zero Percent Overspending

While the goal is to minimize overspend as much as possible, achieving 0% overspend is impractical without accepting meaningful underspend. This is a structural reality of RTB systems: traffic fluctuates, creative types vary, and there are inherent delays in receiving win notifications and impression confirmations. A 1.2% overspend threshold is a realistic and operationally acceptable target for most DSP deployments.

The banker pattern — pre-allocating budget resources before bid confirmation, with a timed release for unconfirmed impressions — provides a practical and well-grounded mechanism for bringing overspend under control in high-throughput programmatic environments.