Cookie Sync and Match Rate: The Bid-Rate Lever Most Exchanges Ignore

Take two bid requests leaving your exchange for the same DSP. Same page, same ad slot, same country, same floor. The only difference is one field: the first carries a buyeruid — the DSP’s own identifier for this user, learned through a sync your platform performed weeks ago. The second carries nothing.

Watch what happens on the other side. For the matched request, the DSP resolves the ID against its own data: this user sits in three retargeting segments, has frequency history, converted on a similar campaign last month. Retargeting line items qualify, caps can be enforced, and the DSP bids from the budgets that pay the most — retargeting spend exists precisely to reach a known user again.

For the anonymous request, none of that machinery engages. Every line item targeting an audience segment fails eligibility — as far as the DSP is concerned, this user does not exist. Campaigns that cap frequency must choose between not bidding and risking a violation, and the cautious ones do not bid. What remains is broad prospecting demand, bidding on context alone, usually at a discount that prices in everything the DSP cannot see.

Your auction was identical in both cases. The difference in what came back was decided before the auction started, by whether your identity plumbing had done its job.

That is the thesis of this article: match rate is an auction input, not a plumbing detail. An exchange with broken sync can run a perfect auction and watch demand ignore it. If you have worked through our guide to setting up an RTB exchange, you will recognize the shape of the argument — bid rate is the metric everyone watches, and identity is the lever hiding behind it.

Table of Contents

• What is match rate, and why does an unmatched request earn less?
• How cookie sync actually works
• Why match tables rot
• Pixel sync versus server-side sync
• What actually happened to third-party cookies?
• Safari and Firefox are the rehearsal
• Alternative IDs: mechanisms and trade-offs
• Passing identity through the bid request
• What an exchange should actually build
• The consent boundary
• Key takeaways
• Running identity on Floxis
• Sources worth bookmarking

What is match rate, and why does an unmatched request earn less?

Match rate is the share of bid requests you send to a demand partner that carry an identifier that partner recognizes — classically a buyeruid resolved from your sync table, increasingly an entry in the eids array the partner has agreed to read. It is a per-partner number, not a platform number: the same request can be matched for one DSP and anonymous for another, because each match comes from a separate sync relationship. A platform-wide “70% matched” can decompose into one DSP at 95% and another at 15%, and the second one is quietly bidding on a fraction of what you send it.

An unmatched request earns less because of eligibility, not sentiment. A DSP’s spend is organized into campaigns, and the highest-value campaign types — retargeting, audience extension, frequency-managed brand buys, conversion-optimized performance spend — all require the DSP to recognize the user before a bid is considered. No recognition, no eligibility; no eligibility, no bid. So low match rate shows up twice: as lower bid rate, because fewer campaigns qualify per request, and as lower bid prices, because the contextual prospecting that remains spends cautiously on users it cannot value.

Resist the urge to quote an industry number for how much less. You can measure your own: segment bid rate and average bid price by matched versus unmatched, per partner, over a week of your own traffic. That number is the business case for everything else in this article, and the only version a demand partner will accept in a conversation about QPS.

How cookie sync actually works

The problem cookie sync solves is domain isolation. Browsers scope cookies to the domain that set them: your exchange can read its own cookie on yourexchange.com requests, a DSP can read its own on dsp.com requests, and neither can read the other’s. Both platforms may know the same user under two different names, with no way to discover the correspondence — and buyeruid requires exactly that correspondence.

The sync mechanism is a redirect chain that lets both parties observe the same browser within one request sequence. OpenRTB’s Appendix C documents the canonical form. With the exchange hosting the match table:

