The Good, the Bad, and the Ugly for WordPress Store Owners#

First-party cookies aren’t dying in 2026. But they’re not all treated equally. Chrome gives your analytics cookies 400 days to live. Safari gives them 7 days—or just 24 hours if visitors clicked a Facebook or Google ad to reach your site. That’s not a typo. The same cookie, on the same website, behaves completely differently depending on which browser your customer uses.

With Safari holding 24% of browser market share (StatCounter, 2024), roughly one in four of your WooCommerce visitors operates under severe cookie restrictions. Understanding these differences—and knowing how to work around them—is the difference between accurate analytics and flying blind.

The Good: First-Party Cookies Still Work#

Amid all the “cookie apocalypse” headlines, here’s what often gets lost: first-party cookies are fine. The restrictions killing cross-site tracking don’t apply to cookies set by your own domain for your own visitors.

Chrome, which commands 67% of browser market share, implemented a 400-day maximum cookie lifetime in August 2022 (Chrome 104). That’s over 13 months—plenty of time to recognize returning customers, track attribution windows, and maintain user sessions. As long as visitors return within 400 days and you refresh the cookie, it persists indefinitely.

Your WooCommerce session cookies, login cookies, and analytics cookies are all first-party. They’re set by your domain (yourstore.com) for visitors on your domain. This is exactly how cookies were designed to work when Lou Montulli invented them in 1994.

The confusion comes from conflating first-party cookies with third-party cookies. Third-party cookies—set by external domains like ad networks—are being blocked everywhere. First-party cookies face restrictions, not elimination. Big difference.

The Bad: Safari’s 7-Day Limit Changes Everything#

Safari’s Intelligent Tracking Prevention (ITP) treats first-party cookies differently than Chrome does. Any cookie set via JavaScript’s document.cookie gets a maximum 7-day expiration in Safari, regardless of what expiration you specify in your code.

This matters because most analytics tools—including Google Analytics 4—set cookies via JavaScript. The GA4 _ga cookie that’s supposed to last 2 years? In Safari, it expires after 7 days of the user not returning. Your “returning visitor” becomes a “new visitor” every week.

Here’s where it gets worse. Safari maintains a list of domains with “cross-site tracking capabilities.” Facebook and Google are on that list. When someone clicks your Facebook ad or Google ad, the URL contains a tracking parameter (fbclid or gclid). Safari sees that parameter, recognizes the referrer as a tracker, and caps all JavaScript cookies set on that page to 24 hours.

Translation: your highest-value traffic—paid ad clicks—gets the shortest cookie life. A customer who clicks your Facebook ad on Monday and buys on Tuesday appears as a new visitor. Your attribution is broken.

This isn’t theoretical. It’s been Safari’s policy since ITP 2.2 in 2019. And with Safari dominating on iOS (where all browsers must use Safari’s WebKit engine), it affects roughly 27% of mobile web traffic (StatCounter, 2024).

The Ugly: The Server-Set Cookie Gotcha#

The standard workaround for Safari’s JavaScript cookie restrictions is server-side tracking. When your server sets cookies via the HTTP Set-Cookie header instead of JavaScript, Safari’s ITP doesn’t apply the 7-day limit. The cookie can persist for its full expiration period.

Here’s the difference in practice:

When a visitor lands on your WooCommerce store, GA4’s JavaScript runs in their browser and sets a cookie like this:

Safari sees JavaScript setting a cookie and caps it at 7 days. Done.

But with server-side tracking, your server responds with an HTTP header:

Safari sees a server response—not JavaScript—and allows the full expiration. That’s why server-side GTM implementations work. It’s legitimate, and it’s the recommended approach for accurate tracking in 2026.

But here’s the ugly part most guides don’t mention: Safari 16.4 (April 2023) added IP matching requirements.

Safari now checks whether the server setting the cookie has an IP address that matches your website’s IP address (specifically, the first half of the IP range).

Example of What Goes Wrong

Your WooCommerce store is hosted on SiteGround (IP: 35.214.xxx.xxx). You set up server-side GTM on Google Cloud (IP: 142.250.xxx.xxx). A Safari visitor hits your site:

The same thing happens with:

• Server-side GTM on Google Cloud + website on WP Engine
• Any tracking server hosted separately from your website
• Cloud-hosted tagging solutions on different infrastructure than your site

Many WordPress site owners set up server-side tracking, congratulate themselves on solving the ITP problem, and never realize their cookies are still being capped. The implementation looks correct. The cookies are technically server-set. But Safari’s IP check still triggers the restriction.

How to Fix the IP Matching Problem

There are three approaches, ranging from technical to simple:

1. Run everything on the same server

