Author: Ben Kneen

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.

History of the Ad Exchange Landscape Part II: Network Fragmentation and the Ad Ops Problem

In Part I of this series, I talked about the Rise of the Ad Networks, and how publisher ad space was commoditized by inventory aggregators known as Ad Networks.  Part II talks about the start of network fragmentation and the technical and operational challenges this caused for publishers.

Part II: Network Fragmentation and the Ad Ops Problem

As the networks fragmented, Ops teams had to add more and more redirect chains to force users through, and created a reporting nightmare for themselves.  Here’s basically what happened – with one ad network, you trafficked a third party tag to that network, and also gave the network a tag back to your site.  The reason being is that no ad network would pay for an unlimited amount of impressions on a CPM basis, so if there was a traffic spike and the network denied, or defaulted on the impression, they had to have a way to send the user back to the publisher ad server so the publisher could figure out something else to serve.  That something else was usually another ad network tag, and the process repeated until the ad was filled.  For a browser, each call to an ad server might take 20 – 50ms, which seems fast, but if the publisher had three ads on a page and the code was written in-line, meaning each ad has to finish loading before the rest of the page content to load, once you start to pass three or four ad calls per tag, the page starts to feel sluggish to a user.  Keep redirecting that user and sooner or later, the ads don’t have time to finish loading before the user moves to the next page, which causes a discrepancy between the publisher and the network, not to mention a lousy experience for users on the publisher’s website.  The publisher thinks an ad was served, but the network’s ad never finished loading.  Ad server reports grew less accurate because the same impression could be counted multiple times as networks sent a user back to the publisher, inflating the numbers and throwing a wrench in any inventory forecasts as well.  Not only that, but from an Ops perspective, the more unsold inventory there was, the more relationships were necessary with ad networks to fill the inventory. Yikes!

The result was a complex and inefficient setups in the publisher’s ad server, with lots of redirects strung together to pass a user from ad network to ad network until one was willing to serve an impression.  All this caused page latency, a lousy user experience, high ad server discrepancies, a billing nightmare, and an accelerating erosion of publisher ad sales.

In other words, it was a huge business opportunity – enter the Network Optimizer, ancestor of the Supply Side Platform.

Next – History of the Ad Exchange Landscape Part III: Network Optimizers to the Rescue (?)

History of the Ad Exchange Landscape Part I: Rise of the Ad Networks

In this new series of articles, I will try to explain the current landscape of digital advertising as it relates to remnant monetization from the publisher perspective.  Specifically, this series covers how publishers have sought to cope with a ever-fragmenting marketplace of remnant buyers and the upstart technology companies built to help them.  I think for anyone trying to understand the current marketplace of technology vendors, data companies, and yield optimizers, it helps to know the history.

Part I: Rise of the Ad Networks

Since most major publishers can rarely sell more than a fraction of the available ad inventory on their site with a direct sales team, they historically sold off whatever was left over to a handful of ad networks, or tried to monetize the unsold space with performance-based advertising, like Google AdSense.  This pile of unsold inventory was typically sold off at fire-sale prices, as little as 5 or 10% of what the publisher might charge for the exact same ad space on a direct buy from an ad agency.  Who bought it?  Well an advertiser eventually bought it, but through a type of company called an ad network.  Ad Networks were initially setup to aggregate a number of publishers together in order to provide advertisers with low cost ads that could reach a lot of people and had very aggressive ROI goals.  Basically, they were built for direct response advertisers who were trying to sell something.  While it seemed like a good idea at the time for publishers to hand off this inventory to a network – some revenue was better than no revenue, right? – this practice started to catch up with publishers.  Agencies decided that prices were so much cheaper on networks, and the quality was pretty much the same, they could get more bang for their buck by moving more of their budgets to the ad networks, including for brand advertisers, the bread and butter of publisher sales teams.  From the publisher perspective ad networks were supposed to help monetize their inventory, but ended up cannibalizing the efforts of their sales team instead.

