First-party vs third-party tracking, in plain English
The distinction is not about who owns the data. It is about which domain the browser sees in the request — and that single fact decides whether your tracking runs at all.
party = whose domain the request goes to, from the browser's point of view
First-party means the request goes to the domain in the address bar. Third-party means it goes somewhere else. Blockers and browser policies work on that distinction alone — they do not know or care who owns the company behind the domain.
First-party is necessary but not sufficient: a first-party cookie written by JavaScript is still capped at 7 days in Safari.
“First-party data” has become a marketing phrase, which has made it less useful than the technical distinction underneath it. Here is the technical version, which is simple and consequential.
The definition
First-party = the request goes to the domain in the address bar.
Third-party = the request goes anywhere else.
That is the whole thing. You are on yourstore.com:
| Request to | Party | Why |
|---|---|---|
yourstore.com/api/events |
First | Same domain as the address bar |
analytics.yourstore.com/collect |
First | Same registrable domain |
google-analytics.com/collect |
Third | Different domain |
connect.facebook.net/…/fbevents.js |
Third | Different domain |
flowsk.com/api/events |
Third | Different domain — including ours |
Note the last row. We are third-party too, if you install the snippet directly. That is why proxy mode exists.
Why it decides whether tracking runs
Ad blockers and tracking protection work on hostnames. Their lists contain google-analytics.com, connect.facebook.net, analytics.tiktok.com and a few thousand others. When the browser is about to make a request to a listed host, the request never happens.
The block occurs before any of your code runs. There is no error to catch, no fallback to trigger, no retry. From your page’s perspective the tag simply does not exist.
A request to your own origin is not on any list, cannot be, and would be catastrophic to block — so it is not blocked.
That is the entire practical difference: third-party requests are optional from the browser’s perspective; first-party ones are not.
Where “we own our data” goes wrong
Plenty of tools describe themselves as first-party because you own the account and the data is yours contractually.
The browser has no idea about your contract. It sees a request to a domain other than the one in the address bar, checks its list, and decides. Ownership is a commercial fact; party is a technical one, and only the technical one affects whether the request completes.
The part most people stop too early on
Going first-party solves blocking. It does not solve durability.
A first-party cookie written by JavaScript — document.cookie = "_id=abc" on your own domain — is still capped at seven days by Safari’s ITP. You have solved “does the tag run” and not touched “does the identity persist.”
Both properties are required, and they are independent:
| Setup | Survives ad block | Survives ITP |
|---|---|---|
| Third-party script, third-party cookie | ✗ | ✗ |
| Third-party script, first-party JS cookie | ✗ | ✗ |
| First-party script, first-party JS cookie | ✓ | ✗ |
| First-party script, server-set cookie | ✓ | ✓ |
Only the last row is actually durable. Most “first-party” migrations land on the third row and are surprised when the window is still seven days.
The shortcut that does not work
CNAME cloaking — pointing analytics.yourdomain.com at a third-party host so its cookie looks first-party — has been the industry’s favourite workaround for years.
Safari detects it and caps CNAME-cloaked cookies at seven days regardless. Blocklists have started including the pattern. And it is, straightforwardly, a disguise: you are presenting a third-party request as first-party to a browser that is trying to enforce a user’s stated preference.
The alternative is not more clever: your own backend receives the request and forwards it server-to-server. Nothing is disguised, because nothing needs to be.
What to do
- Audit what you have. The first-party tracking scanner lists every request on your page by party and vendor.
- Move the identity to your server. A
Set-Cookieresponse header, first-party, long expiry. That gets you row four. - Route events through your own origin if you want the blocking immunity too.
- Keep the ad platform pixels. They are third-party and blockable, and that is fine — they are optimisation fuel, not your ledger.
Frequently asked questions
Is a tool 'first-party' if I pay for it?
No. Ownership is a commercial fact; party is a technical one. If your page makes a request to a domain other than the one in the address bar, that is third-party to the browser, whoever sends the invoice.
Does a subdomain count as first-party?
For cookies, yes — analytics.yourdomain.com shares the registrable domain. But if that subdomain is a CNAME to a third-party host, Safari detects it and treats the cookie as third-party anyway.
Why do blockers block by domain?
Because it is the only signal available before the request runs. Blocklists are lists of hostnames, which is why the fix is not obfuscation but genuinely moving the request to your own origin.
If I go first-party, do I still need consent?
Usually yes, where you are storing an identifier or personal data. First-party changes reliability, not lawful basis. Treat them as separate questions.
What is the fastest way to check my site?
Run the first-party tracking scanner. It lists every script the page loads, classified first vs third party, with the vendor identified.
Find out what your page is actually loading
Every script on the page, classified first vs third party, with the vendor named and the risk explained.
Stop guessing which ad made the sale.
Flowsk Signals stitches the anonymous click to the email to the purchase — first-party, server-side, de-duplicated. One snippet, $29/mo, and every conversion comes with a receipt you can inspect.