Cookie

A cookie is a small text record (a name, a value, and a few attributes) that a website asks the browser to keep for a domain. Cookies make stateless HTTP feel stateful: they remember a logged-in session, a shopping cart, an A/B-test bucket, or an analytics identifier between requests. This guide explains what a cookie is on the web, how first-party and third-party cookies differ, the three GA4 cookies you will see in production (_ga, _ga_<MID>, _gid), the attributes that protect them, and where the post-third-party-cookie web is headed.

What Is a Cookie?

A cookie is a key-value pair the browser stores on behalf of a domain. Servers create cookies via the Set-Cookie response header; the browser sends matching cookies back on every subsequent request to that domain through the Cookie request header. The format is defined in RFC 6265 and supported by every modern browser.

In computing terms, a cookie is the original mechanism that turned the stateless web into something usable. Without cookies the server cannot tell that two requests came from the same browser. With cookies, the server can recognize a returning visitor, keep them logged in, count a session, attribute traffic from a referrer or UTM, and persist a stable client_id for analytics.

How Cookies Work (Browser ↔ Server)

The lifecycle is short and predictable. The server responds with Set-Cookie: name=value; attributes. The browser stores the cookie scoped to the cookie’s domain, path, and security flags. On each subsequent matching request the browser automatically attaches the cookie. The server reads it and recognizes the visitor.

HTTP/1.1 200 OK
Set-Cookie: _ga=GA1.2.1234567890.1700000000; Path=/; Domain=.example.com;
            Expires=Wed, 24 Apr 2028 12:00:00 GMT; Secure; SameSite=Lax

Three things to notice. First, the cookie is scoped to .example.com, so it travels only with requests to that domain. Second, the Expires attribute makes it persistent across browser restarts. Third, Secure; SameSite=Lax are attributes, not part of the value; they shape browser behavior, not what the server reads.

First-Party vs Third-Party Cookies

The party of a cookie is determined by whose domain set it relative to the URL in the address bar. If the domain matches what the user typed, it is first-party. If the cookie is set by a different domain loaded inside the page (an iframe, a tracking pixel, an ad script), it is third-party. The user sees only one site, but the browser keeps separate jars per domain.

For analytics work the practical answer is simple: build everything on first-party cookies. Is _ga a third-party cookie? No: when GA4’s tag runs on your domain, _ga is set by your domain and is first-party. It only becomes effectively third-party when Google Analytics is loaded inside an iframe of someone else’s site.

Session Cookies vs Persistent Cookies

The other axis is lifetime. A session cookie has no Expires or Max-Age attribute, and the browser deletes it when the tab or browser closes. A persistent cookie has a future expiry timestamp and survives restarts until that date. Same wire format, different lifetime.

• Session cookies: shopping carts before checkout, CSRF tokens, server-issued login sessions. Lost on close, which is the point.
• Persistent cookies: “remember me” login, language preferences, analytics IDs like _ga. Configured with Max-Age=63072000 for two years.

GA4’s _ga is persistent at 730 days (two years) so the same browser is recognized as a returning user across multiple visits. Conversely, the per-property _ga_<MID> stores session state and refreshes its timer on activity.

GA4 Cookies: _ga, _ga_<MID>, _gid Explained

GA4 ships with a small, well-defined cookie set. All three are first-party cookies set on your own domain by the gtag.js or GTM container. None of them are required by GA4 to receive events; they are the default identification mechanism, and they are the reason most GA4 reports work without extra configuration.

For full reference, see Google’s documentation on Google Analytics cookie usage. If you write data to GA4 server-side via the Measurement Protocol, the cookie story changes: you generate the client_id yourself and send it as a parameter.

Cookie Attributes: Secure, HttpOnly, SameSite, Domain, Path

The bits that make a cookie safe live in its attributes, not its value. Five of them matter in practice:

• Secure: cookie is sent only over HTTPS. Mandatory for anything sensitive. Without it, an HTTP downgrade reveals the value.
• HttpOnly: cookie is invisible to JavaScript. Use for session/auth cookies to mitigate XSS. GA4’s analytics cookies are deliberately readable by JS, so they are not HttpOnly.
• SameSite: controls cross-site sending. Lax is the safe default; Strict blocks all cross-site sending; None allows everything but requires Secure. See MDN’s SameSite reference.
• Domain: which domain the cookie scopes to. Domain=.example.com covers subdomains; an absent Domain attribute restricts to exactly the host that set it.
• Path: which URL path prefix triggers cookie inclusion. Path=/ is the typical default.

Modern best practice for any non-analytics cookie: Secure; HttpOnly; SameSite=Lax. Drop HttpOnly only when JavaScript truly needs to read the cookie (analytics, A/B testing).

Cookie Privacy: GDPR, ePrivacy, CCPA

Three regimes shape what you can put in a cookie and when. Under GDPR and the EU ePrivacy Directive, any cookie that is not strictly necessary for the service (analytics, marketing, personalization) requires informed opt-in consent before it is set. Under California’s CCPA the rules are softer (opt-out is enough), and a cookie banner with a clear “do not sell” link is the working baseline. Both regimes require a documented inventory: every cookie’s name, purpose, expiry, and data controller.

Practically: gate any non-essential cookie write behind your CMP, log consent decisions, and surface the inventory in a cookie policy. Re-issue identifiers when consent changes; do not silently keep the old _ga value after a “reject all” click.

The Death of Third-Party Cookies (and the First-Party Pivot)

Apple Safari blocks third-party cookies by default since 2020 (ITP full blocking). Mozilla Firefox blocks them via Enhanced Tracking Protection. Google delayed its Chrome phase-out repeatedly but is now rolling out Tracking Protection broadly, with full deprecation of cross-site tracking cookies in progress. The direction of travel is clear: third-party cookies are not the future of identity on the web.

The pivot is to first-party signals plus server-side delivery: Measurement Protocol for backend events, server-side GTM for cookie issuance under your domain, and consent-aware identifiers like Google’s cross-device tracking via signed-in users. For a longer treatment, see the pillar on cookieless analytics strategies that actually work.

Frequently Asked Questions

Related Terms

• first-party cookie: cookies scoped to the visited domain
• cookie banner: consent UI for non-essential cookies
• GDPR: EU regulation governing cookie consent
• cross-device tracking: identity beyond a single browser jar
• Measurement Protocol: server-side delivery without browser cookies
• client_id: the GA4 identifier persisted in _ga
• session: what cookies stitch hits into
• attribution: depends on stable cookie-based IDs