Server-Side Tracking with Cloudflare Workers: Bypass Ad Blockers Without Cookies

Open your analytics dashboard. Now check your server logs. Notice a discrepancy? If you’re seeing 20-40% fewer visitors in Google Analytics than your server actually serves pages to, you’re not alone. The culprit is ad blockers—and the problem is growing.

By 2026, approximately 42% of desktop users globally run some form of ad blocking, and these tools don’t just block ads—they block the JavaScript that powers Google Analytics, Hotjar, Mixpanel, and virtually every client-side analytics tool. Your data is silently disappearing.

Server-side tracking on Cloudflare Workers offers a fundamentally different approach. Instead of relying on third-party JavaScript that ad blockers intercept, analytics data is processed at the edge—on Cloudflare’s infrastructure, not in the visitor’s browser. The result: accurate data, no cookies, full privacy compliance, and near-zero performance impact.

The Ad Blocker Problem by the Numbers

Ad blockers have evolved far beyond simply hiding banner ads. Modern ad blocking extensions like uBlock Origin, AdGuard, and Brave Browser’s built-in shields use filter lists (EasyList, EasyPrivacy, Fanboy’s Annoyance List) that specifically target analytics and tracking scripts.

Here’s what gets blocked:

• Google Analytics (google-analytics.com, googletagmanager.com) – Blocked by all major ad blockers
• Hotjar (static.hotjar.com) – Blocked by all major ad blockers
• Meta Pixel (connect.facebook.net) – Blocked by all major ad blockers
• PostHog (app.posthog.com) – Blocked by most ad blockers
• Any third-party script on a known tracking domain – Blocked by default

The scale of this problem varies by audience:

If your audience is tech-savvy, more than half your desktop traffic might be invisible to Google Analytics. That’s not a minor data discrepancy—that’s a fundamentally broken measurement system.

Client-Side vs. Server-Side Tracking

To understand why server-side tracking solves this, let’s look at how each approach works:

Client-side tracking (traditional)

1. Visitor’s browser downloads your HTML page
2. Browser encounters <script src="https://www.google-analytics.com/gtag/js">
3. Browser makes a request to google-analytics.com
4. Ad blocker intercepts the request and blocks it
5. No data is collected. You never know this visit happened.

The fundamental flaw is that the analytics request goes to a third-party domain that ad blockers recognize as a tracking endpoint. The browser itself is the point of failure.

Server-side tracking (edge-based)

1. Visitor’s browser sends a request to yourdomain.com
2. Cloudflare Worker at the edge intercepts the request
3. Worker logs pageview data (URL, referrer, user agent, timestamp) from the request headers
4. Worker forwards the request to your origin server (or serves from cache)
5. Analytics data is stored—no third-party request was ever made.

Because the analytics data is collected as part of serving your own site, ad blockers see only a normal page request to your domain. There is no third-party tracking domain to block. The analytics are invisible to the blocker by design.

How Cloudflare Workers Enable Server-Side Analytics

Cloudflare Workers is a serverless platform that runs JavaScript at Cloudflare’s 300+ edge data centers worldwide. When you deploy a Worker, it executes at the Cloudflare location physically closest to each visitor—typically within 50ms latency.

Here’s why this matters for analytics:

First-party context

Workers run on your domain. When a visitor loads yourdomain.com/blog, the Worker sees the full HTTP request—URL, referrer, user agent, IP address (which can be hashed for privacy), and any custom headers. All of this is available without any client-side JavaScript whatsoever.

Sub-millisecond processing

A typical analytics Worker processes a request in under 5ms. Because it runs at the edge, there is no additional network hop. The visitor experiences zero latency overhead. Compare this to client-side analytics that must download, parse, and execute JavaScript in the browser.

D1 database storage

Cloudflare D1 is a SQLite-based database that runs at the edge. Analytics data can be written directly from Workers into D1 without going through a central server. This means your analytics data is stored close to where it’s collected, enabling fast queries and low-latency dashboard responses.

For a deeper technical dive into the Cloudflare Workers + D1 architecture, see our post on building analytics on Cloudflare Workers and D1.

How RevKlik uses Workers

RevKlik’s entire analytics pipeline runs on Cloudflare Workers:

• Ingestion Worker – Receives the lightweight beacon from the client script (<1KB) and writes raw events to D1.
• Aggregation Worker – Runs on a cron schedule to pre-compute metrics (pageviews, unique visitors, referrer breakdowns, country-level geo data).
• API Worker – Serves the analytics dashboard and REST API, querying pre-aggregated data from D1.
• Session Recording Worker – Processes interaction events (clicks, scrolls, input) into replayable session recordings server-side.

The only thing the client script does is fire a single navigator.sendBeacon() call with minimal data. Everything else happens on the server.

Why Server-Side Doesn’t Mean Privacy-Violating

There’s a common misconception that server-side tracking is somehow sneakier or less privacy-friendly than client-side tracking. The opposite is often true.

Privacy compliance depends on what data you collect, not where you process it. Consider the comparison:

Server-side analytics done right—like RevKlik—collects less data than GA4, doesn’t use cookies, doesn’t share data with anyone, and gives visitors a straightforward way to opt out. The processing location (server vs. browser) is irrelevant to privacy. The data collection scope is what matters.

For more on our privacy philosophy, read our guide to analytics without cookies and why cookieless tracking is better for everyone.

Implementation Comparison: Three Approaches

If you’re considering moving to server-side analytics, here are the three main approaches:

Approach 1: GA4 Server-Side Tagging via GTM

Google offers server-side tagging through Google Tag Manager (GTM), where you deploy a GTM container on your own server (usually Google Cloud Run). This routes GA4 data through your own domain instead of google-analytics.com.

• Pros: Keeps your existing GA4 setup, familiar interface.
• Cons: Costs $50-200/month for Cloud Run, adds latency, still collects the same invasive data, complex setup.

Approach 2: Self-hosted analytics (Matomo, Umami)

You can self-host an analytics tool on your own server. Matomo and Umami are popular options.

• Pros: Full data ownership, no third-party domains.
• Cons: Requires server maintenance, database management, security patches, CDN setup. Not truly edge-based—adds latency for distant visitors.

Approach 3: Edge-native analytics (RevKlik)

Purpose-built analytics that runs entirely on Cloudflare Workers at the edge, with zero infrastructure to manage.

• Pros: No infrastructure to manage, sub-5ms processing at the edge, no cookies, ad-blocker-proof, includes heatmaps and session recordings.
• Cons: Vendor dependency (same as any SaaS tool).

For more on why Cloudflare is an ideal analytics platform, see our post on Cloudflare analytics for modern websites.

Setting Up RevKlik’s Server-Side Analytics

Getting started takes under 2 minutes. No server setup, no Docker containers, no DNS configuration beyond your existing Cloudflare setup:

1. Create an account at revklik.com (free tier available).
2. Add your site – Enter your domain name in the dashboard.
3. Copy the script tag – A single line of HTML:

4. Paste it in your <head> – That’s it. The defer attribute ensures it never blocks rendering.
5. Verify in real-time – Open your site, then check the RevKlik dashboard. Your first visit appears within seconds.

Because the script sends data to app.revklik.com via the Beacon API (not a traditional third-party analytics domain), it avoids most ad blocker filter lists. The script payload is under 1KB and executes in under 5ms on the main thread. For sites behind Cloudflare (which includes the majority of modern websites), the data travels directly from the visitor’s nearest Cloudflare edge to the RevKlik ingestion Worker—no intermediate hops.

The Bigger Picture: Accurate Data as a Foundation

Ad blocker evasion isn’t about tracking people who don’t want to be tracked. It’s about having accurate data to make good decisions. If 30% of your traffic is invisible to your analytics, every decision you make from that data is compromised:

• Your conversion rate calculations are wrong.
• Your A/B test results are skewed.
• Your content strategy is based on incomplete signals.
• Your revenue attribution is missing transactions.

Server-side analytics on Cloudflare Workers gives you a complete picture—not by tracking more aggressively, but by processing data through a path that ad blockers don’t touch, while collecting less personal information than any major client-side tool.

For more on building a privacy-first analytics stack, check out our guide to the best cookieless analytics tools and learn how RevKlik compares to traditional solutions in our analytics script size and Core Web Vitals analysis.