Download now, read later
Download the full version of our ad banker case studyDOWNLOAD PDF NOW
One of our AdTech development teams completed an internal research and development project where we aimed to reduce overspending in a DSP when buying impressions during real-time bidding (RTB) auctions.
We called this component ad banker and made it part of our AdTech Foundations — a series of essential components used to build AdTech and MarTech platforms.
Controlling an advertiser’s media spend is a major component of any demand-side platform (DSP). If it’s not managed correctly, you’ll either underspend or overspend — both of which disadvantage advertisers.
While underspending means that an advertiser’s campaign doesn’t achieve the right amount of reach, overspending can cause big problems for both the DSP vendor — they’ll likely have to cover the costs — and the advertiser — they would have wasted their opportunity to show ads to their target audience.
On any given web page, there may be half a dozen or so ad slots. Each ad slot, once loaded, will send an ad request to the publisher’s ad server, which in turn will send a request to an SSP/ad exchange and then on to multiple DSPs.
Once the DSPs receive the bid request, they have to return a bid response, typically within 250ms.
This process occurs billions of times per day across the Internet.
Due to the extremely tight time frames, DSPs need to ensure that their advertisers’ budgets are being managed correctly.
There’s typically a several second delay between the time a bidder responds to a bid request and when the DSP receives information that the impression has been displayed. This delay can cause the bidder to overspend when there are multiple bidders handling large amounts of traffic (i.e. bid requests).
Diagram #1: How most DSPs handle impression tracking
With this setup, there’s no proper and efficient way to manage the budget, meaning overspending will occur.
To highlight how overspending can occur, let’s take a look at 3 examples:
When creating a campaign in a DSP, advertisers and AdOps specify the targeting parameters, such as location, device type, and ad size.
If the targeting is too broad, then the bidder will match a large number of bid requests to the campaign. This can occur simultaneously or within a few milliseconds of each other.
While broad targeting isn’t typically an issue, without a proper budget management system, the bidder will likely overspend the budget as it won’t be notified about the winning impressions, and therefore can’t update the budget, until after the impression has been served.
If a DSP is integrated with a DOOH platform whereby advertisers show their ads on digital billboards, then, depending on numerous factors such as the DOOH platform’s setup and media-buying process, there could be a lengthy delay in receiving information that an advertiser’s ad has been displayed.
The delay can range from 15 minutes to 48 hours, in which case you cannot accurately track budget spend.
Due to the location of the DSP, there are some situations where the DSPs bidder and spending will be located in the same region as the SSP/ad exchange (e.g. AWS region us-east-1).
However, there may also be situations where different DSP components (e.g. bidder and spending database) will be located in different regions.
Because of the latency between different data centers, it’s possible that the DSP will overspend a budget unless a proper budget management component is added.
To avoid overspending with online advertising campaigns, we built a budget manager called banker. It’s based on Edsger W. Dijkstra’s banker’s algorithm.
The banker is used to ensure optimal distribution of limited resources (budget) between multiple processes (bidders). It allows several bidders to receive and respond to bid requests at the same time and avoid budget overspending.
The diagram below illustrates the role the banker plays and how it interacts with other components.
You can see here the flow from the example shown above (Diagram #1) in the broader context of a DSP. Implementing the banker into a DSP changes the flow, which now looks as follows:
Diagram #2: The role the banker plays and how it interacts with other components in a DSP.
Here's a step-by-step explanation of what's happening in the image:
Each campaign has its own budget, which is set or updated using the banker REST API.
After a resource request from the bidder is sent to the cashier’s REST API, part of the budget is deducted and kept in the system as a reservation, which are managed by the bidder.
The DSP then tracks future budget spend (via the trackers) and pushes data to the banker via its REST API.
Each resource requested by the bidder is multiplied by a set value in the cashier and the reservation with multiplied values is returned to the bidder to use in the future (e.g. the bidder needs $1 to bid and it gets a $10 reservation from the cashier).
The goal of this feature is to reserve a certain number of resources (budget) for use in multiple future auctions.
Multiplying values is an easily configured setting (it's set to 10 by default). This feature was implemented to limit traffic between bidders and cashiers.
The budget allows both ASAP and Even budget distribution.
ASAP budget distribution aims to spend the budget quickly. The banker can give the bidder as much traffic as requested, but no more than the total available budget volume of a campaign, target group, line item, etc., at any one time.
Even budget distribution aims to spend the budget evenly over the campaign’s flight dates. The banker calculates the pace at which the budget should be spent. The time left for each campaign is calculated every minute. With each reservation request, the banker determines if the requested amount fits in the pacing limits.
Dayparting is an addition to the budget distribution feature. It allows advertisers to show their ads at certain times of the day and on certain days of the week, but is managed by the bidder rather than the banker — the banker uses information about dayparting to distribute the budget evenly.
As we’re a software development company that builds DSPs from scratch and expands existing DSPs, we developed the banker with compatibility in mind.
There are really only a few areas and requirements to consider when implementing the banker to a new or existing DSP:
The bidder has to understand and handle reservations.
When the bidder receives a bid request, it should send a reservation request to cashier's REST API with the required resources volume.
It has to keep track of how many resources have already been spent in its reservations. If the bidder receives more reservations than requested, it should spend all it has, before requesting more, and it has to be aware of the time — if a reservation has expired, it should be deleted.
When an event (impression, conversion, etc.) is tracked, the tracker should send a request with the spent volume to the cashier’s API endpoint.
Budgets have to be initialised using banker's REST API.
To test the performance of the ad banker, we created different algorithms
|Naive||An algorithm with no banker capabilities.|
|Banker1||Banker with 1 minute reservations, releasing the earliest reservation on impression.|
|Banker5||Banker with 5 minute reservations, releasing earliest reservation on impression.|
|BankerR1||Banker with 1 minute reservations, releasing the reservation from the proper bid time.|
|BankerR5||Banker with 5 minute reservations, releasing the reservation from the proper bid time.|
Naive. An algorithm with no banker capabilities: It assumes that the whole budget is available for bidding as it hasn’t yet received impression requests, and therefore hasn’t updated the budget.
Banker with 1 minute reservations: This means that the reservation from the banker cannot be used again within the first minute of being released.
...releasing the earliest reservation on impression and ...releasing the reservation from the proper bid time: This refers to how we attribute the impressions to the banker’s reservations.
NOTE: The above tests were carried out using the as-soon-as-possible (ASAP) budget distribution model. The results would vary if a different model was used, such as the pacing model.
The spend ratios represent how much of a campaign’s budget was spent by the given algorithms.
The ideal spend ratio is 1, which represents 100% of a campaign’s budget being spent.
We can see that the naive algorithm’s maximum overspend was 1.372, which for a $10,000 budget would translate into an overspend of $3,720.
The table below represents the amount of budget overspend each algorithm produced during the testing phase.
|Algorithm||Maximum overspend of a $10,000 budget (lowest to highest)|
Although the goal of the banker is to reduce overspending by as much as possible, with Banker5 getting overspending down to just 1.2%, achieving 0% overspending is unlikely without considerable underspending.
This is a common situation among real-time bidding (RTB) platforms due to fluctuations in traffic, the creative type, and the delays in receiving win or impression notices.
Contact our team and find out how our ad banker can help your DSP reduce budget overspend.Contact our team