Why do adblockers block my analytics?

Because filter lists match requests by hostname and URL substring. EasyPrivacy and its derivatives carry entries for the well-known analytics domains and for generic path fragments like /analytics, /track, /collect and /pixel. Any request whose URL contains one of those strings is cancelled before it leaves the browser, whoever is serving it.

How does a first-party proxy avoid that?

The tracker and the ingest endpoint are served from a subdomain of your own domain, for example a.example.com, over your own certificate. There is no third-party hostname in the request, and the paths Mrkr uses on that subdomain are neutral, so there is nothing on the filter list for the request to match.

Do I have to run any infrastructure for this?

No. You add one CNAME record at your DNS provider. Mrkr provisions a Cloudflare for SaaS custom hostname behind it and validates the TLS certificate over HTTP, so there is no reverse proxy to deploy, no worker to maintain, and no certificate to renew.

Does this recover 100% of blocked traffic?

No, and anyone claiming otherwise is guessing. A first-party subdomain removes the hostname and path signals that most filter lists match on. It does not help against someone who blocks all JavaScript, disables it entirely, or uses a blocker that has specifically learned your subdomain.

Does the proxy change what data is collected?

Not at all. The same cookieless payload goes to the same ingest code and produces the same numbers. Only the hostname in the request URL changes. Cookieless stays the default, so no consent banner is required for it, and switching a site to cookie mode changes that regardless of the proxy.

Analytics adblockers do not block.

Q: Can a proxied subdomain reach the rest of Mrkr?

No, and that is enforced in code. A request arriving on a proxy hostname may only reach /api/data, /api/data/r, /api/data/crawl, /api/collect, /api/replay and /api/health. Every other path is redirected to mrkr.app, so a customer subdomain can never serve Mrkr's dashboard or marketing pages.

Filter lists match analytics by hostname and by path substring. Mrkr's managed proxy serves the tracker and the ingest endpoint from a neutral subdomain of your own domain, with a certificate provisioned for you, so there is nothing on the list to match.

Start 14-day trial See the live demo

How do you stop adblockers from blocking your analytics?

Serve the analytics from your own domain instead of the vendor's. Adblock filter lists match requests by hostname and URL substring, so a script and an ingest endpoint on a neutral subdomain of your site, over your own certificate, carry no string for a list to match. Mrkr provisions that subdomain for you from one CNAME record.

This is worth being precise about, because the phrase “bypass adblockers” gets used for two very different things. Rewriting a third-party request to look first-party at the CDN is one. Actually serving the analytics from the site’s own domain, as first-party infrastructure the site owner controls, is the other. Mrkr does the second one.

The numbers you were already owed.

Blocked analytics does not announce itself. It shows up as a dashboard that quietly disagrees with your server logs, a paid channel that looks worse than it converts, and a developer-heavy audience that appears to be half the size it is.

The proxy does not change a single line of what Mrkr measures. The same cookieless payload reaches the same ingest code and produces the same sources, campaigns, funnels and revenue. It just arrives.

Mrkr traffic sources showing referrers, campaigns, and direct traffic. — Traffic sources and campaigns, counted from requests that were not cancelled before they left the browser. Open it in the live demo.

What a blocker is actually matching.

Hostname rules

The major vendors' domains sit on EasyPrivacy and every list derived from it. The script fails before a byte moves.

Path substring rules

Fragments like /analytics, /track, /collect and /pixel match wherever they appear, on domains a blocker has never seen.

Why the DIY version fails

analytics.yoursite.com/collect is on your own domain and still blocked. The words are the tell, not the host.

Four steps, one DNS record.

01
Pick a neutral subdomain
Something like a.example.com. The form rejects analytics, track, stats, pixel and nine other fragments, because those are substring matches on the public lists.
02
Add one CNAME
Mrkr shows you a single record pointing your subdomain at its proxy target. If your DNS is on Cloudflare, set it to DNS-only rather than proxied.
03
Mrkr issues the certificate
A custom hostname is provisioned and validated over HTTP, so there are no TXT records to juggle. Usually active within ten minutes.
04
Swap the snippet
The updated snippet points at your own subdomain instead of mrkr.app. The numbers carry on in the same dashboard, no reset.

DNS record to add, and nothing to host yourself: 1
DNS record to add, and nothing to host yourself
third-party hostnames in the request path: 0
third-party hostnames in the request path
endpoints a proxy hostname may reach, enforced in middleware: 6
endpoints a proxy hostname may reach, enforced in middleware
tracker script, served from your own domain: <6 kB
tracker script, served from your own domain

The six allowed endpoints are /api/data, /api/data/r, /api/data/crawl, /api/collect, /api/replay and /api/health. Every other path on a proxy hostname is redirected to mrkr.app, so a customer subdomain can never serve Mrkr's own pages.

What each approach actually survives.

An honest read of the four common setups, matched against what blockers actually check.

	Third-party script	Self-proxied at a named path	Mrkr managed proxy	Server-side only
Survives hostname rules	No	Yes	Yes	Yes
Survives path substring rules	No	Usually not	Yes	Yes
Survives a blanket JavaScript block	No	No	No	Yes
Infrastructure you maintain	None	A proxy and a certificate	None	Your own backend
Certificate handling	Vendor	You	Automatic	You
Sees client-side behaviour	Yes	Yes	Yes	No

Server-side-only collection is the one approach that survives a visitor with JavaScript disabled, and it is also the one that cannot see scroll depth, engagement time, replay or Core Web Vitals. Mrkr uses a server-side beacon for crawlers specifically, which is a different job.

See what it reports

The live demo is a fully populated dashboard on real demo traffic. The proxy changes where the request goes, not what you get back.

Open the live demo

Mrkr realtime view showing visitors on the site right now, by country and page.

Where this stops working.

Blanket JavaScript blocking

No client-side analytics measures a visitor who blocks all scripts. The proxy does not change that.

A blocker that learns your subdomain

Filter lists are maintained by people. Neutral naming makes it far less likely, not impossible.

It is not a consent workaround

The proxy is about delivery, not legal basis. Cookie mode needs consent whether the proxy is on or off.

It does not backfill

Counting starts when the certificate goes active. Requests cancelled before that are gone.

Questions, answered.

Keep reading

Managed proxy setup guide
The exact CNAME, the status states, and how to turn it off safely.
Server-side tracking, honestly explained
What Mrkr does on the server, and the parts it deliberately does not do.
How analytics works without cookies
The daily-rotating hash that replaces the cookie, and the trade-off.
Bot traffic filtering
The other half of accurate numbers: keeping the fake traffic out.
AI traffic and AI crawler tracking
Measuring the visitors that never run your JavaScript at all.
Every Mrkr feature
The full index of what the product measures.

Your first visitor is already here.

Drop in the script and watch them land. It takes about a minute.