1. The DSP gives you its sync URL — https://ads.dsp.example/sync?exchange=29. You give the DSP your match endpoint with a slot for its user ID: https://sync.yourexchange.com/match?dsp=12&dsp_uid=<ID>.
2. Your platform gets the DSP’s sync pixel into a browser — on an ad you serve, or a page where you have a tag.
3. The pixel request hits the DSP’s server. The DSP reads its cookie for this browser (or sets a fresh one) and answers with a 302 redirect to your match endpoint, its user ID substituted into the slot.
4. The browser follows the redirect to your domain, where you can read your cookie for the same browser. You now hold both names for one user: yours from the cookie, the DSP’s from the query string.
5. You write the pair into your match table, with a timestamp.

From then on, the bid path uses the table: request arrives, you read your cookie, look up the entry for DSP 12, and put the DSP’s ID in buyeruid on the outbound request. The whole apparatus exists to fill that one field.

The table can live on either side. In the DSP-hosted variant the redirect flows the other way — your ID is handed to the DSP, you send your own user.id in the bid request, and the DSP does the lookup. Partners arrive with their preference fixed, so be prepared for both. Exchange-hosted costs you storage and a lookup on the bid path; DSP-hosted costs nothing at bid time but leaves you blind to your own match rate unless you track sync completions independently.

Note what the mechanism requires: a browser touch, once per user per partner, before any of this exists. That requirement is where the operational pain lives.

Why match tables rot

A match table entry is a claim about the world — “this browser is DSP 12’s user X” — and the world moves. Sync is a maintenance loop, not a setup task, and the decay is structural:

• Cookie churn. Users clear cookies, switch browsers, buy new devices, browse privately. Each event silently invalidates entries on one or both sides.
• Partner-side resets. The DSP’s ID for a user is not permanent either. When a partner rotates IDs, your stored mapping points at nothing, and you find out only if you watch match rate rather than table size.
• New traffic arrives unmatched. Every first-time visitor is unmatched with every partner by definition. Growing supply with a static sync operation means falling match rate.
• Browser policy. In Safari and Firefox, the third-party cookie mechanism the redirect chain rides on is blocked or partitioned outright — more below — so pixel sync cannot create entries for those users at all.

The consequences: give every entry a TTL and evict on it, because traffic “matched” on dead entries is worse than honest anonymity — the DSP discards the stale ID and learns to distrust the field. Re-sync continuously rather than in campaigns; every served impression is a sync opportunity. And watch the rate, not the table: table size is an asset count, match rate on live outbound traffic is the truth.

Pixel sync versus server-side sync

“Server-side sync” means different things in different sales decks, so it is worth being precise about what each mode is and what it costs you.

Pixel sync is the redirect chain above, executed in the user’s browser. Its virtue is universality: no shared key, works with any partner that can serve a 302, bootstraps identity from nothing but a browser session. Its costs are real: every partner sync is another request in the user’s browser, so a supply partner hosting your tags pays page-weight and latency for your match table, your match rate is capped by your pixel footprint, and the whole mechanism rides on third-party cookies — it simply does not run in Safari or Firefox.

Server-side sync moves the exchange-side work off the browser. The honest version of the claim: the matching happens server-to-server, but identity still has to enter the system somewhere, so server-side sync works from an identifier that is already durable — a publisher’s first-party ID, a hashed email, an ID vendor’s envelope — and resolves it against partner IDs over server calls rather than redirect chains. Once the key exists, there is no page weight, no per-partner browser fan-out, and no dependence on a third-party cookie surviving.

The practical answer is not either-or. Pixel sync still earns its keep on Chrome traffic, where third-party cookies remain live; server-side sync reaches what pixel sync cannot, and stops taxing your publishers’ pages for your plumbing. Run both, and know per partner which mechanism produced each match — when match rate moves, you will need to know which one moved.

What actually happened to third-party cookies?

Short answer, as of early 2026: third-party cookies are still on by default in Chrome, the deprecation is officially abandoned, and the replacement APIs Google spent six years building have been mostly retired. If you stopped following the saga somewhere around “Google delays cookie deprecation again,” here is the verified sequence.

