Adblock-immune by construction

Adblockers block by URL. Beaconry's URL is your own WordPress site. There is no domain or path an adblocker can block without breaking WordPress itself.

The problem

Browser-side analytics tools (Meta Pixel, gtag.js, the TikTok Pixel, the LinkedIn Insight Tag) load their own JavaScript from third-party domains: connect.facebook.net, googletagmanager.com, analytics.tiktok.com, snap.licdn.com. Adblocker filter lists like EasyPrivacy have those domains in them. Anyone with uBlock Origin, Brave Shields, Pi-hole or AdGuard installed never even loads the script. The conversion event never fires.

Server-side TMS solutions (GTM Server-Side, Stape) move the dispatch to the server but still need a browser-side bootstrap. They typically use a custom subdomain like tags.yourdomain.com that resolves to a Stape worker. Once filter lists catch on (and they do — within weeks of any Stape onboarding pattern becoming popular), they're back to being adblocker-detectable.

How Beaconry sidesteps it

The endpoint is /wp-json/beaconry/v1/event. It runs inside your WordPress installation, on your own domain.

• Domain: your own site's domain, not a third-party.
• Path: a sub-path of /wp-json/, the WordPress REST API namespace. Every WordPress site uses /wp-json/ for its own internal admin, search, comments, theme settings.
• Payload: custom JSON (Beaconry-specific shape), not the wire format of any pixel. Content-based filter lists cannot match it as tracking either.

An adblocker that blocks /wp-json would break:

• WordPress 6.x core search (uses /wp-json/).
• The WordPress block editor (uses /wp-json/wp/v2/).
• Most modern WordPress themes (use /wp-json/ for AJAX).
• Comments, "load more posts", any AJAX-driven pattern.

No filter-list maintainer is going to ship a rule that breaks WordPress for the millions of legitimate sites that use /wp-json/.

What this means in numbers

Industry data suggests 25 to 30 percent of web traffic uses some form of ad-blocker. That's a quarter of your conversions invisible to you when you depend on browser-side pixels. Beaconry recovers all of them: every visitor who consents to analytics has their conversion captured server-side, regardless of what extension or DNS-level blocker they use.

What does NOT make Beaconry adblock-immune

• Hybrid mode for any channel re-introduces the platform's browser pixel. Adblockers will block that bytes-on-the-wire as before. Beaconry deduplicates, so adblocker-affected visitors still get their server-side event tracked, but the first-party cookie advantage of hybrid mode is lost for that visitor specifically.
• The consent banner itself loads from your own domain, but the visitor must still accept analytics consent for any event to fire. If they reject, Beaconry stays silent. That's GDPR, not an adblocker problem.

Verifying it

Open your site in a browser with uBlock Origin enabled, visit any page, open DevTools → Network tab. You should see:

• POST requests to /wp-json/beaconry/v1/event on your own domain. Status 202.
• Zero requests to connect.facebook.net, googletagmanager.com, analytics.tiktok.com (unless hybrid mode is on for that channel).

That's the entire test. If POST requests reach /wp-json/beaconry/v1/event, the events also reach the platforms.