Safari's 7-day cookie cap: How same-origin tracking restores full cookie lifetimes

A Safari visitor finds you through an ad, browses a few products, and leaves. Eight days later the same browser comes back and buys. Your analytics records a new user instead of connecting both visits.

The visitor didn’t change devices or clear their cookies. An identifier in Safari simply expired.

Server-side Tracking makes data collection less dependent on direct requests to analytics and advertising platforms. It can also use cookies set through an HTTP response, which are treated differently from cookies created by JavaScript.

But Server-side Tracking alone does not guarantee a long cookie lifetime. The public endpoint used by the browser still matters. On Safari, a same-site tracking subdomain can face a seven-day cookie cap when WebKit detects CNAME or IP address cloaking.

Same-origin tracking helps avoid that specific problem.

Server-side Tracking does not remove the browser from measurement

In a typical client-side setup, tags in the browser send events directly to analytics and advertising platforms. Server-side tagging changes the route. Browser-side code sends selected events to a server container first. That container processes the data and forwards it to the required destinations. This gives the website more control over what gets collected and shared. It also reduces reliance on third-party browser requests that may be blocked.

Anonymous visitor recognition still often depends on an identifier stored in the browser. GA4, for example, commonly uses a client ID stored in a first-party cookie to recognize the same browser across visits. A cookie identifies a browser instance, not necessarily a person. Signed-in User ID, modeled data, and other identity methods may also help connect activity.

Same-site and same-origin are not the same

The two terms get used interchangeably, but to a browser they mean different things. 

Same-site means the same registrable domain. Same-origin is stricter: the scheme, host, and port must all match. A tracking subdomain clears the first bar and fails the second.

Take a website at https://yourdomain.com. Its tracking endpoint might run at https://sst.yourdomain.com. Both use HTTPS and share the registrable domain yourdomain.com, so under the modern definition they are same-site, but they are still different origins, because the host is different. 

Move the endpoint to a path on the site's own host, like https://yourdomain.com/metrics, and the page and the tracking endpoint finally share the same scheme, host, and port. Now they are same-origin.

	Same-site subdomain	Same-origin path
Example	sst.yourdomain.com	yourdomain.com/metrics
Browser sees	A separate host	Your own site
Same scheme + host + port as your site	No	Yes
Safari cloaking cap	Can apply	Doesn't apply

Same-site tracking already provides a first-party context. That can be enough for many implementations. However, sharing the registrable domain does not guarantee that Safari will leave every server-set cookie untouched.

Why Safari can cap server-set cookies

The rule in plain terms is: 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.

Cookies written by JavaScript were already capped at seven days of Safari use, and at 24 hours in some link-decoration cases. Setting cookies server-side, through an HTTP response, used to avoid that limit. Since Safari 16.4 (March 27, 2023), that's no longer guaranteed: if Safari detects that the cookie is coming from a server unrelated to your main site, through CNAME or IP address cloaking, it applies the same seven-day cap.

WebKit decides that by comparing the network address behind the tracking response with the one your main site uses. It treats them as belonging to different parties when one address is IPv4 and the other IPv6, when two IPv4 addresses share fewer than 16 leading bits, or when two IPv6 addresses share fewer than 64 leading bits. WebKit calls this a heuristic, so the exact behavior may change in future browser releases.

A common Server-side Tracking setup triggers exactly this. Your 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.

One thing to be precise about: 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, which is exactly what the fix below relies on.

What happens when the identifier expires

For measurement, the effects may not be noticeable but they can end up expensive. Returning Safari visitors get counted as new, new-user numbers inflate, and campaign clicks stop connecting to the conversions that follow.

Suppose a browser identifier is configured to last one year, but Safari reduces it to seven days. The browser can continue sending that identifier during the seven-day window. If the browser returns after it has expired, the tracking setup may create a new identifier. GA4 or another analytics platform can then measure both visits under separate browser identities. New-user counts may rise, while returning-user recognition becomes less complete.

Other identity signals can change the outcome. A signed-in User ID might reconnect the visits. Analytics systems may also use modeled data. Cookie expiry therefore can cause fragmented journeys, rather than guaranteeing that every returning visitors get counted as new, which is one reason why your Meta, GA4, and Google Ads conversions don't match

Attribution faces a similar limitation. If an earlier campaign visit and a later conversion no longer share a usable identifier, the measurement platform may struggle to connect them, which is how weaker conversion data reaches Smart Bidding.

The configured attribution window remains a separate rule. A longer-lived cookie does not turn a seven-day advertising attribution window into a 30-day window. It helps preserve a browser signal that may be used for eligible conversions within the platform’s existing window.

Remarketing works in much the same way. More stable identifiers and more reliably delivered events can improve the inputs used to populate or refresh audiences. Audience membership duration, consent, minimum list sizes, and platform policies still apply.