Google announced in 2020 that Chrome would phase third-party cookies out, and spent four years postponing the date. In July 2024 the plan changed shape — deprecation was dropped in favor of a proposed user-choice prompt. Then in April 2025, Google announced it would not ship that prompt either: “we’ve made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies.” Users can still block third-party cookies in Chrome’s settings, and Incognito blocks them by default — but the default in regular browsing remains on.

In October 2025, Google went further and retired most of the Privacy Sandbox itself. Attribution Reporting, Topics, Protected Audience, Private Aggregation, Shared Storage and Related Website Sets are all on the discontinued list, with Google citing adoption levels and ecosystem feedback. Three technologies survive — CHIPS, FedCM and Private State Tokens — and it is worth noting that CHIPS is partitioned cookies, deliberately scoped so they cannot serve cross-site identity. The surviving pieces do not replace cookie sync; they were never meant to.

Two operator takeaways, held at once. First: cookie sync is not legacy plumbing you can skip. It runs, today, on the browser carrying the majority of web traffic, with no announced end date. Second: do not mistake the reprieve for stability. The deprecation scare permanently changed the demand side — every serious independent DSP built alternative-ID support, and Safari and Firefox never re-opened. The cookie half of your identity stack is load-bearing and eroding at the same time, which is why the alternative-ID half exists. And since this situation has reversed itself three times in three years: if you are reading this far from its publication date, verify against Google’s own announcements before repeating any of it.

Safari and Firefox are the rehearsal

You do not have to speculate about what a cookieless world does to an exchange, because you already operate in two of them.

Safari has blocked third-party cookies outright since March 2020, when Intelligent Tracking Prevention moved to full blocking — in WebKit’s words, “cookies for cross-site resources are now blocked by default across the board.” Firefox reached a similar end by a different mechanism: Total Cookie Protection, default since June 2022, confines every third-party cookie to a per-site “cookie jar.” The DSP’s cookie set while the user was on site A is not the cookie visible from site B, so the redirect chain completes and produces a match that means nothing across sites. Blocked or partitioned, the operational result is identical: pixel sync produces no usable match on this traffic.

That makes your Safari and Firefox traffic a running experiment with the control group built in. Segment bid rate and clearing prices by browser family, per demand partner, and you are looking at your own measured cost of anonymity — no industry study required. The same cut shows where alternative IDs earn their keep: a partner whose Safari bid rate rises once you pass a publisher’s authenticated ID is actually reading the eids array; one sitting at the anonymous baseline is telling you something too, whatever its integration docs say.

Alternative IDs: mechanisms and trade-offs

The alternative-ID ecosystem exists because the industry spent five years expecting cookies to die. The result is a set of identifiers that do not depend on third-party cookies, each with a different mechanism and coverage profile. What follows describes how they work — which ones belong in your stack is a per-partner, per-market question your own match-rate data should answer, not this article.

Three structural observations hold across all of them. The deterministic ones share a bottleneck — authentication: UID2 and RampID are only mintable where a user handed over an email or logged in, so before evaluating either, find out what fraction of your own supply is authenticated. An ID nobody reads is dead weight: each identifier is only worth carrying if the partner on the other end has an agreement with its source and actually resolves it — the OpenRTB spec is explicit that exchanges should ensure business agreements permit sending this data, so ask each DSP which sources it bids on, then verify with the browser-segmented measurement above. And these are consent-bearing identifiers, not consent workarounds: an ID built from a hashed email is personal data under GDPR by any reasonable reading. Alternative IDs move you off the third-party cookie; they do not move you past the consent boundary below.

Passing identity through the bid request

Everything your platform knows about a user is worthless to demand until it is on the wire, and OpenRTB gives you three places to put it.

user.id is your own identifier for the user. user.buyeruid is the receiving DSP’s identifier, resolved from your match table — necessarily different per demand partner, so the same auction fans out with a different buyeruid on each outbound request. These two fields are the cookie-sync payoff, and also its limit: one exchange ID, one buyer ID, nothing else.

