Same-origin proxy analytics for WordPress

With a same-origin proxy, the browser loads the analytics script from your own domain and sends events there; your server then forwards them to PureMetrix. This makes tracking more reliable when visitors use ad blockers.

How it works

When the same-origin proxy is switched on, visitors load /px/js and send events to /px/event on your website. The PureMetrix WordPress plugin forwards the events from your server to PureMetrix in the EU. The browser never has to contact a third-party analytics domain.

What it does not change

Visitor counting stays cookieless, with a salt that changes daily. The proxy only changes the route the data takes; it adds no cookies.

When to switch it on

Your audience is tech-savvy and often uses ad blockers.
Your purchasing or IT team prefers data to go to your own domain.
Your pageviews are much lower than in your server logs.

Setup checklist

Switch on the setting in the PureMetrix plugin.
Clear caches so your pages use the /px paths.
Allow /px in your security plugins.
Check the Network tab of your browser’s developer tools on a public page.
Confirm that events appear in the PureMetrix dashboard.

Performance

The script stays under 3 KB. Forwarding creates very little server work per event compared with building a normal WordPress page. If you have extremely high traffic or an unusual firewall (WAF), keep an eye on it anyway.

Multisite

On multisite networks, check that the proxy routes work for your per-site or network setup. Guide: multisite analytics.

Why third-party tracking fails without anyone noticing

Ad blockers and privacy lists often block requests to well-known analytics domains but leave requests to your own domain alone. A same-origin /px proxy on WordPress sends tracking requests through your domain, so they look like any other request to your website.

Switch on the proxy in PureMetrix, clear caches, then check that the requests go to your own domain. The most common problem after going live: security plugins that block unknown paths.

What the proxy does not do

The proxy makes tracking more robust; it does not hide unlawful tracking elsewhere on the page. Keep the cookieless defaults and role exclusions. Document the proxy in your technical notes so the next developer doesn’t remove it by accident during a firewall change.

Rollout steps

Switch on the PureMetrix /px proxy in the plugin.
Clear page and CDN caches.
Allow the path in your firewall (WAF) and security plugins.
Check tracking requests in a private window with a popular ad blocker switched on.
Watch the error logs for 403/404 errors on /px for 48 hours.

To undo it, switch off the proxy and clear caches again—write that down. Unnoticed 403 errors look like “our traffic collapsed” in client meetings.

CDN notes

Some CDN settings handle POST requests or unusual paths badly. Make sure tracking requests reach your server. If you use strict bot protection, allow your own analytics path so you don’t block yourself.

Multisite and subdirectory notes

On multisite, check that /px works for each site as described in the plugin, and that subdirectory installs don’t send data to the wrong blog. After changing domain mappings, check the tracking requests again. Support tickets about “only half the network is tracked” are often caused by mismatched rewrite rules.

Logging and privacy

Routing through WordPress may add tracking requests to your server’s access logs, next to other requests. Apply the same log retention you already use for other requests (e.g. admin AJAX). PureMetrix still sets no visitor cookies; how server logs are handled is up to your hosting provider.

Tell security reviewers about the proxy so they don’t flag /px as an unknown endpoint during a penetration test.

HTTP method and caching rules

Make sure CDNs don’t cache tracking responses like a normal page. Tracking endpoints should bypass the cache. Wrong caching can look like “tracking only works on staging.” PureMetrix /px needs every tracking request to reach your server.

Document the exact rewrite rule in your server notes so a “clean-up” change doesn’t delete /px during a move to HTTPS.

After switching on the proxy, set up an automatic uptime check that expects an HTTP 2xx response on a sample tracking path.

On Cloudflare or similar services, make sure /px/* is not cached as a static file in a way that serves an outdated script or blocks POST requests to /px/event.