This is the question behind most server-side tracking purchases, even when the deck says "data quality": can we get back the visitors the blockers are hiding from us? The honest answer has three parts: yes for a slice, never for another slice, and there is a third slice you must not touch. Vendors tend to present only the first part. Here are all three.
Why blockers beat client-side tracking so easily
Ad blockers work mostly from public filter lists: known domains and script patterns (googletagmanager.com, google-analytics.com, connect.facebook.net) get their requests dropped before they leave the browser. Client-side tracking is trivially recognizable this way, which is why the blocking is so complete for users who have it.
Safari's Intelligent Tracking Prevention attacks a different layer: it does not block the request, it strangles the memory. Cookies set by JavaScript live seven days at most, sometimes 24 hours, so a returning Safari visitor keeps becoming a stranger, fragmenting attribution and returning-customer reporting on every Apple device in your audience.
What server-side genuinely recovers
Moving collection to data.yourshop.com changes both games meaningfully:
- Generic filter lists no longer match. Your endpoint is a first-party subdomain not on anyone's list (yet; see below), so the standard blocklist user's events arrive again.
- Server-set cookies escape ITP's harshest clipping. Cookies set via HTTP response from your own server can live longer than the script-set kind, so Safari visitors stay recognizable across the multi-day consideration windows that e-commerce actually has.
For a typical store, those two mechanisms are the entire realistic upside, and they are real. Their size is your audience's blocker-and-Safari share, which varies enormously (tech audiences blocking heavily, mainstream shopping audiences less so), and which no vendor can quote for you in advance. Measure your capture gap before and after; that difference is the truth, and anything else is brochure.
What it never recovers
- Determined blockers. Stricter tools and lists add custom first-party tracking endpoints over time (community-maintained lists actively hunt sGTM patterns), and users running them tend to be thorough. This is an arms race in which you are visibly the slower party.
- DNS-level blocking. Pi-hole, NextDNS, and network-wide filters kill requests below anything your architecture can influence. Gone is gone.
- JavaScript disabled, strict browsers, and the genuinely tracking-hostile. A small slice, but permanently dark, and honestly: they have made themselves clear.
- Consent refusals. The big one, and it gets its own section.
The permanent takeaway: some fraction of your audience is unmeasurable, forever, by any architecture. Good analytics is built knowing that, with a known error margin, not pretending a tool made the gap zero.
The line: blockers are not the same as "no"
An ad blocker is a technical countermeasure; routing around it with first-party collection is fair game, the same move every performance-conscious site makes. A declined consent banner is a legal statement, and server-side tracking does not launder it: GDPR governs whether personal data may be processed, not which machine does the processing. A consent refusal must stop your server container's forwarding exactly as hard as it stops a browser tag.
The reason this needs saying is that the architecture makes the crime quiet. Client-side violations are visible to anyone with a network tab; a server that keeps forwarding declined users' events shows nothing in the browser at all. Which means your consent wiring in the server container needs deliberate verification under both consent states, and any vendor whose pitch for server-side leans on "recover consent-declined users" is proposing you build a violation with good uptime.
The honest scorecard
Server-side tracking versus the losses: standard blocklists, largely recovered. ITP cookie clipping, meaningfully softened. Determined blockers and DNS filtering, no. Consent refusal, must remain no. Whether that recoverable slice pays for the setup, hosting, and maintenance depends on your ad spend and your audience mix, and that arithmetic, not the blocker anxiety, should make the decision: the full decision framework is here. If your audience skews mainstream and your spend is real, the recovered signal usually justifies the plumbing. If you sell developer tools to Pi-hole owners, spend the money on better landing pages, and I say that as the person who would have invoiced you for the server.