Is Google Analytics 4 a Third-Party Cookie?

Is Google Analytics 4 a Third-Party Cookie?

The question gets asked in two very different rooms. In one, someone is filling out a data-protection questionnaire and needs a box ticked correctly. In the other, a marketer has read for the fifth year running that third-party cookies are dying and wants to know whether their analytics is about to stop working.

Both readings have the same answer, and it is not the one the phrasing implies.

This guide gives the direct answer, shows you exactly which cookies GA4 writes into a visitor's browser, and walks through how to verify it on your own site in about a minute. It also covers the part of the cookie story that genuinely does deserve your attention, because there is one.

Is GA4 a Third-Party Cookie? The Direct Answer

No. Google Analytics 4 is not a cookie at all. It is a measurement platform, and the question quietly swaps the tool for the storage mechanism it happens to use.

The cookies GA4 does set are first-party cookies. They are written by JavaScript running on your own page and stored against your own domain. If your site is example.com, the cookie belongs to example.com. Google can read the value only because your page attaches it to the measurement request it sends.

A third-party cookie is something different: a cookie set on a domain other than the one in the address bar, usually an ad network's. That cross-domain quality is precisely what lets a third-party cookie follow one person between unrelated websites. GA4's measurement cookies have never worked that way.

The confusion is still reasonable. Google is unquestionably a third party to your business, and Google does operate third-party advertising cookies elsewhere in its stack. But the identifier that distinguishes one visitor from another in your GA4 reports sits on your domain, not Google's.

It is worth naming what a questionnaire is usually driving at when it asks this. The underlying concern is almost never the HTTP mechanics of cookie storage. It is whether your analytics lets an outside company build a profile of your visitors across other people's websites. Measurement cookies do not do that, and saying so plainly, with the domain as evidence, answers the real question rather than the literal one.

Getting the technical facts straight is the cheap part. Knowing what your traffic actually does is the valuable part. Get a free SEO audit and see what your site is really ranking for.

What GA4 Actually Writes Into the Browser

Two cookies do nearly all of the work, and both are set by the gtag JavaScript on your page rather than sent down by a Google server.

_ga — the client identifier

This is the cookie that makes returning-visitor reporting possible. It stores a randomly generated client ID that stands in for "this browser on this device", with a default expiration of two years.

It contains no name, no email address and nothing that identifies a person on its own. It is a pseudonymous label. That distinction matters legally in some jurisdictions and not at all in others, which is why the consent question is answered by your lawyer rather than by the cookie's technical properties.

You can shorten its life. GA4's admin settings let you override the expiration anywhere from immediately up to 25 months, and plenty of organisations dial it down to satisfy an internal retention policy.

The value itself is unremarkable to look at: a version prefix, a dot, and two long numbers. One of those numbers is a random integer and the other is the timestamp the cookie was created. There is nothing in it to decode and nothing in it that came from Google, which is the clearest practical sign that the identifier originates on your own site.

_ga_<container-id> — session state

The second cookie carries your specific measurement ID in its name, so it looks something like _ga_ABC1234567. It persists session state: when the current session started, how many sessions this browser has had, and whether the session is still live.

Its default expiration is also two years. If you run several GA4 properties on one domain, you get one of these per property, which is why a site with a main property and a roll-up property shows two of them.

This is also the cookie that quietly explains odd session counts. Because session state lives in the browser rather than on a server, anything that clears or isolates browser storage mid-visit starts a new session, and a single human journey can arrive in your reports as two or three separate sessions.

The Google Ads cookies, which are a separate matter

When you link a Google Ads account to GA4, additional cookies come into play for conversion measurement and remarketing. These are the ones people are usually half-remembering when they ask the third-party question.

Even most of these are first-party. The _gcl_* family that records ad-click information is written on your domain. The genuinely third-party advertising cookies live on Google's own ad-serving domains and are set by ad and remarketing tags, not by the analytics measurement tag.

The practical rule: analytics measurement is first-party, advertising personalisation is where third-party storage enters the picture.

Most reporting problems are not platform problems, they are setup problems. Request a free audit and get a clear read on where your organic traffic is leaking.

How to Check Your Own GA4 Cookies in Under a Minute

Do not take anyone's word for this, including ours. Verify it on your own site.

1. Open your site in Chrome in a normal window, not incognito, and let the page fully load.
2. Press F12 to open DevTools, then open the Application tab.
3. In the left sidebar, expand Cookies and select the entry for your own domain.
4. Sort by name and look for _ga and _ga_ followed by your measurement ID.
5. Read the Domain column for those rows. It will show your domain, not google.com or doubleclick.net. That column is the whole answer.
6. Read the Expires column to confirm the lifetime your property is actually using, which may be shorter than the two-year default if someone changed it.

If you want to see the third-party side for contrast, keep DevTools open and click the entry for any other domain in that same Cookies list. Anything you find there was set by a tag other than your analytics measurement tag.

One caveat on method: do this in a normal window. Incognito and private windows start with empty storage and discard it on close, so you will see the cookies being created but learn nothing about the lifetimes a returning visitor actually experiences. If your own domain shows no analytics cookies at all in a normal window, check whether a consent banner is holding storage back before you conclude the tag is broken.

A second check worth doing: open the Network tab, filter for collect, and reload. The request that fires carries the client ID as a parameter. The cookie stores it locally; the request is what sends it onward.

When the First-Party Distinction Actually Matters

For most teams this is a compliance-paperwork question, and the honest answer is that it rarely changes what you do day to day. There are four situations where it genuinely does.

Filling out a vendor or security questionnaire. "Does your analytics rely on third-party cookies?" has a defensible one-word answer, and now you can give it with the cookie names and domains to back it up.

