How Safari Blocks Google Analytics (And What Actually Works in 2026)

Have you ever pulled your GA4 numbers, noticed Safari traffic looking strangely shallow, and wondered if Apple is silently chewing through your reports? Yes. It is. And it has been since 2017.

I run linkutm, so I stare at GA4 reports across hundreds of customer properties. Safari shows up wrong in almost every one of them. Sessions short. Users inflated. Sources collapsed into Direct. Campaigns half-attributed.

Here is exactly what Safari does to your Google Analytics 4 data, why it happens, and the fixes I actually trust right now.

The Short Answer Up Top

Safari does not block Google Analytics outright. Your gtag.js snippet still loads. Pageviews still fire. What Safari blocks is the identity layer underneath GA4.

The mechanism, in one paragraph: Safari’s Intelligent Tracking Prevention (ITP) caps the lifetime of any first-party cookie set by JavaScript at 7 days. Cookies set through query-string link decoration get capped at 24 hours. Third-party cookies are blocked outright since Safari 14. iCloud Private Relay hides the IP for some users. And Link Tracking Protection in iOS 17+ strips tracking parameters from URLs in Private Browsing.

The result: GA4 thinks the same Safari user is a brand new visitor every 7 days. Cross-domain journeys break after 24 hours. And referrer data quietly drops in too many cases to count.

Real talk, this is not a bug. This is the design.

Why I Care About This (And Why You Should)

Look, Safari is not a niche browser. StatCounter put global Safari share at around 18% in 2024. In the US it is closer to 24%. On US mobile traffic, I have seen ecommerce properties where Safari is 40-45% of visits.

If you cut a marketing decision based on GA4 reports without understanding what Safari did to those reports, you are optimizing on a distorted picture. That is the part that bugs me.

Here’s the thing. Most marketing teams I talk to do not know this is happening. They assume GA4 is “the truth” because it is the platform of record. Then they pause a campaign that looks weak, when actually it was strong but Safari turned half its conversions into Direct.

What Safari Actually Blocks in GA4

I want to be specific because vague answers send people down the wrong rabbit hole. Here is the exact list of things Safari does to GA4 measurement.

The seven-day cookie cap. Safari ITP 2.1 (released March 2019) capped any cookie set via document.cookie to 7 days. GA4’s _ga cookie holds the client_id that identifies a returning user. After 7 days of no Safari visits, that cookie is gone. Same human, new client ID, counted as a brand new user.

The 24-hour link decoration cap. ITP 2.2 (April 2019) tightened the screw. If your URL includes query parameters from a known “tracker” domain (Safari maintains a list), the JS-set cookie expires in 24 hours. GA4’s cross-domain tracking uses the _gl parameter for exactly this purpose. After 24 hours, the journey across your subdomains splits into two users.

Blocked third-party cookies. Safari 14 (September 2020) blocked all third-party cookies by default. GA4 mostly uses first-party cookies, so this hits less than Universal Analytics did. But any GA4 setup using DoubleClick signals, audience sync, or third-party Google services takes the hit.

Private Relay IP masking. iCloud+ subscribers using Safari can route through Apple’s Private Relay, which hides their real IP from the destination server. GA4’s geographic data goes vague. City-level reports get fuzzier.

Referrer stripping. Safari aggressively reduces document.referrer for cross-site navigation. If a user lands on your site from a partner without UTM tags, GA4 cannot see where they came from. Source/medium becomes (direct) / (none).

Link Tracking Protection. Safari 17 (September 2023) added an opt-in feature in Private Browsing that strips known tracking parameters (gclid, fbclid, dclid, mc_eid) from URLs as they navigate. UTM parameters are not yet on that list, which is the only reason UTM tracking still works on Safari in 2026.

One honest limitation: I cannot give you exact percentages of impact because GA4 itself cannot tell. The whole point of these protections is that Apple does not surface them. Most teams I work with see 10-30% of their Safari client IDs rotate every week.

Five Ways Safari Distorts Your GA4 Reports

Now the practical part. Here is how those mechanics show up in actual reports.

1. Inflated New User Counts

Because the _ga cookie expires after 7 days of Safari inactivity, GA4 keeps treating the same person as new. I have seen Safari segments report “new users” at 70-80% when the desktop equivalent is 35-45%. That is not your acquisition working. That is cookie rotation.

2. Crushed Session Counts Per User

