Cookie syncing

Each ad tech company sets its own third-party cookie with its own random ID, so a DSP and an SSP each know a browser by a different name. Cookie syncing links the two. When a page loads, one company's code redirects to the other's domain, passing its ID; the second company reads its own cookie and stores the pair in a match table.

Once synced, the SSP can include the DSP's ID in a bid request, and the DSP can recognise a user it wants to retarget or frequency cap. Header bidding wrappers like Prebid run many syncs on each page, which is one reason pages load dozens of tracking calls.

Cookie syncing has costs: it slows pages, leaks data to many parties, and match rates are never perfect, so each company only recognises part of the audience. It depends on third-party cookies and so does not work in Safari or Firefox by default. Newer approaches pass shared IDs, such as Unified ID 2.0 or other identity graph IDs, directly in the bid request's extended IDs field instead.

Think of it like this

Cookie syncing is like two shops agreeing that your membership number 123 at one is the same person as number 987 at the other, so they can compare notes.

An example

When a reader in Poland opens a news page, the SSP's code fires 25 sync pixels to DSPs; afterwards, 60% of DSPs can recognise that browser's ID in bid requests.