First-party vs third-party cookies, explained for marketers
Every conversation about tracking ends up at cookies, and most of those conversations use "first-party" to mean "good" and "third-party" to mean "doomed". The real distinction is narrower and more useful: it is about which domain a cookie belongs to, and that single fact decides how long browsers let it live, which decides whether a visitor who comes back in three weeks is still the same visitor to your reports.
The definition
A cookie belongs to the domain that set it. On yoursite.com, a cookie for yoursite.com (or any of its subdomains) is first-party. A cookie for facebook.com or doubleclick.net, set because a script or pixel from that domain loaded on your page, is third-party. Same cookie, same company; what changes is the domain it is filed under, and whether the browser will send it back on the next visit.
What browsers do with each
- Third-party cookies are blocked by default in Safari, Firefox and Brave, and have been for years. Chrome kept them after reversing its removal plan in 2024, with tracking protections and a user choice around them. For cross-site identification they are no longer dependable anywhere.
- First-party cookies set by JavaScript, which is how the Google tag sets
_gaand the Meta pixel sets_fbp, live 7 days in Safari and iOS. If the visitor landed from a link decorated by a known tracker, 24 hours. Firefox applies similar limits. - First-party cookies set by your own server in an HTTP response keep their full lifetime, up to Chrome's ceiling of 400 days. Safari adds one condition since version 16.4: the server that sets them must look like your own, meaning no CNAME to another company and an IP address in the same range as your website's. A tagging subdomain on another provider's server fails that test and drops back to 7 days.
Why marketers should care
- Returning visitors. A cookie that expires after 7 days makes every second visit after a week a new user: inflated new-user counts, shorter paths, lower lifetime value.
- Attribution windows. A click on Monday and a purchase in three weeks only connect if the cookie that remembers the click is still there. Google Ads'
_gcl_aw, Meta's_fbcand TikTok's_ttpare all capped the same way. - Audiences. Remarketing lists are built from recognised visitors. Cap the cookie, shrink the list.
- Consent is a separate question. First-party does not mean consent-free. The ePrivacy rules apply to any storage on the device that is not strictly necessary, whoever owns the domain.
Which cookie is which
| Cookie | Platform | Set by | In Safari by default |
|---|---|---|---|
_ga, _ga_* | Google Analytics | JavaScript, first-party | 7 days |
FPID | Google Analytics via a server container | Your server, first-party | Full lifetime on your own domain |
_gcl_aw, _gcl_gb | Google Ads | JavaScript, first-party | 7 days |
_fbp, _fbc | Meta | JavaScript, first-party | 7 days |
_ttp | TikTok | JavaScript, first-party | 7 days |
_uetmsclkid, _uetvid | Microsoft Ads | JavaScript, first-party | 7 days |
_epik | JavaScript, first-party | 7 days | |
li_fat_id | JavaScript, first-party | 7 days | |
__oppref, __obref | ChatGPT Ads | JavaScript, first-party | 7 days |
fr, IDE | Meta, Google (ad serving) | Third-party | Blocked |
What server-side tagging changes, and what it does not
Moving your tags to a server container on your own subdomain makes the requests first-party: the container and the hits come from mbase.yoursite.com instead of googletagmanager.com. The cookies in the table are still set by JavaScript in the browser, with the same 7-day cap, unless something re-sets them from the server. That is the job of two power-ups:
- Cookie Keeper re-issues the marketing cookies it recognises from the server with their full lifetime, on every request.
- Same-Origin Tracking serves the tagging from a path on your own website, so the server that sets those cookies is your own address and Safari's 16.4 rule is satisfied. Without it, Cookie Keeper helps everywhere except Safari.
Click IDs that browsers strip from the landing URL before any cookie exists are a related problem, solved by Click ID Restorer.
Frequently asked questions
Is a CNAME subdomain first-party?
To the cookie specification, yes. To Safari, no: it detects CNAME cloaking and caps the cookies at 7 days, the same as a JavaScript cookie.
Is a tagging subdomain third-party?
No, it is a subdomain of your own domain, so its cookies are first-party and unaffected by third-party blocking. Safari's 7-day cap on cookies from a server in another IP range is a separate rule, and the one Same-Origin Tracking exists for.
Do I still need a cookie banner for first-party cookies?
Yes, for every cookie that is not strictly necessary for the site to work. Analytics and marketing cookies are not, whoever sets them.