Google Analytics cookies are small first-party text files that let Google Analytics 4 (GA4) recognise unique visitors and stitch their pageviews into sessions. If you run analytics on a Singapore business site, these cookies decide whether your reports are trustworthy or quietly misleading. This guide covers what each GA4 cookie does, how long it lasts, and how consent and browser privacy settings change the picture.
Fair warning before you read on: if you learned Google Analytics before 2020, forget the __utma/__utmb cookies you remember. GA4 uses a completely different, smaller set. We’ll stick to what’s true today.
What are cookies, and are they dangerous?
Cookies are small text files stored in your browser and tied to the domains you visit. They cannot execute code, install anything, or damage your computer – a cookie is data, not a program.
For analytics, that data is how a site tells one visitor apart from another and remembers that your second pageview belongs to the same session as your first. Without cookies (or a modelled substitute), every pageview would look like a brand-new stranger.
What cookies does Google Analytics 4 use?
GA4 sets two first-party cookies by default: _ga and _ga_<container-id>. The _ga cookie stores a randomly generated client ID that identifies the browser across sessions; the _ga_<container-id> cookie holds session-state data for one specific GA4 property.
Here’s the full set you’ll typically see, and what each one does:
| Cookie | Purpose | Default expiry |
|---|---|---|
_ga |
Stores the client ID; distinguishes unique users across sessions | 2 years (capped ~13 months by browsers, see below) |
_ga_<container-id> |
Holds session state for a specific GA4 property | 2 years (same browser cap) |
_gid |
Distinguishes users over a short window; legacy, not always present in current GA4 | 24 hours |
_gcl_au |
Set only when GA4 is linked to Google Ads; conversion linking | 90 days |
According to Google’s official GA4 cookie documentation, GA4’s JavaScript tags use first-party cookies to distinguish unique users and unique sessions. Note that none of these carry names, emails, or other directly identifying information – only a random ID, timestamps, and behavioural markers.
One recent change worth knowing: in May 2025, Google silently altered the internal format of the _ga_<container-id> cookie. According to analytics consultant Ron Kopelman, the value is now split into labelled segments rather than a simple dot-separated string. Session tracking still works, but any custom script or server-side setup that parsed the raw cookie to pull the session ID likely broke. If you have a homemade cross-domain or CRM-reconciliation script reading that cookie, audit it.
What’s the difference between first-party and third-party cookies?
A first-party cookie is set by the domain you’re actually visiting; a third-party cookie is set by a different domain via content embedded on the page. GA4 cookies are first-party only.
If you visit getcloudrock.com and the cookie’s domain reads getcloudrock.com, that’s first-party – only that domain can read it back. A third-party cookie is set by an outside domain (an embedded ad or widget) and can be read across the sites that embed it, often without the visitor’s knowledge. That cross-site tracking is exactly what browsers have spent years dismantling.
This distinction matters more than it used to. Because GA4 relies on first-party cookies, it’s far more resilient to third-party cookie blocking than the ad-tech tags sitting next to it. But first-party isn’t a free pass either, as the next section shows.
How long do Google Analytics cookies actually last?
The _ga cookie has a default two-year lifespan, but most browsers now cap first-party JavaScript cookies at roughly 400 days (about 13 months), so that’s the real ceiling for many of your visitors. Safari cuts it far shorter.
Apple’s Intelligent Tracking Prevention (ITP) limits first-party cookies set via JavaScript in Safari to 7 days – and as little as 24 hours when a visitor arrives from a link ITP flags as a known tracker. According to Graphed’s analysis of GA cookie expiry, a loyal Safari visitor who returns every ten days will look like a brand-new user on every single visit, because their _ga cookie expired in between.
For a Singapore audience, this is not a fringe case. Safari’s share of mobile traffic here is significant, which means your “New Users” count is probably inflated and your “Returning Users” understated. The fix is a server-side implementation that sets the cookie via an HTTP header instead of JavaScript, which ITP’s 7-day limit doesn’t touch.
Where do Google Analytics cookies go wrong in your reports?
The two biggest sources of error are visitors deleting cookies and the same person using multiple devices — both inflate your user counts. GA4 has no way to know these are the same human.
Visitors clear their cookies. Aiya, you’ve cleared your own browsing history before — everyone has. When a returning visitor’s _ga cookie is gone, GA4 issues a fresh client ID and counts them as new. Combined with the Safari 7-day cap above, the “new vs returning” split in GA4 is best read as a rough signal, not gospel.
One person, many devices. Someone who browses on their phone at lunch and their laptop at the office is two separate users to a cookie-based system, because each device holds its own _ga cookie. The only reliable way to unify them is GA4’s User-ID feature, which requires visitors to log in so you can pass a consistent identifier – practical for membership or e-commerce sites, not for anonymous traffic.
Neither problem means GA4 is broken. It means you should treat user-level counts as directional and lean on trends and event data over absolute headcounts.
How does cookie consent change what GA4 collects?
Under a properly configured consent banner, GA4 sets no cookies at all until the visitor accepts – and if they decline while Consent Mode v2 is in Advanced mode, GA4 sends anonymous, cookieless pings instead. Those pings feed Google’s modelling to estimate the traffic you couldn’t measure directly.
This is the part most Singapore site owners get wrong. Analytics cookies are not “strictly necessary” under most privacy frameworks, so firing them before consent is a compliance risk. Under Singapore’s Personal Data Protection Act (PDPA), you need a clear basis for collecting personal data, and consent management is the clean way to establish it. Your cookie banner must actually gate GA4, not just display a notice while the cookies fire anyway.
Practically: deploy a consent management platform that integrates with Google Consent Mode v2, and make sure the “decline” path genuinely blocks _ga and _ga_<container-id>. If your banner is decorative, you have neither compliance nor accurate data – the worst of both.
Getting your analytics set up properly
Most of the reporting problems above trace back to one root cause: an analytics setup that was pasted in once and never revisited. GA4 rewards a deliberate configuration – correct consent gating, a decision on server-side tagging if your audience skews Safari, and cookie-expiry settings that match how you actually read your reports.
If you’d rather have that done right the first time than debug inflated user counts six months in, CloudRock handles GA4 implementation and analytics strategy for Singapore businesses. We’ll tell you plainly whether server-side tagging is worth it for your traffic, or whether the default setup is fine – no upsell for tooling you don’t need.
