Cookie Syncs


Cookie syncs have a disproportionate impact on the ad tech ecosystem. In this Lift Letter, we discuss what they are, why they're so important, and how they will influence the future.


Cookies are little pieces of data that are stored by the browser on each user's computer - this is primarily a web concept, so don't think about apps too much for this Lift Letter. Cookies have information like the name of the cookie, the value, the time it should expire, and the domain that it belongs to. A sample might be of the form:

name: important_secret_security_token
value: 1x8ibenuteb

When a browser sends any request to, it will send the cookies that belong to that it stores (there can be multiple cookies for any domain). It is essential to the security of the modern web that the cookies not go to any other domain - otherwise the server that is at that other domain could fake requests. Meaning of user A logged into its bank, site X, and site X uses cookies to save the login information - if the browser sent the cookies for user A and site X to site Y, then site Y could pretend to be user A and steal all of A's money. This is pretty obviously not good, so browsers will only ever send cookies for the appropriate domains.

TripleLift works with dozens of DSPs. Each DSP has its own system for assigning user IDs so it can do things like frequency cap the number of times it serves an ad to a user. For example, Turn might use, and assign user A the ID of 123. TripleLift uses and assigns the same user the ID of 456. 

When user A goes to a partner site, the TripleLift tag is called by the browser. This makes a call to - so the TripleLift cookie that's stored on the user's browser is sent, meaning TripleLift gets the ID of 456. The bid request that is subsequently made from TripleLift to Turn is done server-to-server, meaning the user's browser is not part of the request-response process. Turn's cookie is not sent to, because it belongs to a different domain. As a result, without some way of coordinating user IDs TripleLift would be unable to send Turn its user ID. 

To address this issue, ad tech companies have cookie syncs. This is a process whereby pixels and redirects are used to enable a sharing of information that is saved in cookies, but is also known to be safe to share - and helps coordinate IDs across domains. In the 3lift / Turn example above, TripleLift and Turn would have an offline process to sync pixel formats. Every time TripleLift sees a user, it could drop a user-sync pixel of the following form:$UID

The pixel request would be sent with the cookies for that domain by the browser. The server at is programmed to understand that this is a cookie sync request. The first part of the request:

tells the server that it's a URL that will redirect for cookies. Then it should look at everything that comes after the following question mark and redirect to that URL. In this case, that is:$UID

But before the redirect, the Turn server will replace the $UID with its user ID for that user. So the redirect would be to:

To be more specific, the Turn server response - instead of the contents of the pixel - uses an HTTP code 302 that effectively says "the content that you wanted isn't here, it's actually over here." This is a redirect. So the browser would send the new request to with the 3lift cookies, and now the value that was in the Turn cookie for the user ID is sent to 3lift. 

TripleLift receives this request and can see that, for the DSP turn, their user ID is 123. TripleLift saves that internally knowing that - because it got the request with its cookies that identified this user as 456, that the Turn ID for that user is 123. The next time TripleLift receives a request for user 456, it will lookup all the DSP IDs that has performed user syncs for, and see that the Turn user ID is 123, so this ID will be sent in the request to Turn. User syncs are performed widely throughout the ecosystem, including SSPs, DSPs, DMPs, and more. Apple's Safari has made this relatively challenging on both iOS and on Macs when the user uses Safari. 

The order in which user syncs are done may make a significant difference. Cookies expire over time, and they're sometimes intentionally deleted. Thus it isn't the case that DSPs and SSPs will eventually reach full mappings. The order in which DSPs and SSPs drop each others' pixels matter. If there's a new user, each DSP that we haven't synced with is a DSP that won't bid on that user for the particular impression. Thus it's important to align the highest spending partners first in the order for user syncs. 

For header bidding, as it moves server side, cookie syncing is also important. The SSP needs to know the user ID from the server-side header bidding platform, and thus it's one more layer of cookie syncing that must be performed. It is generally understood that there is some degradation of user mapping with each additional hop. Thus as client-side header bidding moves server side, the SSPs will have a reduced ability to monetize some percentage of their users. For this reason, publishers are resistant to move all partners server side, and instead are looking to a hybrid of top partners client side and others server side (though this will have the effect of reinforcing which partners are top performers).

One idea that has been floated to help with the idea of cookie matching and reducing syncs is to have a single canonical user ID. This means that each SSP would only sync with one third party to get their ID, and each DSP would use the same 3rd party ID. This single ID third-party system was at the core of the people-based programmatic advertising consortium ( when it was announced. Unfortunately, this didn't have much behind it at the time it was launched. That said, if the fees are reasonable, it's very possible that this will materially help when it starts to take off.