Tinker Stats for Rybbit

Rybbit is an open-source, privacy-friendly web analytics platform — a modern alternative to Google Analytics. It supports self-hosting and tracks visitors without cookies.

Yes, if you enable it. The Tracking section lets you inject the Rybbit tracking script on your frontend with one toggle. You can also configure role exclusion, user identification, and custom events. If tracking is disabled, the plugin only reads existing analytics data from your Rybbit instance via its API.

Every hour, the plugin fetches lifetime cumulative metrics from Rybbit and saves them as post meta (_tinker_stats_views). This makes view counts available to themes, page builders, and sorting queries.

The stored value is a running total from the date your Rybbit site was first created — it doesn’t reset at month boundaries. The plugin auto-detects this start date from your Rybbit instance the first time it syncs; if the connection details change (different Rybbit instance or different Site ID), the start date is re-detected on the next sync.

Yes. Go to Tinker Stats → Settings and click “Sync Postmeta Now” in the Tools section.

Yes. The API key is encrypted using AES-256-CBC with keys derived from your WordPress salts before being stored in the database.

The most common cause is ad blockers (uBlock Origin, Brave’s built-in blocker, etc.) blocking the Rybbit tracking script. Even though Rybbit is privacy-friendly and cookieless, some blocklist maintainers block all analytics scripts indiscriminately. Estimates put the impact between 6% and 60% of visitors depending on your audience’s technical level.

A common gotcha: ad blocker filter lists also match on URL keywords. Words like “stats”, “analytics”, “tracking”, “metrics”, or “telemetry” anywhere in the script URL will trigger blockers regardless of the actual script content. If your Script URL contains any of these, expect blocking even before the request reaches your server.

The fix is to proxy the tracking script through your own domain so it loads as a first-party request. The plugin includes a built-in proxy that handles this for you: go to Tinker Stats → Settings → Tracking and enable the “Bypass Ad Blockers” toggle. The plugin will fetch and cache the Rybbit script, generate a randomized first-party path, and forward all tracking events through your own domain. No webserver config required.

If you’d rather configure the proxy yourself at the webserver or CDN level, see Rybbit’s proxy guide and enter the relative path (e.g. /api/script.js) in the Script URL field.

To verify your tracking is actually firing, open your Rybbit dashboard, go to Site Settings → Tracking Script, and click “Verify Installation”. Rybbit will check whether the script is loading on your site and confirm the connection.

Other less common causes: tracking is disabled in the plugin settings, your role is in the Exclude Roles list, or the tracking ID isn’t populated yet.

When enabled, the plugin generates a randomized 8-character hex prefix (e.g. k3p9m2qr) and serves the Rybbit tracking script and tracking endpoints through https://yoursite.com/[hash]/.... Static script files are cached locally and refreshed daily; tracking POSTs are forwarded to your Rybbit instance in real time, with the visitor’s real IP address preserved via X-Forwarded-For.

The randomized prefix breaks ad blocker rules that anchor on the platform-pattern /api/ path used by analytics services. You can regenerate paths anytime, refresh the script cache manually, and verify proxy reachability with the Test Proxy button.

The proxy works on most hosts without webserver-level changes. On WordPress Multisite, each subsite gets its own proxy paths (subdirectory subsites can share the parent domain’s Rybbit Site ID; subdomain and mapped-domain subsites have their own).

The tracking script is injected into your page HTML via wp_enqueue_script(), so it becomes part of the cached HTML output. This is normally desirable: once cached, the script tag is served on every page hit without any per-request PHP work.

The trade-off: if you enable, disable, or change tracking settings, your cached HTML still reflects the previous state. You’ll need to purge your page cache (FastCGI, Cloudflare, Varnish, etc.) for the change to take effect on the frontend.

The built-in proxy’s cached script files (/tsr-{hash}/script.js etc.) are static files at WordPress root, served directly by your webserver. They’re independent of WordPress page caching: they refresh on their own daily-cron schedule and aren’t affected by page cache purges.