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 no public blocklist can enumerate.

Admin-AJAX is the shipped default. Whichever you pick, fallback is always on: the plugin’s own help text states that if the selected method fails, SlimStat automatically tries the next available one.

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 and no browser request is made, so there is no transport to choose — see server-side tracking for which mode suits your site.

What it cannot do, and this matters

The bypass changes the endpoint the tracker calls. It does not change the script that calls it. If a blocker stops wp-slimstat.min.js from loading at all, no transport setting will help, because nothing is running to send the hit. The bypass recovers visits where the script loaded and the request was blocked, which is the more common case, but it is not a guarantee of completeness and no plugin can offer one.

Where a visitor’s browser blocks the script entirely, the only configuration that records that visit is Server tracking mode, which writes the row during the PHP request and never depends on the browser. That is the trade: server-side mode sees everything but cannot be used behind a page cache, because a cached page never runs PHP.

Nor is the bypass a way around a consent decision. If GDPR Compliance Mode is on and consent has not been granted, SlimStat does not record the visit regardless of transport, and Respect Do Not Track is checked before any of this.

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. A request to /request/ followed by a long hash, returning 200, means the bypass is live.
4. Open SlimStat, then Real-time, and confirm the visit appears in the access log.
5. Repeat with your ad blocker enabled and compare — that difference is the traffic you were losing.

Comparing totals before and after the switch is the only measurement that means anything here. The recovered share varies enormously by audience: a developer-heavy site can see a large jump, a general-audience site very little.

If nothing is recorded on either transport, the cause is usually elsewhere in the chain — work through the tracker diagnostic checklist, which starts with the error code SlimStat has already stored for you. 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.