What it does
`_ga` holds a client ID: a randomly generated value used to distinguish a browser across visits. Google’s current GA4 documentation lists `_ga` for distinguishing users and `_ga_<container-id>` for persisting session state. It is pseudonymous rather than anonymous in the legal sense; other data and access available to the parties determine identifiability.
It is written through JavaScript running in your page, which means it sits on your own domain. That makes it a first-party cookie, and it is the reason a domain-based audit misattributes it to the site rather than to Google. The scanner matches the name first, so `_ga` is reported as Google Analytics wherever it is found.
A companion cookie named `_ga_` followed by the measurement ID holds GA4 session state. Both belong to the same purpose and the same category.
What to write in a cookie declaration
Describe it by what it does rather than by its name. "Distinguishes returning visitors so that sessions can be counted" is accurate and readable; "Google Analytics cookie" tells a visitor nothing they did not already infer.
| Field | Value |
|---|---|
| Name | _ga |
| Provider | Google Analytics |
| Purpose category | analytics |
| Consent category | Analytics |
| Expiry | 2 years (vendor default) |
| Storage | First-party, written by script |
Treat the expiry as indicative
The value above is the vendor’s documented default. Vendors change configuration and several browsers cap script-written lifetimes. Record what repeated scans observe on your own site, with the browser, region, path and interaction state; one run is not authoritative for every visitor.
Can a visitor refuse it?
Yes. A standard Google Analytics identifier is not strictly necessary to deliver the page a visitor requested, so it should be withheld where prior consent is required. Some authorities recognise narrowly conditioned audience-measurement exceptions; relying on one requires a documented, jurisdiction-specific configuration. Under StrongPrivacy’s opt-in model the managed Google Analytics loader is not created before analytics consent, so it cannot write this cookie.
A verification scan supplies runtime evidence for the pages and states it exercises. Test a fresh profile with no choice made, then after refusal, and reconcile observed storage with response headers, server-side integrations and paths the scan did not visit.
Common questions
Is _ga a first-party or third-party cookie?
First-party. It is written by script running in your page, onto your own domain. That says nothing about who benefits from it, which is why first-party status does not make it consent-exempt.
Does _ga contain personal data?
It contains a pseudonymous identifier. In the EEA that is treated as personal data where the individual is identifiable, and Recital 30 of the GDPR names cookie identifiers explicitly.
Can I shorten the _ga lifetime?
Google Analytics exposes a cookie expiry setting, and shortening it is a reasonable minimisation step. It does not remove the consent requirement, because the identifier still exists.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- Google Analytics: cookie usage on websites
Vendor documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.