How same-origin tracking avoids the separate-host scenario

With same-origin tracking, the browser sends tracking requests to a path on the website’s primary host:

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 perform this routing at the edge.

For these calls, the browser communicates with yourdomain.com, not a separate tracking subdomain. The separate-host CNAME and IP 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.

Cookies are not generally scoped to an origin. Their availability depends on attributes such as Domain, Path, Secure, HttpOnly, and SameSite. The proxy must preserve or correctly configure those attributes.

Same-origin routing avoids this particular seven-day cloaking cap. It does not make cookies permanent or guarantee that Safari will keep them for the full configured period.

Browsers can impose other limits. Persistent cookies are also commonly subject to a general maximum of around 400 days. Users can delete storage, change consent, or use private browsing.

Same-origin tracking and ad blockers

A separate tracking hostname gives blockers a clear signal to match. Moving tracking to a path on the website’s main host removes that hostname signal.

That can reduce blocking caused by hostname and CNAME rules. It cannot guarantee delivery.

Browser extensions can also match URL paths, request patterns, or site-specific rules. Obvious paths such as /analytics, /track, or /collect may still attract filters.

Same-origin routing should therefore be treated as a way to reduce specific blocking signals, not as a method that bypasses every ad blocker.

What marketers gain

Same-origin tracking can improve the continuity of cookie-based measurement in Safari. Browsers returning after more than a week are less likely to receive a new identifier solely because WebKit classified a separate tracking host as cloaked.

More durable browser recognition can help analytics connect longer customer journeys. It can also preserve useful signals for attribution and audience processing, within the rules set by each platform.

The improvement concerns measurement accuracy. It does not create more visitors or conversions. Fewer existing journeys may be split across multiple browser identifiers, which means less of your reporting rests on modeled conversions.

Applicable privacy and device-storage rules still apply. Where consent is required, extending a cookie’s lifetime does not replace that consent. The purpose, duration, and use of the identifier must remain properly disclosed. When done properly, same-origin tracking is one piece of a wider shift toward first-party data marketing — measurement built on data you own and can account for.

Where TAGGRS fits

TAGGRS supports same-origin serving through a Cloudflare Worker. The implementation keeps the 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 own host. The Worker removes that path prefix and forwards each request to the existing TAGGRS tracking host.

For this specific implementation, the website hostname carrying the Worker route must be proxied through Cloudflare. The Worker is bound only to the selected tracking path, so it does not run on every website request.

The standard TAGGRS snippet remains in place, with its script and noscript URLs updated to use the same-origin path. If Cloudflare blocks GTM Preview traffic, its Security Events should be checked before adding a narrowly scoped exception.

You can find the full walkthrough in our documentation: Same-origin tracking with a Cloudflare Worker.

Conclusion

Server-side Tracking improves control over data collection, but the browser-facing endpoint still affects how long some identifiers survive. A same-site subdomain can remain subject to Safari’s CNAME or IP cloaking checks. Serving tracking through a path on the website’s exact origin avoids that separate-host scenario.

The change can improve returning-browser recognition and preserve more measurement continuity. It does not extend an advertising platform’s attribution settings, guarantee cookie storage, or make tracking immune to ad blockers.

Ready to set it up? Follow our step-by-step guide on Same-origin tracking with a Cloudflare Worker, or start with TAGGRS for free and get the server container running first.

FAQ

Is same-site tracking the same as same-origin tracking?

No. Same-site URLs share the same scheme and registrable domain, so different subdomains can be same-site. Same-origin is stricter: the scheme, host, and port must match. https://yourdomain.com and https://sst.yourdomain.com are same-site but cross-origin.

Does Safari cap every first-party cookie at seven days?

No. Persistent cookies created through JavaScript are covered by WebKit’s limits on script-writable storage. Cookies set through an HTTP response can also receive a seven-day cap when WebKit detects third-party CNAME or IP address cloaking. Ordinary same-origin server-set cookies are not covered by that specific cloaking cap.

Does same-origin tracking guarantee a 400-day cookie lifetime?

No. It avoids the specific seven-day cap associated with a cloaked tracking subdomain. The configured cookie attributes, other browser policies, private browsing, user deletion, and consent changes can still shorten or prevent storage. Browsers may also apply a general maximum lifetime to persistent cookies.

Will same-origin tracking extend attribution or remarketing windows?

No. Those windows are controlled separately by each advertising platform. A more durable browser identifier may help connect eligible activity within an existing window, but it does not change the window itself or an audience’s configured membership duration.

Does same-origin tracking bypass all ad blockers?

No. It removes the separate tracking hostname that some blocking rules use. Extensions can still block requests by path, behavior, or site-specific rules. Same-origin routing reduces certain blocking signals without guaranteeing that every request will be delivered. For broader protection against ad-blocking techniques, combine same-origin routing with Enhanced Tracking Script (ETS v3).