The eids array is where the rest of the identity stack travels. Each entry names a source — the canonical domain of the ID’s issuer — and carries one or more uids, each with the identifier itself and an atype declaring what kind of agent it identifies. In OpenRTB 2.5 the array lives in user.ext.eids; OpenRTB 2.6 promotes it to a first-class user.eids field and adds provenance attributes — inserter, matcher and the match-method code mm — so a buyer can see not just the ID but who attached it and how it was matched.

The operator’s rules for this surface are short. Pass through the eids your supply sends, intact — publishers and their wrappers populate identity upstream of you, and an exchange that strips it destroys value in transit. Append what you resolve yourself, with your own domain as inserter where the 2.6 provenance fields apply. Send each partner only the sources it has an agreement to receive. And never fabricate: an invented ID or a knowingly expired mapping is provenance fraud once it is in the array, and buyers audit this surface precisely because it moves money.

What an exchange should actually build

Stripped to the load-bearing parts, an exchange-side identity stack is four components and a discipline.

Sync endpoints, both directions. A match endpoint that accepts a partner’s user ID in the query string, reads or sets your own cookie, validates the partner identifier against your integration registry, and writes the pair to the match table — plus the ability to fire partner sync URLs with your ID substituted, for DSP-hosted tables. Two hard requirements. Every sync URL in either direction must carry the consent parameters — gdpr, gdpr_consent, GPP — per the IAB specifications; a sync chain that drops them mid-redirect makes everyone downstream non-compliant. And treat the endpoint as hostile-input surface: it is a public, unauthenticated GET that writes to your data store and issues redirects, which makes an unvalidated redirect parameter an open-redirect vulnerability wearing your domain’s reputation. The edge-hardening logic from our ad fraud prevention guide applies — validate, rate-limit per source, log rejections with reasons.

A match table built for the bid path. The lookup happens inside the auction clock, on every request, for every partner you fan out to — the same rule as floor lookups: in-memory, single-digit milliseconds, no database round trip. Key it on your user ID, store per-partner entries with timestamps, evict on TTL, and size it as entries times partners, because that product grows faster than either factor. This table is your ID bridge; when you add alternative IDs, the same structure maps your ID to eids sources as well as to per-DSP cookie matches.

Request-time population. At fan-out, fill buyeruid per partner from the table, attach the eids you are entitled to send, and pass through what supply provided. The failure mode is silent: a broken lookup does not error, it just sends anonymous requests, and the only symptom is a bid-rate sag you will misattribute to demand.

Per-partner match-rate telemetry. The metric is the share of outbound requests per partner carrying a usable identifier, graphed next to that partner’s bid rate. This pairing is the point of the whole build: when bid rate falls, ask which of the two moved first. Match rate fell first — your sync decayed, a pixel stopped firing, a TTL purge outran re-syncing. Bid rate fell alone — the cause is on the partner’s side, and you have just saved a week of debugging the wrong layer. Alert on match-rate deltas per partner against their own baseline, exactly as you alert on bid-to-win discrepancy.

The discipline is prioritization. Browser touches are scarce — you cannot fire every partner’s pixel on every impression without taxing your publishers’ pages — so sync effort should follow demand value: the partners whose matched bids pay the most get synced first and re-synced most aggressively. That turns sync from an indiscriminate pixel spray into an allocation decision, which is what everything scarce on an exchange eventually becomes.

It is worth seeing where this sits in the larger picture, because identity is the most valuable case of a general principle: enrichment. Everything added to a request between its arrival and the auction opening makes it more biddable, and the commercial shape is always the same — the same traffic, the same page, the same impression, worth more, because more buyers can evaluate it. Identity is the expensive half of that and the subject of this article. Geography is the cheap half and pure table stakes: without country, region and city resolved on every request, a buyer cannot apply geographic targeting, you cannot floor by geography, and you cannot report by it. Neither one wins you new inventory. Both raise what the inventory you already have is worth, which is a better return than almost anything else available to an exchange.