It was great for the networks, publishers desperately needed them to monetize their unsold inventory, and the network could change a huge margin and still be much cheaper than buying from the publisher directly.  And even though technically networks were supposed to aggregate a few publishers together to dilute the value of the ad placement, there was so much inventory available that they didn’t really need to, especially if they could charge an advertiser a bit more money to run them exclusively to one site versus a handful.  The best part was you didn’t really need any infrastructure to start an ad network, just someone to call a bunch of publishers to aggregate some cheap inventory, and someone to call a bunch of advertisers, trying to sell that inventory.  It was easy!  So easy in fact that a few hundred sprang up over the course of just a few years.  Competition drives specialization, and that’s exactly what the networks did – they started to specialize in various levels of ad quality or audiences to differentiate themselves in the marketplace, and of course, maintain their high margins.

Read More –  History of the Ad Exchange Landscape Part II: Network Fragmentation and the Ad Ops Problem

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.

AdOps Guide – Pulling 3rd Party Ad Server Reports with Daily Breakouts

Pulling 3rd Party reports is one of the key reporting needs of any publisher ad operations group, unfortunately the publisher-facing reporting interface of most 3rd party ad servers isn’t terribly intuitive.  It can be particularly difficult to extract the daily breakout, which is key to troubleshoot discrepancy or implementation issues, and usually a required attachment to any official ticket to the ad server support team.

Often times, without being able to look at a daily breakout, it is difficult to understand if a large variance in delivery between a publisher’s ad server and an advertiser’s ad server has been a problem from the very start of the campaign, or perhaps only at a certain date when new creative was added, or perhaps when the publisher added a site release.

Therefore, I’ve created a guide below on how to build a report in the major 3rd party ad servers that provide a daily breakout of delivery.

This post covers how to pull a report showing delivery by day from the following 3rd party ad servers: DART for Publishers, Atlas DMT, Pointroll, Eyeblaster / MediaMind, Mediaplex, and Eyewonder.  I will update with others as I am able and if this post turns out to be helpful.

In DART –

Go to ‘Report Central

Select ‘Queries’

Under ‘Create New Queries’ select ‘Single Advertiser’

Select an Advertiser

Under ‘Main Criteria’ select ‘Daily’ in the ‘Breakdown’ section.

Under ‘Main Criteria’ add ‘Date’ as a selected field, along with any other fields you require, such as Advertiser / Placement / Campaign Name / etc.

Run the report

Creating a daily breakout in the DART Publisher interface

In Atlas –

Note: Atlas’s UI only functions in Internet Explorer.

Things are a bit easier in the Atlas UI – there is a canned report that will likely suffice.

Select ‘Publisher Reports’

Select ‘Publisher Daily Summary Without Subtotals’. Be sure to select this report and not the one above it labeled ‘Publisher Daily Summary’, which exports the data in a format that is difficult to manipulate any further in excel.

Run the report

Creating a daily breakout report in the Atlas Publisher Interface

In Pointroll –

Select ‘Analyze’

Select ‘Reports’

Select ‘New’

Select ‘User Defined’

Select your time frame and relevant metrics

Under ‘Aggregations’, move ‘Daily’ into the ‘Selected Aggregations‘ column, along with any other items you require

Select ‘Run‘ and On the ‘Run Report Options’ pop-up, select ‘Flat Data’ if you plan to manipulate the data in Excel with a pivot table, etc.

Creating a daily breakout in the Pointroll Publisher Interface

In Eyeblaster / MediaMind –

Note: Daily breakouts are only available in MediaMind on a campaign-specific basis, and only 45 days at a time.

Select ‘Analytics’

Select ‘Delivery Analysis’ from the ‘Analytics Reports’ section

Under ‘Data Resolution’ select ‘Days’

Run the report

Creating a daily breakout report in the Eyeblaster / MediaMind Publisher Interface

In MediaPlex –

About as easy as it comes, since there is only one report available to publishers.

Select ‘Reports’

Select ‘Site Delivery’

Under ‘Time’, select ‘date’

Run the reportCreating a daily report in Mediaplex MOJO Adserver

In Eyewonder –

Eyewonder’s reporting system looks complex, but really isn’t that difficult to use.

Select ‘Custom’

Under ‘Reporting Criteria’ select ‘Impressions’

Under ‘Breakdown Criteria’ select ‘By Date Range’, and then select ‘Breakdown by Day’ from the drop-down menu

Run the report

Creating a daily breakout in Eyewonder's Publisher Reporting Interface