A tracking cookie is any cookie whose purpose is to recognise the same browser across more than one page view, and usually across more than one site. Nothing in that definition is about the technology. The same name and value that holds a shopping basket can be a tracking cookie if a third party reads it on a thousand other sites, and the practical problem for the person running a small company website is that almost none of the tracking cookies on their own site were put there on purpose. They arrived with a tag, an embed, a chat widget or an ads pixel, and the first honest step is to find out what is actually being set.
What makes a cookie a tracking cookie
Two things, and neither is the cookie itself. The first is scope: a cookie set on a domain the visitor did not type, read back when they are on somebody else's site, identifies a person across the web rather than a session on yours. The second is purpose: a value that exists to build a profile, attribute a conversion or target an advertisement is tracking whether it lives for ten minutes or two years. A strictly functional session identifier can be perfectly long-lived and still not track anyone, because nobody but your own server ever sees it.
Where yours came from, which is almost never your own code
On a typical small company site the tracking cookies are set by tags rather than by the application. An analytics snippet, an advertising pixel, a video embed, a live chat widget, a heatmap tool, an A/B testing script and a social share button each bring their own. The people who installed them are frequently not the people who now own the banner, and the tag manager that loads them will happily fire on page load before anyone has clicked anything. That is why an audit starts with the rendered page rather than the source repository.
Which ones need consent before they are set
In the European Union the rule is in the ePrivacy Directive rather than in the GDPR: storing or reading information on a user's terminal equipment requires consent unless it is strictly necessary to provide the service the user asked for. That test is about necessity for the user, not necessity for your business, so an analytics cookie fails it even though the analytics are genuinely useful to you. In California the shape is different: the obligation attaches to a business that meets the thresholds in the Civil Code and turns on sale and sharing rather than on storage, which is why a Californian banner is usually an opt-out of sharing and a European one an opt-in to storage.
What to do about the ones you cannot remove
Some tracking cookies pay for the site and are not going anywhere. The answer there is not to hide them but to stop them firing before consent, which for most tag stacks means moving the tag out of the page and behind the consent signal, then verifying in the browser that nothing is written on a fresh visit until a choice is made. A banner that appears while the pixel has already fired is worse than no banner, because it documents an intention that the page does not honour.
The categories a banner offers, and how tracking cookies map onto them
Most consent tools present four or five categories: strictly necessary, functional or preferences, analytics or performance, and advertising or targeting. Tracking cookies land in the last two almost without exception, and the mapping is a decision somebody has to make rather than something the tool knows. Get it wrong in the permissive direction and a visitor who refused advertising is still being profiled; get it wrong in the restrictive direction and your own analytics disappear for people who would happily have allowed them. The mapping is worth writing down beside the cookie table, because it is the thing an auditor will ask you to justify and the thing a new tag silently breaks.
What a records trail for tracking cookies has to contain
If somebody asks in eight months whether a particular visitor agreed to advertising cookies, the answer has to survive three things that will have happened since: the banner text will have been edited, the category mapping will have changed, and the vendor list will be different. So the record needs the choice, the moment, the categories as they were named that day, and a pointer to the version of the banner that was on screen. A store that keeps only the latest state per visitor cannot answer the question at all, and that is what most of the cheap consent plugins keep.
Questions people ask about tracking cookies
Are tracking cookies illegal?
No. Setting one without a lawful basis is the problem, not the cookie. In the EU that basis is normally the visitor's consent, given before the cookie is written; in California the question is about selling or sharing what the cookie feeds, and an opt-out has to be honoured.
Does a first party analytics cookie count as tracking?
Usually yes for consent purposes. It is not strictly necessary to deliver the page, which is the test, and the fact that only you read it changes the risk rather than the requirement.
How do I see which tracking cookies my site sets?
Open the site in a clean browser profile with the developer tools on the storage tab, load one page, and list what is written before you interact with anything. That list is the one that matters, because it is what a regulator or a customer would see.
Do tracking cookies still work if browsers block third party cookies?
Not reliably, which is why so much tracking has moved to first party storage set by a third party script. That shift changes where the cookie lives without changing whether it needs consent.
Do I need to list every tracking cookie by name?
Not necessarily, and on a site with a large ad stack the names change too often for a by-name list to stay true. Categories with the purposes and the receiving parties named are usually both more honest and more maintainable.