Ad Banker Case Study

How Impression Tracking Works in Most DSPs

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

Step-by-step explanation:

1. The publisher sends an ad request to an SSP/ad exchange.
2. The SSP/ad exchange then sends a bid request to the DSP’s bidder.
3. If the bid matches a campaign in the DSP, the bidder sends back a bid (e.g. $1.05 CPM) and ad markup.
4. Assuming the DSP wins the impression, the SSP/ad exchange sends the DSP’s ad markup to the publisher.
5. The publisher loads the ad markup and sends a request to retrieve the creative (ad).
6. The ad server sends the creative to the publisher and displays it to the user.
7. The tracker records data about the impression and click (if applicable).
8. The tracker sends information about the impression to update the frequency capping conditions.
9. The tracker sends event data to the campaign reporting database, which will be used to generate reports.

With this setup, there’s no proper and efficient way to manage the budget, meaning overspending will occur.

The Solution

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.

How It Works

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:

1. The publisher sends an ad request to an SSP/ad exchange.
2. The SSP/ad exchange then sends a bid request to the DSP’s bidder.
3. If the bid matches a campaign in the DSP, then the bidder asks the cashier (a component of the banker) for resources to place a bid (e.g. $1.05 CPM).
4. If there are resources available for the given campaign, the banker gives them to the bidder, which actually gives more resources than bidder requested for use in future auctions.
5. If the bidder receives the resources from the banker, it sends back a bid response and ad markup.
6. Assuming the DSP wins the impression, the SSP/ad exchange sends the DSP’s ad markup to the publisher.
7. The publisher loads the ad markup and sends a request to the DSP’s ad server (either an internal or external one).
8. The ad server sends the creative to the publisher and displays it to the user.
9. The ad markup sends a request to the tracker with data about the impression and click (if applicable).
10. The tracker informs the banker that an impression has been served and the budget is updated. If the tracker doesn't inform the banker about the event within set time range, the resources are considered as not spent.
11. The tracker sends information about the impression to update the frequency capping conditions.
12. The tracker sends event data to the campaign reporting database, which will be used to generate reports.

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.

System Requirements for Using Ad Banker

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:

1. Integration with the bidder

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.

2. Trackers have to communicate with cashiers to confirm spending

When an event (impression, conversion, etc.) is tracked, the tracker should send a request with the spent volume to the cashier’s API endpoint.

3. Information about the budget needs to go to the banker

Budgets have to be initialised using banker's REST API.

Results From Benchmark Tests

To test the performance of the ad banker, we created different algorithms

What do the algorithm descriptions mean?

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.

How to interpret the results

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.

A note about 0% overspending

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.