If your WordPress site and tracking server share the same infrastructure, IPs automatically match. No configuration needed. Safari sees matching IPs and allows full cookie expiration. The downside: most tracking solutions aren’t designed to run inside WordPress.

2. Use a subdomain proxy through your existing hosting

Set up a subdomain like track.yourstore.com that proxies requests through your website’s infrastructure. Safari sees the cookie coming from your server’s IP, not the tracking provider’s IP. This requires reverse proxy configuration on your host, or a Cloudflare Worker to route traffic.

3. Use a first-party subdomain (simplest)

This is how Transmute Engine™ solves it. When you connect to your WordPress site, we set up a subdomain on YOUR domain:

This subdomain handles cookie setting. When Safari checks:

Why the first-party subdomain approach works

Safari’s ITP checks whether a cookie is “first-party” based on the registrable domain (the eTLD+1). For cherry.yourstore.com, the registrable domain is yourstore.com—same as your website. Safari treats it as first-party because it literally is.

This is different from CNAME cloaking, where you point a subdomain’s DNS to a third-party tracker’s IP. Safari detects and blocks CNAME cloaking by resolving the DNS chain. The first-party subdomain approach is legitimate because the subdomain is genuinely part of your domain’s tracking infrastructure—which is exactly what first-party means.

What you get with this approach:

Browser-by-Browser: What Actually Happens to Your Cookies#

2026 First-Party Cookie Limits: Quick Reference

* Safari 16.4+ checks if server IP matches website IP. Mismatch = 7-day limit even for server-set cookies. First-party subdomains (e.g., track.yourstore.com) bypass this check.

** Safari purges ALL site data (cookies, localStorage, IndexedDB) after 30 days without user interaction—regardless of how cookies were set. This is the ultimate backstop.

Here’s the reality for each major browser as of late 2024:

Chrome (67% market share): 400-day maximum lifetime for all cookies. No distinction between JavaScript and server-set. Third-party cookies still allowed (user choice model after Google’s April 2025 reversal). First-party cookies work normally.

Safari (24% market share): JavaScript cookies capped at 7 days. URLs with tracking parameters from classified trackers get 24-hour cap. Server-set cookies bypass limits IF IP addresses match. All site data purged after 30 days without user interaction. CNAME cloaking detected and blocked.

Firefox (3-5% market share): No hard cap on first-party cookies. Third-party cookies from known trackers blocked via Enhanced Tracking Protection (ETP). Storage purged from known trackers after 45 days without interaction. Total Cookie Protection partitions third-party cookies per-site.

Brave (1-3% market share): JavaScript cookies capped at 7 days, 6-month maximum for any cookie. CNAME uncloaking detects and blocks disguised trackers. Removes tracking parameters (fbclid, gclid) from URLs automatically.

Edge (4-5% market share): Follows Chrome’s 400-day limit. Tracking prevention blocks known trackers in Balanced mode (default).

How to Actually Fix This for WordPress#

Knowing the restrictions is step one. Here’s what you do about them:

1. Use server-set cookies with matching IPs. If you implement server-side tracking, ensure your tagging server runs on the same infrastructure (or uses a reverse proxy) so IP addresses align. Solutions like Stape’s Cookie Keeper or running server-side GTM on your existing hosting accomplish this. First-party data strategy starts with proper cookie infrastructure.

2. Stop relying on cookies for conversion data. WooCommerce gives you something better than cookies: actual customer data. When someone completes a purchase, you have their email, name, address, and order details. Facebook CAPI and Google Enhanced Conversions use this data—hashed and sent server-side—to attribute conversions without any cookies. No 7-day limit. No 24-hour trap. Just deterministic matching.

3. Accept the Safari reality for analytics. For general analytics (pageviews, sessions, engagement), some Safari data loss is unavoidable without server-side implementation. Prioritize conversion tracking accuracy over session tracking accuracy. A visitor who shows up as “new” but converts correctly is better than perfect session data with broken attribution.

4. Use coded UTM parameters. Ad blockers and browsers strip standard UTM parameters (utm_source, utm_campaign) using regex pattern matching. Coded UTM parameters like ref=a8x9z bypass pattern matching because they don’t match the predictable utm_ prefix.

For WordPress specifically, Transmute Engine™ handles this by capturing data server-side before browser restrictions apply, then routing conversions to GA4, Facebook CAPI, and Google Ads with proper attribution. No GTM required, no IP matching headaches, no JavaScript cookie limitations.

Key Takeaways#

First-party cookies aren’t going anywhere in 2026. But treating them as one-size-fits-all guarantees data loss. See what’s happening with third-party cookies for the complete picture—and why the solution to both is the same: server-side data collection. See how Seresa handles this for WordPress.