Sessions tied to short-lived client IDs cannot stitch back together. A user who visited on a Tuesday and again the next Wednesday should count as two sessions for one user. On Safari, they count as two users with one session each. Engagement-rate denominators get warped.

3. Broken Cross-Domain Journeys

If your funnel crosses domains (say yourbrand.com → app.yourbrand.com), GA4 uses _gl link decoration to carry the client ID across. That decoration cookie lives 24 hours on Safari. Any user with more than a day between the visit and the conversion gets split into two users. Funnel reports look like garbage.

4. Direct Traffic Bloat

Safari’s referrer stripping plus the in-app browser problem (Twitter, LinkedIn, Mail in-app webviews) push more traffic into (direct) / (none). If your Direct traffic is unusually high and you have audited UTMs properly, this is the cause. The GA4 source/medium not set guide walks through how to isolate it.

5. Underweighted Awareness Channels

Last-click campaign attribution is bad enough at giving credit to top-of-funnel work. Add Safari to it and the awareness channel that introduced the customer 10 days ago shows up as Direct, because the original client_id and referrer both rotated out. Performance marketing teams cut awareness budgets based on this. Then pipeline craters.

How Safari Stacks Up Against Other Browsers

I get asked all the time whether Firefox and Brave are doing the same thing. Short answer: yes, but Safari is the leader. Here is the practical hierarchy.

• Safari: ITP, 7-day JS cookies, 24-hour link decoration, Private Relay, link tracking protection in Private Browsing.
• Brave: Aggressive ad and tracker blocking by default. Strips known tracking parameters at the URL layer. GA4 often fully blocked without user action.
• Firefox: Enhanced Tracking Protection blocks known cross-site trackers and limits cookie scope. Less aggressive on first-party JS cookies than Safari.
• Chrome: Third-party cookies deprecated in 2025 with user-choice (not full block). First-party cookies untouched.

The pattern is clear. Anyone running a browser other than Chrome is feeding GA4 partial data. The shift to first-party data is not a marketing fad. It is the structural response to this.

Three Diagnostic Checks to Run This Week

Before throwing more tools at the problem, confirm Safari is the cause. These three checks take 15 minutes total.

Check 1: Compare new-user rate by browser. Open GA4 > Reports > Tech > Browser. Add a comparison segment for “Returning users”. Look at the percentage of new users by browser. If Safari shows 25+ percentage points higher than Chrome, ITP cookie rotation is doing it.

Check 2: Audit Direct traffic share by device. Same Tech > Browser report, but filter to Direct / (none). If Safari mobile contributes 2x its expected share of Direct traffic, referrer stripping is the cause. Pair this against the unassigned traffic diagnostic to rule out the other causes first.

Check 3: Test cross-domain _gl decoration manually. In Safari, click a link from your main domain to a tracked subdomain. Then wait 25 hours. Click again. In GA4 DebugView, you will see two different client_id values for the same human. That confirms the 24-hour decoration cap.

If any of those three light up, Safari is distorting your data. You now know what you are fighting.

What Actually Fixes It (And What Does Not)

I have tried most of the workarounds floating around. Some work. Some are theater. Here is what holds up in 2026.

Server-side tagging works, with caveats

Server-side Google Tag Manager (sGTM) sets the GA4 cookie via a HTTP Set-Cookie response header from your own subdomain. That bypasses the 7-day JS cookie cap because the cookie is set server-side, not via document.cookie. Lifetime returns to whatever you set (typically 2 years).

The caveat: setup is non-trivial. You need to run a tagging server (Cloud Run, Stape, or self-hosted), point a subdomain like metrics.yourbrand.com at it, and route your GA4 traffic through it. It costs money. Roughly $40-150/month for most teams I have helped.

This is what I would do first if Safari is more than 25% of your traffic.

First-party tagged links work everywhere

This is the cheapest fix. Tag every campaign link with proper UTM parameters. UTMs are first-party query parameters that Safari currently does not strip. When the cookie identity layer fails, the UTM data still gives GA4 the source.

This is the lane linkutm lives in. Generate a tagged URL once, enforce naming conventions across your team, and Safari traffic still reports the right source/medium even when client IDs rotate. It does not fix the user identity problem, but it fixes the attribution problem, which is usually what matters.

Measurement Protocol works for conversions

If your goal is to make sure conversions count even when the browser side fails, send conversion events to GA4 directly via the Measurement Protocol from your server. The browser cookie can rotate all it wants. The conversion still lands.

The catch: you need your backend to know the GA4 client_id at conversion time, which means either capturing it on form submit or stitching at the user level. It is more engineering than most teams want.

