Your Cookie Banner Already Lost: Tracking That Fires Before Consent
A banner that appears after the analytics cookie is already set is not asking for consent — it is announcing a decision. Here is how to tell whether your trackers fire before the click, why the banner makes it worse rather than better, and what to actually change.
By ShipReady
If an analytics or advertising cookie is already set by the time your consent banner renders, the banner is decorative. In the EU/EEA and UK the standard is prior consent — the storage has to happen after the affirmative choice, not before it. Open your site in a private window, open developer tools, and look at the cookies present before you click anything. Anything from an analytics or advertising vendor sitting there is the problem, and having a banner on the page makes it harder to argue was accidental, not easier.
A note on what follows: this is a technical article about what your site does, written for developers. It describes the standards that consent requirements are drawn from, but it is not legal advice, and none of ShipReady’s checks are a compliance determination. Whether any of this applies to you depends on where your visitors are and what you do with the data. That is a question for a lawyer, not a scanner.
Where the requirement actually comes from
This is worth getting right, because "GDPR cookie banner" is a phrase that obscures two separate instruments.
- The rule about storing or reading anything on a visitor’s device comes from the ePrivacy Directive, Article 5(3). It applies to cookies, and equally to
localStorage, device fingerprinting, and pixels — the technology is irrelevant. It carves out storage that is strictly necessary for a service the user explicitly requested. - The GDPR supplies the definition of consent that Article 5(3) points at: freely given, specific, informed and unambiguous, given by a clear affirmative action (Article 4(11) and Article 7).
- In the UK the equivalent is PECR regulation 6, reading consent through the UK GDPR.
Two consequences follow directly. First, "strictly necessary" is narrow and is judged against what the user asked for, not what your business needs — a session cookie that keeps someone logged in qualifies; an analytics cookie that tells you how many people logged in does not. Second, because consent must precede the storage, a banner shown at the same moment the tracker fires does not satisfy it. The Court of Justice settled the related question of what counts as an affirmative action in Planet49 — a pre-ticked box is not consent.
Check your own site in two minutes
- Open a private or incognito window. This matters — an existing consent cookie from your own past visits will hide the entire problem.
- Open developer tools before you navigate, and switch to the Network panel with recording on.
- Load your homepage. Do not click anything, including the banner.
- Open Application → Cookies (Chrome) or Storage → Cookies (Firefox) and read what is already there.
- In the Network panel, look for requests to analytics and advertising hosts that have already fired.
| Cookie | Set by | Before consent? |
|---|---|---|
_ga, _ga_* | Google Analytics 4 | Should not be there |
_gcl_au | Google Ads conversion linker | Should not be there |
_fbp | Meta Pixel | Should not be there |
_hjSession* | Hotjar | Should not be there |
| Your session cookie | Your application | Fine — strictly necessary for a logged-in service |
| Your consent cookie | Your banner | Fine — it exists to record the choice |
The most damning version of this is a tracking cookie set by the server on the very first response — before any JavaScript has run, before the banner exists as pixels. There is no sequence of events in which that was consented to.
Why the banner makes it worse
A site with no banner and analytics running has one problem. A site with a banner and analytics running before the banner is answered has the same problem plus a contradiction: the page demonstrably knows consent is required — that is what the banner is for — and takes the data anyway. ShipReady grades these differently for exactly this reason. Trackers with no consent step visible at all is a low-severity observation. A tracking cookie set despite a consent banner being present is medium, because the intent to gate is established and the gate does not work.
How this happens, and it is rarely deliberate
- The snippet was installed before the banner was. Most people add analytics on day one and consent management in month six, and adding the banner does not retroactively move the analytics tag behind it.
- The banner is a UI component, not a gate. Plenty of banner libraries render a bar and store a choice without controlling script execution at all. It looks identical to a real consent management platform and does nothing.
- A tag manager loads early. If the container itself is in the
<head>and tags fire on container load, the consent state is settled after the fact. - A third-party embed sets cookies on its own. A YouTube player, an intercom widget, a map — each of these can set cookies the moment it is embedded. ShipReady reports third-party embeds setting cookies separately for that reason.
- Server-side, in middleware. An A/B testing or attribution cookie assigned in an edge function fires before any client-side logic exists to gate it.
What to actually change
Make the gate real
The fix is that the tracker’s script does not execute until consent is recorded. Not "does not report" — does not execute. In practice that means loading it dynamically from your consent callback rather than including it in the initial HTML:
// Instead of a <script> tag in the document head:
function onAnalyticsConsent() {
const s = document.createElement('script')
s.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX'
s.async = true
document.head.appendChild(s)
}
// Called only from the consent handler, never on load.
consentManager.on('accept:analytics', onAnalyticsConsent)Then re-run the two-minute check above. In a fresh private window, before clicking, there should be no analytics cookies and no requests to analytics hosts.
Or use a consent mode, knowingly
Google Consent Mode takes a different approach: the tag loads but withholds or de-identifies measurement until consent arrives. Whether that satisfies Article 5(3) depends on whether anything is stored on or read from the device in the meantime, which depends on how it is configured. It is a legitimate architecture and it is not automatically compliant — decide deliberately rather than by default.
This is also a case ShipReady cannot see. The scan reads the page’s initial HTML, so a consent platform that loads later via JavaScript, or Consent Mode configured inside a tag manager, is invisible to it. That is why the trackers without consent finding is rated low and its guidance opens by asking you to confirm whether a gate exists. If you already have one, there is nothing to change.
Consider needing less consent
The cheapest way to pass a consent check is to have less to consent to. Cookieless, aggregate analytics tools avoid device storage entirely and therefore largely avoid Article 5(3). Self-hosting a font instead of loading it from a third party removes a request that transmits your visitor’s IP address to another company — ShipReady reports Google Fonts loaded from a third party as an observation for that reason, though it is worth knowing the well-known German ruling on this was a single regional court decision rather than settled EU-wide law.
Session replay and fingerprinting deserve their own decision. Both collect far more than page views — ShipReady flags session replay scripts and device fingerprinting so the choice to run them is at least a visible one.
Then make the policy match
Getting the timing right solves half of it. The other half is that the services you run should be named in your privacy policy — does your privacy policy name the tools your site actually loads? covers the reverse direction of the same check.
How ShipReady detects this
ShipReady reads each crawled page’s initial HTML and response headers — no extra requests, no script execution. It identifies known analytics and advertising trackers in the markup, looks for a consent banner or consent-mode signal in the same HTML, and reads Set-Cookie headers on the first response. From that it distinguishes three situations: trackers with no visible consent step, a tracking cookie set on the first response, and a tracking cookie set despite a banner being present.
These are page-scoped, because a marketing homepage and a bare /login genuinely differ — and the route carrying your signup form is the one worth looking at. None of them is a compliance verdict; they are observations about what the page does, with the evidence attached. Scan your site free to see them for your own pages, or read the Compliance and Privacy pillar for the full set.
Frequently asked questions
- Is Google Analytics illegal in the EU?
- No, and that framing has never been accurate. Several national authorities found specific 2020-era implementations unlawful on international-transfer grounds, and the legal landscape has moved since. The consent question in this article is separate and simpler: whatever tool you use, device storage generally needs prior consent.
- Do I need a banner if all my visitors are in the US?
- The ePrivacy rules described here follow your visitors, not your company. If you genuinely have no EU/EEA or UK visitors they do not apply — but US state privacy laws have their own requirements, several of which centre on opt-out of sale or sharing rather than opt-in consent.
- Are session cookies exempt?
- A cookie strictly necessary to deliver a service the user explicitly requested — keeping them logged in, holding a shopping basket, recording the consent choice itself — falls in the exemption. Analytics does not, however useful it is to you.
- What about localStorage instead of cookies?
- Same rule. Article 5(3) is about storing or accessing information on the user’s device and is deliberately technology-neutral. Moving an identifier from a cookie to localStorage changes nothing about the requirement.