The symptom
On paper the setup is the one everybody recommends. Collection runs through a server-side container, the endpoint sits on a subdomain of your client's own site, and the cookie is written by that server instead of by a script in the browser. You scoped it, the client paid for it, and the report should have moved.
Months later the same pattern is still in the data. Safari and iOS visitors keep arriving as new, conversions landing more than a week after the first click still have no campaign attached, and Chrome looks healthy. That last part is what keeps it out of the weekly call: if Chrome is fine, the implementation reads as fine, and the Safari gap gets filed under "that is just how browsers are now".
At Archon Labs this is one of the more common things agencies ask us to look at, and it is rarely a broken container. The container is doing what it was told. The cookie it sets is being capped anyway, and the reason has nothing to do with the domain name on the request.
Why does a first-party subdomain still get capped?
Because Safari does not decide what counts as first-party by reading the domain name. It follows where the name resolves.
The rule is about the DNS chain, not the domain
Safari 14 shipped a defense against what it calls third-party CNAME cloaking, defined by WebKit as "a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host's CNAME, if one exists". Where that applies, "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days".
A tracking subdomain usually fits that description precisely, because the vendor's setup guide told you to verify metrics.clientsite.com with a CNAME pointing at a host the vendor operates. The cookie is then set by a server, over HTTP, on your client's own registrable domain, and Safari caps it at seven days anyway, because the chain leaves the site. Nothing failed. The browser simply did not accept the premise.
Swapping the record type does not help either. WebKit's tracking prevention documentation states that "ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days", so pointing the subdomain straight at the vendor's IP address lands in the same place.
Some subdomains are not capped, and that matters before you migrate
The rule of thumb going around, subdomain bad and path good, is not what WebKit published. Its own examples separate three cases:
A collection host that CNAMEs to another host inside your client's own domain is not capped.
A collection host that resolves through the same chain as the site itself, a shared CDN for example, is not capped.
A collection host whose chain ends somewhere that is neither of those is capped at seven days. A vendor-hosted endpoint is that case.
So a subdomain riding the same CDN chain as the site is not capped, and something else is producing that client's gap. Establish which case you are in before you propose the work: the migration is real effort, and a wrong diagnosis costs more credibility than the fix earns.
The JavaScript cap is still underneath all of it
Seven days is not a new number. It is the cap Safari has applied to browser-written cookies since 2019, when WebKit capped "all persistent client-side cookies, i.e. persistent cookies created through document.cookie" to a seven day expiry, and its documentation adds that a cookie created in JavaScript on a landing page reached through a decorated link is capped to 24 hours. A Google or Meta click identifier is exactly that kind of decoration, so ad traffic gets the shortest lifetime of all.
Which is why order of operations matters here. Plenty of setups described as server-side still let the browser write the identifier, and moving the endpoint changes nothing while that is true. Get the cookie set in the response first, the distinction we cover in first-party cookies and the 400-day difference, and then the DNS question is worth asking. Chrome's ceiling for a server-set cookie is 400 days, per Chrome for Developers.
Blockers follow the chain too
Browsers are not the only thing resolving your DNS. uBlock Origin ships a setting that looks up canonical names and blocks on what it finds, on by default and, per its own documentation, supported on Firefox. Once a vendor's CNAME target is on a public list, the subdomain in front of it inherits that reputation. Ad blockers already strip 30-40% of tracking events before they leave the browser, and a shared vendor host is an easy thing for a list to target.
What good looks like
Collection on the same origin as the page. Not a subdomain, a path on your client's own domain, routed by the CDN or reverse proxy already sitting in front of the site. There is no separate chain for the cloaking rule to catch, so the lifetime you set is the lifetime you get, up to the browser's own ceiling.
This is not an Archon opinion. Google requires it for its own gateway when a CDN is involved, "Google tag gateway using a CDN requires a same-origin setup (e.g., example.com/abjfo)", per Google for Developers. Tagging vendors have followed, and Stape documents the same-origin route as a reverse proxy, CDN or edge configuration rather than a DNS record.
That difference is the real cost, and worth being straight with the client about. A subdomain is a DNS record you can add on your side in an afternoon. A same-origin path changes the delivery path of the client's website, so somebody with access to the CDN or the web server has to be in the room. That is the work Archon Signal exists to do, including the parts that get skipped: specifying it, testing it against the client's own traffic, and handing it over documented.
Two things it does not do. It does not recover what consent refusals and blockers remove, so roughly 95% of events is the realistic ceiling on any setup, and it stays a ceiling rather than a promise. And it does not decide whether the effort is justified: that depends on the client's Safari and iOS share, and on how long their buying cycle runs. A one-week impulse purchase loses little to a seven day cookie. A six-week considered purchase loses most of its attribution. On the accounts where the windows are long and the iPhone share is heavy, a server-side setup done properly recovers 15-40% more conversions against today's baseline, and that is the account to start with.
FAQ
We already pay for a custom domain on the container. Is that not first-party?
It is first-party by ownership, which is what the vendor sold you, and Safari's cap does not read ownership. If the subdomain resolves through a CNAME to your vendor's host, WebKit's definition of third-party CNAME cloaking covers it and the cookie in that response is capped at seven days. Same domain on the request, same server setting the cookie, different treatment.
Does this affect Chrome and Android as well?
The cap described here is WebKit's, and Chrome publishes a 400-day ceiling on cookie lifetime rather than a seven day cloaking cap. That is why the damage is concentrated rather than spread evenly. We covered the browser split and how to segment for it in why Safari and iOS quietly eat your conversions.
Is a same-origin path just a way around ad blockers?
No, and selling it that way is a mistake. The reason to do it is cookie lifetime and delivery from the origin the visitor is already on. A blocklist can target a path as easily as a host once it knows about it, and consent still decides whether you are allowed to collect at all. Treat the blocker benefit as a side effect that may change, not as the business case.
How do we tell which clients are affected without guessing?
Three checks, in this order. Whether the identifier is written by the server in the response or by a script. Where the collection host resolves, compared with where the site resolves. Then conversion rate per click split by browser, over a window longer than a week. The first two take minutes to establish, and the third tells you what the fix is worth in that account.
If you want to know which of your client setups is quietly capped, that is one of the first things we look at in a free tracking audit.