The short version: Yes, Google Analytics uses cookies, most notably one called _ga that sticks around for two years, and it sets these before you’ve usually thought to ask permission. That matters because cookies are how GA tells one visitor from another across sessions, which under UK and EU law makes them personal data requiring consent, not just a “nice to have” banner you bolt on afterwards. If you’ve installed GA4 and haven’t touched your consent setup since, you’re probably collecting data you’re not legally allowed to keep.
Which cookies Google Analytics sets
Google Analytics 4, the version almost everyone runs now that Universal Analytics was switched off in July 2023, drops a small handful of first-party cookies onto your domain the moment the tracking snippet fires. The main ones are:
- _ga: the core identifier cookie, expires after 2 years, used to distinguish unique users
- _ga_<container-id>: a session-state cookie unique to your GA4 property, also lasts 2 years, stores session status and campaign information
- _gac_gb_<container-id>: only appears if you’ve linked Google Ads, stores campaign data for conversion tracking, lasts 90 days
That’s the practical list. Older Universal Analytics also used _gid, which expired after 24 hours, but that’s gone with the old platform. If you’re still seeing _gid on your site, something older than GA4 is running alongside it, which is worth checking because it usually means an old tag is firing twice, quietly inflating your session counts.
None of these cookies contain your name or email address directly. What they contain is a randomly generated client ID, something like 1234567890.1234567890, which on its own looks meaningless. The trouble is that under GDPR and the UK’s Privacy and Electronic Communications Regulations, that ID still counts as personal data the moment it can be linked back to an identifiable person, and combined with IP address, device details, and behaviour patterns, it usually can be.
Why “it’s just an ID” doesn’t get you out of consent
I hear this argument constantly from small business owners: “but it’s not my customer’s name, it’s just a random string of numbers, surely that’s fine without asking.” It isn’t. The UK’s Information Commissioner’s Office and its EU equivalents have been clear for years that persistent identifiers used to track behaviour across a site, and especially across sites, meet the bar for personal data. A cookie that lets Google (or you) recognise the same browser returning three weeks later is doing exactly the job a name would do. It’s just doing it more quietly.
This is where whether Google Analytics requires cookie consent under GDPR gets asked in almost every client kickoff call I run, and the answer is yes, in nearly every real-world setup. The narrow exception is “strictly necessary” cookies that a site needs to function, like a shopping basket remembering its contents. Analytics cookies do not meet that bar. They’re for your benefit, not the visitor’s, and regulators treat them accordingly.
A real example: the hotel that was collecting data illegally for four months
I worked with a small hotel client in the Cotswolds last year who’d had GA4 installed by a web developer as part of a site rebuild. The developer had done a solid job on the design. The tracking code, though, was hardcoded into the site’s header template so it fired on every single page load, before any cookie banner appeared, before anyone clicked accept or reject.
When I audited the site, GA was already showing four months of session data, complete with location, device type, and on-site behaviour for every visitor, including the roughly 30% who later declined cookies when a consent tool was eventually added. None of that earlier data had valid consent behind it. Under GDPR that’s not a technicality, it’s unlawful processing, full stop. We had to have an honest conversation about deleting the historical property data and rebuilding the setup with a consent management platform gating the GA tag itself, not just displaying a banner cosmetically while the script ran underneath it regardless.
That’s the bit most agencies skip when they quote for “GDPR compliant cookie banners”: a banner that visually says “cookies rejected” while the analytics script still fires in the background isn’t compliance, it’s decoration. I see this misconfiguration on roughly one in three sites I audit for new clients. It’s the single most common privacy failure in Google Analytics setups I come across, more common than missing IP anonymisation, more common than forgetting a privacy policy update.
What Consent Mode changes (and what it doesn’t)
Google’s answer to all this is something called Consent Mode, now on version 2, which is meant to let GA behave differently depending on whether a visitor accepts or declines cookies. If someone rejects analytics cookies, GA is supposed to stop setting _ga and instead send “cookieless pings,” anonymous signals with no persistent identifier attached.
Here’s the part that doesn’t get said enough. Those cookieless pings still travel to Google’s servers. They still carry the page URL, a timestamp, the browser’s user agent, and the IP address at the point of transmission, even though no cookie is set. Google then uses statistical modelling, essentially educated guesswork built from your consented users, to estimate what the declining visitors probably did. So “no cookies” doesn’t mean “no data leaves your site.” It means the data that leaves is aggregated and modelled rather than tied to a named identifier, which is better, but it’s not nothing, and it’s not something most privacy policies explain honestly to visitors.
This is also the detail sitting behind the bigger, less comfortable fact in this whole area: several EU data protection authorities, including Austria’s DSB, France’s CNIL, and Italy’s Garante, ruled in 2022 that using Google Analytics at all could breach GDPR, regardless of your consent banner, because visitor data ends up transferred to Google’s US infrastructure in a way that doesn’t meet EU protection standards after the Schrems II ruling struck down the previous data-sharing framework. Google has since layered in EU-based processing options to address this, but the underlying tension, US company, US surveillance law, EU personal data, hasn’t fully gone away. Most blog posts on this topic won’t mention that because it makes the “just add a cookie banner and you’re sorted” advice look thinner than it is. A banner fixes your consent problem. It doesn’t fix the data-residency problem sitting underneath it.
What this means for your consent banner and privacy policy, practically
If you run GA4 on a UK or EU-facing site, here’s what needs to happen, in order:
- Step 1: Install a proper consent management platform (Cookiebot, Osano, or similar) that blocks the GA script from loading until consent is given, rather than just displaying a banner over the top of a script that’s already running
- Step 2: Turn on IP anonymisation and disable Google Signals if you’re not using audience remarketing, since Signals links GA data to logged-in Google account activity, which raises the privacy stakes further
- Step 3: Set your data retention window in GA4’s admin settings to the shortest period that’s useful to you, commonly 2 or 14 months rather than the default, so old identifiable data doesn’t sit around indefinitely
- Step 4: Update your privacy policy to name Google Analytics specifically, list the cookies by name (_ga, _ga_<id>), state the retention period, and explain that data may be processed outside the UK/EU
- Step 5: Test the setup in an incognito browser by rejecting cookies and confirming in your network tab that no _ga cookie gets written, not just that the banner disappears
That fifth step is the one nobody does. Everyone tests that the banner looks right. Almost nobody opens developer tools and checks whether the promise the banner makes is true in the code.
Does anonymising or blocking cookies break your data?
A fair worry I get from business owners is that all this consent friction will wreck their reporting. It does reduce volume, yes, sometimes visibly. But it’s worth remembering what Google Analytics tracks on your site and what it quietly misses already, ad blockers, Safari’s Intelligent Tracking Prevention, and Firefox’s default cookie blocking were already stripping out a meaningful chunk of your visitors before consent banners existed. Studies from analytics vendors suggest anywhere from 15% to 30% of traffic was already invisible to cookie-based tools on privacy-forward browsers. Consent-driven data loss on top of that is real but it’s not the sole cause of gaps in your numbers, and it’s certainly not a reason to skip consent to protect your dashboard.
If your whole reporting strategy depends on catching every single session, you were already building on sand. Better to accept a smaller, honestly-collected dataset and understand what Google Analytics is telling you about your business from the traffic you can see, than to chase completeness by ignoring consent law.
What about events, not just pageviews?
It’s worth knowing that GA4 tracks far more than page loads through the same cookie-based session mechanism. Scroll depth, outbound clicks, video engagement, and file downloads are all captured as events tied to that same _ga client ID, which is part of why what counts as an event in Google Analytics is a broader category than most site owners assume. Every one of those events, when a visitor has consented, gets stitched to the same cookie identifier, building a fuller behavioural profile than a simple pageview count ever would. That’s more useful data for you. It’s also more reason the consent conversation matters, because you’re not just logging that someone visited, you’re logging what they did while they were there.
The cost angle nobody connects to privacy
One thing I tell clients weighing up whether to fix their GA setup or just switch tools entirely: Google Analytics itself is free for the vast majority of sites, and even understanding what Google Analytics costs to use in 2026 won’t change your privacy obligations, since consent requirements attach to the cookies, not the price tag. Swapping to a paid, cookieless analytics tool like Fathom or Plausible removes the consent banner headache entirely for some businesses, because they don’t use persistent identifiers at all. That’s a genuine option worth costing out if consent friction is hurting your conversion rate on a small site, rather than assuming GA is the only route because it’s free.
Frequently asked questions
Does Google Analytics 4 use cookies by default?
Yes. GA4 sets first-party cookies, mainly _ga and _ga_<container-id>, as soon as the tracking snippet loads on a page, unless you’ve configured a consent management platform to block it until a visitor agrees.
Can I use Google Analytics without a cookie banner?
Not legally if you’re targeting UK or EU visitors and using standard GA4 cookies, since these count as personal data requiring consent under GDPR and UK PECR. The only real exceptions are cookieless analytics tools such as Plausible or Fathom, or GA configured in Consent Mode with the script fully blocked until consent is given.
Does Google Analytics comply with GDPR on its own?
No, GA isn’t automatically compliant just because it’s installed. You need explicit opt-in consent before setting analytics cookies, IP anonymisation enabled, a defined data retention period, and a privacy policy that names GA specifically, and even then some EU regulators have questioned whether data transfer to Google’s US servers meets GDPR standards.
What happens if a visitor rejects cookies in a GA4 consent banner?
If your consent tool is integrated with Google’s Consent Mode, GA stops writing the _ga cookie and instead sends anonymous “cookieless pings” to Google, which get modelled statistically rather than tied to an individual. The visitor’s IP, timestamp, and page URL still reach Google’s servers briefly, just without a persistent identifier attached.
