Bypassing Safari ITP:
Same-Origin sGTM for 400-Day Cookies in 2026

1. What ITP actually does

Intelligent Tracking Prevention is Apple's anti-tracking mechanism in Safari. Lives in the WebKit browser engine, so Safari macOS, Safari iOS, every iPhone browser (Chrome on iPhone uses WebKit, not Blink). ITP classifies domains by user behavior as „tracking" or „non-tracking" and treats cookies on tracking domains more restrictively.

Three central mechanisms:

• 7-day cap for JavaScript cookies (all cookies set via document.cookie)
• 24-hour cap for cross-site trackers (cookies deleted after 24h if domain classified as tracker)
• IP-matching rule (Safari 16.4+): server-set cookies only get full lifetime if IP matches main site

2. History 2017-2026

3. The cookie capping problem in detail

Normal Google Ads conversion tracking works like this: user clicks ad, GCLID is written to a cookie (_gcl_aw), cookie lives 90 days, user returns in 3 weeks and converts, GCLID is sent, conversion is attributed.

With Safari ITP: user clicks ad, GCLID is written to cookie via JavaScript, cookie is capped to 7 days by ITP, user returns in 3 weeks - cookie is gone, GCLID gone, conversion not attributed. From Google's view it looks as if the user came „organically."

4. Safari 16.4 IP-Matching Rule (what many overlook)

Until Safari 16.4 (April 2023), there was a clear workaround: set cookies via HTTP Set-Cookie header from the server instead of via JavaScript. Server-set cookies were exempt from the 7-day cap and lived up to 400 days (browser default).

Since Safari 16.4, this has been restricted: server-set cookies only live their full lifetime if the server's IP address (or at least the /16 subnet prefix) matches the main domain's IP prefix. If not, the cookie still gets capped to 7 days.

Practical example: your website runs on Cloudflare (104.21.x.x), your sGTM on Stape EU (34.107.x.x). Safari sees: two different IP prefixes → treats sGTM cookies as „suspicious first-party" → caps to 7 days, even if you correctly set them via Set-Cookie HTTP header.

5. Why CNAME cloaking is dead today

An old workaround technique was CNAME cloaking: create a subdomain (track.example.com), point it via DNS CNAME to the tracking provider's server (e.g. track.example.com → customer.adobe.com). From the browser's perspective the subdomain is first-party, but Adobe is actually tracking.

