ssp

SSP to DSP Cookie Syncing Explained

The matching process of the SSP cookie ID to the DSP cookie ID happens through a parallel process to serving ads called cookie syncing. A cookie sync is necessary because as a standard security process, web servers of any kind can only request cookies that are set to their own domain. Since the SSP sits between the end-user and all the DSP bidders in a real-time auction however, the DSP needs a way to identify the users it is looking for.

Why Cookie Syncing is Necessary

So let’s take a simple example on a store trying to retarget their users. Let’s say that you run storeABC, and user123 drops in and adds a pair of $150 shoes to their shopping cart, but never makes it to the checkout. You want to retarget that user and serve them an ad directing them back to your store to try and close the sale. Since you work with DSP456, you have a 1×1 pixel sitting on your shopping cart page, which forces the user to call out to DSP456′s web server as they load the shopping cart page, giving DSP456 a chance to drop a cookie on user123. That cookie ID is DSPcookie789. Now, user123 is surfing around the web, and lands on awesomesite.com, which is using SSP123 to monetize their ad inventory. awesomesite.com serves a 3rd party redirect to SSP123, which drops a cookie on user123. That cookie ID is SSPcookieXYZ. SSP123 now requests a bid from DSP456 among other bidders for the impression that SSPcookieXYZ is about to view. But wait, how does DSP456 know that SSPcookieXYZ = DSPcookie789? On this first ad, it doesn’t, so your DSP doesn’t bid on the impression. Bummer. Remember, the SSP can only read and pass its own cookie ID to bidders.

Piggyback Scripts Power Cookie Syncs

After SSP123 selects a winning bidder though, it runs one last piece of javascript that forces user123 to call out to a handful of regular bidders, including DSP456. In that redirect, using a query string, the SSP passes its cookie ID on user123 (SSPcookieXYZ). Now the user IS calling DSP456′s web server and the DSP can request its own cookie from user123 in a process the industry refers to as “piggybacking”. Eureka! SSPcookieXYZ also has DSPcookie789 – it’s user123! The DSP knows the SSP’s cookie ID because of the query string in the piggyback call, and it can read its own cookie ID because that user called its web server as the end destination with the piggyback call. DSP456 now writes into its database that DSPcookie789 = SSPcookieXYZ for bid requests from SSP123. The next time user123 hits a page that SSP123 is helping to monetize, DSP456 will know it is the same user that abandoned their shopping cart and can bid appropriately. The process repeats for sites using other SSPs.

It sounds complex, but all it means is that for every ad served through RTB, about 10x as many technology companies are involved in the cookie-sync process. The reason the syncing process occurs after the auction happens and not before it is because of latency and user experience. If user123 had to call 10 DSPs, wait for those DSPs to cookie their machine, write the matching SSP id into their database, and then bid, it would dramatically slow down the entire auction process for everyone. If the cookie sync fails on the other hand, well there will be many more opportunities for that.

Cookie Syncing Step-by-Step

Below is a simplified diagram of the cookie sync process, where user123 visits the Marketer’s website first (1), is then redirected to the Marketer’s DSP (2), calls the Marketer’s DSP (3), receives the DSP’s cookie (4) and is simultaneously redirected to various SSPs that the DSP is cookie syncing with (5).  When the user calls those SSPs, the call passes DSP456’s cookie ID on that user in a key value parameter.  The process completes when the DSP456’s ID is logged in the match table for each SSP, and receives the SSP’s cookie in return.

 

cookie syncing

As an interesting post-script to this, the SSP might redirect the user back to DSP if the DSP is hosting the match table instead of the SSP.  This would be the same process as 4 / 5, just in the reverse order, with the SSP passing its ID to the DSP so the DSP can log both IDs in its own match table.  Who hosts the match table is a commercial arrangement that DSPs and SSPs / Exchanges make with each other, with the match table host typically paid to shoulder the cost of maintaining the database.

Example Cookie Sync Scripts

If you are interested, here are the URL’s that run the piggyback script for each major SSP – these pages look blank, so you’ll have to ‘view source’ to see the code.
Pubmatic: http://ads.pubmatic.com/AdServer/js/syncuppixels.html It looks as though ‘vcode’ is the item passing the cookie ID.
Rubicon Project: http://tap2-cdn.rubiconproject.com/partner/scripts/rubicon/emily.html It looks as though ‘nid’ is the item passing the cookie ID.

SSPs, aka Supply Side Platforms

Supply Side Platforms, or SSPs as they are commonly known in the digital advertising community, are an emerging category of technology companies that are in the business of optimizing various types of advertising demand for publishers, including demand from traditional ad network as well as the newly-minted ad exchanges using real-time bidding.  Doubleclick AdX (formerly Admeld), Appnexus, and Rubicon Project are the largest and most commonly used Supply Side Platforms, though OpenX, Index Exchange (formerly Casale), PubMatic, Sovrn and others provide similar services.

