Safari Link Tracking Protection in 2026: What It Strips From WooCommerce URLs

What does Safari’s Link Tracking Protection actually strip from URLs?#

Safari’s Link Tracking Protection removes click identifiers like gclid and fbclid from URLs in Private Browsing, Mail, and Messages, while preserving UTM parameters and privacy-preserving identifiers like gbraid and wbraid (ABLE CDP, 2025). The stripping happens before the page loads — your WooCommerce analytics code never sees the parameters at all.

Here’s the thing: Apple distinguishes between user-level and campaign-level identifiers. A gclid ties a click to a specific user profile in Google’s system. A utm_source just says “this visitor came from Google.” Apple strips the first and leaves the second — which sounds reasonable until you realise gclid is exactly how Google Ads attributes conversions to individual clicks.

For a WooCommerce store running Google Ads, a stripped gclid means the customer still buys but Google Ads never learns which click drove the sale. ROAS reporting drops, Smart Bidding loses signal, and you can’t tell which keywords are profitable.

Safari’s Link Tracking Protection strips gclid and fbclid from URLs but preserves UTM parameters, gbraid, and wbraid — removing user-level identifiers while leaving campaign-level ones intact (ABLE CDP, 2025).

How much of US mobile traffic is affected by Safari’s tracking restrictions?#

Safari commands 51.8% of US mobile browser traffic as of 2026 (Cloudflare Radar via TechnologyChecker, 2026). More than half of American smartphone visitors to your WooCommerce store are running a browser that actively restricts how you measure their behaviour.

Globally the picture is less dramatic — Safari holds 26.5% of mobile traffic and 17.8% overall (Cloudflare Radar via TechnologyChecker, 2026). But if your WooCommerce store sells primarily to US customers, the global average is irrelevant. Your measurement problem is a majority-of-traffic problem, not an edge case.

The concentration is higher in valuable demographics. iPhone ownership skews toward higher-income consumers — the audience you most want to attribute is the one Safari most actively prevents you from tracking.

Related: How Does ITP Differ from Advanced Tracking Protection?

What is the difference between Safari’s ITP and Link Tracking Protection?#

ITP limits cookie lifetimes — capping JavaScript-set first-party cookies to 7 days and flagged tracker cookies to 24 hours — while Link Tracking Protection operates on URLs, stripping click identifiers before the page even loads (Piwik PRO, 2025; ABLE CDP, 2025). They attack different parts of the tracking chain, and together they create a two-layer data loss problem for WooCommerce stores.

Feature	ITP (Intelligent Tracking Prevention)	LTP (Link Tracking Protection)
What it targets	Cookies and local storage	URL query parameters
Mechanism	Caps cookie expiry (7 days JS; 24 hrs flagged)	Strips click IDs before page load
Active by default	Yes, all Safari browsing	Private Browsing, Mail, Messages only
Parameters affected	None directly (cookies only)	gclid, fbclid (not UTMs)
Server-side bypass	HTTP-set cookies exempt from cap	Server-side UTM capture before stripping

Translation: ITP erodes your ability to recognise returning visitors over time. LTP prevents you from knowing how they arrived in the first place. A WooCommerce store hit by both can’t attribute the initial click and can’t connect the eventual purchase to the same visitor — two blind spots that compound into a single attribution black hole.

How does ITP’s 7-day cookie cap break WooCommerce conversion attribution?#

When a visitor clicks an ad on Friday and returns to purchase the following Monday — more than 7 days later — ITP has already deleted the cookie linking the sale to the original click (Piwik PRO, 2025). The WooCommerce store records the revenue but cannot attribute it to the ad campaign that drove it.

The 24-hour cap is worse. Since ITP 2.2, if Google classifies a domain as a cross-site tracker — which it does for its own ad-serving domains — ITP downgrades that cookie to a single day. A visitor who clicks a Google Ads link on Monday morning and buys on Tuesday has already lost their attribution cookie.

For WooCommerce stores selling considered purchases — furniture, electronics, B2B supplies — buying cycles run days or weeks. ITP’s caps expire well before the purchase decision is made, and Direct traffic gets the credit in GA4.

Related: What Is iOS 26 Link Tracking Protection?

Is Safari’s Link Tracking Protection turned on by default?#

Link Tracking Protection is active by default only in Safari Private Browsing, Apple Mail, and Messages — users must manually enable it for standard browsing via the Advanced Tracking and Fingerprinting Protection setting (ABLE CDP, 2025). But “only Private Browsing” is a bigger slice than it sounds, and Mail links are a growing attribution gap.

Every link in an Apple Mail email passes through LTP before the browser opens. If your WooCommerce store runs email campaigns with gclid-tagged links, every Apple Mail user who clicks through loses that click identifier. The landing page still loads, the visit still registers — but the connection between the email campaign and the eventual purchase is severed.

The question isn’t whether LTP is on by default for all browsing. The question is whether Private Browsing, Mail, and Messages cover enough of your traffic to distort reporting. For most WooCommerce stores doing email marketing to a US audience, the answer is yes.

How much tracking data can server-side tracking recover from Safari restrictions?#

A 90-day case study processing over 200,000 tracking requests found server-side tracking recovered 12% of requests lost to browser-level disruptions, with 8.62% specifically affected by tracking prevention like ITP (SEOplus, 2025). That’s not a rounding error — it’s more than one in twelve conversions that your client-side tracking never reports.

