A cookie banner is a gate, not a notice
Most people see a cookie banner as a box asking permission, click something, and move on. That's the visible half. The half that matters is what happens behind it: a properly built banner is a gate that decides which scripts on the page are allowed to run, and holds the non-essential ones back until you choose. A banner that only displays a message while the trackers fire anyway looks compliant and isn't. So the real question isn't what a cookie banner says, it's what it does.
This guide is about the mechanics. If you're wondering whether your site legally needs one, read do I need a cookie banner; to put one live, see how to add a cookie banner to any website.
The anatomy of a banner
Strip a compliant banner to its parts and you get:
- A clear notice. Plain-language text saying the site uses cookies and why.
- Balanced choices. Accept and Reject presented with equal prominence, plus a way to customise. Reject can't be buried.
- Category toggles. Granular switches for each purpose: necessary (always on, no toggle), analytics, marketing, preferences, so the visitor can allow some and refuse others.
- A link to detail. A route to the full cookie policy listing what each cookie does.
The banner is the visible tip of a wider system usually called a consent management platform, or CMP. More on that in what a CMP is.
What happens on page load, in order
The CMP loads first
Before any analytics or ad tags, the consent script runs. It has to be early, because it's about to decide what everything else is allowed to do.
Non-essential scripts are held back
The CMP blocks tags that aren't strictly necessary from executing or setting cookies. This is the step that separates a real banner from a decorative one.
The banner is shown
The visitor sees the notice and the balanced accept / reject / customise choices, with nothing non-essential having run yet.
The visitor chooses
Accept all, reject all, or a granular per-category selection. The choice is captured as a set of allowed purposes.
The choice is stored
The decision is written to a consent cookie or local storage entry (itself treated as strictly necessary) so the banner doesn't reappear on the next page.
Allowed scripts are released
Tags in the granted categories are unblocked and run. Everything in a refused category stays blocked.
Signals go out to your tags
The banner broadcasts the decision through Google Consent Mode v2, the IAB TCF string, or both, so downstream tools adjust their behaviour to match.
Prior blocking is the whole point
The step that trips up most sites is step two. If tags fire before the visitor chooses, or fire regardless of the choice, the banner is theatre. Article 5(3) of the ePrivacy Directive requires consent before non-essential storage or access, which means the blocking has to come first. A banner bolted on top of tags that already ran doesn't make the site compliant.
The signals a banner sends
A banner doesn't just start and stop scripts, it also tells other systems what the visitor decided, through standard signals. Google Consent Mode v2 passes the consent state to Google tags so they run in a restricted, cookieless mode when consent is denied and fully when it's granted. The IAB TCF encodes choices into a string that advertising vendors read. And browser-level signals like the Global Privacy Control can carry a visitor's opt-out to the site automatically. A capable banner speaks these so your tags behave consistently.
What separates a compliant banner from a box
Pulling it together, a banner works properly when it loads first and blocks non-essential scripts until a decision, offers reject as easily as accept, records granular per-purpose choices, remembers them, and signals them to your tags, all without dark patterns nudging people toward "accept." CookieBeam does this end to end: it blocks scripts before consent, renders the balanced banner, stores each decision as an audit record, and emits Consent Mode and TCF signals. Once it's running, confirm the blocking actually holds with a cookie audit, since a banner you can't verify is a banner you can't trust.
The common ways banners get it wrong
Once you understand the sequence, the failure modes are easy to spot. The banner that loads after the analytics tag has already fired the order backwards. The banner with a bright "Accept all" button and a "reject" hidden two clicks deep inside "manage preferences" fails the equal-prominence test. The banner that offers only "Accept" and "Learn more," with no way to refuse, isn't offering a choice at all. And the banner that reappears on every page because it never stored the decision annoys users into clicking accept just to make it stop, which produces consent a regulator can throw out. A banner is only doing its job when the blocking is real, the choices are balanced, and the decision sticks. Everything else is decoration that carries legal risk. For the patterns to avoid, see cookie consent UX patterns.
The same banner behaves differently by region
A capable banner doesn't show identical behaviour to everyone. Under the EU and UK regime, the default is opt-in: nothing non-essential runs until the visitor agrees. Under most US state laws the model is opt-out: tracking may run until the visitor says stop, often via a "Do Not Sell or Share" link or a Global Privacy Control signal. A single banner that adapts its defaults to the visitor's location is how one deployment stays compliant across both, rather than forcing EU-style prompts on everyone or leaving US visitors without an opt-out.