What "consent" means in this context
A cookie is a small piece of data a site asks a browser to store, then reads back on later visits. Consent, in the legal sense that cookie banners exist to satisfy, is a freely given, specific, informed and unambiguous signal from the visitor that they agree to that storage happening for a purpose they were told about in advance. A pre-ticked box is not consent. A banner that only offers "accept" with no equivalent way to decline is not consent either, under the frameworks that require it. The visitor has to take a clear action, and that action has to be as easy to reverse as it was to give.
Why cookie banners exist at all
The requirement comes from two overlapping pieces of EU law: the ePrivacy Directive, which governs storing or accessing information on a user's device, and the General Data Protection Regulation, which governs processing personal data once it exists. The UK runs an equivalent regime under PECR and UK GDPR. A handful of US states, starting with California, layer on a separate opt-out right rather than a full opt-in consent requirement. None of that tells you what your specific site has to do, and no general guide will. What it explains is why the banner exists at all. Storing something on a device is one legal question. What happens to the personal data that storage produces is a second one, and cookie law tries to answer both at the same time.
What typically needs consent and what does not
Not every cookie is equal under these rules. Cookies that are strictly necessary for a feature the visitor asked for (a shopping cart remembering its contents, a login session staying open, a language preference they set explicitly) generally fall under an exemption and do not require consent. Cookies for analytics, advertising, or cross-site profiling generally do need it. The table below is a starting map, not a verdict on any particular tool or configuration.
| Cookie category | Typical example | Usually needs consent |
|---|---|---|
| Strictly necessary | Login session, shopping cart, load balancing | No, generally exempt |
| Functional preference | Remembered language, remembered currency | Often exempt if set by explicit user action |
| First-party analytics | Page views and session counts on the site's own domain | Usually yes, though a few regulators allow narrow exemptions |
| Advertising or retargeting | Third-party ad network cookies, cross-site pixels | Yes |
| Social media embeds | Share buttons, embedded video players that set their own cookies | Yes, since a third party sets them |
Do you need a cookie banner
If a site sets anything beyond strictly necessary cookies, and almost every site running analytics or an ad pixel does, it needs a consent mechanism. That much isn't really in dispute under EU and UK rules, and it's getting harder to avoid under US state law too, depending on where visitors are and what data leaves the site. What that mechanism actually has to say, though, varies by jurisdiction, traffic mix, and what's being collected, and that's the part worth a lawyer's eyes rather than a generic guide's. What a guide can do is tell you the shape of the decision: know what you're setting, know why, and give the visitor a real way to say no before anything non-essential fires. Site owners auditing their own page often miss a tracking pixel embedded from a third party, since it's easy to overlook something you didn't add yourself.
What consent mode actually is
Consent mode, as Google implements it, is often misunderstood as a way to become compliant by installing it. It is not that. It is a tag configuration that tells Google's own tags how to behave based on a consent status the site already collected somewhere else, typically from a separate consent management platform. When a visitor declines, consent mode tells the analytics and ads tags to stop setting identifying cookies and instead send limited, modeled pings. It changes what data Google receives after a choice has been made. It does not collect that choice, present the banner, or decide what the site is legally required to ask for. A site can install consent mode perfectly and still have no valid consent mechanism underneath it. The two solve different problems. Consent mode reacts to a choice the site already collected somewhere else, and it doesn't make that choice or collect it itself.
How this connects to click and campaign tracking
Consent decisions do not stop at the banner. They flow into how click and campaign data gets collected downstream. A link-in-bio tool like Raydar, for instance, sets first-touch and last-touch cookies to work out which post or campaign actually produced a click, which is the same category of cookie that a consent framework is built to govern, distinct from server logs that only capture a referrer and a UTM parameter without setting anything on the device. Understanding which category a given tracking method falls into, cookie-based or not, is the actual decision that determines what a banner needs to disclose, more than any single tool's marketing copy does. If cookies are being avoided altogether, cookieless visitor identification methods carry their own separate consent questions worth understanding before assuming they sidestep the issue.
A note on scope
None of this is legal advice, and nothing here tells you whether a specific site, in a specific country, with a specific visitor mix, needs a banner today. It is a map of the moving parts: what a cookie is, why the law splits into a storage rule and a data processing rule, and where a tool that relies on first-party tracking or an attribution cookie sits inside that map. Whether your own setup needs a banner, and what that banner has to say, is a question worth putting to someone who can look at the actual configuration rather than a general explainer.