The recovery comes from two mechanisms. First, server-side tracking fires from the server when WooCommerce processes an event, so browser extensions, ad blockers, and consent banner interactions cannot prevent the request. Second, cookies set via HTTP response headers bypass ITP’s JavaScript cookie cap entirely.

For a WooCommerce store spending $5,000 a month on Google Ads, a 12% tracking recovery means roughly $600 worth of conversions that Google Ads can now see and optimise against. Smart Bidding gets better data, ROAS reporting improves, and budget decisions are based on what actually happened rather than what Safari allowed you to measure.

Server-side tracking recovered 12% of tracking requests lost to browser-level disruptions in a 90-day study of 200,000+ requests, with 8.62% blocked specifically by ITP/ETP (SEOplus, 2025).

Does Safari strip UTM parameters from WooCommerce landing page URLs?#

No — Safari’s Link Tracking Protection preserves UTM parameters because they identify campaigns rather than individual users (ABLE CDP, 2025). But preserving UTMs at the URL level doesn’t help if ITP deletes the cookie that stored them before the visitor converts.

Most WooCommerce analytics setups capture UTM parameters on the first pageview and store them in a cookie or localStorage for later attribution. ITP purges both after 7 days. A visitor who arrives via utm_source=google&utm_medium=cpc on Monday and converts the following Tuesday still has the UTM in their landing page URL — but the stored version that would connect their purchase to the original campaign is gone.

This is where the distinction between LTP and ITP creates a false sense of security. Store owners hear “Safari doesn’t strip UTMs” and assume their campaign attribution is intact. It is — for same-session conversions. For anything beyond 7 days, ITP has already erased the breadcrumbs.

Related: Safari ITP’s 7-Day Cookie Kill vs Server-Set 400-Day Cookies: The Attribution Gap

How does server-side cookie setting bypass Safari ITP for WooCommerce?#

Server-side tracking sets cookies via HTTP response headers rather than JavaScript, and ITP’s 7-day cap only applies to cookies created via document.cookie (Piwik PRO, 2025). A server-set cookie retains its full expiration — up to 400 days — while a JavaScript cookie on the same domain expires in 7.

The technical distinction matters: when a browser receives a Set-Cookie header in an HTTP response from a first-party domain, Safari treats it as a legitimate server decision rather than a JavaScript tracking attempt. The cookie persists for its stated lifetime, giving WooCommerce stores the full attribution window they need for considered purchases.

For WooCommerce stores, tools like Transmute Engine route events through first-party server infrastructure, setting cookies via HTTP headers that bypass ITP’s cap entirely. Combined with inPIPE‘s server-side UTM capture — which grabs parameters before Safari can strip them — the store recovers both the visitor identity and the campaign attribution that browser-side tracking loses.

What happened with Safari 26 and fingerprinting protection?#

Safari 26, released September 2025, extended Advanced Fingerprinting Protection to all browsing by default, though Link Tracking Protection for standard browsing — which appeared in beta — was absent from the final release (ABLE CDP, 2025). Apple signalled its direction even if it pulled back on this specific feature for now.

The fingerprinting changes compound the data loss. Advanced Fingerprinting Protection limits device characteristics websites can collect — canvas rendering, audio contexts, font enumeration — that some analytics tools use as fallback identifiers when cookies are unavailable.

Let that sink in. Apple built LTP into the Safari 26 beta for all browsing, then pulled it from the final release. That’s not a reversal — it’s a timeline. The infrastructure exists, the feature works, and the only reason it’s not active today is Apple’s release schedule. Stores that wait for the default rollout will be reacting to data loss they could have prevented.

How does Safari’s ITP inflate WooCommerce new-visitor counts?#

When ITP deletes a returning visitor’s cookie after 7 days of inactivity, the next visit is counted as a brand-new user, inflating new-visitor metrics and distorting customer acquisition reporting (Piwik PRO, 2025). Your “new customer” count includes people who’ve already bought from you — they just look new because Safari erased their history.

This inflation cascades through every report using new-vs-returning segmentation. Acquisition cost rises because the denominator includes repeat visitors. Lifetime value breaks because the same person appears as multiple customers. Retargeting audiences shrink because the pixel can’t recognise returning visitors.

The impact is measurable: if your WooCommerce backend shows a 35% repeat purchase rate but GA4 shows 15% returning visitors, the difference is likely ITP deleting cookies between visits.

Key Takeaways#

• LTP strips click IDs, not UTMs: Safari removes gclid and fbclid from URLs in Private Browsing, Mail, and Messages but preserves UTM parameters and gbraid/wbraid.
• 51.8% of US mobile traffic: Over half of American smartphone visitors run Safari, making Apple’s tracking restrictions a majority-of-traffic problem for US-focused WooCommerce stores.
• ITP and LTP are two separate layers: ITP caps cookies to 7 days (24 hours for flagged trackers); LTP strips URL identifiers before the page loads. Together they break both visitor recognition and click attribution.
• Server-side cookies bypass ITP: Cookies set via HTTP response headers retain their full expiration, unlike JavaScript cookies that ITP caps at 7 days.
• 12% recovery with server-side tracking: A 90-day study of 200,000+ requests showed server-side tracking recovered tracking data that browser-level protections blocked.

References#

1. Cloudflare Radar via TechnologyChecker (2026). Safari Market Share 2026. Source
2. Piwik PRO (2025). ITP Impact on Web Analytics and Marketing. Source
3. ABLE CDP (2025). Does Safari Strip Click IDs (gclid, fbclid)? Source
4. SEOplus (2025). How Server-Side GTM Supercharged Marketing Measurement. Source