A tracking subdomain that shares a website's name but not its network can lose most of its cookie lifetime in Safari, according to an analysis published on September 30, 2026 on the blog of TAGGRS, a Dutch server-side tagging host. Written by Mariusz Brucki, an analytics engineer and founder of Measurelake, the piece describes how WebKit compares the network address of a tracking endpoint with that of the main site and, when the two look unrelated, caps cookies set by the server at seven days. The proposed workaround, serving tracking from a path on the site's own host instead of a subdomain, is also a feature TAGGRS sells.

In Short

Many websites send their tracking data through a helper address such as sst.example.com, and Safari can notice when that helper actually lives on a different company's servers and shorten its cookies to one week. When a shopper comes back after more than a week, the site may treat that person as a brand-new visitor, which breaks the link between an ad click and a later purchase. Moving the tracking to a folder on the main website, like example.com/metrics, avoids this one Safari rule, though it does not stop other browser limits, ad blockers or consent requirements from applying.

The eight-day gap

The article opens with a scenario that most e-commerce analysts will recognise. A Safari visitor arrives through an ad, browses some products and leaves. "Eight days later the same browser comes back and buys," Brucki wrote. The analytics platform records a new user rather than connecting the two visits. "The visitor didn't change devices or clear their cookies. An identifier in Safari simply expired."

The point of the piece is that moving to Server-side Tracking, which many advertisers adopted precisely to make measurement less fragile, does not by itself guarantee a long cookie lifetime. According to Brucki, "the public endpoint used by the browser still matters." A same-site tracking subdomain "can face a seven-day cookie cap when WebKit detects CNAME or IP address cloaking."

That distinction matters because the industry has spent several years treating server-side tagging as the answer to Safari. Moving to a server-side container changes the route data takes: browser code sends selected events to a server container first, which processes them and forwards them to analytics and advertising platforms. That gives a site more control over what is collected and shared. But, as the analysis notes, "anonymous visitor recognition still often depends on an identifier stored in the browser." GA4, for example, commonly recognises a returning browser through a client ID held in a first-party cookie. A cookie identifies a browser instance, not necessarily a person.

Same-site is not same-origin

Much of the confusion, according to Brucki, comes from two terms that are used as if they were interchangeable. "The two terms get used interchangeably, but to a browser they mean different things."

Same-site means two addresses share the same registrable domain, the unit browsers call eTLD+1. Same-origin is stricter: scheme, host and port must all match. A site at https://yourdomain.com and a tracking endpoint at https://sst.yourdomain.com both use HTTPS and share yourdomain.com, so they are same-site. They are still different origins, because the host differs. Only when the endpoint moves to a path on the main host, such as https://yourdomain.com/metrics, do page and endpoint share scheme, host and port.

The TAGGRS article sets out the comparison in a table. A same-site subdomain is seen by the browser as "a separate host," and Safari's cloaking cap "can apply." A same-origin path is seen as the site itself, and the cap "doesn't apply."

Same-site tracking already provides a first-party context, and for many implementations that is enough. The article is explicit, though, that "sharing the registrable domain does not guarantee that Safari will leave every server-set cookie untouched."

How WebKit decides what counts as cloaking

The rule, as Brucki summarised it, is this: "if the server setting your cookie sits on a network address unrelated to your main site's, Safari treats it as disguised tracking and caps that cookie at seven days, even when the cookie was set server-side through an HTTP response."

Some history helps. Cookies written by JavaScript were already capped at seven days of Safari use, and at 24 hours in some link-decoration cases, under Intelligent Tracking Prevention. Setting cookies through an HTTP response used to sidestep that limit, which is one reason server-set cookies became the standard recommendation. According to the article, that changed with Safari 16.4 on March 27, 2023: when Safari detects that a cookie comes from a server unrelated to the main site, through CNAME or IP address cloaking, it applies the same seven-day cap.

The technical test is specific. According to the TAGGRS analysis, WebKit compares the network address behind the tracking response with the one the main site uses, and treats them as belonging to different parties in three cases:

  • one address is IPv4 and the other is IPv6
  • two IPv4 addresses share fewer than 16 leading bits
  • two IPv6 addresses share fewer than 64 leading bits

In IPv4 terms, 16 leading bits means the first two of the four numbers in an address. Two servers whose addresses begin with different first or second blocks would be treated as unrelated. WebKit calls this a heuristic, the article notes, "so the exact behavior may change in future browser releases."

