RTB cookie syncing: what it means and how to review it

Consider a page that requests sync.vendor-a.example, receives a redirect to match.vendor-b.example, and passes an identifier-shaped value between the two. These reserved example domains illustrate a pattern; they are not a retained finding or a claim about real vendors.

Retain the initiator, redirect status and destination, request start times, parameter names with values redacted, vendor classification, and consent state. A pair of advertising hosts appearing in the same session is weaker evidence than a directly retained redirect or identifier-transfer chain.

An advertising auction, measurement pixel, ordinary redirect, and cookie synchronization are not identical. A suggestive endpoint name does not prove matching or downstream use. Compare the direct chain with vendor documentation and the retained classification.

Cookie blocking can suppress storage while requests still occur. Conversely, a cookie already present does not prove it was sent in a sync request. Review transport and storage separately.

Locate the tag or embedded service at the start of the initiator chain. Give its owner the consent context and redacted evidence, then inspect CMP gating and vendor settings. Compare fresh baseline and choice sessions under matching conditions after an authorized change.

CertScore.ai reviews observed request hosts, URL patterns, vendor categories, redirect-like behavior, and known advertising or identity endpoints.

The scan does not claim to know every downstream use of an identifier. It surfaces evidence that a team should review with its advertising, consent, and vendor-management owners.

Identifier-sharing behavior can be more sensitive than a simple cookie inventory because it may indicate cross-domain advertising or measurement flows.

Review the evidence for request timing, vendor purpose, user-consent state, and whether the behavior is expected for the scanned surface.