Cookie syncing is a process that enables all members of an ad transaction on desktop or mobile web to have a common understanding of who they are targeting. Cookie syncing ensures that SSPs, DMPs, DSPs, and all ad tech partners can match up the users they have in their separate databases so that custom-tailored ads specific to each user can be delivered.
What are cookies?
Cookies are small text files that are created by your browser and stored on your computer as you browse the web. Websites that you visit coordinate the creation of cookies and use them to power many core functions that you expect of a modern website.
When it comes to cookies, there are two main types you need to be aware of: first-party and third-party.
First-party cookies are created by the websites that you intentionally visit. These are the websites with their domain present in your address bar. If you visit “yourfavoriteblog.com”, any first-party cookie created by that site would be under the “yourfavoriteblog.com” domain.
First-party cookies remember logins or enable shopping carts. Nobody has a problem with first-party cookies, they are totally cool and the usability of the Internet would suffer without them
Now, this is where things get a bit dicey. Third-party cookies, also sometimes referred to as “trackers” are created by companies who want to track you wherever you go on the web, most typically, advertisers. They are called “third-party cookies” because even though they are created on a domain you visited (like “yourfavoriteblog.com”) they are created under a “third-party” domain like “adtracker.com”. This is because yourfavoriteblog.com runs code on their website that allows third-party advertisers to create these cookies that are stored on your computer.
Third-party cookies are the “bad” cookies that you may have heard about. Some major browsers like Firefox and Safari block these cookies by default to preserve your privacy. Since these cookies are used to track you around the web without your knowledge, most people consider this an invasion of privacy. But like them or not, they are the current backbone of the advanced digital advertising economy that powers the free media of the open web.
Cookies are the best way to track user activity on desktop or mobile web. There is no other mechanism (except browser fingerprinting, but major privacy concerns there) that can identify a user from a web browser. On our mobile and connected TV devices, we have individual identifiers like IDFA on Apple devices and GAID on Android, but cookies are the best thing advertisers have on the good ol’ fashioned web. But why do advertisers care about your online activity?
Chances are you have visited an online store at one point and added some items to your cart, but ultimately decided not to checkout. You then go about your week online and start reading an article on your favorite blog or news website a few days later — let’s just stick with yourfavoriteblog.com. You click around and read a few different articles, then you see an ad nested next to a news article for an item you added to your shopping cart earlier in the week. How do they know!? Cookies.
When you visited that online store, a cookie was dropped by the DSP used by the store to help them increase the number of paying customers. That cookie contained an individual “User ID” that the DSP stores along with data on which items of the store you viewed and if you eventually checked out.
When yourfavoriteblog.com’s SSP loads an ad next to the article you are reading or before a video you play, the SSP makes a bid request to the store’s DSP containing their user ID for you (also sometimes referred to as a “buyer ID”). But how did the SSP know the DSP’s user ID value for you? Because the SSP and DSP cookie synced.
Cookie syncing explained
Like most of ad tech, the process of cookie syncing isn’t completely straightforward. The relationships of who is syncing with who and how the sync is executed can vary. SSPs can sync with DSPs and DSPs can sync with DMPs and DMPs can sync with SSPs and so on.
I’m going to detail below how an SSP would sync with a DSP but all the acronyms could just as easily be swapped around. I’m going to explain a simplistic way of cookie syncing and also another method that involves a series of redirects. I will refer to them as “single partner simple sync” and “multi-partner redirect sync”.
Single Partner Simple Sync
When you initially navigate to yourfavoriteblog.com, ad slots load on the site that make calls to their SSP. The calls to the SSP allow them to drop a cookie on your browser containing their user ID for you and also return a cookie sync pixel from their DSP partner that is called by code executed on the web page. Cookie sync pixels are typically an invisible image with a width and height of 1 pixel by 1 pixel - hence why it is called a “pixel”.
Loading this pixel allows the DSP to drop a cookie on your browser containing their User ID for you. When the DSP’s cookie sync pixel is called, they then redirect that call to an endpoint provided by the SSP that allows the DSP to pass their ID for that user in a query string parameter to the SSP. The endpoint typically looks something like this:
Where [buyer_id] would be the SSPs internal id for the DSP and [user_id] would be the DSPs ID for that user.
The SSP then reads their cookie for that user, and stores their user ID alongside the DSPs user ID in what is called a “match table”. The next time the SSP makes a bid request to the DSP, they can first read their cookie, look up if they have a matched user for the DSP in the match table, and if so, the SSP will send the DSPs buyer ID in the outgoing bid request to the DSP.
Are you confused yet? Maybe a nice picture will help:
- An ad request is made to the SSP from the browser
- The SSP is then able to cookie the user (or read an existing cookie) and return the DSP sync pixel
- The DSP cookie sync pixel is called from the browser
- The DSP cookies the user and then redirects to the SSP cookie sync endpoint to pass along their ID for the user
It is important to note that all cookies created by the SSP and DSP in this process are third-party cookies since they will be created under those platforms’ domains rather than the domain of the site the user is currently visiting (yourfavoriteblog.com). This whole process cannot take place on browsers that block third-party cookies.
Multi-Partner Redirect Sync
The previous sync process was initiated from an initial ad request made to the SSP. However, cookie syncing can live outside of the ad request process. The SSP can give the partner a cookie sync pixel to load on any page whether there are ads or not. They can also cookie sync across multiple DSP partners by implementing a series of redirects.
Check out the graphic below and the following explanation to understand how this process can work:
- SSP cookie sync pixel is called
- The SSP is then able to cookie the user (or read an existing cookie) and returns DSP1’s sync pixel
- DSP1 cookie sync pixel is called from the browser
- DSP1 cookies the user and then redirects to the SSP cookie sync endpoint to pass along their ID for the user. SSP stores DSP1 user id in the match table.
- SSP redirects to DSP2’s cookie sync pixel
- DSP2 cookies the user and then redirects to the SSP cookie sync endpoint to pass along their ID for the user. SSP stores DSP2 user id in the match table.
- Repeat for remaining DSP partners
Through this series of redirects, the SSP can sync with multiple DSP partners. The concern for the publisher here is that page load time increases with each DSP partner added to the sync process and they may want to limit the number of third-parties tracking their users.
Cookie syncing continues to serve as the primary method for ad tech partners to have a shared understanding of identity across desktop and mobile web. Without cookie syncing, the targeting capabilities of advertisers would be severely limited. Targeting based on demographics, browsing history and interests would be all but impossible in the current ad tech ecosystem.
Photo by Nick Brunner on Unsplash