Building a First-Party Analytics Proxy to Bypass Ad Blockers

The problem

Ad blockers don't just block ads — they block analytics too. Most blocklists target known analytics domains (including Application Insights endpoints like js.monitor.azure.com and *.in.applicationinsights.azure.com), which means site owners lose visibility into real traffic patterns. For a personal blog, this can mean 30-40% of visits go untracked.

The first-party proxy pattern

Instead of sending telemetry directly to App Insights endpoints (which get blocked), route it through a first-party path. Since the requests go to your own domain, ad blockers have no reason to block them.

The proxy receives telemetry from the browser, forwards it to App Insights, and returns the response. From the browser's perspective, it's just talking to your own domain.

Two approaches considered

Option A: Azure Container Apps with custom subdomain

• C# Azure Function using .NET 10 isolated worker model
• Deployed as a container on Azure Container Apps (consumption plan)
• Custom subdomain like analytics.alexjohnson.ai
• Container registry needed (GHCR free, ACR ~$5/mo)
• Separate infrastructure to deploy and maintain

Pros: Full control over the runtime, can use C#/.NET, works for any site regardless of hosting platform.

Cons: Extra infrastructure (Container Apps resource, custom domain, TLS cert, container registry, separate deployment pipeline). Overkill when simpler options exist.

Cost: ~$0-2/mo (Container Apps consumption scales to zero, GHCR is free).

Option B: SWA managed function (chosen approach)

• Azure Static Web Apps has built-in API support via managed Azure Functions
• Add an /api folder to the repo — deployed automatically alongside the static site
• Proxy lives at https://alexjohnson.ai/api/t — already first-party, no extra subdomain
• No container, no registry, no additional Azure resources

Pros: Zero additional infrastructure. Deploys with the site. Already first-party by default. Free on SWA Free tier. Single repo, single pipeline.

Cons: Limited to languages SWA supports for managed functions (Node.js, Python, .NET, Java). Less control over the runtime environment.

Cost: $0 (included in SWA Free tier).

Why Option B wins

For a personal blog already on Azure Static Web Apps, the managed function approach is the obvious choice. There's no reason to stand up a separate Container Apps resource, container registry, and deployment pipeline when SWA gives you a serverless function for free. The proxy endpoint is inherently first-party (same domain), so no custom subdomain or extra DNS setup is needed.

Option A makes more sense if you're hosting on a platform without built-in serverless functions, or if you need C#/.NET specifically, or if you want the proxy to serve multiple sites.

Custom client vs full SDK

A third design decision alongside the proxy approach: do you self-host the full App Insights SDK or write a lightweight custom client?

Full SDK (~36KB gzipped)

• Drop-in replacement — just change the script src and endpoint URL
• Includes auto-collection for cookies, storage, user tracking, dependency tracking, SPA route changes
• All of those features are disabled or unused on this site — we call trackPageView() once

Custom client (<1KB inline)

• Uses standard browser APIs (PerformanceNavigationTiming, document.title, location.href) to collect page views and performance metrics
• Formats data in the same App Insights JSON envelope and POSTs to /api/t
• No external script to load — inlined directly in the HTML
• Harder for ad blockers to fingerprint (no recognizable SDK patterns)
• Can be extended later with error tracking, Core Web Vitals, custom events — just add new baseType entries to the same envelope

The custom client is the better fit here. Shipping 36KB to call one endpoint goes against the site's minimal-JS philosophy. The browser already exposes everything we need — page load timing, TTFB, DNS lookup, DOM processing — through the Performance API.

Privacy-first design

This isn't about sneaking tracking past ad blockers — it's about getting accurate page view counts while respecting privacy:

• No cookies — the custom client simply never sets any
• No local storage or session storage
• No cross-site tracking
• IP addresses are not logged by the proxy
• Only page views and performance metrics sent to App Insights
• Users with JavaScript disabled are simply not tracked

The proxy is transparent — it doesn't add any tracking beyond what the original SDK collected. It just ensures the requests actually reach the endpoint, and the custom client ensures the code actually runs.

Open questions

• Should the proxy validate/sanitize the telemetry payload before forwarding?
• Worth adding a simple rate limiter to prevent abuse?
• Could this pattern work for other blocked third-party scripts?

Potential blog post structure

1. The problem: why your analytics numbers are wrong
2. The solution: first-party proxy pattern explained
3. The two infrastructure approaches: standalone container vs built-in platform function
4. Full SDK vs custom client: why less is more
5. Building it: SWA managed function + lightweight client walkthrough
6. Performance metrics for free via the Performance API
7. Privacy considerations: doing this ethically
8. Cost: what it actually costs to run (spoiler: $0)