Article
Server-side GA4 on Shopify: what it costs, what it recovers, and why the CNAME isn't enough
The tagging subdomain via CNAME does not give you back the two-year cookie on Safari: since November 2020 ITP recognises it and caps it at seven days. What server-side really recovers, and what it costs.
The step almost every guide describes as decisive, the tagging subdomain via CNAME, does not give you back the two-year cookie on Safari. Since November 2020 ITP recognises it and caps it at seven days. This guide explains what server-side really recovers, what it costs, and which configuration actually produces the effect everyone takes for granted.
Category: implementation · 13 minute read · Mattia Minafò · updated 18 August 2026
What this is about
You’ve read that GA4 loses data, that server-side recovers it, and that all you need is a container on Stape and a DNS record. Then you did the setup, the cookie is still seven days on Safari, and you can’t tell whether you got something wrong.
The questions this guide answers: how much does server-side really recover, what does it cost to maintain, and which configuration is needed for the cookie to survive on Safari.
In order: what gets lost in the browser, why the CNAME alone isn’t enough, what it costs across three hosting options, how much it recovers according to the vendor and according to our own measurements, the five steps, what it doesn’t solve, and the checklist.
Method and limits. Safari’s behaviour is verified against WebKit’s official blog and vendor documentation, as of 18 August 2026. Project numbers come from our own audits, with the window stated. Prices change often and should be re-checked on the linked pages. This is not a guide to debugging your specific setup.
You’ll find three labels in the text. Documentation when the source is official, measured by us when the number comes from one of our audits, recommendation when it is a professional judgement rather than a fact.
Contents
- What browser tracking really loses
- Why the CNAME alone doesn’t give you back the two-year cookie
- What it really costs, three options compared
- How much it recovers, and who measured that number
- The five steps, including the one usually skipped
- What server-side does not solve
- The checklist before and after go-live
What browser tracking really loses
Three causes, of very different weight.
The first is Safari. Cookies set by JavaScript, including the _ga cookie GA4 uses to recognise the user, are capped at seven days of life. Anyone returning after a week counts as a new user. On a store with a long purchase cycle this inflates new users and flattens returning ones.
The second is network-level blocking. Ad blockers intercept requests to known tracking domains before the browser executes them. The tag is never downloaded and no event fires.
29.5% of internet users worldwide use an ad blocker, according to Backlinko’s compilation of DataReportal data. Read it for what it is: an average across global internet users, not across your store’s visitors. On yours it can be double or half.
The third is the composition of your traffic, and it is the only one you can measure before spending.
Measured by us. On a Shopify store, in the 8 July / 4 August 2026 window, traffic was 64% Safari and 27% Instagram in-app browser on Android, over 90% combined. Those are the two environments where the browser channel loses most, and they are the reason server-side made sense on that store.
Recommendation. Before reading the rest, open GA4 under Tech and look at the Safari share and the in-app browser share. If they are under 25% combined, the rest of this guide matters much less to you.
Why the CNAME alone doesn’t give you back the two-year cookie
This is the part that changes how the setup should be done.
The widespread idea is: put the tagging container on a subdomain of yours, the browser treats it as first-party, the cookie goes back to two years. The first half is right. The second hasn’t been true for six years.
Documentation. On 12 November 2020 WebKit wrote that “ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days”, and defined CNAME cloaking as “a first-party subresource that resolves through a CNAME that differs from the first-party domain”.
A subdomain tag.yourdomain.com resolving via CNAME to your vendor’s endpoint falls exactly within that definition. Safari recognises it and caps the cookie at seven days, even when the cookie arrives from an HTTP header rather than from JavaScript.
Then the defence widened twice. In autumn 2022 the cap was extended to responses coming from third-party IP addresses. With Safari 16.4 came the address-matching rule: if the tagging subdomain resolves to an IP too far from the site’s own, the cookie goes back to seven days regardless.
Stape, which sells hosting for tagging containers, documents this on its own blog and has no interest in doing so: “Safari won’t decrease cookies’ lifetime if the IP address of the domain that sets first-party cookies is half matching”, that is the first 16 bits on IPv4 and the first 64 on IPv6 (Stape, Safari ITP guide).
Translated: the cookie survives only if the container’s traffic leaves from the same address as your site, or close to it.
| Configuration | What Safari does to the cookie | When it makes sense |
|---|---|---|
| Subdomain via CNAME to the vendor | Caps it at 7 days | Fine for getting past ad blockers, not for cookie lifetime |
| Subdomain via A record to the vendor’s IP | Caps it at 7 days if the IP doesn’t match the site | Doesn’t solve it on its own, the IP has to be checked |
Path on the same domain, e.g. yoursite.com/sgtm | Full lifetime | The most solid, requires a reverse proxy at the origin |
| Traffic routed through your CDN, same IP as the site | Full lifetime | Good compromise, requires Cloudflare or equivalent |
Recommendation. If your goal is getting past ad blockers, the CNAME is enough and you can stop there. If your goal is cookie lifetime and recognising returning users, you need a same-origin configuration or routing through your CDN. They are two different jobs and they get sold as if they were one.
What it really costs, three options compared
Prices change, the pricing model doesn’t. You pay per request to the container, not per site traffic, and the two diverge quickly once you start forwarding events to several platforms.
Managed service. Stape has a limited free plan and paid plans starting around $17-20 a month per container, with rising request thresholds. The current price list is the only source to use, because these figures move.
Google Cloud Run. Here the number that circulates in guides, under ten dollars a month, deserves a clarification. Google recommends provisioning the server “as a cluster for better availability, scalability, and performance”. Under ten dollars a month you are paying for a single instance that scales to zero, which is the opposite of what Google advises, and cold starts lose events. A real production environment costs considerably more.
Self-hosted. It works, it costs little, and you take on maintenance, image updates and monitoring. It makes sense if someone in the company already does that work.
Recommendation, and the threshold we use with clients. Infrastructure cost is almost always the smaller line. What matters is the cost of configuration and maintenance. The threshold we state in proposals is that server-side starts to make sense above €1,000-1,500 a month in ad spend, where the infrastructure accounts for two or three per cent of spend. Below that the work doesn’t pay for itself, and you are better off fixing UTMs and the data layer first.
How much it recovers, and who measured that number
Here most content on the subject quotes a single figure and doesn’t say where it comes from.
The vendor’s number. Stape published an analysis of over seven million requests and reports a recovery of 20.71% of events and 30.67% on purchases alone. It is real data, and it is published by the company selling the service that data justifies. Read it knowing that.
Our independent measurement. On a Shopify store, in the 8 July / 4 August 2026 window, we counted the events that exist only on the server channel and not on the browser one. The net contribution is 1,774 events, that is 23.9% of the overall signal and 31.7% on product views alone. In detail, page views 4,025 against 3,327, plus 21%. Product views 3,389 against 2,316, plus 46%. The deduplication rate was 78%, above the 75% operational reference threshold.
That one measurement of ours and one of the vendor’s land three points apart is the most useful thing in this section. Not because it confirms the number, but because it establishes the order of magnitude: you recover something around a quarter of the signal, not half and not ten per cent.
The counterexample, which counts as much as the rest. On another project we tested an official Google claim that one of its server-side tagging solutions delivers a conversion uplift of around 14%. In our tests that number was not confirmed. We haven’t published it as a general refutation, because a small sample refutes nothing, but we don’t use it to sell either.
A case where server-side made a number worse. On one GA4 property, after the release, the share of sessions with no source rose to 17%. Part of that increase was traffic that used to be lost entirely and that the server had started to see, arriving however without a provenance label. The system was working better and the report was getting worse.
The five steps, including the one usually skipped
1. Choose where the container runs. Managed service if you have no technical team, Cloud Run if you already have Google Cloud and someone watching it. This choice matters less than the next step.
2. Configure the domain, and check the IP address. This is the step that decides whether you get cookie lifetime or not. Set up the subdomain, then compare the IP address it resolves to with your site’s. If they don’t match on the first blocks, you have got past ad blockers and nothing else. For full lifetime you need a same-origin path or routing through your CDN.
3. Update the web container. In the GA4 configuration tag, set the server address as the events’ destination. From that moment the browser talks to your domain instead of directly to Google, and that is what gets requests past domain-list-based ad blockers.
4. Set the cookie from the server. In the server container, enable writing the cookie via HTTP header. Without step 2 done properly, this step does not produce the effect you expect, and in production it is the most misunderstood combination of the two.
5. Verify, before declaring the job done. The useful check is not that events arrive. It is that the user identifier stays the same between one session and the next more than seven days apart, on Safari, on a real device.
Recommendation. Run the step 5 check on a real iPhone, not a simulator and not Chrome. It is the only environment where the defect shows, and it is why it goes unnoticed for months.
What server-side does not solve
Consent. If the user doesn’t consent, nothing fires, neither from the browser nor from the server. Server-side and consent management coexist, they don’t replace each other, and moving collection to the server does not make it lawful to collect what you couldn’t collect before.
Wrong or missing UTMs. The server collects more, it doesn’t collect better. If campaign links aren’t labelled, you’ll have more events attributed the same wrong way.
The Shopify sandbox separation. Shopify’s native pixel and your container remain two independent layers. If you send the same events from both without deduplication, the problem you create is worse than the one you solve.
The most aggressive ad blockers. Advanced lists recognise address patterns too, not just domains. The loss falls a lot, it doesn’t go to zero.
Discontinuity in time series. On release day the numbers go up and it isn’t growth. Annotate the date in GA4, otherwise in six months someone will read that step change as a marketing result.
The checklist before and after go-live
Before
- Safari and in-app browser share measured in GA4, not estimated
- Monthly ad spend above the threshold that justifies the maintenance
- UTMs and data layer already correct, verified on a real order
- Decided whether the goal is getting past ad blockers, cookie lifetime, or both
After
- The subdomain’s IP address compared with the site’s
_gacookie expiry checked on a real iPhone, beyond seven days- User identifier stable across two sessions more than a week apart
- Deduplication rate measured, if you are also forwarding to advertising platforms
- Release date annotated in GA4
- Comparison between back-office orders and GA4 transactions redone after release, on the same window as before
In short
Server-side recovers a real share of signal, on the order of a quarter on stores with heavy Safari and in-app traffic.
Cookie lifetime, which is the benefit it gets sold on most often, depends on how your subdomain resolves and not on having a container. It is worth verifying before signing, not after.
Sources
- WebKit, CNAME Cloaking and Web Privacy, 12 November 2020, retrieved 18 August 2026
- WebKit, Intelligent Tracking Prevention, 2017 and later updates, retrieved 18 August 2026
- Google Developers, Server-side tagging manual setup guide, retrieved 18 August 2026
- Google Developers, Introduction to server-side tagging, retrieved 18 August 2026
- Stape, Safari ITP guide, retrieved 18 August 2026, vendor of hosting for tagging containers
- Stape, pricing, retrieved 18 August 2026
- Stape, analysis of server-side event recovery, July 2025, interested vendor
- Backlinko, Internet statistics, on DataReportal data, retrieved 18 August 2026
- Internal measurements from audits of Shopify stores, windows stated in the text
The first step
Open a terminal and compare two addresses: the one your tagging subdomain resolves to and your site’s. If the first two blocks don’t match, the cookie you are writing from the server on Safari lives seven days.
It is a two-minute check. If the result doesn’t add up, get in touch and we’ll work out together which configuration you need.
Content verified against official documentation on 18 August 2026. Safari’s rules and vendor pricing change often; if you are reading this much later, re-check the links.