The distinction browsers actually enforce is not who owns the data afterward. It is which
domain made the request or set the cookie in the moment. A tracking script loaded from
doubleclick.net on your site is third-party tracking even if the resulting report
lands in your dashboard. A click logged by your own domain, or a subdomain that resolves to your
own infrastructure, is first-party even if a vendor built the software running it.
First-party vs third-party tracking
| First-party tracking | Third-party tracking | |
|---|---|---|
| Who sets the cookie or logs the event | The domain shown in the address bar | A separate domain, usually an ad or analytics vendor, embedded on the page |
| Safari (Intelligent Tracking Prevention) | Allowed; JavaScript-set cookies capped at 7 days, server-set cookies not capped the same way | Blocked entirely |
| Firefox (Total Cookie Protection) | Allowed and persists normally | Partitioned per site, so it still works but cannot follow a person across different domains |
| Chrome | Allowed | Allowed by default; Google walked back its plan to remove third-party cookies wholesale and instead added user-facing controls |
| Typical example | Your own site logging a page view or a redirect click | An ad network's pixel tracking the same visitor across unrelated sites |
First-party data vs first-party tracking
These two phrases get used interchangeably, and they should not be. First-party data is the resulting asset: your customer list, your click log, your email subscriber base. First-party tracking is the collection method that produces it. You can have first-party data that was originally gathered through a third-party mechanism, an imported list bought from a broker, for instance, and that data does not become more trustworthy just because you now hold it. The label describes how something was collected, not who currently has it.
The part most explainers skip: first-party is not automatically private
Being first-party describes where the browser sees the collection happening, not what happens to the data afterward. A site can log a visit entirely first-party, in its own domain, and then forward that data server-side to a dozen other companies through server-to-server integrations the browser never sees and cannot block. Server-side tracking, sometimes marketed as a workaround for cookie restrictions, is a genuine example of this: it is first-party by the browser's definition and can still end up feeding third-party systems, because the browser only ever evaluates the request it can see, not what a server does with the data next. First-party is a technical category about request origin. It is not a guarantee about where the data ends up.
This is also why a custom domain matters more than most people assume. A link-in-bio page
hosted on a shared domain like bio.link/yourname puts every visitor's click under
that shared domain's cookie jar, not yours, which is closer to third-party behavior from the
browser's point of view even though the page looks like it belongs to you. Raydar's paid plans
serve the same page through a real reverse proxy on the customer's own custom domain, which is
what keeps the resulting click and cookie data first-party to that business rather than pooled
under a domain the business does not control, a distinction covered in more detail on the
pricing page where custom domains become available.
How to tell which one you are looking at
- Check the domain in the request, not the company name on the dashboard. If the request goes to your own domain or a subdomain you control, it is first-party.
- Open your browser's network tab on your own site. Requests to unfamiliar domains, ad networks, analytics vendors, chat widgets, are third-party by definition, regardless of how the resulting report is labeled internally.
- Remember that "we only use first-party cookies" is a narrower claim than "we don't share your data", and the two are often confused in privacy copy.
- If you are trying to identify who a visitor is rather than just where a cookie was set, that is a related but separate question, covered in website visitor tracking and what a visitor ID actually is.
A worked example
A small business runs a link-in-bio page. If that page lives at a shared domain the provider controls, every visit is logged under that shared domain's cookie space, alongside every other customer using the same provider. Move the same page to the business's own custom domain, through a proper reverse proxy rather than a redirect, and the exact same click event is now recorded under a domain only that business uses. Nothing about the tracking code changed. What changed is which domain the browser considers the requester, and that single fact is the entire difference between first-party and third-party in the eyes of Safari's and Firefox's privacy rules.
A plain redirect does not get you this. If the "custom domain" is just forwarding traffic on to a shared domain rather than serving the page itself, the browser still sees the shared domain doing the actual work, and first-party status does not transfer. The distinction between a reverse proxy and a simple redirect sounds like an implementation detail. It is the thing that decides whether cookie data survives Safari's rules at all.
Why this keeps coming up in 2026
Third-party cookies have been steadily restricted for years, blocked outright in Safari since 2020 and partitioned in Firefox since 2022, which is why first-party tracking has become the practical default for anyone who wants attribution data that survives more than one browsing session. Link tracking protection, a separate but related browser feature, exists for much the same reason: both are downstream of the same shift toward limiting what can be tracked across sites rather than within one. If you are deciding how to instrument a link-in-bio page or a landing page, the practical question is not whether a vendor is involved, almost every stack involves one, but whether the requests that matter run on a domain you control.