Most advice on Safari GA4 tracking jumps straight to the same answer: move to server-side GTM. That is often the right eventual fix, but recommending it before anyone has measured the actual gap is how stores end up spending on a server-side rebuild that moves a number nobody was tracking in the first place.
- Safari's Intelligent Tracking Prevention caps the lifetime of any cookie set by JavaScript, including GA4's identity cookie, long before most sessions would naturally expire.
- The visible symptom is not "GA4 is broken." It is Safari and iPhone traffic that looks like it converts worse and churns faster than it actually does.
- The fix is sequenced: quantify the gap on your own property first, then decide whether server-side tagging, a shorter attribution expectation, or just living with the noise is the right call.
What Safari's ITP actually caps
Apple's WebKit team documented the rule plainly when it shipped: Intelligent Tracking Prevention 2.1 caps "all persistent client-side cookies created through document.cookie" at a seven-day expiry, specifically because cross-site trackers had started hiding inside first-party cookie jars. WebKit's own ITP 2.1 announcement is explicit that the cap applies regardless of what expiry date the cookie itself requests.
GA4's identity cookie, _ga, is set exactly this way on most Shopify and WooCommerce stores: a JavaScript tag writes it to the browser, and Google's own documentation confirms it is meant to persist for a two-year default lifetime so GA4 can recognize the same browser across visits. Under ITP, that two-year intention gets overridden down to seven days, no matter what the tag asks for.
It gets tighter. If a visitor lands on your site through a link carrying query parameters from a domain ITP has classified as a tracker, WebKit's ITP 2.3 update cuts that same cookie's lifetime to twenty-four hours. A shopper who clicks a Meta or Google ad, a very common first-touch path for ecommerce, can be carrying exactly that kind of decorated link.
Why it reads as "Safari users don't convert" instead of "tracking is broken"
Once the _ga cookie expires, nothing visible breaks. The site still works, the purchase still fires, GA4 still records a session. What changes is identity: GA4 can no longer tell that the person buying today is the same person who browsed six days ago, so it issues a fresh client ID and logs a second "new user" where there was only ever one.
Run that forward across a real purchase cycle and the damage compounds. A shopper who sees an ad on a Monday, researches Thursday, and buys the following Tuesday has crossed the seven-day window at least once. In GA4's eyes, that can read as three different people: one session with no purchase, a second session with no purchase, and a third session that converts in isolation, with no visible path connecting them. The funnel looks thinner than it is, new-visitor volume looks inflated, and the Safari conversion rate looks worse than Chrome's for a product that performs identically on both.
This isn't a rounding error you can ignore once you check the scale. Safari holds roughly a sixth of global browser traffic and a meaningfully larger share of mobile sessions, since it is the default on every iPhone, per Statcounter's browser market share data. For a DTC brand skewed toward mobile shopping, which most are, that is not a tail case. It is a structural distortion sitting on top of whatever other tracking issues the account already has.
How to check whether your own GA4 is lying about Safari
Before building anything, run this comparison inside GA4 itself. Open an exploration, add browser as a breakdown dimension, and put two numbers side by side: the new-versus-returning visitor split for Safari against Chrome, and the session-to-purchase conversion rate for the same pair. If Safari shows a meaningfully higher new-visitor share and a meaningfully lower conversion rate than Chrome, despite both channels sending comparable traffic quality, that pattern is consistent with cookie churn, not an actual difference in how iPhone shoppers behave.
The second check is your own purchase cycle length. Pull the median days-to-purchase for converting customers, ideally from Shopify's own order timestamps rather than GA4's path-to-purchase report, since that report inherits the same cookie-churn problem you are trying to measure. If that number sits anywhere near or beyond seven days, a real share of your Safari conversions are crossing ITP's cap before they close, which means the gap above is not cosmetic, it is attribution and new-customer reporting actively miscounting your acquisition channels.
A third, cheaper check: look at how your Safari new-user count moves week over week against total Safari sessions. If new users on Safari track almost one-to-one with sessions, rather than settling into the kind of repeat-visitor curve Chrome shows for the same audience, that is the cookie reissuing itself on nearly every visit rather than persisting across them. None of these three checks require new tooling, only the GA4 property you already have and a Shopify order export. This is exactly the kind of discrepancy a free tracking audit is built to surface with your actual numbers rather than an industry average, before anyone recommends a rebuild.
The fix hierarchy, and what server-side GTM does not solve
Server-side tagging is the standard answer for a reason that holds up: WebKit's seven-day cap applies specifically to cookies "created through document.cookie," meaning a cookie set by an HTTP response header from a server endpoint on your own domain is not automatically subject to the same client-side cap. Moving the GA4 tag to run server-side, as we cover in our breakdown of how server-side GTM actually works, is how that durability gets reclaimed on Safari.
It is not a complete fix on its own. A declined consent banner still blocks the cookie entirely, no matter where it is set, because consent governs storage permission before any tagging architecture gets involved. And a server endpoint that Safari has separately flagged as third-party tracking infrastructure, which can happen with some generic tag-hosting setups, loses the same protection a properly configured first-party subdomain keeps. The purchase-side signal loss that stacks on top of this, Meta and Google Ads both losing conversions to the same browser restrictions, is the other half of the picture we walk through in our Meta Conversions API setup guide, since CAPI exists for the same structural reason server-side GTM does.
If the diagnostic above shows a real gap, a tracking setup rebuild that moves the GA4 and ad-platform tags server-side, with consent handled correctly first, is the next step, not the first one.
Deciding whether this is worth fixing right now
If Safari makes up a small share of your traffic and your purchase cycle closes well inside seven days, the ITP-driven gap is probably small enough to leave alone this quarter. If Safari carries a meaningful share of mobile sessions and your median days-to-purchase runs close to or past that seven-day window, the identity loss above is actively distorting how you read new-customer acquisition and channel performance, and it is worth quantifying before the next budget conversation rather than after a campaign gets paused over numbers that were never accurate to begin with.
