No — for most WooCommerce stores, server-side GTM stopped extending cookie lifetimes beyond Safari’s 7-day cap in April 2023. That is when Apple introduced the IP-matching rule in Safari 16.4. If your sGTM container runs on Google Cloud, Stape, or any infrastructure with a different IP range from your WordPress host, Safari silently overrides the cookie expiry back to 7 days — regardless of what your Set-Cookie header says. Safari holds 24% of global browser market share (StatCounter / Stape, 2025), and every iPhone regardless of browser is affected. The ITP bypass most stores paid to implement is not working.

What Safari ITP Actually Does to Your Attribution#

Safari’s Intelligent Tracking Prevention has two separate restrictions that compound each other. The first is the JavaScript cookie cap: when a visitor arrives via a paid ad click (carrying gclid or fbclid in the URL), Safari caps any JavaScript-set cookie to 24 hours. A Google Ads click on Monday is invisible to GA4 by Tuesday morning.

The second restriction targets server-set cookies specifically. Safari ITP caps JavaScript-set cookies to 24 hours when gclid or fbclid tracking parameters appear in the URL — covering every paid ad click (Apple WebKit, 2025). Server-side GTM was supposed to be the fix for this. Set the cookie server-side via a Set-Cookie response header, and Safari would honour the full expiry — 400 days, 2 years, whatever you configured.

That worked until Safari 16.4. Then Apple changed the rules.

All iOS browsers — Chrome, Firefox, Edge, Brave — use Safari’s WebKit engine under Apple policy, so ITP restrictions apply to every browser on every iPhone (Apple / Conversios, 2025). That is not just Safari users. That is every mobile visitor on every iOS device, regardless of which browser icon they tapped.

You may be interested in: Your WooCommerce Payment Gateway Just Stripped GA4’s Tracking Parameter — And GTM Doesn’t Know

The Safari 16.4 IP-Matching Rule: What It Is and Why It Matters#

Safari 16.4, released in April 2023, added a new test for server-set cookies. The rule: if the server setting the cookie has a different first-half IP address prefix from the website being visited, the cookie is capped at 7 days — regardless of the Set-Cookie expiry header.

Safari 16.4 extended the IP-matching rule to server-set cookies: if the sGTM server IP prefix does not match the website server IP prefix, cookies are capped at 7 days regardless of the Set-Cookie header expiry (Snowplow / Louder Agency, 2023). Apple designed this rule specifically to close the CNAME cloaking workaround — the technique where a subdomain like tag.yourstore.com is pointed via CNAME to a third-party tracking server to make it appear first-party.

Here is the problem for standard sGTM deployments. Your WooCommerce store runs on SiteGround, WP Engine, or Kinsta — a shared hosting or managed WordPress environment with an IP range in one subnet. Your sGTM container runs on Google Cloud Run — an entirely different infrastructure with Google’s IP range. The IP prefixes do not match. Safari applies the 7-day cap. The ITP bypass fails silently.

The cookie is set. The expiry header says 400 days. Safari reads it, rejects the expiry, and enforces 7 days — without telling anyone.

Louder Agency reported that for some sGTM implementations, campaign attribution windows had been reduced back to 7 days for Safari users on versions 16.4 and later — even where those setups had previously been extending cookies to up to 2 years (Gavin, Louder.com.au, 2023).

How to Check If Your sGTM Setup Is Actually Passing the IP Test#

Open Safari on a Mac or iPhone. Navigate to your WooCommerce store. Open Safari DevTools (Develop → Show Web Inspector → Storage → Cookies). Look for your analytics cookie — typically _ga or whatever your GA4 client ID cookie is named in your sGTM configuration.

Check the expiry date. If it shows 7 days from today, your sGTM container is failing the IP-matching test. If it shows 13 months or longer, the IP ranges are aligning and the bypass is working.

You can also check directly: look up your sGTM container’s IP address (use nslookup your-sgtm-domain.com) and compare the first two octets with your WooCommerce hosting IP (use nslookup yourstore.com). If the first half of the IP does not match, Safari will cap your cookies.

Most stores running standard Google Cloud or Stape-hosted sGTM against shared WordPress hosting will fail this test.

You may be interested in: The GTM Container Audit You Must Run Before Switching to Server-Side Tracking

Why the Problem Is About to Get Significantly Worse#

Safari 26 will strip gclid from URLs in all standard browsing sessions — not just Private Browsing — removing the click ID before any cookie can be set (Stape / DMPG / Conversios, 2025). Right now, if your sGTM setup fails the IP-matching test, you still get a 7-day attribution window. With Safari 26, you may get nothing at all. The gclid disappears before landing, the session has no click attribution, and your Google Ads conversion data for Safari traffic goes dark.

This is not a future concern. Safari 26 is already in beta. WooCommerce stores that have not resolved the IP-matching failure will face compounding attribution loss — first the 7-day cap, then the removal of the parameter that makes even the 7-day window meaningful.

Fixing the IP-matching problem now is not just good tracking hygiene. It is preparation for a Safari change that will make the current 7-day cap feel generous.

The Architecture Fix: IP Alignment by Design#

There are two ways to pass Safari’s IP-matching test. The first is to migrate your sGTM container off Google Cloud and onto infrastructure that shares an IP prefix with your WooCommerce host. That means Docker deployments, custom VPS configurations, or hosting your sGTM container on the same server as WordPress. It is technically achievable. It is also a significant infrastructure project that most WooCommerce store owners are not positioned to execute.

The second way is to use a tracking architecture that passes the IP test by design — not by configuration.

Transmute Engine™ runs on your own subdomain (e.g., data.yourstore.com) on infrastructure you control. Because it is deployed on your hosting environment alongside your WooCommerce site, the IP ranges naturally align. Safari’s IP-matching test passes without any Docker migration, without Cloud Run configuration changes, and without ongoing maintenance as hosting IPs shift.

The result: server-set cookies from Transmute Engine carry the full expiry date Safari is willing to honour. Your 30-day Google Ads attribution window works on Safari. Your Meta click attribution survives past the first week. And when Safari 26 strips gclid from URLs, the server-side event capture at the PHP hook level means purchase data is still recorded regardless of what the URL contained.

Key Takeaways#

• Safari 16.4 changed the rules in April 2023. Server-set cookies are now capped at 7 days if the tagging server IP prefix does not match the website IP prefix. Most sGTM setups on Google Cloud or Stape fail this test against shared WordPress hosting.
• 24% of your visitors are affected — plus every iOS device. All iOS browsers use WebKit regardless of which browser is installed, meaning ITP restrictions apply to your entire mobile audience on Apple devices.
• You can check your status in Safari DevTools today. Look at your analytics cookie expiry in Safari Storage. If it shows 7 days, the bypass is not working.
• Safari 26 will make this worse. gclid stripping in standard browsing means the 7-day cap becomes the optimistic scenario. The fix needs to happen before that release.
• IP alignment by architecture is the clean solution. Running your tagging server on the same infrastructure as your WooCommerce site passes Safari’s IP-matching test without ongoing configuration work.