What is cookie syncing, and why does it matter to a media buyer?
Part of Supply path transparency
The short answer
Cookie syncing is the process by which one ad platform learns another platform's user ID for the same browser. A sync pixel loads, the first party reads its own cookie, then redirects the browser to the second party with that ID attached. One side stores the pair in a match table and uses it later in bid requests.
Key takeaways
- Cookies belong to one domain, so an exchange and a DSP cannot read each other's IDs without a sync step in the browser.
- The result of a sync shows up in the OpenRTB bid request as buyeruid, or as an extended ID whose match method value 2 means browser cookie sync.
- Sync pixels fire in the reader's browser, so they add requests to the page and pass an identifier to each partner that receives one.
- Where third party cookies are blocked, the partner cannot read or keep its cookie, so no match forms.
What is cookie syncing in programmatic advertising?
Definition
- Cookie syncing
- IAB Tech Lab's OpenRTB 2.6 appendix defines it as "the process by which one party learns another party's user IDs". It is also called user syncing, user matching or cookie matching.
The need comes from how browsers scope cookies. Google's Authorized Buyers cookie matching guide (opens in a new tab) (updated September 17, 2026) says the security model of browsers "restricts one from reading a cookie set by another domain." So when an exchange sends a bid request, the DSP cannot tell that the exchange's ID for that browser belongs to the browser its own pixel saw on an advertiser's site last week.
Syncing bridges the two ID spaces. The OpenRTB 2.6 specification (opens in a new tab), in Appendix C, says one party keeps a match table "that knows that cookieID123 from party A is the same user as cookieID789 from party B." Classically, Tech Lab says, syncs run between DSPs and exchanges or SSPs, and between DSPs and data management platforms.
How does a cookie sync work, step by step?
The exchange hosted flow in OpenRTB 2.6 Appendix C
- Swap sync URLs. The DSP gives the exchange its sync URL; the exchange returns a match URL with a slot for the DSP's ID.
- Load the DSP pixel. The exchange causes it to load in a browser, for example while serving an ad.
- Redirect with the ID. The DSP reads its cookie and answers with a 302 redirect to the match URL, ID filled in.
- Store the pair. The exchange reads its own cookie on arrival and records both IDs.
- Use it in bidding. Later requests to that DSP carry the DSP's ID in buyeruid when the exchange's cookie is present.
Google's guide describes the same mechanics: a 302 redirect to the bidder's matching URL, and a bidder that "must always respond by serving a 1x1 invisible pixel image" or an empty 204 answer. Endpoints must use HTTPS, and a hosted entry "may be considered expired in 14 days."
Who holds the match table, the exchange or the DSP?
Either side can. OpenRTB 2.6 says the exchange holds it most commonly between DSPs and exchanges, "but it can be done either way." The choice changes which field a buyer reads. Google also offers hosted match data, letting a bidder store up to 40 bytes against the Google user ID.
| Model | How the pair is formed | What the bid request carries | Strength | Weakness |
|---|---|---|---|---|
| Exchange hosted | DSP pixel redirects to the exchange with the DSP's ID | The DSP's own ID in user.buyeruid | The DSP can act on the ID without a lookup | The exchange stores a table for each DSP it works with |
| DSP hosted | Exchange pixel redirects to the DSP with the exchange's ID | The exchange's ID in user.id; the DSP looks up its own | The DSP keeps control of its own table | The DSP must run a server side store and a lookup on each request |
In the specification, user.id is the "Exchange-specific ID for the user," and buyeruid is the "Buyer-specific ID for the user as mapped by the exchange for the buyer," expected to be "derived from an ID sync" unless buyer and seller arranged otherwise.
Why do ad platforms sync cookies at all?
Because buyer data is keyed to buyer IDs. A DSP's segments, frequency caps and conversion records are stored against the IDs its pixels set. OpenRTB 2.6 says that once the exchange sends the DSP's ID, the DSP "acts on it for audience targeting, frequency capping, measurement, etc."
That is why the specification pushes for coverage: fire sync pixels at "all available opportunities," have both parties fire them, and refresh a match before it expires, with retention of "some period of time like 14 to 60 days." Google's Ads Data Hub cookie matching page (opens in a new tab) (updated April 30, 2026) cautions that "Match rates are often lower than users expect," and says cookie matching "is no longer supported as part of Ads Data Hub onboarding," while existing setups keep working.
How does cookie syncing affect page speed and privacy?
On speed, the specification is direct: "Sync pixels fire in the user's browser, and thus sync activity creates overhead when web pages load." It suggests non blocking loading, such as a hidden iframe, and rotating "up to 5 partners on each occasion." Prebid.js, the open source header bidding wrapper, builds in the same caution: its userSync settings (opens in a new tab) by default wait 3,000 milliseconds after the auction, allow each bidder up to five image syncs and leave iframe syncs off, so ad cookie work can run after content loads.
Each sync also hands an identifier to another company. In a paper presented at The Web Conference 2019 (opens in a new tab), Papadopoulos, Kourtellis and Markatos studied a year of browsing logs from 850 mobile users: 97 percent of regular web users were exposed to cookie syncing, the median user ID leaked to 3.5 domains on average, and syncing raised the number of domains tracking a user by a factor of 6.75. It is a historical panel study, not a current market rate.
| Jurisdiction | What the regulator says | Source |
|---|---|---|
| Canada, federal | Information used for online behavioural advertising "will generally constitute personal information"; people must be told about "the various parties involved" | OPC guidelines on online behavioural advertising (opens in a new tab), modified August 11, 2025 |
| California | Sharing means sharing "for cross-context behavioral advertising"; consumers may opt out of selling or sharing, including "via a user-enabled global privacy control" | California Attorney General CCPA page (opens in a new tab), updated August 28, 2026 |
The OpenRTB appendix notes that parties pass consent strings such as GPP in sync URLs and may skip a sync when consent is unknown. See also US state privacy laws for advertising and PIPEDA and online advertising.
What happens to cookie syncing without third party cookies?
A sync depends on each party reading its own cookie while it is a third party on someone else's page. When the browser blocks third party cookies, the receiving domain cannot read or keep its ID, so no pair forms. WebKit announced on March 24, 2020 that in Safari "Cookies for cross-site resources are now blocked by default across the board," (opens in a new tab) and that its classifier keeps working to detect "bounce trackers, tracker collusion, and link decoration tracking." The wider planning picture is on cookieless advertising.
Chrome is a different case. Chrome did not remove third party cookies. On April 22, 2025 Google said (opens in a new tab) it would maintain its current approach to offering users third party cookie choice in Chrome and would not roll out a new standalone prompt. On October 17, 2025 it said (opens in a new tab) it would retire Privacy Sandbox technologies including Topics, Protected Audience and the Attribution Reporting API. No later Google announcement changed this as of October 2026. Chrome Help (opens in a new tab) says users can block third party cookies, and that Incognito blocks them by default, so Chrome syncs depend on settings.
What does a cookie sync review look like on a real plan?
Fictional example
A made to measure suit retailer in Missouri and Kansas
An unnamed online made to measure suit retailer in Kansas City sells to men in Missouri and Kansas, with fittings in St. Louis and Wichita. Its agency planned a retargeting line for past site visitors and a prospecting line on menswear, wedding and business news sites, and asked how the retargeting audience would reach bid requests.
After the DSP named its match methods, the planner split the budget: a contextual line from a site list that needs no ID, and an audience line limited to IDs whose match method the DSP could document. No performance figures are implied.
- Asked for sample bid requests showing whether buyeruid or eids were present on the retargeting line.
- Recorded the mm value for each extended ID and which party was the inserter.
- Kept the contextual line separate so it could run where no sync had formed.
Questions to put to a DSP or exchange about synced IDs
- Which party hosts the match table, and how long are entries kept before expiry?
- Which mm values appear on our audience line, and which inserter added each ID?
- How are consent strings and global privacy control signals handled before a sync fires?
- What share of our bid requests carried a buyeruid, measured from our own logs?
How does PlacementGraph build a plan that needs no synced ID?
Frequently asked questions
Is cookie syncing the same as an identity graph?
No. A sync joins two companies' cookie IDs for one browser through a redirect. An identity graph links many IDs, including across devices, using methods such as logins or inference. AdCOM lists these as separate match methods: value 2 for browser cookie sync, 3 for authenticated and 5 for inference.
Does cookie syncing happen in mobile apps?
Not in the browser sense. Apps have no third party cookie jar, so app requests carry other identifiers. AdCOM's value 1, No Match, covers an ID taken directly from the device's resettable advertising ID, and the UID atype field marks an ID as app native or browser based.
Can a publisher see which partners sync on its pages?
Yes, in part. Sync pixels are ordinary network requests, visible in the browser's developer tools. A publisher using Prebid.js also controls them through userSync settings: the delay, syncs per bidder, and whether image or iframe syncs are allowed.
Why does a DSP report a low match rate on an exchange?
Matches form only where both parties read their cookies in the same browser and the entry has not expired. Blocked third party cookies, rotated IDs and missing consent leave gaps. Google's Ads Data Hub page warns that match rates are often lower than users expect.
Sources
- OpenRTB 2.6 specification, Appendix C: Cookie Based ID Syncing (opens in a new tab)IAB Tech Lab
- AdCOM 1.0, List: ID Match Methods (opens in a new tab)IAB Tech Lab
- Cookie Matching (Real time bidding guide, updated September 17, 2026) (opens in a new tab)Google Authorized Buyers
- Cookie matching (updated April 30, 2026) (opens in a new tab)Google Ads Data Hub
- pbjs.setConfig: userSync (opens in a new tab)Prebid.org
- Cookie Synchronization: Everything You Always Wanted to Know But Were Afraid to Ask (opens in a new tab)Papadopoulos, Kourtellis and Markatos, The Web Conference 2019 (arXiv)
- Full Third-Party Cookie Blocking and More (March 24, 2020) (opens in a new tab)WebKit
- Next steps for Privacy Sandbox and tracking protections in Chrome (April 22, 2025) (opens in a new tab)Google Privacy Sandbox
- Update on plans for Privacy Sandbox technologies (October 17, 2025) (opens in a new tab)Google Privacy Sandbox
- Delete, allow and manage cookies in Chrome (opens in a new tab)Google Chrome Help
- Guidelines on privacy and online behavioural advertising (opens in a new tab)Office of the Privacy Commissioner of Canada
- California Consumer Privacy Act (CCPA) (opens in a new tab)California Department of Justice, Office of the Attorney General
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.