A common configuration trips it. The main website runs behind Cloudflare, while sst.yourdomain.com resolves to a tracking provider on another network. "The names are same-site, but their network addresses are unrelated, so cookies set in the tracking response get capped at seven days," Brucki wrote.

He was careful to limit the claim. "This is not a seven-day limit on every server-set first-party cookie. It applies only when Safari detects that specific cloaking condition. An ordinary same-origin cookie isn't affected."

The article does not say how many Server-side Tracking setups fall into this category, or what share of TAGGRS customers do. It gives no measured figures for lost returning users or broken conversion paths. The mechanism is documented; its scale, in this source, is not.

What expiry does to the numbers

The consequences sit in reporting, and the article describes them in conditional terms. Suppose a browser identifier is configured to last one year, and Safari reduces it to seven days. The browser keeps sending the identifier during the seven-day window. If it returns after expiry, the tracking setup may issue a new identifier, and GA4 or another analytics platform then measures both visits under separate browser identities. "Returning Safari visitors get counted as new, new-user numbers inflate, and campaign clicks stop connecting to the conversions that follow," according to Brucki.

Other signals can soften this. A signed-in User ID might reconnect the visits, and analytics systems may use modeled data. Cookie expiry therefore can cause fragmented journeys rather than guaranteeing that every returning visitor is counted as new, the article says.

For paid media, the effect reaches bidding. If an earlier campaign visit and a later conversion no longer share a usable identifier, the platform may struggle to connect them, "which is how weaker conversion data reaches Smart Bidding," according to the analysis. Remarketing works the same way: more stable identifiers can improve the inputs used to build and refresh audiences.

Two clarifications in the piece are worth noting because they correct a common misreading. A longer cookie does not lengthen an attribution window. "A longer-lived cookie does not turn a seven-day advertising attribution window into a 30-day window," the article says. It only preserves a browser signal that may be used for conversions within the platform's existing window. Likewise, audience membership duration, consent, minimum list sizes and platform policies still apply to remarketing.

The same-origin route

The fix the article proposes is to stop using a separate host. With same-origin tracking, the browser sends requests to a path on the website's primary host, for example https://yourdomain.com/metrics. A reverse proxy receives requests under that path and forwards them to the Server-side Tracking container; a Cloudflare Worker can do this routing at the edge.

For those calls, the browser talks to yourdomain.com, not a tracking subdomain, so the separate-host cloaking scenario no longer applies. The Worker sends the request to the existing tracking host and returns its response to the browser. "Any Set-Cookie header must be forwarded correctly," Brucki wrote.

There are technical caveats. Cookies are not generally scoped to an origin; their availability depends on attributes such as Domain, Path, Secure, HttpOnly and SameSite, and the proxy has to preserve or correctly configure them. Same-origin routing "does not make cookies permanent or guarantee that Safari will keep them for the full configured period." Persistent cookies are commonly subject to a general maximum of around 400 days in browsers. Users can delete storage, change consent or browse privately.

The approach will look familiar to anyone who followed Google's own measurement infrastructure. The Google tag gateway works on the same principle, serving Google tags from a path on the advertiser's domain rather than from googletagmanager.com. When Google introduced the tag gateway in May 2025, Cloudflare was the launch partner, and advertisers who configured it reported an 11% uplift in signals compared with standard implementations. Google later added one-click deployment on Google Cloud, suggesting paths such as /metrics, /securemetric or /analytics, and the Google Cloud integration reached general availability on June 1, 2026, by which point Fastly was citing a 14% uplift. Those figures come from Google and its CDN partners rather than independent measurement.

Ad blockers, and a path-naming tension

The article also addresses blocking. A separate tracking hostname gives blockers a clear signal to match; moving tracking to a path on the main host removes it. That can reduce blocking based on hostname and CNAME rules, but, according to Brucki, "it cannot guarantee delivery."

Extensions can match URL paths, request patterns or site-specific rules, and the article warns that "obvious paths such as /analytics, /track, or /collect may still attract filters." That sits awkwardly with some of the industry's default examples: /analytics is one of the three paths Google suggested for its own tag gateway, and the TAGGRS article's own example is /metrics. Same-origin routing, the piece concludes, "should therefore be treated as a way to reduce specific blocking signals, not as a method that bypasses every ad blocker."

The scale of the blocking problem is not small. An analysis covered by PPC Land in October 2024 estimated that about 250 million users run some form of blocker, and about 129 million use blockers that stop Google Analytics by default.

