Does Safari block Google Analytics?

Safari does not have a blanket rule that blocks every GA4 request. But it can affect GA4 collection, visitor recognition and attribution. Those are different problems. A reference to Google Analytics in Safari's Privacy Report does not, by itself, establish that a page_view request from your implementation was blocked.

GA4 can collect events in Safari. Whether your particular visit is recorded depends on the browser version and settings, consent handling, content blockers and your implementation. Start by checking the request rather than guessing from a change in the dashboard. A second, cookieless count from Simple Analytics, run alongside GA4, shows whether a drop is specific to GA4 or also appears in an independent dataset.

First-party cookies do not make GA4 unaffected

Google documents that GA4's JavaScript tags use first-party cookies to distinguish users and sessions. Blocking third-party cookies is therefore not the same as blocking GA4's first-party analytics cookies or every request to its collection endpoint. Google's cookie documentation.

Safari's protections extend beyond third-party cookies. Google documents a Safari-imposed maximum lifespan of seven days for first-party GA4 cookies when the user does not return. Separately, WebKit documents deletion of JavaScript-created cookies and other script-writeable storage after seven days without user interaction with a website. Those are storage rules, not a claim that every GA4 request is blocked. Google's cookie documentation, WebKit's tracking prevention documentation.

If a stored identifier is no longer available, a later visit may no longer be recognized as belonging to the same browser. That can affect user counts and returning-user analysis without preventing the new pageview from being sent. Do not interpret an identity discontinuity as proof of missing pageviews.

Private Browsing and newer Safari protections matter

In Private Browsing, Safari blocks network loads to known trackers. It also removes a subset of query parameters identified as being used for pervasive cross-site tracking and hides cross-site referrer information from scripts. Apple's example leaves a campaign parameter intact. This is not evidence that GA4 is always classified as a known tracker or that every campaign parameter is removed. WebKit's Private Browsing explanation.

Safari 26 also introduced restrictions preventing known fingerprinting scripts from accessing some device APIs, setting long-lived script-written storage, or reading navigational state such as query parameters and document.referrer. This is not a statement that every analytics script is classified identically. Safari 26 release explanation.

A campaign identifier becoming unavailable is a different outcome from a pageview request being blocked. Check the landing URL, the values visible to the tag and the outgoing event. Do not infer the handling of UTM parameters from the handling of click identifiers, or vice versa.

Record the Safari and operating-system versions when investigating. “It works in Safari” is incomplete without the version, browsing mode and relevant settings.

Consent is a separate collection decision

A consent manager can prevent GA4 from loading even when Safari would allow the request. In basic Consent Mode, Google tags are blocked until consent. In advanced Consent Mode, tags can send cookieless measurements while analytics_storage is denied. Google's Consent Mode overview.

Check which behavior your implementation actually uses. A request sent without analytics consent is not evidence that the normal persistent analytics identifier is available, or that all GA4 reports will show the visit as they would for consenting traffic.

Eligible properties may use behavioral modeling. The reporting identity and the report you inspect matter when interpreting the result. Google's behavioral modeling documentation.

Diagnose the discrepancy in the browser first

Use a test environment where possible. Record the page, consent choice, browsing mode, installed blockers and expected event before starting. Change one condition at a time; a comparison between different configurations cannot isolate the cause.

Repeat the same action in normal and Private Browsing, with the same consent choice. Preserve the request and console evidence. If testing a returning visit, inspect identifier continuity separately from whether the second visit sends a pageview.

Once collection is understood, check the reporting layer: the selected property, date range, time zone, filters, reporting identity and processing delay. A difference between Safari and Chrome traffic volumes is not a controlled browser test; those audiences may behave differently.

What an independent traffic baseline can tell you

Running Simple Analytics alongside GA4 gives you a second pageview dataset to compare by date, page and browser. If Safari pageviews change in one dataset but not the other, that gives you a narrower investigation to pursue. It does not establish the cause on its own.

Simple Analytics records pageviews and events without persistent visitor identities. Its calculated session starts use a different method from GA4 sessions, so start with pageviews rather than treating user or session totals as equivalent. How Simple Analytics measures sessions without consent.

Cookieless does not mean immune to browser restrictions. Simple Analytics still needs its script to execute and its requests to arrive. Referrer and campaign information also depends on what the browser makes available. We cannot recover a tracking parameter the browser has already removed or reconstruct a journey across separate visits without an identifier.

The aim is to understand the difference in your implementation. Keep GA4 in place, define a comparable metric and investigate the evidence before deciding that Safari is responsible for the gap.