The _ga cookie is the main cookie set by Google Analytics 4 on your website. It stores a randomly generated client ID so GA4 can tell when the same browser comes back, which is how it counts users and links several visits together.
How the _ga cookie works
When the Google tag loads and analytics storage is allowed, it looks for an existing _ga cookie. If there is none, it creates one with a value such as GA1.1.1234567890.1727000000. The last two numbers form the client ID: a random number and the time of the first visit. Every event GA4 records from that browser carries this ID.
Alongside it, GA4 sets a second cookie named _ga_ followed by your measurement ID without the “G-” (for example _ga_ABC123XYZ). This one keeps track of session state, including the current session and how many sessions the browser has had, so GA4 can tell a new visit from a continuing one.
Both are first-party cookies, set on your own domain rather than Google’s. By default they last two years and are refreshed on each visit, though you can change that in the tag settings. Browsers can shorten that: Safari’s tracking prevention limits cookies set by JavaScript, so returning Safari visitors after a gap of about a week can appear as new users.
Why it matters
Almost every user-based figure in GA4 depends on this cookie. If it is blocked, cleared or never set, GA4 cannot connect visits, so returning customers look new and conversion paths break apart. With consent mode, GA4 can still receive cookieless signals from visitors who decline and estimate some of the missing activity, but those are estimates.
In the UK, the _ga cookie is commonly listed in cookie policies as an analytics cookie that needs consent under PECR, because it is not strictly necessary to provide the service the visitor asked for. The Data (Use and Access) Act 2025 adds a narrow exception for some analytics used only to improve your own site, where visitors are told clearly and can object. Check whether it is in force and what the ICO’s current guidance says before relying on it (this entry was written in October 2026), and note that a GA4 setup sharing data with Google for advertising, or with Google signals switched on, is unlikely to fit an exception designed for first-party statistics.
Common mistakes
- Setting _ga before the visitor has made a choice on the cookie banner.
- Describing _ga as “strictly necessary” in a cookie policy.
- Listing the wrong duration, or forgetting the separate _ga_ session cookie altogether.
- Running two GA4 setups (one hard-coded, one through Tag Manager) that both write to the same cookie, causing double counting.
- Assuming every visitor is counted, when declines and browser limits remove a share of them.
How to act on it
Run a quick cookie audit: open your site in a private window, open the browser’s developer tools and check the cookies before you click anything on the banner. If _ga is already there, your consent setup is not working for UK visitors.
Make sure your cookie policy lists both _ga and the _ga_ session cookie, with their purpose and duration. If you want to rely on the analytics exception, document why your configuration fits it and keep your privacy notice and objection route clear.
Getting consent and GA4 working together properly is part of the tracking setup I include in performance marketing for UK businesses.