Enhanced Conversions and Conversion APIs work for ad platforms

For Google Ads, Enhanced Conversions sends hashed user data server-to-server. Meta CAPI does the same for Meta. These do not fix GA4 directly. They fix the ad platform’s own attribution, which often matters more for budget decisions.

Privacy-respecting analytics work as a backup

Tools like Plausible, Fathom, and Matomo do not depend on cookies. They count visits via stateless server-side logging. They do not give you GA4’s depth, but they give you a stable second source. I run one of these on most properties just to sanity-check GA4 numbers.

The full first-party measurement stack is what I would build if starting fresh today.

What I Stopped Bothering With

Some things look like fixes and are not. Cutting them from your roadmap is its own win.

• Setting _ga cookie via custom JS to a longer expiry. Safari resets it back to 7 days on next visit. You cannot bypass ITP at the JS layer.
• Forcing cross-domain tracking through hash fragments. This used to work pre-ITP 2.2 and is now flagged as evasion behavior.
• Asking users to disable tracking prevention. Nobody does this. Stop pretending it is a strategy.
• Bouncing traffic through a redirect chain to refresh cookies. Adds latency, hurts CTR, and Safari has gotten better at detecting this pattern.

Honest Limitations

None of the fixes above gives you back perfect Safari measurement. Server-side tagging extends cookie life but does not bring back referrer data Safari already dropped. UTM tagging fixes source attribution but not user identity. The Measurement Protocol fixes conversion counts but creates engineering overhead.

The honest target is to get your Safari data trustworthy enough to make directional decisions. Perfect attribution on Apple devices is gone. It is not coming back.

Frequently Asked Questions

Does Safari block Google Analytics?

Safari does not block the Google Analytics script itself. The gtag.js file loads and events fire. What Safari blocks is the cookie-based identity layer GA4 depends on. Cookies set via JavaScript get capped at 7 days. Cross-domain link decoration cookies get capped at 24 hours. Third-party cookies are blocked outright.

Why does Safari traffic show as Direct in GA4?

Safari aggressively strips document.referrer on cross-site navigation, especially from in-app browsers and Apple Mail. Without a referrer and without UTM parameters on the link, GA4 has no source signal and bins the visit under (direct) / (none). Tagging every campaign link with UTM parameters is the most reliable fix.

How long do GA4 cookies last in Safari?

The GA4 _ga cookie lasts 7 days when set via JavaScript on Safari. The _gl cross-domain decoration cookie lasts 24 hours. Both restrictions come from Safari’s Intelligent Tracking Prevention (ITP), introduced in 2017 and tightened in 2019. Server-side cookies set via HTTP response headers can persist longer.

Does Private Relay break Google Analytics?

Private Relay does not break GA4 outright. It hides the user’s real IP address, which fuzzes city-level geographic data and can affect IP-based bot detection. Browser fingerprinting and cookie tracking continue to work for users on Private Relay. It is an annoyance, not a showstopper.

Is server-side tracking necessary to track Safari users?

Server-side tracking is the most reliable way to extend GA4 cookie lifetime on Safari beyond 7 days, but it is not strictly necessary. For most teams, consistent UTM tagging and Measurement Protocol conversion events solve the practical attribution problem at a fraction of the cost. Server-side becomes worth it when Safari is over 25% of your traffic.

What percentage of GA4 data does Safari distort?

Direct measurement is not possible because the distortion is the design. Based on properties I have audited, Safari client IDs rotate at a rate where 10-30% of weekly active Safari users count as multiple “new” users in the same month. Cross-domain journeys break for roughly half of Safari users with multi-day sessions. Direct traffic share is typically 1.5-2x what it should be on Safari mobile.

Pick One Fix and Ship It

You do not need to do all of this. Start with the one that matches your situation.

If Safari is under 20% of your traffic and you have shaky UTM hygiene, fix the UTMs first. Build every campaign URL through the UTM builder and lock in naming rules. That alone usually cleans 60% of the noise.

If Safari is 25%+ and you have budget, set up server-side GTM next quarter. The cookie lifetime extension pays for itself in cleaner returning-user data within a month.

If Safari is your majority traffic and you are running paid acquisition, add Enhanced Conversions and Meta CAPI on top so your ad platforms can still optimize against real conversion signal.

The mistake is assuming GA4 alone tells the truth on Apple devices. It does not. Build the layers that make the truth knowable.