Full Answer

Safari-friendly cookies come down to who sets them and from where. ITP's seven-day expiry targets cookies created in JavaScript through document.cookie. Cookies your own server sets in the HTTP Set-Cookie header, on your genuine first-party domain, aren't created by a script and so aren't subject to the same cap. That single distinction is the whole game.

A few practical rules follow. Set the cookie from your origin or a true first-party subdomain you control, not a vendor's domain. Add HttpOnly so client scripts can't touch it, and SameSite=Lax so it survives normal navigation without leaking cross-site. Avoid the old CNAME-cloaking trick where a subdomain like metrics.yourstore.com secretly resolves to a third-party tracker; Safari detects that arrangement and applies the seven-day cap as if the cookie were third-party, so it buys you nothing.

All of this is far easier when tracking already runs server-side, because the server is issuing identity as part of the request rather than bolting it on in the browser. The conversion is then matched against first-party data you already store. If your current setup writes its identifiers in JavaScript, no amount of cookie configuration will hold against ITP. The durable answer is to move the cookie write to the server in the first place.