Recovering Visits Lost to Ad Blockers

SlimStat sends tracking hits through one of three transports, set by Tracking Request Method at Settings, General. Two of them use paths ad blockers commonly match: admin-ajax.php and the slimstat/v1/hit REST route. The third, Ad-Blocker Bypass, routes hits through a hashed path on your own domain instead, which can avoid some name-based blocking rules. It does not guarantee delivery.

Admin-AJAX is the shipped default. The browser can try another available transport after a network or protocol failure. An explicit tracking rejection stops that request; fallback does not override consent or exclusions.

What the bypass actually does

The bypass registers a WordPress rewrite rule at request/<hash>/ and points the JavaScript tracker at it. The hash is 32 characters, derived with hash_hmac('sha256', ...) from your site URL and your WordPress auth salt, so it is unique to your installation and cannot be guessed from another site running SlimStat. That is the whole mechanism: a first-party URL that looks like nothing in particular.

Two details in the implementation are worth knowing because they explain behaviour you would otherwise find surprising:

• The hash deliberately excludes the plugin version. Cached pages bake the tracking URL into their HTML, so tying the hash to a version number would silently invalidate every cached bypass URL on the next plugin update. It is stable across upgrades by design.
• The rewrite rule is only registered when this transport is selected. Selecting REST or Admin-AJAX removes it, so the bypass URL 404s rather than sitting there as a dead fallback.

The endpoint also defines DONOTCACHEPAGE and DONOTCACHEOBJECT when it answers, so a page cache does not serve a stale tracking response.

Turning it on

1. Open SlimStat, then Settings, then the General tab.
2. Find Tracking Request Method under the Tracker section.
3. Select Ad-Blocker Bypass.
4. Click Save Changes. SlimStat flushes WordPress’s rewrite rules itself when the method changes, so no separate permalink save is needed.
5. Clear every caching layer, so pages regenerate with the new tracking URL baked in.

The setting is only visible while Tracking Mode is Client. In Server mode, PHP records the visit during page render while JavaScript can still send interaction updates, so the settings hide the transport selector — see server-side tracking for which mode suits your site.

What it cannot do, and this matters

The bypass changes the tracker asset URL and the request endpoint. It can avoid some name-based blocking rules, but it cannot guarantee delivery. A browser can still block the script or request. Consent and exclusions still apply.

Server mode can record eligible requests without browser JavaScript when they reach WordPress PHP. It undercounts cached pages, and browser interactions still need JavaScript.

Nor is the bypass a way around a consent decision. Consent settings apply regardless of transport. Depending on your integration and statistics categories, a visit may be refused or recorded with restricted fields. Test refusal, acceptance and withdrawal; Respect Do Not Track is a separate control.

Confirming it works

1. Open a front-end page in a private window with your browser’s developer tools on the Network tab.
2. Filter for request and reload.
3. Look for the hashed request and inspect its response. HTTP 200 alone does not prove storage; the body can contain a rejection code.
4. Open SlimStat, then Real-time, and confirm the visit appears in the access log.
5. Repeat the same eligible test with your ad blocker enabled to check that browser and rule set.

A controlled browser test verifies delivery for that configuration. Production totals also depend on traffic mix, consent and exclusions, so a before/after change alone does not measure visits recovered from blockers.

If nothing is recorded on either transport, the cause is usually elsewhere in the chain — work through the tracker diagnostic checklist, which includes available tracker diagnostics. Requests blocked before reaching WordPress cannot produce a server-side diagnostic. If some visits record and others do not, check that your caching plugin is not serving pages generated before the switch, covered in excluding SlimStat from caching and minification.