Does Safari Block Google Analytics?

Does Safari Block Google Analytics?

Open Safari's Privacy Report and you will probably see google-analytics.com sitting in a list headed "Trackers Prevented." It is an alarming thing to read if you depend on that data, and it has launched a long run of blog posts announcing that Safari has killed Google Analytics.

It has not. The wording in that report is doing something much narrower than it appears to, and the gap between what Safari restricts and what people assume it restricts is where most of the confusion lives.

That said, Safari genuinely does distort your numbers, just not by blocking anything. Knowing which part is real matters, because the fixes for "my script is blocked" and "my cookies expire too fast" are completely different pieces of work.

Does Safari Block Google Analytics? The Direct Answer

No. Safari does not block the Google Analytics script from loading, and it does not block the measurement requests GA sends. Pages that load gtag.js or Google Tag Manager in Safari load them successfully, and the resulting hits arrive in your property.

This has been tested repeatedly by people who went looking. Analytics engineer Simo Ahava loaded both libraries on a test site with the Google domains explicitly flagged as tracking domains and found the scripts loaded and the requests fired. WebKit engineer John Wilander has stated directly that Intelligent Tracking Prevention "has not started to block resource loads."

What Safari does instead is restrict what a flagged domain can do with cookies across sites. That is a real restriction, and it is a meaningful one for some kinds of measurement. It is simply not the same as blocking.

The practical upshot: if your GA4 property is showing traffic from Safari users, nothing is broken. If it is showing no Safari traffic at all, the cause is almost certainly a tagging error or a content blocker, not Safari's own privacy features.

Not sure whether your analytics setup is losing data to browser privacy features or to a broken tag? Get a free SEO audit and find out what is actually firing.

What Safari Actually Does to Your Analytics

Safari applies several distinct privacy mechanisms, and they are often discussed as one thing. They are not. Each affects measurement differently, and only one of them resembles blocking at all.

Intelligent Tracking Prevention

ITP is the headline feature. It watches which domains receive requests from browsing across many different websites, and classifies a domain as having cross-site tracking capability once it appears widely enough. Once a domain is classified, Safari strips its ability to set or send cookies in a third-party context.

Google Analytics does not depend on that ability. GA writes its client identifier into a first-party cookie on your own domain, and its measurement requests carry that identifier as a parameter. The cross-site restriction therefore misses the thing people worry it hits.

The Seven-Day Cookie Cap

This is the restriction that actually costs you accuracy. Safari limits the lifetime of cookies set by client-side JavaScript to roughly seven days. GA4's _ga cookie is set by JavaScript, so on Safari it does not survive two years, or even two weeks.

A visitor who arrives on Monday, leaves, and comes back a fortnight later arrives without a cookie. GA has no way to recognise them, so it writes a fresh client identifier and counts a brand new user.

Third-Party Cookies Are Gone Entirely

Safari has blocked third-party cookies by default for years, well ahead of other browsers. Anything in your stack that relied on reading a cookie set on a different domain — older cross-domain tracking setups, some advertising integrations, certain session-stitching tools — simply does not work for Safari visitors.

GA4's standard first-party setup does not rely on this. Some of the integrations bolted onto it do.

Private Relay and IP Addresses

Private Relay, available to iCloud+ subscribers, routes Safari traffic through two relays so that no single party sees both who the user is and which site they are visiting. The site receives an IP address from a pool, geolocated roughly to the user's region rather than their actual location.

For analytics this means approximate geography and a complete loss of IP-based identification. Reports still populate; city-level data just gets vaguer.

Link Tracking Protection

In private browsing, Safari strips known tracking parameters from URLs as you navigate. Click identifiers are the main target. Campaign parameters such as utm_source and utm_medium are not generally stripped, so standard UTM-tagged campaign reporting survives — but anything depending on a click ID can arrive incomplete.

Content Blockers: The Only Real Blocking

Here is the irony. The thing that genuinely blocks Google Analytics in Safari is not Safari. It is the content blocker extensions users install themselves, which refuse the request to the Google domain outright. Those hits never leave the browser and never appear anywhere in your property.

That loss is invisible by definition. You cannot measure traffic that never contacted you.

How to Check What Safari Is Doing to Your Own Data

You do not have to take any of this on trust. Five checks will tell you where you stand, and none of them take long.

Step 1: Confirm Hits Are Arriving at All

Open your site in Safari with GA4's DebugView active, or watch the Network tab in Safari's Web Inspector and filter for the collection endpoint. If you see requests going out and a response coming back, Safari is not blocking anything.

Step 2: Segment Your Reports by Browser

In GA4, build a report with Browser as the dimension. Compare Safari's share of your sessions against its share of the market for your audience. A large shortfall points at content blockers; a rough match means you are fine.

