"first-party tracking" doesn't mean what most apps say it means.
if a cookie is set on a third-party domain and just proxies through a subdomain of yours, that's not first-party. here's the technical bar — and why it matters under ITP.
“First-party tracking” is the most overloaded phrase in adtech right now. every analytics tool, server-side GTM wrapper, and conversion-API enhancer claims it. some of them really are first-party. most of them are doing something that looks first-party from the browser’s perspective but isn’t, technically.
This matters because Safari, Brave, and Firefox all enforce different rules on first-party vs third-party cookies, and they don’t take your word for it. they look at network behavior. if your “first-party” tracker is actually a third-party tracker wearing a costume, the browser may un-mask it and treat it accordingly.
The three tiers of “first-party”
Tier 1: True first-party
Your application sets cookies on its own domain, served from infrastructure you control. when a user is at yourstore.com and your server returns a Set-Cookie header, that cookie is unambiguously first-party. ITP gives it the full TTL you request. no browser is going to argue with this.
This is what Shopify’s own session cookies are. it’s also what Maximo’s tracking cookies are: we deploy a worker on a subdomain of your store (e.g. tag.yourstore.com), and the cookie is set in the HTTP response from that worker. the cookie’s Domain attribute matches the URL bar. nothing is being proxied to anyone else.
Tier 2: CNAME proxy
You set up a CNAME from a subdomain of your site to a vendor’s domain. track.yourstore.com CNAMEs to vendor-cdn.com. when the browser hits track.yourstore.com, it resolves the DNS, gets a vendor IP, and the vendor’s server returns the cookie with Domain=track.yourstore.com.
To the browser at first glance, this looks first-party — the cookie’s domain matches the URL. but Safari’s ITP, since version 14, specifically detects CNAME cloaking. if the CNAME target is on a known tracker list, the cookie gets capped at 7 days regardless of what the server requested. this is the rule that broke a lot of “we set up a CNAME so you’re first-party now” claims.
Most server-side GTM setups that use a vendor’s hosted tagging server fall into this bucket. they’re better than nothing — they’re not subject to third-party cookie blocks — but they’re not the full first-party experience.
Tier 3: Browser-side wrapper that calls a third-party
The script is loaded from your domain (or even inlined). but when it fires, it makes an HTTP request to a vendor’s domain — analytics-collect.com, track.someapp.io — and that’s where the cookie lives. this is the most common setup, and it’s not first-party in any meaningful sense. it’s just regular third-party tracking with a thin wrapper.
Tier 3 setups are the ones most affected by Safari and Brave. cookies set on the vendor’s domain are blocked outright by Safari, regardless of how the script was loaded.
open the network tab in dev tools on a fresh incognito window. load your store. look at the requests being made. the domain hosting your tracking script’s beacon endpoint tells you everything: if it’s a subdomain of your store and resolves to your infrastructure, you’re Tier 1. if it’s a subdomain of your store but the SSL cert belongs to someone else, you’re Tier 2. if it’s a domain you don’t own, you’re Tier 3.
Why this matters beyond Safari
Three reasons:
- Browser tracking-protection lists. Brave, Firefox, and increasingly Safari ship lists of known tracker domains. requests to those domains get blocked outright. Tier 3 setups are on these lists. CNAME-proxied Tier 2 setups used to evade them, but Brave and Firefox now do CNAME un-cloaking on the lists. Tier 1 setups, by definition, can’t be on a tracker list — the domain is yours.
- Privacy reviews and audits. EU regulators and US-state privacy enforcement increasingly look at where data flows, not what the cookie’s
Domainattribute says. a CNAME-proxied tracker still ships data to the vendor’s servers; that’s a third-party data transfer, full stop. for stores in regulated categories (health, finance, kids’ products) this is a real legal exposure. - Vendor lock-in. with Tier 3, your data lives on the vendor’s servers and you have whatever access their platform gives you. with Tier 1, your data lives on your infrastructure (or on the vendor’s, but written by your code, with no hidden enrichment). switching tools costs you less.
The honest version of every claim
If a vendor says “first-party tracking” without qualifying it, ask exactly two questions:
- What domain do beacon requests get sent to? if it’s not a subdomain of my store, they’re Tier 3.
- If it’s a subdomain of my store, is it CNAMed to your infrastructure, or do I deploy a worker on my own DNS? if CNAMed, they’re Tier 2.
Tier 2 is fine for most use cases, as long as the vendor is honest about it being Tier 2. Tier 3 with first-party branding is the thing to flag. and Tier 1 is what to ask for if you’re rebuilding your stack and have the option.
Domain attribute does not make tracking first-party. the network path of the request that set it does.How Maximo does it
Tier 1, with one caveat: you have to add a CNAME to a Cloudflare worker we deploy on your behalf. the worker runs on Cloudflare’s edge, but the response comes from a domain you control, with our code, and writes server-set cookies on your domain. data is forwarded server-to-server to the ad platforms; nothing about the user’s browser ever talks to a Maximo-owned domain.
Practical effect: ITP gives our cookies the full requested TTL. tracker lists don’t have us on them because there’s no tracker domain to list. and your data flows from your infrastructure to the ad platforms, with us as a processor on the path, not as a separate destination.
It’s slightly more work to set up than a script tag — typically 5–10 minutes including DNS propagation. it’s also genuinely first-party, in the way Safari and Brave actually check.