The matching process of the SSP cookie ID to the DSP cookie ID happens through a parallel process to serving ads called cookie-syncing. Cookie-syncing 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.
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.
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-synch process. The reason the synching 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 synch fails on the other hand, well there will be many more opportunities for that.
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.
Admeld appears to take a slightly different solution, passing a browser partner by partner with callbacks to Admeld on each run rather than calling out to a handful at once like the SSPs above. I’m not able to identify the logic here as easily, but they must accomplish the same end result.
This is great. Thanks for a detailed step-by-step explanation.
Could you expand on this statement:
“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″
So how exactly does that happen?
Thx
Hi Jason,
Basically speaking, the SSP’s tag is a chunk of JavaScript that in turn references other scripts. That’s pretty common with JS ad tags in general, actually – they usually have to do a few things to get the ad to work as designed. Sometimes they need to reference jQuery libraries, access browser plugins, compile information from other servers, reference cookies values, and a bunch of other things. Specific to the SSPs, the first sub-script usually redirects the user to the SSP’s server which starts the auction process. The last sub-script is a call which tells the browser to go call a bunch of other companies for the sake of cookie syncing users. For most browsers, this last script in practice may run more or less simultaneous to the auction / ad load, because by then, the browser has been redirected downstream to other parties and has moved on to the next part of the tag. Most modern browsers can keep 6 – 8 HTTP connections active at any given time, so once it executes the first sub-script, it starts following that path with some of the available connections and starts executing the next sub-script with others, depending on what else it has to load on the page.
Hope that makes sense –
Ben
Hi Ben,
Can one company be both SSP and DSP, then no syncing is necessary? Is it because of privacy concern?
Hi Wes,
No, no company plays both sides of the fence and is at once a DSP and an SSP. Google does own both types of companies – Invite Media is a DSP and Admeld is an SSP, but those companies still maintain separate cookie spaces on separate domains, so still need to cookie sync with one another. Their is no real privacy concern, the reason that there isn’t a DSP / SSP hybrid is because having both advertisers and publishers as a client on the same platform is a large conflict of interest – how would the platform represent both sides fairly – that if such a platform existed, I doubt they would have any customers. You wouldn’t hire a real estate agent to sell your house if they also represented the buyer, would you? Why would the agent have any incentive to get a fair market value for your house? For the same reason, DSPs and SSPs must stay as separate systems – many expect clients to abandon Admeld because of the conflict of interest for Google to represent both a buying and selling technology, but I can’t say I know that it’s actually happened in practice. As far as I know Google keeps those two companies very separate, and there’s no reason to think that Invite and Admeld don’t effectively operate as two separate, independent entities.
Ben
Thanks for the great explanation, just curious to know
1. Will DSP always have their code on advertiser website or there will be cases when the DSP cookie needs to be synched with advertiser’s cookie ?
2. As explained in your another post, DMP will have cookies synched with various 3rd party systems, now how will DMP integrate with DSP, will it require cookie synching ?
Hi Akhil,
To answer your questions –
1. There’s no reason I can see why an advertiser wouldn’t fire their DSP’s cookie at the same time they drop their own cookie for any users they want to target in the exchange. In some cases however, an advertiser may have offline data and work through a match partner and data management platform (DMP) to bring that data online to a cookie, in which case the DMP would need to sync with the DSP before those users would be active in the exchange. That’s a much less common use case however, and in that instance, the advertiser doesn’t really have a cookie in the classic sense, dropped from their own domain, but really reusing someone else’s cookie space for their own purposes.
2. Yes, DMPs integrate with DSPs through cookie syncing. A system to system sync only needs to happen once however, not once per system per client. Once the users are synced, the bridge benefits all the clients on both systems, who can move securely move proprietary data from one place to the other through a server to server integration.
Hope that helps –
Ben
Hi,
I am not sure I understand this:
“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”
- wouldn’t it be in the DSP’s favor to ‘fake’ the cookie match? Say for e.g. the DSP456 says that the DSPcookie999 = SSPcookieXYZ, then SSP has no way of knowing whether DSP has genuine match or not and it will have to favor DSP456 for the subsequent bids.
[here I am assuming that winning the bid matters the most to the DSP rather than winning the right bid, for the purpose of getting visibility or some other xyz reason...]
Hi Rohan,
It’s important to realize that the DSP and the SSP have a mutual benefit in syncing cookies – browsers only allow a cookie to be read by the domain from which it was set, meaning the SSP can only read its own cookie on a user, and can’t know if a DSP also has a cookie on that user. In the bid request then, the SSP can only show bidders its own cookie ID, it can’t provide the DSP’s cookie ID. So it’s critical then that the DSP have a way to know if it has a cookie on that user, and what it knows about that cookie, from the SSP’s cookie ID only. The way it does this is through the cookie syncing process.
To your question about faking the cookie match, though, the DSP doesn’t really have anything to gain in that scenario. It’s not as if the SSP knows anything meaningful about that user through the match, they just know if the user exists in the DSPs system, and vice versa. The cookie match simply facilitates the transaction. And the fact of the matter is that DSPs don’t bid more for un-synced cookies, they bid less, because they don’t know if they know anything about that user. Even if they were lying some of the time, in general, the DSP will likely bid less for unsynced users overall, so the SSP won’t favor them at all in that case. But again, there’s not much point – it’s far more important for the DSP to win the right bids than to simply win any bid, that’s the entire point of using a DSP. Otherwise, you could just use an ad network to buy as many impressions for the cheapest price possible, regardless of any knowledge about the user set.
Hope that clears things up –
Ben
Hi Ben,
What other information can be passed via an SSP ID to the DSP to add value in the bidding process. From your description, the cookie syncing only supports a binary decision from the DSP as to whether or not there is a DSP cookie on the users machine – yes or no. It is commonly referenced within the industry that publishers have a wealth of data points on their users, and the onus should be on the publishers to expose this data with a view to better monetizing their sites. With the above definition, all of the information used as the basis for the bidding decision is on the advertiser side; through the retargeting pixel. Is there any other information that can be passed via the SSP cookie which would give the bidders greater insight into the user and their behaviour, so for example; the segment IDs (and segment definitions) to which the user belongs as classified by the publisher or the SSP.
“you have a 1×1 pixel sitting on your shopping cart page”
Hello,
you mean embedded javascript right? not a real pixel ?
Ty
Franck
Hi Ty,
What I mean by that 1×1 pixel is basically, “you have a mechanism to track a conversion event” – that might manifest as a simple image tag for a transparent 1×1, or a piece of javascript may configure that conversion beacon call in some kind of dynamic fashion, or you may simply drop a cookie on that user through an image call. But whatever the specific technical execution, the point is the same, to track a conversion, and associate it to a specific user and that user’s other actions and touchpoints.
Ben