The one thing a tracking cookie is built to do
A tracking cookie exists to answer a single question: is this the same browser I saw before? Everything else follows from that. It stores a unique identifier, something like id=8f3a9c2e, and hands it back to a server every time you load a page that talks to that server. The server keeps the profile. The cookie just carries the key that opens it.
That's the whole trick, and it's worth being precise about it because "cookie" gets blamed for a lot of things a cookie doesn't actually do. The cookie doesn't hold your browsing history, your name, or your interests. It holds an ID. The history and the interests live in a database somewhere else, linked to that ID. If you're new to cookies in general, start with what cookies are, then come back here for the tracking-specific mechanics.
How the mechanism works, step by step
Here's the sequence for a typical tracking cookie set by an analytics or advertising script:
- You visit a page. It loads a script from a measurement or ad domain (either the site's own domain or a third party's).
- The script generates a random unique ID and stores it in a cookie, either through a
Set-Cookieresponse header or viadocument.cookiein JavaScript. - Your browser saves that cookie and, from then on, automatically attaches it to every request sent to the domain that set it.
- Each request the cookie rides along on tells the server "this ID is here again, on this page, at this time."
- The server appends that event to the profile stored under your ID: pages seen, time spent, items viewed, whether you converted.
Over many visits the profile fills out. None of that data is in the cookie. The cookie is the library card; the server holds the file.
First-party tracking vs third-party tracking
The same mechanism runs in two very different contexts, and the difference decides how far the tracking reaches.
First-party tracking happens when the cookie belongs to the domain in your address bar. If you're on shop.example and its own analytics counts your visit, that's first-party. It can only see what you do on that one site. Useful, contained, and the more durable of the two.
Third-party tracking happens when the cookie belongs to a domain embedded on the page, an ad network or data broker whose script sits on thousands of sites. Because the same domain recognises you everywhere it's embedded, it stitches your behaviour across all of those sites into one cross-site profile. That cross-site reach is what built the behavioural advertising industry, and it's exactly what regulators and browsers went after. The full breakdown is in first-party vs third-party cookies.
Third-party tracking is already a degraded signal
Safari has blocked third-party cookies by default for years, and Firefox isolates them with Total Cookie Protection. Chrome kept them, but between default-blocking browsers, ad blockers, and consent refusals, cross-site tracking cookies reach a shrinking and uneven slice of real traffic. Building measurement on them is building on sand.
Browsers put tracking cookies on a timer
Even where tracking cookies survive, browsers cap how long they last. Safari's Intelligent Tracking Prevention limits any cookie written by JavaScript through document.cookie to a maximum 7-day lifetime, and reserves the right to cut that to 24 hours for domains it classifies as trackers. Cookies set by a first-party server through the Set-Cookie response header aren't subject to that 7-day JavaScript cap, which is one reason serious measurement is moving server-side. See first-party cookieless tracking for where that leads.
Tracking cookies need consent. All of them.
A common and expensive misconception: that a first-party cookie is exempt from consent because your own domain set it. It isn't. Under Article 5(3) of the ePrivacy Directive, you need prior consent to store or read any information on a user's device unless it's strictly necessary to provide the service the user asked for. Analytics and advertising aren't strictly necessary, so they need consent whether the cookie is first-party or third-party. The GDPR then sets the bar for what counts as valid consent: a freely given, specific, informed, and unambiguous affirmative action.
In practice that means a tracking cookie must not be set until the visitor has actively agreed to the category it belongs to. A banner that loads the tracker first and asks permission afterwards has the order backwards, and that's a compliance failure, not a technicality. See how to block scripts before consent.
How to see the tracking cookies on your own site
Most site owners underestimate how many trackers they're running, because plugins, embeds, and tag managers pull in more than anyone signed off on. The only reliable way to know is to scan. CookieBeam crawls your pages, records every cookie that gets set (and the connections and scripts behind them), flags which ones are tracking rather than necessary, and lets you gate them behind consent. Once you can see the full list, categorising it and writing an honest cookie policy becomes straightforward. Start with a cookie audit.
Analytics trackers and advertising trackers aren't the same
"Tracking cookie" covers two jobs that people often blur. An analytics tracker measures how your own site is used: which pages get read, where visitors drop off, what a conversion looks like. Handled first-party, it stays within your site. An advertising tracker is built to follow a user off your site and match them to campaigns, audiences, and other advertisers' data, which is where the cross-site profile comes from. Both need consent, but they carry different privacy weight, and separating them matters when you build your banner. A visitor might reasonably accept analytics and refuse advertising, so bundling the two into a single "accept" removes the granular choice the GDPR expects. Split them into their own categories, as covered in cookie categories, and you give people a real decision instead of a false one.