Supply Side Platform Benefits

Publishers use Supply Side Platforms for three primary purposes:

  1. To bring unsold inventory to many ad exchange markets at once
  2. To manage the complexity of ad network relationships
  3. To provide a suite of tools and reports on both sets of demand.

By using a supply side platform to represent their inventory on an ad exchange, publishers are able to sell their impressions to the highest bidder, and access thousands of new advertisers that might not ever buy from the publisher directly.  The idea for publishers is that the more sources of potential advertisers, the more revenue they can make.  Ad exchanges also make it easy to sell a variable amount of inventory at any time to a long tail of thousands of advertisers.  Because machines instead of people handle every transaction, a publisher can just as easily sell 5 impressions to a small mom and pop shop as they can 5,000,000 impressions to a global brand.

In terms of network demand, Supply Side Platforms provide a programmatic way to deal with ever-changing network fill rates and yields.  For example, many publisher have a variety of ad network buying their inventory, but are in a situation where one network will pay a $2.00 CPM but only fill 20% of the time, another network will pay $1.00 CPM and fill 70% of the time, and a final network that will only pay $0.50 but fill 100% of the time.  Each ad network might also have requirements like maximums per day, only want impressions from specific geographies, and may have different levels of latency or discrepancies.  Instead of trying to manually figure out which order is best, SSPs provide technology that predicts which network will provide the highest effective yield when all factors are considered and then constantly adjusts which tag serves on a regular basis, usually every few minutes.  This solution limits latency, increases yield, and takes a huge burden off ad operations teams.  In fact, before the days of ad exchanges and real time buying, SSPs were called Network Optimizers and dealt exclusively with managing Ad Network relationships that the publisher already had.

Key Supply Side Platform Features

Supply Side Platforms are constantly expanding their capabilities, but at their core should provide a few key services.

  • Access to multiple sources of supply: Any publisher could easily sell their inventory on an ad exchange, but SSPs add value by connecting a publisher to a broader set of demand and auction the same impression across multiple ad networks and to buyers across on multiple ad exchanges simultaneously.
  • The ability to block certain advertisers from buying their inventory:  Publishers may not want to let certain advertisers buy their inventory for a variety of reasons – perhaps the site is family friendly and doesn’t want ads for beer & liquor companies, or wants to ensure their competitors can’t place ads on their site.  Supply Side Platforms should enforce these rules and preferences on the auction process.
  • The ability to set price floors: While the second price auction theoretically provides an efficient market and encourages advertisers to bid truthfully, in some cases the publisher may want to enforce higher prices on a particular buyer.  For example, a publisher might want to ensure that their existing customers can’t buy them more cheaply through an exchange than directly.
  • A suite of reports to enable the publisher to see who is bidding, what they are paying, and how much they are buying: reporting is a key for any SSP to understand who values their inventory, and what it is worth on the open market.
  • Knowledgeable service & support staff: the ad exchange ecosystem is a complex one, and publishers would do well to put a high premium on partnering with a platform that has the time and talent on staff to help advise them on how to approach this emerging market in a way that fits their overall business needs.

How Real Time Bidding, DSPs, SSPs, and Ad Exchanges Work

Let’s say you’re online one day and decide to do a little shoe shopping. You navigate to your favorite store, check out a pair of boots, add something to your cart and just as you’re about to checkout, the phone rings and you get distracted.  By the time you’re done talking to your friend, it’s late and you decide to buy the shoes later.

Then, the next day, you check to see who won the big game last night and you notice an ad from the shoe store you were on last night.  Not only is it an ad for the store, but the exact pair of boots you were looking at are in the ad!  Weird.  You decide to check your email and see that your mom sent you a link to a news article. You go to read the article and staring you in the face on the page is another ad for the same pair of boots, this time tempting you with a 10% discount!

How did the ads know you were shopping for shoes last night, and how did they wind up on all those different sites?  The answer is, probably through an ad exchange.

Ad Exchanges have been around for a few years, but have exploded in importance in the last year.  Along with Demand Side Platforms (DSPs) and Supply Side Platforms (SSPs), Ad Exchanges are dramatically changing the way digital media is bought and sold. If you are a digital marketer or publisher, it is a very exciting time to be working in the industry.

What makes these companies so innovative is how they allow buyers and sellers to value inventory on an impression by impression basis and in real-time.  That’s right, real time.  That means that when you clicked on your mom’s link to the news article and your browser requested an ad from the news site, the publisher put that ad up for auction on an exchange, marketers bid on that impression, and it was served to your browser in about 250 milliseconds, so fast it was indistinguishable from the time it took any other image on the page to render.  Welcome to the world of real-time bidding, or RTB, where marketers value each impression as it is created and the Ad Exchange is where it all happens.

From a technical perspective though, how does the ad exchange process differ from regular ol’ third-party adserving?  I’ll answer that question and diagram the process in my next post, similar to what I showed you in my diagram for how third-party ad serving works.