Writing or reviewing your cookie notice. Measurement cookies belong in the analytics category of your consent banner, not the advertising category. Mislabelling them is a small error that an auditor will nonetheless find.

Diagnosing a browser-blocking complaint. When someone reports that traffic dropped after a browser update, knowing that GA4 cookies are first-party tells you where to look. Browser third-party cookie blocking is not the cause; JavaScript-set first-party cookie limits and tracker blocklists might be.

Deciding whether a cookieless or server-side setup is worth the work. You cannot evaluate that honestly until you know what the current setup actually relies on.

Comparing two analytics tools fairly. Vendors market heavily on the cookie question, and some of the sharpest marketing claims are technically true but irrelevant, because they contrast their own first-party approach with third-party advertising cookies rather than with how GA4 actually measures. Knowing the baseline makes those comparisons much easier to read.

Limitations: Where GA4's First-Party Cookies Still Break

First-party is more durable than third-party. It is not bulletproof, and the gap between those two statements is where a lot of unexplained reporting noise lives.

Browsers cap first-party cookie lifetimes. Chrome limits a first-party cookie to a maximum of 400 days when a visitor does not return in the meantime, so the two-year default is aspirational rather than real. Safari is far more aggressive: cookies set by JavaScript are typically held for around seven days, which means a Safari visitor who returns a fortnight later usually counts as new.

That inflates your new-user numbers. Every expiry, cleared-cookie event and switch to a different browser creates a fresh client ID. Your "new users" figure is therefore a count of new browsers with no cookie, not a count of human beings, and it skews high on Safari-heavy and mobile-heavy audiences.

Consent denial removes the cookie entirely. Under a properly configured consent banner, a visitor who declines analytics storage gets no _ga cookie at all. Depending on your configuration those visits are either modelled or simply absent.

Tracker blocking does not care about cookie party. Content blockers and privacy browsers commonly block the measurement script before it runs. No script, no cookie, no hit.

Cross-domain journeys need explicit configuration. Because the cookie is tied to one domain, a visitor moving from your marketing site to a separate checkout domain looks like two people unless cross-domain measurement is set up to pass the client ID across.

Multiple devices stay separate. The same person on a laptop and a phone is two client IDs and therefore two users, unless you send a stable user ID of your own from a login. No cookie policy on any browser will fix that one for you.

None of this is a defect in the first-party approach. It is the predictable cost of measurement that lives in the visitor's own browser under the visitor's own control.

Numbers nobody can explain are worse than no numbers at all. Book a free audit and see which of your traffic assumptions survive contact with the data.

GA4 Cookies vs the Alternatives

If the cookie dependency bothers you, there are three directions to go, each with a real trade-off.

• Server-side tagging. You move the measurement endpoint onto your own subdomain and set the cookie from the server instead of from JavaScript. This sidesteps the seven-day Safari limit on script-set cookies and survives some client-side blocking, at the cost of running infrastructure and the engineering time to maintain it.
• Cookieless or privacy-first analytics. Tools that fingerprint-free and cookie-free by design give you clean aggregate trends and usually need no consent banner, but they cannot do durable returning-visitor or multi-session attribution, because that is the thing the cookie was for.
• Server-log or edge analytics. Immune to every client-side blocker because it never runs in the browser, and correspondingly blind to on-page behaviour and anything requiring JavaScript.
• Consent-mode modelling inside GA4. Rather than replacing the cookie, you accept the gaps and let Google model the unconsented portion. Cheap to switch on, and the output is an estimate you should label as one when reporting.

The sensible default for most sites stays as it is: GA4 with first-party cookies, an accurate consent banner, and a clear-eyed understanding that your user counts are directional rather than exact.

A reasonable sequence, if you want to improve things without over-engineering: fix your consent configuration first, since it is free and is the largest single source of missing data on most sites; then set an honest retention window; then, only if returning-visitor accuracy genuinely drives a business decision, look at server-side tagging. Most teams stop usefully after the first two steps.

What you should not do is rebuild your entire measurement stack in response to a third-party cookie deadline. That deadline kept moving and then stopped moving altogether. Google missed its original 2024 target, replaced removal with a user-choice prompt in July 2024, abandoned the prompt in April 2025, and wound down the Privacy Sandbox initiative itself in late 2025. Third-party cookies remain supported in Chrome, enabled by default, with users free to block them in settings.

The irony is worth sitting with: the cookie apocalypse that drove a decade of measurement anxiety never arrived, and GA4 was never exposed to it in the first place.

Final Thoughts

GA4 is not a third-party cookie. It is an analytics platform that writes two first-party cookies, _ga and _ga_<container-id>, onto your own domain from JavaScript on your own page. You can confirm that in DevTools in under a minute, and the Domain column settles the argument on its own.

The more useful question is not which party owns the cookie but how much of your audience you are losing to expiry, consent and blocking, and whether you are reporting your user counts with the appropriate hedging. That is a measurement-quality conversation, and it is a far better use of an afternoon than re-litigating the cookie taxonomy.

It also pays to write that hedging down somewhere your stakeholders will see it. A single line on the dashboard noting that user counts are browser-based and understate repeat visitors prevents the quarterly conversation where someone treats a 4% change in new users as a finding. The limitation is not embarrassing; discovering it in a board meeting is.

If you are tidying up how parameters and identifiers flow through your reports, our guide to what fbclid is in Google Analytics covers the adjacent problem of ad-click parameters cluttering your data and how to handle them without breaking attribution.

Clean analytics deserves traffic worth measuring. Get a free SEO audit and find the organic opportunities your competitors have not taken yet.