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.
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.
http://ads.pubmatic.com/AdServer/js/syncuppixels.html It looks as though vcode is the item passing the cookie ID.
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.