How to Integrate a DSP with Ad Exchanges and SSPs

When you hear most people in the online advertising world talk about integrating a demand-side platform (DSP) with an ad exchange or supply-side platform (SSP), they make it sound as if it’s a matter of connecting the platforms together via a cable.

In reality, integrating a DSP with other AdTech platforms is a meticulous technological process that can take anywhere from two to three development sprints (that’s four to six weeks).

Why Do DSPs Need to Integrate With Ad Exchanges and SSPs?

Demand-side platforms play a key role in helping advertisers (brands) and ad agencies run online media campaigns. They provide a number of features to help them create, run, measure, and optimize campaigns across different mediums (e.g. laptops and mobile devices) and channels, such as display, video, and native.

However, in order to achieve all of this, they need to connect to other advertising-technology (AdTech) platforms to purchase the available ad space (aka inventory) from publishers.

The most common way for DSPs to buy available ad space on websites and apps is via real-time bidding (RTB). The RTB process is a live auction whereby DSPs bid on impressions offered by ad exchanges and supply-side platforms (SSPs).

We’ve explained what RTB is and how it works in a previous post.

Without integrating with an ad exchange or SSP (or other inventory suppliers), a demand-side platform wouldn’t be able to purchase online advertising.

How the DSP Integration Process Works

Each DSP company will approach the integration process differently, but there are essentially three main phases.

Here’s a brief overview of what would typically be carried out during the DSP integration phases:

Phase 1: Research and Setup

The initial phase of DSP integration involves the following:

• Analyzing the documentation provided by the ad exchange or SSP and consulting with their team to determine the target OpenRTB version, identify any custom extensions the ad exchange/SSP may have, and get answers to questions arising from the documentation.
• Discovering if the ad exchanges and SSPs have any specific business requirements for obtaining a seat, such as a minimum monthly account spend.
• Researching the proposed ad exchange or SSP to find out what kinds of ad-quality standards they have, e.g. which creative categories they accept.
• Participating in the SSP/ad exchange’s quality requirements, which typically consists of conducting an audit on the creative or specific content category.
• Determining the communication protocol used as some SSPs/ad exchanges provide their own protocol apart from OpenRTB.
• Determining if the current budget-control component will be sufficient for the integration. Sometimes a loose (aka naive) budget control will be enough with win notifications/impressions arriving within a few seconds after the bid, but with an increase in volume and for notifications that arrive even minutes after the bid, a strict (aka banker) budget-control component is typically required.
• Deciding whether the creatives (ads) will be delivered by the bidder in the bid responses or from a external ad server.

This initial phase typically requires one sprint (two weeks) to complete.

Phase 2: Development and Implementation

The second phase of DSP integration involves development and implementation, which includes the following:

• Making changes to the DSP’s bidder to ensure it’s compatible with the ad exchanges’ and SSPs’ versions of the OpenRTB protocol and any custom arrangements (e.g. additional information passed in the bid request).
• Building an ad server or setting up the external ad server to serve the creatives.
• Adjusting the request path and bid-request implementation for the given ad exchange or SSP.
• Building out a map to match the ad exchange’s and SSP’s content categories (there are often additional ones) to the DSP’s.
• Defining the billing and reporting methods to ensure the campaign’s budget is spent and reported on correctly and that its performance is shown as soon as possible.

Phase 2 generally takes two sprints (four weeks) to complete.

Phase 3: Testing the Integration

The last phase is all about testing out the new integration, usually with a small amount of traffic, and involves the following:

• Analyzing the performance and speed of the bid requests between the platforms to ensure the DSP isn’t constantly being timed out.
• Regularly working on lowering the reporting and billing discrepancies between the DSP and ad exchanges/SSPs. In the initial testing phase, achieving a 10% discrepancy (recommended by the IAB) is the desired goal, but we would constantly optimize the trackers to lower the discrepancies over time.

The actual testing phase takes around one sprint (two weeks) to complete.

Phase 4: Post-Integration

Once the integration is complete, it’s now a matter of maintaining the integration, which can include:

• Making changes to the integration when APIs and the OpenRTB version are updated.
• Optimizing the reporting and billing trackers to lower the discrepancies between the DSP and SSP/ad exchange.

While the above overview of a DSP integration with a SSP or ad exchange may make sense to a seasoned AdTech professional, the actual technical process requires knowledge of the inner workings of the online-advertising ecosystem and years of development experience.

About Clearcode

Clearcode is a full-service software-development company that specializes in AdTech and MarTech.

Since 2009, we’ve partnered with brands, agencies, and vendors to build new platforms from scratch and integrate existing platforms with other components in the online advertising ecosystem.

This article was written with the help of Clearcode’s experienced DSP developers.