Why "server-side tracking" still loses 25 % of conversions to adblockers

Most setups labelled "server-side" still bootstrap from a third-party domain in the browser. Filter lists catch up within weeks of any pattern becoming popular. The fix is not a faster fallback, it's same-origin from the very first byte.

The "server-side" misnomer

"Server-side tracking" sounds like a description of where the dispatch happens. In practice it almost always describes where the dispatch is declared. The actual sequence on a typical "server-side" page load is still:

1. Browser loads https://tags.customer.com/gtm.js (a third-party script, even if the subdomain looks first-party).
2. The script fires events from the browser, addressed to the same third-party endpoint.
3. That endpoint forwards the event to Meta, Google, TikTok server-to-server.

The forward in step 3 is genuinely server-side. But step 1 is the entry point, and it's exactly where every adblocker filter list operates. If tags.customer.com is on the list, the script never loads. If the script doesn't load, the event never fires. The server-to-server forward is moot because nothing reached the server.

How filter lists actually work

EasyPrivacy and similar lists are maintained collaboratively. New tracking patterns get reported, reviewed and added in days, not months. The lists are pulled into uBlock Origin, Brave Shields, AdGuard, Pi-hole and others on roughly a 4-to-24-hour refresh cycle. By the time a tracking pattern becomes popular enough to matter, it's also popular enough to have been reported.

The exact rules vary, but the typical signature includes: known tracker subdomains (analytics., tags., track.), known third-party CDN paths, recognisable script-content fingerprints (Meta Pixel, gtag.js, TikTok Pixel byte signatures). Once a pattern matches one of these, the request is dropped at the network layer before it ever reaches your server.

What this means for "server-side" setups: the moment your pattern is recognised, your reach drops by whatever your audience's adblock-rate is. Industry estimates put that at 25 to 30 percent on the open web, higher in B2B / dev audiences (35-50 percent), lower in retail mainstream (15-20 percent).

The Stape DNS pattern

Stape's solution is to point a customer subdomain like tags.yourshop.com at a Stape-hosted worker via CNAME. From the browser's perspective, the request looks first-party: it goes to your domain. From the adblocker's perspective, it depends on whether the filter list has caught up to "tags.* CNAME-points-at-stape.io".

For a while, this is genuinely better than the third-party-domain pattern. But filter-list maintainers eventually notice the pattern. CNAME-cloaking detection is a known capability (Brave Shields enables it by default, uBlock has it as an opt-in setting, NextDNS implements it server-side). Once enabled, the request gets blocked at the same DNS layer as before.

Stape's response cycle is to rotate worker domains. The result is a cat-and-mouse game where each new Stape pattern gets a few weeks of headroom before being added to the lists. Customers stay technically reachable, but the variance in adblock-resistance over time is uncomfortable for anyone running performance-marketing campaigns at scale.

The GTM Server-Side / Cloud Run pattern

Google's official server-side answer is GTM Server-Side, typically deployed on Cloud Run with a customer-owned subdomain like server.yourshop.com. Functionally similar to Stape, with two practical differences: (a) you operate the infrastructure yourself (Cloud Run pricing, DNS, SSL renewal), and (b) you write your own tag templates.

Adblock-resistance follows the same dynamic as Stape. The custom subdomain helps for a while; CNAME-cloaking detection eventually catches up. The added cost, $30 to $500/month for the Cloud Run container, plus engineering time on tag templates, is significant for individual small-to-mid customers.

What "first-party from the first byte" means

The only way out is to make sure the very first request the browser sends, the entry-point script, is not on any filter list and is not on a pattern that is likely to land on one.

"First-party" in this strong sense means: same-origin with the page itself, served from the customer's WordPress install, on a path that the WordPress core uses for its own AJAX. No subdomain, no CNAME, no third-party CDN, no recognisable script-content signature.

The honest test: open the site in a browser with uBlock Origin enabled, visit a page, watch the Network tab. If you see a successful POST request to a path on your own domain, the tracking works. If you see a failed request to any other domain, the tracking does not work for adblock users on that channel.

Why /wp-json/beaconry/v1/event structurally evades adblock

Beaconry's endpoint is POST /wp-json/beaconry/v1/event on your own domain. Three properties make it structurally adblock-resistant:

• Same-origin: the request goes to the same domain the page is served from. No subdomain, no CNAME.
• Generic WP REST namespace: /wp-json/ is the path WordPress core uses for its own block editor, search, comments, "load more posts", and a thousand third-party plugins' AJAX. Any filter list that blocks /wp-json/ would break a quarter of the public WordPress web.
• Custom JSON payload: the body is Beaconry's own shape, not the wire format of Meta Pixel or GA4 or TikTok Pixel. Content-based filter rules cannot identify it as tracking either.

The combination is what makes it stick. Domain-based rules can't target /wp-json/ on a per-customer domain. Content-based rules can't pattern-match the payload. The only way to block it would be a generic "block all /wp-json/ POSTs" rule, which would brick WordPress for every site that uses it.

Numbers

The recovered conversion-volume is whatever your audience's adblock-rate is. Concretely:

• A B2B SaaS site with 1,000 leads/month at €100 lead-value, 35% adblock-rate audience: ~350 leads × €100 = €35,000/month invisible to your reporting.
• A retail e-commerce shop with 5,000 orders/month at €60 average order value, 20% adblock-rate audience: ~1,000 orders × €60 = €60,000/month never reaching Meta or Google for optimisation.
• A media site with 50,000 newsletter signups/month at €5 LTV-attributed value, 30% adblock-rate audience: ~15,000 signups × €5 = €75,000/month silently lost.

Try the reach calculator on the home page with your own numbers. The figure is what stays invisible to your reporting today, every month, until the dispatch path is moved off the third-party tracker domains.

Take-away

The label "server-side tracking" describes what happens after the entry script loads. Adblock loss happens before that. If you care about the 25-30 percent of conversions you can't currently see in Meta or Google, the question to ask any vendor is not "is your dispatch server-side?", it's "what URL does the browser send the first request to?". If the answer involves a subdomain, a CNAME, or any third-party domain, the resilience is rented.