Ad-blocker bypass

FunnelTrack defeats privacy-browser blocklists with two independent layers: first-party loading from your own subdomain, plus a non-standard collect path that doesn't match the generic filters every blocklist ships with.

The problem

Why most tracking pixels lose signal in Brave, Safari, Firefox Strict, and any browser running uBlock Origin / AdGuard / Ghostery.

Privacy-focused browsers and ad-blockers ship with filter lists — primarily EasyList and EasyPrivacy — that block requests to tracking-related domains and URL patterns. Two kinds of rules do the most damage to analytics signal:

Domain rules like ||googletagmanager.com^ block every request to that domain. The pixel script never loads, no events ever fire.
Path rules like /collect? or /track?block requests matching those URL patterns regardless of domain. GA4's /g/collect trips this kind of rule too — every tracking endpoint that calls itself /collect inherits the heat.

Either rule alone is enough to wipe out a meaningful slice of your traffic — typically 15–40% of visitors depending on your audience's privacy posture. Both rules together (which is what Brave + EasyPrivacy default users see) makes standard pixels effectively invisible.

Layer 1 — Custom loader (first-party domain)

Defeats domain-based blocking by loading the pixel from a subdomain you control.

When you enable a custom loader (see Custom loader), the pixel snippet loads from load.ft.yourdomain.com and events POST to ft.yourdomain.cominstead of funneltrack.com. From the browser's perspective these are first-party requests to the site itself — there's no cross-origin signal a domain blocklist can match against.

Filter lists can't pre-emptively block a hostname they don't know about, and a single customer's subdomain isn't going to land in EasyList or Brave's filter lists individually. Each customer gets their own clean hostname.

Layer 2 — Non-standard collect path

Defeats path-based blocking by not using the word /collect anywhere.

Filter lists key on URL paths too — anything matching /collect,/track, /pixel, /beacon, /event, or other distinctive analytics-related names is suspect. GA4 ships at /g/collect — that path has been on EasyPrivacy for years.

The FunnelTrack pixel POSTs events to /api/v1/e— versioned, generic, uses a single letter rather than a descriptive name. The URL pattern doesn't trip any of the standard filter rules and isn't distinctive enough to easily add a custom rule for.

Backwards compatibility

The old /api/collectpath is still mounted server-side as a fallback for any pixel snippets deployed before the rename. Existing pixels keep working; new deployments (and any customer who recopies the snippet from the dashboard) use the new path automatically. There's no breaking change.

Together — both layers shipping in one snippet

The two layers are independent. With both enabled you defeat both classes of filter rule.

A request from the pixel running on a custom loader site looks like this:

POST https://ft.acme.com/api/v1/e
Content-Type: application/json

There's no funneltrack.com for a domain rule to match, no /collectfor a path rule to match. The hostname is the customer's own subdomain, the path is generic-looking. Filter lists let it through.

Compare to the standard FunnelTrack snippet without a custom loader, which posts to https://app.funneltrack.com/api/v1/e — still defeats the/collect path rule, but a domain rule on funneltrack.com would catch it. The custom loader closes that gap.

How to verify it's working

Confirm both layers are active in your live site.

1. Inspect the network tab

On a page where your pixel is installed, open browser DevTools → Network. Filter for e or refresh. You should see a POST request to /api/v1/e (not /api/collect) with a 200 response.

2. Check the request URL

If you've enabled a custom loader, the request hostname should be your own subdomain (e.g. ft.yourdomain.com/api/v1/e). If you seeapp.funneltrack.com, your snippet is the pre-custom-loader version — re-copy from the Pixel page and re-deploy on your site.

3. Test in browsers like Brave, Safari, & DuckDuckGo

Open the page in Brave with default shields (Standard), Safari with full ITP, or DuckDuckGo's browser with its built-in tracker blocking enabled. If the pixel was being blocked before, you'll now see events flowing in your Usage Logs dashboard within seconds.