How Does a First-Party Analytics Cookie Actually Get Set and Scoped to My Domain?
A first-party cookie is set by (and scoped to) the domain the visitor is actually on - when your site's own tracking script writes a cookie via document.cookie or an HTTP Set-Cookie response header from your own domain, the browser attaches that cookie only to future requests to that same domain. A third-party cookie, by contrast, is set by a script or resource loaded from a different domain than the one in the address bar, which is exactly what browsers now restrict by default.
Why this happens
Cookie "party" status is determined entirely by which domain set the cookie relative to the domain shown in the browser's address bar - not by intent, and not by who technically owns the tracking relationship. If your site loads a script from a third-party vendor's domain and that script sets a cookie under its own domain, that cookie is third-party even if you configured and paid for the integration yourself.
GA4's own _ga and _ga_<container-id> cookies are first-party by design: the gtag.js library writes them under your site's domain (not google-analytics.com), which is precisely why GA4 mostly survived the third-party cookie crackdown that killed off cross-site ad-tracking cookies. The confusion arises because people assume "made by Google" means "set by Google's domain" - it doesn't, here.
Domain scoping follows the same logic: a cookie set on www.example.com is, by default, only sent back on requests to www.example.com, not a subdomain like shop.example.com, unless the cookie's Domain attribute is deliberately widened (to .example.com) to cover the whole domain and its subdomains - exactly the mechanism cross-subdomain tracking depends on, and exactly what breaks it when configured wrong.
Fix it
- 1
Confirm which domain is actually setting the cookie
Open your browser's DevTools > Application > Cookies panel while on your site, and check the Domain column next to your tracking cookie. If it reads your own domain (or a leading-dot version of it, like .example.com), it's first-party. If it reads a vendor's domain, the cookie itself is third-party regardless of how the integration is marketed.
- 2
Decide the correct Domain attribute scope for your setup
If tracking needs to work on a single domain only, leave the cookie scoped to that exact host. If you need continuity across subdomains (www.example.com and shop.example.com sharing one session/identity), the cookie must be explicitly set with Domain=.example.com - most analytics platforms expose this as a "cookie domain" configuration setting rather than requiring you to write the Set-Cookie header by hand.
- 3
For genuinely cross-site tracking, move server-side rather than fighting the browser
Third-party cookies are being actively phased out by browser policy, not a bug you can patch around client-side. If a vendor integration genuinely needs to persist identity across separate domains you don't control together, a server-side, first-party-proxied approach is the durable fix, not a client-side cookie workaround.
- 4
Set Secure, SameSite, and expiry deliberately, not by default
A first-party analytics cookie should generally carry SameSite=Lax (or Strict, if you don’t need it sent on top-level cross-site navigations) and Secure (HTTPS-only). Leaving these unset invites browser-specific default behavior that can differ between Chrome, Safari, and Firefox - pin the values instead of relying on defaults matching across browsers.
How to verify it worked
In DevTools > Application > Cookies, inspect the cookie's Domain, Secure, and SameSite columns after a fresh page load.
Passing: Domain matches your own site (or the intended subdomain scope), Secure is checked (on an HTTPS site), and SameSite is set to a deliberate value rather than blank.
Still broken: If Domain shows a vendor's domain when you expected first-party behavior, the script is likely still calling out to the vendor's endpoint directly instead of through a first-party-proxied path.
If cross-subdomain tracking is the goal, navigate from the root domain to the subdomain and re-check the cookie in DevTools.
Passing: The same cookie (same value) is present and readable on both www.example.com and shop.example.com, confirming the Domain attribute is correctly scoped to cover both.
Still broken: If the subdomain shows a different cookie value (effectively a new session), the Domain attribute is still scoped to the single host - widen it to the leading-dot form and retest.
If this is happening on a client-critical property, we'll verify it directly.
A data audit checks this exact failure mode against your actual implementation, not a generic checklist.