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.
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-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.
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.
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.
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.