First-Party Cookies via Server-Side Tracking: Extending Cookie Lifetime Beyond Safari ITP

What Safari ITP Does to Your Cookie Lifetime

Safari's Intelligent Tracking Prevention (ITP) was introduced by Apple to limit cross-site tracking. Its most significant impact for analytics is the cookie lifetime restriction on JavaScript-set cookies.

Specifically: any cookie set by JavaScript on a domain that Safari's machine learning classifies as a "tracker" — or any third-party cookie — has its expiration date capped at 7 days. After 7 days, the cookie expires and the user appears as a new visitor.

For server-side tracking and GA4, this means Safari users who return to your site more than 7 days after their first visit appear as new users. Sessions are broken. Conversion attribution for users with longer consideration cycles is lost. Your GA4 new user numbers are inflated.

The ITP Timeline

ITP has evolved over the years. Key milestones that affected analytics:

• ITP 2.1 (2019): capped JavaScript-set first-party cookies at 7 days when the domain was a known tracker
• ITP 2.2 and later: increasingly aggressive caps across more domains
• Current ITP (Safari on iOS and macOS): 7-day cap on JavaScript-set first-party cookies for any domain with cross-site tracking classification

Google's analytics domains (googletagmanager.com, analytics.google.com) are classified as cross-site trackers by Safari. Any _ga cookie set by the GA4 JavaScript tag expires in 7 days on Safari.

How Server-Side Tracking Solves This

Safari's 7-day limitation applies to cookies set by JavaScript. It does NOT apply to cookies set by HTTP Set-Cookie headers from the server — specifically, from your own first-party domain.

When your sGTM server processes a GA4 event and responds with a Set-Cookie HTTP header for your custom subdomain (collect.yoursite.com), Safari treats this as a genuine first-party server-set cookie. These cookies can have expiration dates of up to 2 years — completely unrestricted by ITP.

How It Works in Practice

1. User visits your website in Safari
2. A request is sent to your sGTM server at collect.yoursite.com
3. Your sGTM server sets a _ga (or custom) cookie via HTTP Set-Cookie header: Set-Cookie: _ga=GA1.1.xxxx; Max-Age=63072000; Path=/; Domain=yoursite.com; Secure
4. Safari receives and stores this cookie with the full 2-year expiration
5. When the user returns 30 days later, the cookie is still present and they are recognised as a returning user

The server-side GTM cookie client (specifically, the GA4 cookie client in sGTM) handles this automatically when configured to set and read first-party cookies.

Configuration in sGTM

In your sGTM GA4 client settings:

• Enable "Serve cookie" (or "Set cookie" depending on the template version)
• Set cookie name: _ga (to maintain compatibility with client-side GA4) or a custom name
• Set expiration: 63072000 seconds (2 years)
• Set domain: your root domain (yoursite.com, not collect.yoursite.com — so the cookie is accessible to your main site)

The Before and After

• Before server-side tracking: Safari users who return after 7 days appear as new users in GA4. Long attribution windows for Safari users are broken.
• After server-side tracking: Safari users are correctly recognised as returning users for up to 2 years. Conversion paths longer than 7 days are now attributable.

For businesses with long consideration cycles (B2B, high-value purchases, subscription services), this is one of the most impactful improvements server-side tracking provides.

Summary

Safari ITP's 7-day cookie cap is a real problem for any business with returning users and longer-than-a-week consideration cycles. Server-side tracking bypasses this limitation by setting cookies at the HTTP header level from your own first-party domain, restoring full cookie lifetime for Safari users.

See our Server-Side Tracking service for implementation including first-party cookie configuration.

Need to fix your Safari cookie lifetime issues? Contact Adslytics.