Safari/WebKit detects CNAME cloaking since 2020. Mechanism: Safari performs a DNS lookup, checks if the CNAME target is outside the eTLD+1 (i.e. „outside the registrable domain"), and if yes → treats as tracker, caps JavaScript cookies to 7 days. CNAME cloaking is functionally dead today.

6. How much it actually costs

Real impact by business model:

Loss = Safari market share × share of users who convert after 7+ days. Safari share Germany: ~17% desktop, ~30% mobile. In mobile-first commerce disproportionately painful.

What this means for your conversion tools: with Meta CAPI the fbc and fbp cookies get capped - your EMQ score drops for Safari users. With Google Ads Enhanced Conversions the GCLID cookie only lives 7 days - conversions without an email match get unattributed after a week. Same-Origin sGTM rescues both tools at once.

7. The three solution paths

Three technical options, depending on setup complexity:

8. Same-Origin sGTM via Cloudflare Worker

Concrete setup for most cases - Cloudflare site fronts Stape sGTM:

1. Create Cloudflare Worker: Dashboard → Workers & Pages → Create Worker
2. Write Worker code (see below)
3. Bind route: example.com/sgtm/* → Worker
4. Change sGTM tagging URL in Web container from https://sgtm.example.com to https://example.com/sgtm
5. Publish container + live test

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    // Strip /sgtm prefix, forward to Stape endpoint
    const targetPath = url.pathname.replace(/^\/sgtm/, '');
    const targetUrl = 'https://sgtm.example.com' + targetPath + url.search;

    // Rebuild request with original method, headers, body
    const proxyRequest = new Request(targetUrl, {
      method: request.method,
      headers: request.headers,
      body: request.body,
      redirect: 'manual'
    });

    const response = await fetch(proxyRequest);

    // Pass through Set-Cookie headers (critical!)
    // Cloudflare merges them automatically
    return new Response(response.body, {
      status: response.status,
      headers: response.headers
    });
  }
};

What happens here: Cloudflare receives requests at example.com/sgtm/*, proxies them to Stape, returns the response including Set-Cookie headers. From the browser's perspective: all requests land on example.com - same domain, same IP range, no IP-matching problem, cookies live 400 days.

9. Alternative: Stape Custom Loader Power-Up

If you don't want to build a Cloudflare Worker, Stape offers the Custom Loader Power-Up (~$20/month extra). It injects a small loader script into your main domain that routes all sGTM requests through your main domain. Functionally the same result as the Worker approach, but Stape handles the infrastructure for you.

1. Stape dashboard → your container → Power-Ups
2. Activate Custom Loader
3. Stape generates code snippet - place this BEFORE the GTM script on your website
4. Switch sub-domain to same-origin path in container settings
5. Test in Safari ITP Debug Mode

10. Test in Safari ITP Debug Mode

How to verify your cookies are no longer capped:

1. Open Safari → Preferences → Advanced → enable „Show Develop menu"
2. Menubar → Develop → Experimental Features → ITP Debug Mode enable
3. Visit website → Develop → Show Web Inspector → Storage → Cookies
4. For each cookie check the Expires column - should be 400 days in the future, not 7 days
5. Console tab search for ITP Debug: logs - shows why a cookie was capped

11. GDPR remains unchanged

The same-origin solution doesn't change your GDPR obligations:

• ✓ Consent Mode v2 active: cookies only fire with consent
• ✓ Privacy Policy mentions all tracking cookies, even if set as first-party
• ✓ DPA with Stape/Cloudflare: Data Processing Agreement under Art. 28 GDPR
• ✓ Data minimization: 400-day cookie only for data you actually need (e.g. GCLID, session-ID)

Important: longer cookie lifetime does NOT make tracking „more GDPR-compliant" - you still have to meet all GDPR requirements. It just makes it technically functional for Safari users.

12. FAQ

What exactly is Safari ITP?

Intelligent Tracking Prevention is Apple's anti-tracking mechanism in Safari (since 2017). Since 2019, ITP caps all JavaScript-set cookies at a maximum of 7 days. Since Safari 16.4 (April 2023), it also caps server-set cookies if the server IP does not match the main-site IP prefix. Result: attribution data disappears after a week - which destroys performance bidding.

Why doesn't normal server-side GTM automatically help against ITP?

If your sGTM container runs on a subdomain (e.g. sgtm.example.com via Stape) and the IP prefix of the Stape servers does not match the IP prefix of your main server, Safari 16.4+ still treats it as „suspicious" and caps cookies at 7 days. Most Stape setups hit this problem - the solution is Same-Origin Path-Based setup.

What is CNAME cloaking and why doesn't it work anymore?

CNAME cloaking was an old technique: have a subdomain (track.example.com) point via CNAME to a third-party server so it appears first-party. Safari/WebKit has detected this since 2020 and caps all JavaScript cookies on such subdomains at 7 days. CNAME cloaking is functionally dead today - don't use it.

What's the solution against Safari ITP?

Same-Origin Path-Based sGTM: instead of subdomain sgtm.example.com, sGTM runs under example.com/sgtm/ via a reverse proxy (Cloudflare Worker, Nginx, or Stape Custom Loader Power-Up). Being same-origin, there are no IP-matching issues and cookies can be set for up to 400 days. Google explicitly recommends this setup.

How much difference does it really make?

Safari market share in Germany is ~17-20% desktop, ~30% mobile. With the 7-day cookie cap, all Safari users disappear from attribution as soon as they wait a week between click and conversion. With B2B sales cycles (weeks to months), that's 15-25% of attribution lost. With 400-day cookies via Same-Origin sGTM, attribution is preserved.

Is Same-Origin sGTM GDPR-compliant?

Yes - GDPR compliance does not depend on technical cookie lifetime, but on Consent Mode v2, correct privacy policy, DPA with providers and data minimization. Same-Origin Path-Based sGTM doesn't change these obligations - on the contrary, the first-party nature makes data ownership clearer for the advertiser.