Where TAGGRS fits, and what is a sales pitch

The final third of the article describes TAGGRS's own implementation. TAGGRS supports same-origin serving through a Cloudflare Worker that keeps a customer's existing Product ID and server container while changing the browser-facing route. The tracking script and collection calls load through a path on the website's host; the Worker strips the path prefix and forwards each request to the existing TAGGRS tracking host. The site's hostname carrying the Worker route must be proxied through Cloudflare, and the Worker is bound only to the selected tracking path, so it does not run on every request. The standard TAGGRS snippet remains, with script and noscript URLs updated to the new path. If Cloudflare blocks Google Tag Manager Preview traffic, the article points to Cloudflare's Security Events as the first place to look before any narrowly scoped exception is added.

That context matters for how the piece is read. TAGGRS, which its site says was established in 2022 and is based in Heerenveen in the Netherlands, sells server-side tagging hosting, and the article ends with a call to start a free account. Its FAQ also points readers seeking "broader protection against ad-blocking techniques" to the company's Enhanced Tracking Script, ETS v3. The WebKit mechanism it describes is not a TAGGRS claim and is consistent with Safari's published behaviour since 2023, but the framing of the remedy, and the absence of any data on how often the problem occurs, are those of a vendor explaining a product. The article states its benefits cautiously: "The improvement concerns measurement accuracy. It does not create more visitors or conversions." It also makes the point that, where consent is required, a longer cookie lifetime "does not replace that consent."

The byline adds a further wrinkle. Brucki is described in his author profile as the founder of Measurelake.com, a separate business, while writing on the TAGGRS blog. The article does not set out the commercial relationship between the two.

Why this matters now

Safari's tracking rules have been tightening in stages, and each stage has hit a different layer. Apple's Intelligent Tracking Prevention pushed Google and Microsoft to first-party click identifiers in 2018. Safari blocked all third-party cookies by default in March 2020. With Safari 26, Apple made Advanced Fingerprinting Protection the default for all browsing, restricting cookies and query-parameter access for classified fingerprinting scripts.

Then came Safari 27. In July, a review by Brucki on the same TAGGRS blog found that the Safari 27 beta blocks Bing's tracking endpoint by checking the destination IP address of outbound connections, a layer that first-party proxying does not avoid because it evaluates where the request goes rather than where the script came from. When iOS 27 shipped on September 14, 2026, Safari stopped resolving The Trade Desk's adsrvr.org domain and several identity vendors' domains.

The September 30 analysis concerns a quieter mechanism than those blocks, but it shares their logic: Safari increasingly looks past what a domain name claims to be and at the network that actually serves it. For advertisers, that is the practical lesson of the piece. A first-party name on a third-party network is, to WebKit, not first-party. The same reasoning helps explain why Google built its tag gateway around paths on the advertiser's own host.

What remains unknown is how widespread the problem is. The analysis offers no data on how many server-side setups run on a subdomain pointed at a different network, how many Safari journeys are split by the seven-day cap, or how much conversion volume reappears after a move to same-origin routing. Safari's share of traffic, and the length of a typical purchase cycle, will decide whether the gap matters for any given advertiser. For a product bought within a day, a seven-day cookie is ample. For a considered purchase that takes two weeks, it is not.

Timeline

Summary

Who: Mariusz Brucki, an analytics engineer and founder of Measurelake, writing on the blog of TAGGRS, a server-side tagging host based in Heerenveen, the Netherlands. The analysis concerns Apple's Safari and its WebKit engine, and affects advertisers, analysts and agencies running Server-side Tracking.

What: An explanation of how Safari caps cookies set by a server at seven days when a same-site tracking subdomain resolves to a network address WebKit considers unrelated to the main site, using thresholds of 16 shared leading bits for IPv4 and 64 for IPv6, and how serving tracking from a path on the site's own host avoids that specific cap. TAGGRS offers this through a Cloudflare Worker.

When: Published on September 30, 2026. The underlying Safari behaviour dates from Safari 16.4 on March 27, 2023.

Where: In Safari on Apple devices, wherever a website's tracking endpoint runs on a subdomain hosted on a different network, such as a site behind Cloudflare with a tracking subdomain pointed at a separate provider.

Why: When the identifier expires after seven days, returning Safari visitors can be measured as new users and earlier ad clicks can lose their link to later conversions, weakening the data that reaches analytics, attribution and bidding systems. The article gives no figures on how often this happens, and its proposed remedy is a product its publisher sells.