Glossary Term

Cookie Syncing

glossary cookie syncing featured

Cookie syncing is the process two ad tech platforms use to match their separate user IDs for the same browser. Browsers stop one domain from reading another domain’s cookies, so a demand-side platform and a supply-side platform each hold a different ID for the same person. Syncing builds a translation table between those IDs, and it is also called cookie matching or ID sync.

How the ID Sync Process Works

The sync happens through a chain of redirects that each platform reads as it passes. The mechanism is the same for any pair of partners.

  1. A user loads a page. The publisher’s page fires a tracking pixel belonging to the SSP.
  2. The SSP reads its own cookie. On its own domain, the SSP can see the ID it assigned this browser, for example SSP-9f3c1a.
  3. The SSP redirects to the partner. It sends the browser to the DSP’s sync endpoint with its own ID attached as a URL parameter.
  4. The DSP reads its own cookie. Now on the DSP’s domain, the DSP can see its own ID for this browser, for example DSP-44b7e2.
  5. The DSP stores the pair. It writes SSP-9f3c1a = DSP-44b7e2 into a match table and returns a 1×1 pixel.

From then on, the SSP sends its own ID in a bid request and the DSP looks up which of its users that means. The handoff looks like this:

https://ssp.example.com/sync?ssp_id=SSP-9f3c1a&redirect=https%3A%2F%2Fdsp.example.com%2Fsync%3Fssp_uid%3D

Nothing about the person moves in that call, only the two IDs. The profiles stay on each platform’s own servers, and the match table is what lets them be joined later.

Types of Cookie Sync

Three patterns dominate, and large platforms run all three.

  • Pixel sync (client-side). The classic redirect chain above, fired in the user’s browser. It works with any partner and requires no prior integration, but every hop costs load time.
  • Server-to-server sync. Two platforms exchange ID pairs in bulk over a direct backend connection. It avoids browser latency entirely, but both sides must already share a common anchor ID.
  • Centralized sync. One intermediary syncs with every partner on the publisher’s behalf and stores the results together. Prebid Server does this with a /cookie_sync endpoint that consolidates bidder IDs into a single uids cookie on the host domain.

Centralized sync exists because the alternative scales badly: 40 bidders means 40 redirect chains per page.

Match Rates and What They Cost

Match rate is the share of users a platform can identify in a partner’s ID space, and it decides whether a sync is worth running. Typical rates sit between 30% and 50%. Above 60% is considered strong.

The gap is expensive on both sides. An unmatched user means the DSP cannot recognize a retargeting audience member, so it bids low or not at all, and the publisher gets a worse price for the same impression.

Match rates also collapse by browser:

Browser Third-party cookie status Practical match rate
Chrome Allowed by default 30% to 60%
Safari Blocked by ITP Near zero
Firefox Blocked by ETP Near zero

Safari and Firefox users are not partially matched. They are invisible to the mechanism.

Why Cookie Syncing Is Ending

Cookie syncing depends on third-party cookies, and it fails wherever those are blocked. That decline is already well underway, though not for the reason most people expect.

Google did not remove third-party cookies from Chrome. It confirmed in July 2024 that it would not phase them out on a fixed deadline, and on 22 April 2025 it dropped even the standalone choice prompt. Cookies stay on by default. On 17 October 2025 Google announced the retirement of ten Privacy Sandbox APIs, including Topics, Protected Audience, and Attribution Reporting, citing low adoption. Chrome began deprecating them in version 144 in January 2026, with removal targeted for version 150 in July 2026.

So the pressure is not coming from Chrome. It is coming from three other directions:

  • Safari and Firefox already block it. Between them they account for a large share of consumer web traffic that syncing simply cannot reach.
  • Consent requirements did not change. GDPR and ePrivacy still require consent for third-party cookies, so a denied banner kills the sync regardless of browser.
  • Better replacements exist. Universal IDs such as UID2 give every platform the same hashed-email identifier from the start, so no translation table is needed.

Responses have split between login-based universal IDs, server-side tracking, and probabilistic device fingerprinting.

Cookie Sync vs Server-Side Tracking

These solve different problems and are often confused. Cookie syncing reconciles identities between two separate companies. Server-side tracking moves your own data collection from the browser to your own infrastructure.

Server-side tracking does not restore cross-company matching. It protects first-party measurement from ad blockers and browser restrictions, a narrower and more durable goal. Campaign parameters survive all of it, because they travel in the link rather than in a cookie. Link analytics records the click server-side at redirect time, before any cookie policy applies.

Frequently Asked Questions

What is cookie syncing?

Cookie syncing is how two ad tech platforms work out that their separate user IDs refer to the same browser. Each platform can only read cookies on its own domain, so they exchange IDs through a redirect chain and store the pair in a match table.

What is cookie matching in adtech?

Cookie matching is the same process as cookie syncing, and the two terms are used interchangeably. Google Ad Manager and Display and Video 360 use “cookie matching” in their documentation, while SSPs and header bidding vendors more often say “cookie sync” or “user sync”. All refer to mapping one platform’s user ID to another’s.

Does cookie syncing share personal data?

The sync call itself carries only two pseudonymous IDs, not names or email addresses. The concern is what the match table enables afterwards: two companies can join the profiles they hold separately. Princeton’s 1-million-site study by Steven Englehardt and Arvind Narayanan found that 157 of the top 200 third parties sync cookies with at least one other party, and that syncing let colluding parties reconstruct 62% to 73% of a user’s browsing history.

Is cookie syncing bad for site speed?

Yes. Each redirect hop adds roughly 50 to 200 milliseconds, and a page running many bidders can fire dozens of sync chains at once. A Redbud study of 68 news and magazine sites across the UK, Germany, and France found third-party redirects added substantial load time and up to 0.8 MB of transfer, about the weight of a 15-second video ad.

What replaces cookie syncing?

Universal IDs such as UID2 are the main replacement, since a shared hashed-email identifier removes the need for any translation table. Server-side integrations, publisher-provided IDs, and identity resolution inside a customer data platform cover the rest. For campaign measurement, URL parameters remain the most reliable signal, since they do not depend on any cookie.

Tag your campaign links so attribution survives cookie loss, using the free UTM builder at linkutm.

Back to Glossary