Safari holds 24% of global browser share—and since April 2023, most server-side GTM deployments still cap cookies at 7 days for every one of those visitors. The reason isn’t your sGTM configuration. It’s a Safari 16.4 rule almost no setup guide mentions: if the IP address of your sGTM server doesn’t match the first half of your website’s IP address, Safari treats your server-set cookies the same as JavaScript-set cookies. Seven days. Then attribution resets.

The IP Mismatch Problem Nobody Warned You About#

You spent weeks setting up server-side GTM. You moved to Google Cloud or Stape. You configured first-party cookies. You read the guides. By every measure, the setup looks correct—and Safari visitors are still showing up as new users after 7 days. This is why.

Before Safari 16.4, the distinction was simple: JavaScript-set cookies max 7 days, server-set cookies survive longer. Moving to sGTM meant crossing that line. Store owners who made the switch in 2022 and early 2023 were right to—it worked. Then Apple changed the rule.

Safari 16.4 (released April 2023) added IP address matching enforcement. The rule: Safari checks whether the first half of the sGTM server’s IP address matches the first half of the main website’s IP address. If they match, the server-set cookie gets its full lifetime. If they don’t match, the cookie is capped at 7 days—regardless of what the Set-Cookie header says (Snowplow, 2023).

Every WooCommerce store with sGTM hosted on Google Cloud, Stape, or any managed infrastructure that doesn’t share an IP range with their web host is hitting this limit right now. Most don’t know it.

Why sGTM Was Supposed to Fix This#

The Safari ITP problem has two layers. The first layer—JavaScript cookie limits—has been active since ITP 2.0 launched in 2018. Safari caps JavaScript-set first-party cookies at 7 days. URLs with fbclid or gclid tracking parameters trigger a stricter 24-hour cap (Apple WebKit, 2024). Client-side GTM, which writes cookies via JavaScript, hits this ceiling hard.

Server-set cookies were the solution. A server that writes cookies via Set-Cookie response headers bypasses the JavaScript restriction entirely. Apple’s own WebKit engineers confirmed this path at WWDC: same-domain secure server-side cookies are not subject to the 7-day constraint. That’s what moved the industry toward sGTM as the Safari fix.

The 2023 update added a second layer. A server-set cookie from a Google Cloud IP sending to a site hosted on SiteGround, WP Engine, or Cloudflare doesn’t qualify as “same-domain” under the new IP matching test. The cookie gets downgraded. Attribution resets at 7 days. The fix that was supposed to last for years stopped working—silently, with no error, no alert, no indication in any GTM report.

You may be interested in: GA4 Data Sampling Is Lying to Your WooCommerce Store

Which sGTM Setups Fail the IP Test#

The IP matching rule affects any sGTM deployment where the server infrastructure is separate from the web host. In practice, that’s the majority of WordPress implementations.

Setups that fail: sGTM on Google Cloud Run (any region), Stape standard hosting without Cookie Keeper, Addingwell, any cloud-hosted managed sGTM platform. The sGTM server has a Google Cloud or provider IP. The WordPress site has a separate hosting IP. First half doesn’t match. Seven-day cap applies.

Setups that pass: sGTM deployed on infrastructure that shares an IP range with the WordPress site. A VPS on the same host. A subdomain that resolves to the same server as the WordPress install. Same-origin deployment by design—not by coincidence.

Stape’s own documentation acknowledges the limitation and introduced their Cookie Keeper power-up specifically to work around it (Stape, 2025). The workaround adds another layer and another monthly cost. It addresses the symptom, not the architecture.

This matters at scale. All iOS browsers—Chrome, Firefox, Brave, Edge—run on Apple’s WebKit engine on iPhone and iPad (Apple Developer Documentation, 2024). The ITP restrictions aren’t Safari-only. They’re every browser on every iPhone and iPad. For WooCommerce stores with significant mobile traffic, the IP mismatch isn’t a 24% browser-share problem. It’s the majority of mobile visits.

How to Check If Your Setup Is Affected#

Testing the IP match is straightforward. You need two IP addresses and one comparison.

Find your WordPress site’s IP address by running nslookup yourdomain.com in terminal, or checking your hosting control panel. Find your sGTM server’s IP by running nslookup your-sgtm-subdomain.yourdomain.com. Compare the first two octets of each IP address—the first half under IPv4 (e.g., 192.168 vs 34.107).

If the first two octets don’t match, your server-set cookies are capped at 7 days in Safari. Your 30-day attribution window, your Google Ads ROAS, your remarketing audience—all of it resets for Safari visitors after one week.

The setup that looks correct in GTM Preview can still be failing the Safari IP test. GTM has no Safari cookie lifetime reporting. The gap is invisible unless you specifically look for it.

You may be interested in: Browser Fingerprinting Won’t Save Your Attribution

The Same-Origin Fix#

The only architecture that satisfies Safari’s IP matching requirement by design is one where the tracking server and the WordPress site share an IP origin—a subdomain that resolves to the same hosting environment as the main site.

Transmute Engine™ is a first-party Node.js server that deploys on your own subdomain (e.g., data.yourstore.com). Because it runs on your hosting infrastructure—not Google Cloud, not Stape’s servers—the IP address of the Transmute Engine subdomain matches the IP address of the WordPress site. Safari’s IP matching requirement is satisfied by default. No Cookie Keeper workaround. No additional configuration layer. No cloud hosting that shares no IP range with your web host.

The inPIPE WordPress plugin captures events from WooCommerce hooks and sends them via API to the Transmute Engine server, which routes to GA4, Facebook CAPI, Google Ads Enhanced Conversions, and BigQuery simultaneously. First-party by architecture. Safari-compliant by IP. No additional cost to clear a rule that cloud hosting can’t satisfy without workarounds.

Key Takeaways#

• Safari 16.4 added IP address matching enforcement in April 2023. Server-set cookies from IPs whose first half doesn’t match the site’s IP are capped at 7 days—the same limit as JavaScript cookies.
• Google Cloud and Stape hosting fail the IP match for WordPress sites on separate web hosts (SiteGround, WP Engine, Cloudflare, etc.). Most sGTM implementations in this category are still hitting the 7-day limit.
• Safari’s 24% browser share covers 100% of iOS browsers. ITP restrictions apply to Chrome, Firefox, and Edge on iPhone and iPad—not just Safari (Apple, 2024).
• Check your IP match: compare first two octets of your WordPress site IP vs your sGTM server IP. A mismatch means 7-day attribution windows for Safari and every iOS visitor.
• Same-origin deployment is the permanent fix. A tracking server on your own subdomain, sharing your hosting IP range, satisfies Safari’s requirement without workarounds.

If your sGTM is on Google Cloud or a managed host, your Safari attribution is likely capped at 7 days right now. Seresa.io builds tracking infrastructure that deploys on your subdomain—same-origin by design, Safari-compliant without workarounds.