"For some reason, the numbers only don't add up for our iPhone users." This is a slow-burning but increasingly common complaint in ad operations and site optimization. It tracks correctly in Chrome, yet traffic through Safari (iPhone, iPad, Mac) comes back thin. You don't remember changing a thing — but the numbers just don't reconcile. Most of the time, the cause is cookie restrictions imposed by ITP (Intelligent Tracking Prevention), built into Safari by default.
Do any of these sound familiar?
- Lots of traffic from iPhone and Mac, yet only Safari conversions are low
- In GA4, the new-user rate for Safari is abnormally high (the same person seems to be counted as new over and over)
- A conversion from an ad clicked a few days ago isn't attributed, even though it's within the attribution window
- Users who should be treated as returning visitors look like first-time visitors every single time
- Ad click IDs (
gclid,fbclid) stop working after a few days
This guide explains how Safari's ITP causes conversions to drop or go missing, why repeat-visitor identification and attribution break, what you can do about it, and how to verify — in your real production environment — exactly how cookies are being handled right now.
First principle: ITP isn't a "malfunction," it's a privacy feature
The biggest reason this goes wrong is assuming that lower numbers on Safari mean a "broken tag" or a "setup mistake." In reality, this is the result of a privacy protection deliberately built into Safari (more precisely, into its browser engine, WebKit). It isn't something you can "fix" — it's a spec you need to account for as a given from the start.
Here's what ITP actually does:
| What ITP does | Concrete behavior |
|---|---|
| Caps first-party cookie lifespan | First-party cookies set via JavaScript (document.cookie) are deleted after 7 days at most. After a cross-site navigation (link decoration — a redirect with query parameters), it can shrink to 24 hours |
| Blocks third-party cookies | Cookies set by other domains are blocked by default, cutting off cross-site tracking |
| Suppresses cross-site measurement | Progressively restricts identifying a user across sites |
The key point: the more a cookie is set via JavaScript, the shorter its lifespan is treated as. Most measurement tags set cookies through exactly that JavaScript path — which is why the foundation of your measurement runs head-on into Safari's ITP.
Why "gone in 7 days" drops your conversions
The ITP rule that matters most in practice is the cap on first-party cookie lifespan at 7 days maximum. Here's why that reduces your numbers, broken into four effects.
1. Repeat-visitor identification breaks
Measurement tags store an identifier in a cookie (like _ga for GA4) to recognize a user. When that identifier is deleted after 7 days, the same person returning on day 8 is recounted as a "different new user." The result: fewer repeat visitors, and new users inflated beyond reality.
Common pitfall: "the new-user rate for Safari is weirdly high" — this often isn't acquisition going great. It's a sign that
_gais being reset and the same person is being counted as new again and again.
2. The attribution window effectively shrinks
Even if you've set "count conversions within 14 days of an ad click," if the cookie used for that judgment is gone in 7 days (sometimes 24 hours), the back half of the window simply can't be attributed. No matter how long your configured attribution window is, on Safari you can only pick up results within a substantially shorter window.
3. gclid / fbclid storage expires
Users arriving from ads carry a click ID indicating which ad they came from (Google's gclid, Meta's fbclid). Many implementations store these in a first-party cookie via JavaScript and read them back when the user later converts. But if that cookie is gone in 7 days, a later conversion can't be tied back to the ad click. You end up with "there was a click, but the result isn't credited."
4. New users get inflated
As effects 1–3 stack up, on Safari the same person is counted as new repeatedly, inflating user counts and the new-user rate beyond reality. Because the denominator swells, you also get a secondary distortion: conversion rate (CVR) looks lower than it actually is.
It's not just Safari: all iOS browsers are affected
A detail many teams overlook: on iOS (iPhone and iPad), every browser — Chrome, Firefox, Edge, and others — uses Apple's WebKit engine under the hood. Apple's App Store policy requires this. That means ITP's cookie restrictions apply to all of them, not just the Safari app.
In practice, this means:
- A user opening your site in "Chrome on iPhone" is still subject to the same 7-day cookie cap and third-party cookie blocking as Safari
- Your Safari-specific traffic reports understate the true scope of ITP impact — the losses extend to all iOS browser traffic
- The share of affected users is much larger than Safari's standalone market share suggests
When estimating impact, look at total iOS traffic, not just Safari sessions.
Third-party cookie blocking is at work too
On top of the lifespan cap, ITP blocks third-party cookies set by other domains by default. Historically, ad retargeting and cross-domain measurement leaned on these third-party cookies.
Because Safari won't allow them:
- Users can't be identified across sites, so your retargeting audience shrinks
- Tying a completed purchase across multiple domains (e.g., your main site and a payment domain) breaks more easily
- The more your measurement relies on external-domain tags, the larger the loss on Safari
In short, Safari applies a double restriction — "short-lived first-party cookies" plus "third-party cookies denied by default" — so if you run the same implementation as Chrome, it's no surprise the numbers don't line up.
Why conversions drop even though the tag "fires"
The tag is running (firing), yet the report numbers fall. This is the most confusing pattern with ITP. The reason: firing (a request is sent) and being measured (continuous, cookie-based identification) become decoupled.
On Safari, even when the tag fires correctly and requests go out:
- Cookies vanish in 7 days, so the same person can't be identified continuously (repeats masquerade as new)
- When click-ID storage expires, you lose which ad drove the result
- Third-party cookies are unavailable, so cross-site and cross-domain stitching breaks
So even if you confirm "the request is firing in Network," if the cookie behind it is being shortened or expired, it is not recorded as a continuous, ad-usable conversion. Checking only whether the tag fires will never reveal an ITP problem.
The hidden cost: ad algorithms degrade when signals go missing
The impact of ITP goes beyond inaccurate reports — it actively degrades how well your ad campaigns perform. Ad platforms like Google Ads and Meta Ads rely on conversion signals to train their machine-learning models. When Safari (and iOS) conversions go unreported:
- Smart Bidding and campaign optimization receive incomplete data. The algorithm sees fewer conversions than actually occurred, so it under-values audiences and placements that do convert — especially those skewing toward Apple devices.
- Campaigns may enter "limited learning" status. When a campaign's reported conversions fall below the platform's threshold (often around 50 per week), the algorithm can't exit the learning phase, leading to erratic delivery and higher costs.
- Lookalike and similar audiences lose accuracy. With a biased conversion pool that under-represents iOS users, the platform builds audience models that skew toward non-Apple demographics, potentially missing your highest-value customers.
This creates a vicious cycle: fewer reported conversions lead to worse optimization, which leads to genuinely fewer conversions, which produces even less signal for the algorithm. Breaking this cycle requires feeding conversion data back to the platform through a path that bypasses browser-side cookie limitations — which is where server-side tagging and Conversions APIs come in.
What you can do: mitigations for ITP
You can't "turn off" ITP, but you can soften its impact by changing how cookies are set. The direction is: "replace cookies set via JavaScript with a longer-lived method."
1. Set first-party cookies from the server (HTTP cookies)
A first-party cookie set by the server via the HTTP response header (Set-Cookie) — rather than via JavaScript (document.cookie) — is much less likely to be subject to ITP's 7-day cap. Shifting identifier storage to the server side is the most fundamental mitigation.
2. Use server-side tagging (server-side GTM)
This moves tag processing out of the browser and through a server you control. Because cookies can be handled server-side (on your own domain), they're less exposed to lifespan caps and blocking. The implementation is heavier, but it's a high-impact measure against Safari losses.
3. Send directly from the server with a Conversions API (CAPI)
Instead of going through the browser, this sends conversions from your server directly to the ad platform (such as Meta's CAPI). Because it's less dependent on the browser's cookie situation, it can backfill losses on Safari. Pairing a CAPI with enhanced conversions strengthens the match rate by sending hashed first-party data alongside the conversion event.
Common pitfall: even when you think you've moved to server-side, it's not unusual for the actual cookie to still be JavaScript-set (not a
Set-Cookieheader). "Having implemented it" and "the cookie actually being issued as an HTTP cookie" are two different things. You need to confirm, in your production response headers, that the cookie really is server-issued.
Watch out: the IP-matching rule can undo your server-side fix
Since Safari 16.4, WebKit applies an additional check: if the IP address prefix of the server issuing the Set-Cookie header does not match the IP address prefix of the website's origin server, the cookie is capped at 7 days — even though it was set server-side.
This catches a common deployment pattern: your site runs on one hosting provider while your server-side GTM container runs on a different cloud (Google Cloud, a managed sGTM service, etc.). Because the IPs are in different ranges, Safari silently overrides your cookie expiry back to 7 days, and your mitigation quietly stops working.
What to check:
- Confirm that your sGTM endpoint and your website resolve to IP addresses in the same prefix range
- If you use a CNAME subdomain (e.g.,
data.yoursite.com) pointing to a third-party tracking server, WebKit's CNAME cloaking detection may also cap the cookie - After deployment, verify the actual cookie expiry on a production Safari browser — the
Set-Cookieheader alone doesn't guarantee the browser honored the expiry you set
What checking on your own machine can't tell you
Once you've mitigated ITP, you'll naturally want to confirm "is it working?" But testing once on your own machine has two blind spots specific to ITP:
- Your environment isn't the same as a real Safari user's. A development browser differs from a typical visitor in extensions, cache, and login state. ITP in particular behaves differently depending on "was there a cross-site navigation?" and "has this browser touched the domain before?" — so on a developer's not-clean environment, the 7-day expiry or 24-hour shortening that hits real users may not reproduce. You get the mismatch of "it stitched on my Safari" while it breaks for a first-time general visitor.
- Anything involving an ad click is hard to reproduce. To properly see "how Safari treats someone who arrived with a
gclidfrom an ad click and converted a few days later," you'd need to click a live ad to recreate the path and the passage of time — which carries the risk of an ad-policy violation as a self-click.
ITP problems happen on the path of "the first-time production Safari user," not "your already-mitigated environment." The fact that it stitches when you test is exactly what breeds complacency.
How to verify "how cookies are being handled right now" in production
Method 1: Check the cookie's issuance method and expiry in DevTools
The most basic check. In both Safari and Chrome, DevTools "Application (or Storage)" → "Cookies" shows each cookie's expiry (Expires / Max-Age).
- Is the expiry of your measurement cookie (like
_ga) being truncated to within 7 days? - Is that cookie JavaScript-set, or server-set (HttpOnly)?
What it tells you: whether, in production right now, your identifier cookie is being shortened by ITP, and whether it has been replaced with a server-issued one.
Method 2: Check Set-Cookie in the response headers
In the Network tab, open the page's response headers and see whether the cookie is issued via a Set-Cookie header. If your identifier cookie appears here, that's evidence it's being issued server-side (as an HTTP cookie). If it's set only via JavaScript, it won't appear here.
What it tells you: whether your ITP mitigation (server-side issuance) is actually working, not just claimed.
Method 3: Verify on Safari, including the passage of time
The essence of ITP is that "cookies vanish as time passes." So you need to check not only right after issuance but whether the same user identifier is preserved a few days later. In particular, on Safari, confirm that the cookie's expiry hasn't shrunk to 24 hours after a cross-site navigation via link decoration (with query parameters).
What it tells you: whether, under production-like conditions of a first visit and a cross-site navigation, the identifier is hitting the 7-day / 24-hour wall.
A checklist to verify with confidence
- Did you check the expiry of your measurement cookie (like
_ga) on production Safari? - Is that cookie server-set (
Set-Cookie) or JavaScript-set? - After a cross-site navigation (link decoration), has the expiry not shrunk to 24 hours?
- Is
gclid/fbclidstorage still valid a few days later (not expired)? - Is the new-user rate via Safari not unnaturally high (suspect repeats being recounted as new)?
- Are server-side tagging / CAPI actually issuing and sending — not just "implemented"?
- Did you verify under real Safari conditions, not just Chrome (don't judge from your not-clean environment)?
Frequently asked questions
Q. How much do conversions drop under Safari's ITP? A. It varies. The size depends heavily on the share of Safari users, the length of your attribution window, and whether yours is a repeat-purchase business. What's true across the board: the more a path involves revisiting or reconverting beyond 7 days, the bigger the impact.
Q. Is this a Safari bug? Can I fix it? A. It's not a bug — it's a spec, a result of Safari's (WebKit's) privacy protection (ITP). It isn't something to "fix"; the realistic response is to mitigate the impact with server-side cookie issuance, a CAPI, and the like.
Q. Is Chrome fine, then? A. Chrome long allowed third-party cookies, but the move toward stronger privacy is common to all browsers. ITP is a Safari-specific name, but preparing for "short-lived first-party cookies" and "restricted third-party cookies" pays off beyond Safari, well into the future.
Q. I'm storing gclid, but results aren't attributed. Why?
A. If you store gclid in a first-party cookie via JavaScript, ITP can delete it after 7 days (24 hours after a cross-site navigation). If the conversion happens past that window, it can't be attributed. The fix is to switch to server-side storage — see first-party data conversion tracking for a broader strategy around reducing dependence on browser-managed identifiers.
Q. Will server-side tagging solve it completely? A. It sharply reduces losses, but not "completely." If an implementation mistake leaves the cookie still JavaScript-set, or the cross-domain wiring is missing, the effect is limited. After implementing, it's essential to confirm that an HTTP cookie really is being issued in production.
Q. Is the impact of ITP the same for GA4 and ads? A. The root is the same (cookie shortening and blocking), but it shows up differently. On GA4 it appears as new-user inflation and session fragmentation; on ads it appears as click-ID expiry and lost attribution. It's safer to check the two separately.
Conclusion: verify with "the first-time production Safari user," not "your clean environment"
The problem of conversions dropping under Safari's ITP can't be diagnosed by watching whether the tag fires. What matters is verifying — under real Safari conditions — how cookies are actually issued, how long they live, and whether identification holds up as time passes. This is a privacy spec, not a malfunction, so account for it as a given, mitigate it with server-side issuance and the like, and then measure whether it's "really working."
ConversionOK runs your live page in an independent, isolated browser and intercepts the actual requests sent and the cookies issued (their issuance method and expiry), then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm how the entry point of your measurement is handled under real browser conditions.