They also fail the same way, which is the practical reason to think of them together: silently. Nothing breaks when enrichment degrades. There is no error, no alert, no entry in a drop report. Requests still go out, buyers still respond, and the number is simply lower than it should have been — for weeks, if nobody is watching. That is why both belong on a dashboard as first-class metrics rather than buried in a pipeline. If you measure one thing after reading this, measure match rate per demand partner. If you measure two, add the share of requests leaving with geography resolved.

The consent boundary

Everything above operates inside a legal boundary, and the boundary is not decorative.

A sync cookie is storage on a user’s device, and a user ID is personal data under GDPR — which puts cookie syncing squarely where European law requires a legal basis, in practice consent signalled through the IAB Europe Transparency & Consent Framework. The TCF string on your requests encodes, per vendor, whether this user consented to storage and identity processing. The rule that follows: gate sync firing on the consent string. If it does not establish a basis for the partner you are about to sync, the pixel does not fire and the table does not get written. OpenRTB’s own cookie-sync appendix lists consent-gated sync firing as customary practice — the standards body’s way of saying the ecosystem expects it of you. In the US, the Global Privacy Platform plays the equivalent role for state-level signals: carry the string, honor the opt-outs, pass it on every sync URL and bid request.

Two failure modes deserve naming because both are tempting under match-rate pressure. Syncing without a basis — firing pixels into consent-absent traffic because the match rate looks better — is not a growth tactic; it converts your identity stack into a liability that attaches to you and every partner you synced, and it is discoverable, because sync chains are visible in any browser’s network panel. And mutating consent signals so more traffic appears consented makes every downstream partner non-compliant on your behalf; the signals cross your platform unmodified, and any code path that edits them is a defect.

The constructive reading: consent discipline and identity value point the same direction. The identifiers that survive scrutiny — consented syncs, authenticated IDs with documented opt-out, publisher first-party data — are exactly the ones demand can spend against without its compliance teams objecting.

Key takeaways

Running identity on Floxis

Every component above is buildable, and as with the auction itself, the build is the smaller half — the sync loop, like the settlement loop, never reaches done.

Floxis is a white-label RTB exchange you run as your own — your domain, your branding, your margin — and identity is part of what comes in the box. User sync runs both server-side and as pixel sync, lifting match rates so more demand bids and more of your traffic clears, and it is signal-resilient: it works with the IDs you already run, including UID2, ID5, RampID and hashed email. Cookie-sync performance lands in the same real-time analytics as everything else — reporting arrives about a minute after the event, as log-level data, next to fill, win and drop reports — so the per-partner match-rate telemetry this article argues for is a report you open, not a pipeline you build. On the consent side, IAB TCF and GPP signalling is handled natively and passed through every request, and Floxis is registered on the IAB Europe Global Vendor List as vendor 1609.

If you are evaluating platforms rather than building, the identity questions belong on the vendor checklist alongside the ones in our white label ad exchange guide: which sync modes, which ID frameworks, and whether match rate is a first-class metric you can see per demand partner. Book a demo and we will walk through the sync and identity path against your actual supply mix.

Sources worth bookmarking

• IAB Tech Lab — OpenRTB, and the OpenRTB 2.6 specification with its cookie-syncing appendix and EID object
• Google Privacy Sandbox — April 2025 update on third-party cookies
• Google Privacy Sandbox — October 2025 update on plans for Privacy Sandbox technologies
• WebKit — Full third-party cookie blocking and the WebKit tracking prevention policy
• Mozilla — Total Cookie Protection by default
• Prebid — user ID modules and Prebid Server cookie sync
• IAB Europe — Transparency & Consent Framework and IAB Tech Lab — Global Privacy Platform