Why ad blockers break third-party pixels
uBlock Origin and filter lists like EasyList block requests to `facebook.net` and `google-analytics.com` by default. Understand the mechanism so you can design tracking that actually delivers.
- ad blockers
- EasyList
- first-party
- pixels
Problem: Meta Events Manager shows a fraction of the signups you know happened. The pixel helper says events fired in your browser — but your coworker with uBlock sees nothing. You need to understand why before picking a fix.
How block lists work
Browser extensions like uBlock Origin, AdGuard, and Brave Shields ship with filter lists — EasyList, EasyPrivacy, Peter Lowe's list — that block network requests matching known tracker domains and URL patterns.
connect.facebook.net, www.google-analytics.com, analytics.tiktok.com, and dozens of ad-tech endpoints are on these lists by default. The block happens at the network layer: the script may load from your page, but its beacon requests never leave the browser.
Script blocking vs request blocking
Some lists block the script tag itself (||facebook.net^$third-party). Others allow the script but block XHR/fetch/beacon calls. Either way, the conversion never reaches the ad platform.
First-party scripts are generally not blocked — your app's bundle on yourdomain.com runs fine. The issue is specifically third-party domains associated with tracking.
Who runs blockers
Blocker usage skews toward technical audiences — developers, designers, privacy-conscious users. B2B SaaS with developer buyers sees higher blocker rates than consumer e-commerce.
Do not build business logic on typeof fbq === 'undefined' checks. Assume a meaningful share of conversions are invisible to pixels and route server-side.
What actually fixes it
Move conversion delivery off third-party domains: direct CAPI from your backend, or a first-party edge proxy on your domain that forwards to platform APIs.
The browser SDK captures events locally and sends them to your first-party endpoint. The edge worker calls Meta, Google, or TikTok server-side. Filter lists target known tracker domains, not your API subdomain.
Pair with event deduplication when you keep the pixel for click IDs.
trackstack.capture("SignUp", {
email: user.email,
eventId: `signup_${user.id}`,
});Measurement without guessing
Compare Stripe or auth signup counts to platform-attributed conversions over the same window. A persistent gap after correct install usually means delivery loss, not bad ads.
Use delivery logs to confirm server-side acceptance — blockers do not affect that path.
Sources
Official documentation and references cited in this article.
More in Engineering
First-party conversion tracking vs third-party pixels
Browser pixels and server-side CAPI solve different problems. Here is when to use each, how they complement each other, and what breaks when you rely on scripts alone.
Read postEvent deduplication between client and server
Sending the same conversion from browser and server without a shared event ID double-counts in ad platforms. Here is how dedup works at Meta, Google, and TikTok — and how to implement it in your app.
Read postDead-letter queues and delivery monitoring for conversion APIs
CAPI endpoints return 429s, 500s, and invalid payload errors. Without retries and a dead-letter queue, failed conversions vanish. Here is what to monitor and how to alert on delivery health.
Read postReady to fix your conversion pipeline?
Install the TrackStack SDK, route events to Meta and Google, and verify delivery from one dashboard.