Diagramming the SSP, DSP, and RTB Redirect Path

Diagram of the Ad Exchange Redirect Process

I wrote about the basics of how DSPs, SSPs, and Ad Exchanges work from a high level and the value they add to the marketplace in my last post – for this piece we’re going to dig into the nitty gritty of how they work from a technical perspective.

In my explanation of third-party ad serving, I outlined a 12-step process to get from publisher ad call to marketer ad creative.  In an Exchange environment the process is basically the same, but with three new parties involved: the SSP, the DSP, and the Ad Exchange itself, which all act as the ad selector, instead of the publisher’s ad server.

You can view a diagram of the ad serving process at the top of this post – the numbers in the text refer to the steps labeled in the diagram.

When a browser navigates to a publisher website (1), the publisher’s web server sends back a bunch of HTML code (2) that tells the browser where to get the content (3) and how to format it.  Part of the HTML code returned to the browser (4) will include a coded link known as an ad tag.  That part is the same as in regular third-party ad serving.  But instead of returning a DFA or Atlas tag, the Publisher Ad server will return a tag that points to a RTB-enabled SSP, typically through a dynamic Javascript tag that passes information like the publisher’s ID, the site ID, and ad slot dimensions.

From there, the user calls the SSP server (5) where the SSP reads that user’s SSP cookie ID, likely already on their machine.  Assuming the user already has that SSP’s cookie on their machine (and most users will, given that the largest SSPs boast 80 – 90% reach rates to the US internet population), the SSP starts the auction (6), by requesting bids from a host of demand sources, the DSPs (7).  If the user does not have an SSP cookie on their machine, their ad inventory can technically still be auctioned, but since nothing is know about that user, the price will be very low and more related to the site context than the user’s attributes.  For the DSPs to truly value the impression though, they need to know something about the user that is going to see it.  This is where the SSP cookie ID comes in – packaged with the bid request is the SSP’s cookie ID, along with the url the impression will deliver on, and what the current user’s frequency is on the site.

All these factors help the DSP value the impression.  First, through a rather complex cookie-synching process, DSPs are able to match the SSP’s cookie ID to their own cookie on that user, which is tied to a huge cache of marketer data and 3rd party data.  What kind of 3rd party data?  Using the cookie ID, the DSP will be able to know if that user recently priced out a car, is flying to Paris in the next 90 days, was recently shopping for shoes, and even more general demographic information about the user such as their age, gender, income range, credit score, and much, much more.  I’ll cover how that all works in a later post.  But suffice to say, rich data is far and away the driver of higher bids, and the cookie ID is the mechanism through which data is associated to a user.

In addition to the cookie though, where the ad will appear, the URL, is also important.  Many brands don’t want their ads to appear on just any site, even if they want that user.  If the user is on a site with PG-13 content, for example, the advertiser might bid a lower amount or not at all.  Similarly, the frequency of that user to the site they are on is also important to valuation.  Advertisers are willing to pay a premium to reach users on their first or second pageview on a site vs. their 50th pageview for the simple fact that users are less engaged with site content and more likely to respond to an ad during their first few pageviews.

Using those pieces of data, the DSPs all value that impression and submit a bid back to the SSP (8) as well an ad redirect to send the user should their bid win the auction.  The SSP picks the winning bid (9) and passes the DSP’s redirect back to the user (10).  From here the process is basically the same as third party ad serving – The user calls the DSP (11), the DSP sends the user the marketer’s ad server redirect (12), and user calls the marketer’s ad server (13) and the marketer serves the user the final ad (14).  Whew!