Cookies explained: first-party, third-party and syncing

Open a news site and, before the headline has finished loading, dozens of companies may already have noticed you. Most of them do it with a tiny text file your browser keeps on their behalf: a cookie. To understand targeting, frequency caps, attribution and a lot of ad fraud, you first need to understand who is allowed to write that file and who can read it back.

Think of a cookie as a wristband at a music festival. The festival (the website you visit) snaps one on you so the bar knows you already paid. That is a first-party wristband. A third-party cookie is a wristband handed out by a drinks sponsor that works at every festival it sponsors, so the sponsor can see you were in Mumbai in March and São Paulo in June.

What a cookie actually is

A cookie is a small name-value pair, such as uid=8f3a2c, that a web server asks your browser to store. Every later request your browser makes to that same domain carries the cookie back automatically. Cookies were invented in 1994 so shopping carts could remember what you had put in them. Advertising simply noticed that a remembered ID is also a way to recognise a person across visits.

The same code can be first-party on one site and third-party on another. When you visit adserver.example directly, its cookie is first-party. When a pixel from adserver.example loads inside news.example, that same cookie is a third-party cookie. The browser decides by comparing the cookie's domain with the domain in the address bar.

Cookie syncing: how strangers agree on who you are

Here is the problem. Your DSP knows you as abc123, and the SSP selling the ad slot knows you as xyz789. Neither can read the other's cookie. Cookie syncing solves this with a quiet redirect so each company can build a lookup table matching its ID to the other's.

1. A sync pixel firesWhile the page loads, the SSP drops an invisible 1x1 tracking pixel that points at the SSP's own domain, which reads its cookie (xyz789).
2. Redirect with the ID attachedThe SSP redirects the browser to the DSP's sync URL and appends its ID in the address, for example ?ssp_uid=xyz789.
3. The partner reads its own cookieThe DSP now sees both its own cookie (abc123) and the SSP's ID in the same request.
4. Both sides store the matchThe DSP records abc123 = xyz789. Next time the SSP sends a bid request for xyz789, the DSP knows it is someone it has seen before.

Multiply that by hundreds of partners and you get the famous wall of pixels that slows pages down. Match rates are never perfect, because cookies expire, users clear them and each sync only happens when that particular pair of companies happens to meet on a page.

1. You visit two sites: You browse a shoe store, then read the news. Each site, and the ad tech on it, gives your browser its own ID in a cookie.
2. Different IDs for the same person: Cookie A and cookie B do not know they are the same browser. On their own, the shoe ad cannot follow you to the news site.
3. Cookie syncing joins them: Third-party cookies and cookie syncing let ad platforms swap IDs in the background, so A and B are matched. That is how retargeting works across the web.
4. Where cookies fail: Safari and Firefox restrict third-party cookies, and apps never had them. Chrome still allows them (Google dropped its plan to remove them), but many people still cannot be matched this way.
5. Logged-in IDs: When you log in, your email can be turned into a one-way hashed ID such as UID2. It is stable across sites that use it, and you can opt out.
6. Clean rooms: match without handing over data: In a data clean room, a retailer and a brand match their customer lists in a controlled space and only see aggregated results, never each other’s raw data.

The browsers split

Apple's Safari introduced Intelligent Tracking Prevention (ITP) in 2017 and by 2020 blocked third-party cookies by default. Mozilla's Firefox turned on Enhanced Tracking Protection (ETP) by default in 2019 and later added Total Cookie Protection, which gives each site its own separate cookie jar. ITP also shortens the life of some first-party cookies set by JavaScript, which is why many ad tech vendors moved to server-set cookies.

Google's Chrome, the most-used browser in most markets including India, Brazil and the US, spent years promising to follow. It launched the Privacy Sandbox, a set of replacement APIs such as the Topics API and the Protected Audience API, and delayed the cookie shutdown several times. Then it reversed course.

Google said a few narrower pieces would survive, including CHIPS (partitioned cookies), FedCM (federated login) and Private State Tokens (an anti-fraud signal). Sources: Google Privacy Sandbox blog and AdExchanger's coverage.

Why cookies matter for invalid traffic

Cookies are easy to fake and easy to throw away. Bots can clear them on every visit to look like fresh users, or keep them to build a history that looks like a valuable shopper. Cookie stuffing drops affiliate cookies on people who never clicked, so the fraudster gets credit for sales they did not cause. A spike in brand-new cookies with no history, or one cookie appearing from many IP addresses at once, is a classic signal that fraud detection systems look for.