Step 3: Compare New-User Rates Across Browsers

Add New Users and Returning Users to that same browser breakdown. Safari will almost always show a higher proportion of new users than Chrome, and the gap is the seven-day cookie cap showing up in your reporting rather than a real difference in audience loyalty.

Step 4: Inspect the Cookie Lifetime Directly

Load your site in Safari, open Web Inspector, go to Storage, and find the _ga cookie. Look at its expiry date. If it is about a week out rather than roughly two years, you are seeing the cap.

Step 5: Check Your Geographic Data for Drift

Look at city-level reports split by browser. If Safari shows a heavy concentration in a handful of large metro areas that Chrome does not, that is Private Relay's regional IP pool, not a change in who is visiting.

Running these checks and not liking what you see? Get a free SEO audit and we will tell you which gaps are fixable and which are not.

When This Actually Matters

Not every site needs to care. The cost of Safari's restrictions scales with how much of your measurement depends on recognising the same person over time.

Long Consideration Cycles

If people research for weeks before converting, the seven-day cap sits right in the middle of your funnel. A visitor who comes back on day ten is a new user, and the first touch that earned the eventual conversion gets credited to nothing.

Heavily Apple-Skewed Audiences

Design, publishing, consumer apps and anything aimed at a US mobile audience can run well over half Safari. At that share the distortion stops being a rounding error and starts driving decisions.

Attribution and Paid Reporting

Anything that compares platform-reported conversions to GA-reported conversions will show a gap, and the Safari share of your traffic is usually the largest single explanation for it.

When It Mostly Does Not Matter

If you are reading traffic trends, landing-page performance, or engagement by content type, the Safari effect is a consistent bias rather than noise. Trends stay readable. It is user counts and multi-visit journeys that suffer.

Limitations: What You Cannot Fix

Being honest about the ceiling saves a lot of wasted engineering.

Content blockers cannot be worked around, and should not be. A user who installs one has made their preference explicit, and attempting to defeat it is both a trust problem and, in several jurisdictions, a legal one.

Private Relay's IP masking is not recoverable either. You can infer region from other signals, but the precise location is gone.

The seven-day cap can be extended, but only by changing how the cookie is set — which means server-side tagging, not a setting in the GA interface.

And no fix recovers data you have already lost. Everything here changes what you collect from now on; the historical gap stays in your reports permanently.

Want a clear picture of what your analytics can and cannot tell you? Get a free SEO audit and start from a measurement baseline you trust.

Safari's Impact vs the Alternatives

It helps to see where Safari sits relative to everything else that shapes your data.

Safari vs Chrome

Chrome caps first-party cookies at 400 days for a visitor who does not return in the meantime, which is far more generous than seven days but still short of GA's two-year default. Chrome is the lenient end of the range, not a clean baseline.

Safari vs Firefox

Firefox's Total Cookie Protection partitions cookies per site rather than capping lifetimes aggressively. Different mechanism, similar outcome for cross-site measurement, less damage to first-party identification.

Safari vs Ad Blockers

Ad blockers are far more destructive than any browser default, because they remove the request entirely rather than restricting a cookie. If you are going to worry about one thing, worry about this one.

Client-Side vs Server-Side Tagging

Server-side tagging is the substantive response to the cookie cap. You set the cookie from your own server rather than from JavaScript, which puts it outside the client-side limit. The trade is real: infrastructure to run, a subdomain to configure, and ongoing maintenance. It is worth it for sites where user identity drives revenue decisions, and overkill for most content sites.

Modelled Data and Consent Mode

Google's modelling fills some gaps statistically rather than observationally. It helps aggregate reporting and does nothing for individual journeys, and it is worth understanding as an estimate rather than a measurement.

Final Thoughts

Safari does not block Google Analytics. It restricts cross-site cookie behaviour, caps JavaScript-set cookie lifetimes to about a week, masks IP addresses for Private Relay users, and surfaces all of this under a Privacy Report label that reads far more dramatically than the underlying behaviour warrants.

The practical consequence is not missing traffic. It is inflated new-user counts, shortened visible journeys, and vaguer geography for a meaningful slice of your audience. That is a bias you can correct for by reading trends rather than absolute user counts, and by segmenting Safari out when you need an accurate picture.

If you want to go a level deeper on the cookie mechanics underneath all this, our guide to whether GA4 uses third-party cookies covers what GA4 actually writes into the browser and why the first-party distinction matters.

Start by measuring the size of your own Safari gap before you spend anything on closing it. For many sites the honest answer is that the bias is tolerable and well understood, which is a much better place to be than assuming your data is either perfect or broken.

Ready to find out what your analytics is really telling you? Get a free SEO audit and we will map the gaps that matter.