Ad blockers and browser privacy settings block Google Analytics on a large share of your visits — commonly 30-50%. Those visitors still browse, still add to cart, and still buy. You just never see them. Your reports under-count traffic, your best-converting channels look worse than they are, and every decision you make from that data is made from an incomplete picture.
Easy Server Side Tracking closes that gap. Instead of the browser talking straight to
google-analytics.com — the request blockers are built to recognise — events go to a tracking endpoint that isn't on any blocklist, and are forwarded to Google Analytics 4 from there.
What you get back
- The visits, add-to-carts and purchases that were previously invisible
- Channel and campaign reporting based on close to all of your traffic, not the fraction that got through
- WooCommerce revenue that matches your actual orders far more closely
- A dashboard showing every event received, so you can see what is arriving instead of guessing
How it works
- A small script collects the event in the visitor's browser — event name, page URL, referrer, and anonymous client and session IDs.
- It posts to
collect.easyserversidetracking.com over HTTPS, signed with a short-lived token so only your site can send as your site.
- The endpoint validates the request, filters obvious bots, and forwards the event straight on to Google Analytics 4 using Google's Measurement Protocol.
- A copy is kept so you can see your own event stream on the dashboard.
We are a proxy, not a data broker. Your analytics data is forwarded to your own Google Analytics property and kept so you can look at it. It is not sold, not shared with third parties, not used to build profiles, and not combined across customers.
What we do and do not store
Stored per event: event name, page URL, referrer, user agent, country, consent state, anonymous client and session IDs, and a bot score.
Raw IP addresses are never stored. The IP is hashed with a salt that rotates every day and truncated, which is enough to rate-limit abuse and nothing more — the hash cannot be reversed, and the same visitor produces a different hash tomorrow.
Events are deleted automatically according to your plan's retention period.
Privacy and consent
- Nothing is sent anywhere until you explicitly connect. Installing and activating the plugin contacts no external service. You see exactly what will be shared, tick a box, and press a button — until then the plugin is inert.
- The visitor's real consent choice is read from Google Consent Mode and passed through with every event, rather than assumed.
- When consent is denied, data is anonymised before it goes anywhere: identifiers are dropped and location is reduced. You keep a basic visit count and nothing personal.
- Works with your existing cookie banner. Complianz, Cookiebot and Iubenda are detected automatically; anything else can be pointed at your accept and reject buttons.
What you need
- A GA4 Measurement ID and a Measurement Protocol API Secret from your Google Analytics property. Both are required — without them events reach the service but cannot be forwarded to Google, so nothing appears in your reports.
- Nothing else. No Google Tag Manager, no server to rent, no container to configure.
Setup
A guided setup walks you through it: agree to what is shared and create your free account, enter your two Google Analytics credentials, tell us which cookie banner you use, and answer two questions so the right tracking settings are applied. Most sites are done in a few minutes.
Features
- WooCommerce tracking out of the box:
view_item, add_to_cart, begin_checkout, shipping and payment steps, and purchase
- Click, scroll, engagement and form-submission tracking
- Server-side bot filtering, so automated traffic does not pollute your reports
- Consent-aware anonymisation built in
- Event dashboard with your live event stream
- Free tier: 10,000 events per month, fully functional, indefinitely
Pricing
The free tier is not a trial and does not expire. Paid plans raise the monthly event allowance and extend dashboard retention; they are bought on the dashboard and applied to your site automatically.
No licence key is ever entered in WordPress, and no plugin feature is locked, disabled or degraded on the free tier.
- Install the plugin from Plugins → Add New, or upload the folder to
/wp-content/plugins/.
- Activate it. Nothing is transmitted at this point — the plugin does not contact any external service until you ask it to.
- The guided setup opens automatically. Step one shows exactly what will be shared and asks you to agree before your free account is created.
- Enter your GA4 Measurement ID and Measurement Protocol API Secret. Both are in Google Analytics under Admin → Data streams → your web stream.
- Choose your cookie banner, answer two short questions about how you want tracking configured, and you are done.
To check data is arriving, open
Realtime in Google Analytics and load a page on your site.
5.7.1
- Fix: visits from people who decline cookies are no longer lost. They were being held back from Google Analytics entirely, so those visits vanished from your totals with nothing to show they had happened. They are now sent the way Google intends for this case: counted, with the decline recorded and with nothing that identifies the person, so your traffic figures are complete again.
- Fix: the answer a visitor gives about analytics was not being sent with the event, so every event from the plugin’s own tracking was filed as an unclear "partial" regardless of what they actually chose. The consent shown in your dashboard now reflects the real answer.
5.7.0
- Fix: a visitor who refused cookies was being recorded as having allowed analytics. The consent signal from your cookie banner is four characters long and the first two are a fixed marker; the plugin read the marker as if it were the answer, so the analytics permission always came out as granted and the advertising permissions were each read one place along. Everyone who declined has been recorded incorrectly until now.
- Fix: events from a visitor who declined no longer carry the identifier that recognises them across visits. The plugin already replaced it on its own tracking path; the path that carries your Google tag did not, so the same visitor arrived identifiable on one and not the other. The visit is still counted — refusing consent should cost you a statistic, not the whole visit — and the advertising details are dropped with it.
- Fix: your visitors are no longer all reported from your web server’s location. Events passing through the plugin are sent to Google from your server, so Google saw the server and reports showed one city for everybody. The visitor’s own address is now passed along, and only for visitors who allowed analytics.
5.6.2
- Correction to the 5.5.0 and 5.6.0 notes below, which claimed more than was true. Two of them have been rewritten. There was never a risk of Google Analytics filtering your customers out as internal traffic: the field that filter matches on was not being sent at all. And recognising payment providers does not change which source Google Analytics credits a sale to, because those fields never reach Google Analytics; it corrects reporting fields the plugin sends of its own. Checked against 149,000 recorded events before saying so.
- The product-list fix in 5.5.0 is unaffected and has since been confirmed on live data: shop events carried no products at all before it, and carry them after it.
- No plugin code changed in this release.
5.6.1
- Fix: a username containing a slash was accepted when saving and then refused by the service, with nothing on screen explaining why. The check ran in a lenient mode that only strips HTML, so it disagreed with the rule shown next to the field. Both now allow exactly the same thing: letters, numbers, spaces, and _ . - @
- Improvement: the consent checkbox on the Connection screen now says what it actually controls. Unticking it stops all tracking, not just reconnecting, and the screen said only the latter.
- Improvement: you can now correct the account email and username on a site that is already connected. Untick the consent box and both fields appear; tick it again to save them and reconnect. Previously they could only be set during first-time setup.
5.6.0
- Fix: ordinary navigation on your own site is no longer described as traffic from yourself. This affects a reporting field the plugin sends of its own; it never reached the field Google Analytics filters internal traffic on, so no reports were being altered by it.
- Fix: a visitor who returns after paying, or from a link on your own site, is treated as the same visit rather than a new one, so the plugin's own reporting keeps the traffic type that brought them. If the visit expired while the shopper was paying — routine when paying in a banking app or with Bancontact on a phone — the return was previously counted as a brand new visit. A genuine new campaign link still takes precedence. Which source Google Analytics itself credits a sale to is decided by Google Analytics and is not changed by this.
- New: WooCommerce orders now record which Google advertisement brought the visitor, including the app and iOS click identifiers that replace the usual one. The plugin keeps this in the browser, which forgets it on a cleared cookie, another device, or a later return; the order is the record that never gets lost. It is stored only after the visitor has given advertising consent, it stays on your own site, and it lets you check advertising revenue yourself. Both the classic and the block checkout are covered.
- Housekeeping: the privacy section now describes the cookie this adds,
esst_click_id, and the three values it puts on an order.
5.5.0
- Fix: purchases and other shop events reached Google Analytics without any products in them. The order total, currency and transaction ID all arrived, so the conversion looked correct — but the product list was dropped in transit and never appeared in your reports. Every shop event was affected: purchase, add to cart, begin checkout, product views and product list views. Product-level reporting now works, which matters most if you run campaigns that bid on individual products.
- Fix: returning from a Dutch or Belgian payment provider is now recognised as a return rather than a new visit. MultiSafepay, Buckaroo, Pay.nl, Sisow, iDEAL, Payconiq, Bancontact, Worldline, CCV, ICEPAY and the issuing banks were not recognised as payment pages at all. This corrects the plugin's own reporting fields; the source Google Analytics credits a sale to is decided by Google Analytics, and if returns from a payment page are being counted there as referrals, that is fixed by listing those providers as unwanted referrals in your data stream settings.
- New: you now choose the email address and username your tracking account is created under, instead of the plugin sending whatever address WordPress happens to have. That address is your login for the dashboard and it decides which account owns this site, so it is worth getting right — and on many sites the address WordPress holds is one nobody reads.
- Improvement: the setup steps explain themselves properly. Step 2 walks you through where to find your Measurement ID and API secret in Google Analytics, click by click, and step 3 explains what actually happens while a visitor has not yet answered your cookie banner.
- Housekeeping: the plugin's compiled files are now verified against their source automatically. A fix could previously be released to WordPress.org while sites updating from GitHub kept the old version — silently, with no way to tell the two apart.
5.4.3
- Housekeeping: internal test tooling only, no change to how the plugin behaves.
5.4.2
- Fix: setup no longer moves on when your Google Analytics credentials fail to reach the tracking service. Previously the credentials were saved locally and setup continued, leaving a site that looked finished while nothing could be forwarded to Google. Setup now stays on that step and shows exactly why it failed.
- New: if the delivery keeps failing — the service limits how often a site may reconnect — you can continue anyway. A reminder then stays in place until the credentials are delivered, so it cannot be forgotten.
5.4.1
- Fix: the Settings Templates button did nothing. The template data is published to the page while it renders, but the script that reads it was loaded earlier, so the data never reached it and the button had no effect at all. The templates picker and its two-question helper now open and apply correctly.
- Fix: reading your saved GA4 API Secret no longer logs "GA4 Key Decryption Error" when debug mode is on. The secret was always decrypted correctly, but it was first run through a check meant for a different kind of key, which failed and wrote an alarming line to the log. Anyone troubleshooting why data was not reaching Google was being pointed at a decryption failure that had not happened.
5.4.0
- New: a guided setup walks you through getting tracking working. Agree to what is shared and create your free account, enter your two Google Analytics credentials, pick your cookie banner, and answer two questions so the right settings are applied. Until the first two steps are done the plugin's other screens stay out of the way, so there is one obvious thing to do at any moment. Sites that are already set up never see it.
- New: your cookie banner is detected automatically. Complianz and Cookiebot fill in their accept and reject buttons for you; CookieYes and Iubenda are recognised too. Any other banner can still be pointed at your own buttons, and every field stays editable.
- Fix: saving your Google Analytics credentials no longer crashes the settings page. The credentials were stored and then the page died with a fatal error, which also meant they were never delivered to the tracking service - so server-side forwarding stayed broken no matter how many times you saved. Present since 5.3.0.
- Fix: the settings pages can no longer clear each other's checkboxes. Saving one section previously wrote every checkbox it knew about, so a form that did not show a box could silently switch it off. Each form now only saves what it actually displays.
- Improvement: events that fail to reach the tracking service are now retried once and, if they still do not arrive, counted and reported in the admin. Previously delivery was fire-and-forget: the plugin never looked at the result, so a brief outage silently under-counted your usage and nothing anywhere said so.
- Improvement: while setup is unfinished the plugin's other menu items are hidden, so there is one obvious thing to do. Their URLs still work and lead back into setup rather than an error page.
- Improvement: the plugin listing on WordPress.org has been rewritten. Several statements were wrong, including one that said no Google Analytics Measurement ID was needed - it is required, and without it nothing reaches your reports.
5.3.2
- New: "Never collect or send visitor IP data" and "Test Mode" are now ordinary settings you can see and change on the Settings page. Until now they could only be set by applying a settings template, and nothing in the interface showed whether they were on.
- Fix: the settings templates no longer describe things the plugin does not do. Several promised "no Google Analytics cookies" or full logging in an Event Monitor screen that no longer exists, and six of the ten were identical to one another in effect. There are now three templates that genuinely differ: Recommended, Maximum Privacy, and Testing & Debug.
- Fix: saving the settings page no longer silently clears options it has no field for.
- Housekeeping: removed settings that no longer had any effect, and the unused code behind them. Tracking behaviour is unchanged - if you apply a template, it now does exactly what its description says.
5.3.1
- Fix: deactivating and reactivating the plugin silently switched off two settings. "Disable IP geolocation" was switched off, so visitor IP data was collected again on sites set up for maximum privacy, and Test Mode was switched off, so events that were meant to be held back started being sent to Google Analytics for real. Neither change was announced and neither was visible in the interface. Both settings now survive activation. If you rely on either one and have reactivated the plugin at any point since 5.0, re-apply your settings template to restore it.
5.3.0
- Fix: the GA4 Measurement ID and API Secret were never sent to the tracking service. They are now included when a site connects and, because they are usually filled in afterwards, re-sent automatically whenever you save them. Server-side forwarding to your own GA4 property could not work before this.
- Fix: events forwarded through the gtag proxy lost all of their parameters. Purchase value, currency, transaction ID and the full item list are now preserved, so ecommerce reporting works for sites tracking through the proxy.
- Fix: a consent override stored in lower case ("denied") was not recognised and fell back to granting consent. Consent values are now normalised, and anything unrecognised fails closed to DENIED.
- Fix: the admin consent-override setting had two conflicting defaults depending on which part of the plugin read it first. Both now default to DENIED.
- Improvement: connection problems are reported instead of passing silently. Saving GA4 settings shows an explicit warning when they could not be delivered, and dropped events are written to the plugin log with the reason.
5.2.6
- Fix: events failed to send on sites where a theme/plugin defines a global
function fetch(){…} (e.g. the common admin-ajax "data_fetch" live-search snippet), which overwrites the browser's native window.fetch. The tracker now detects a shadowed fetch and recovers a pristine native fetch (via a hidden same-origin iframe) so events send normally. Init marker advanced to "v5".
5.2.5
- Fix: prevent an uncaught JavaScript error ("Cannot read properties of undefined (reading 'then')") when a content blocker, privacy extension or browser tracking-protection neutralises window.fetch for the collector domain. The tracker now detects that the request was blocked and drops the event gracefully instead of throwing. Init marker advanced to "v4".
5.2.4
- Maintenance: rebuild the public tracker bundle so aggressive JS optimizers/CDNs (e.g. WP Rocket's content-hashed cache) generate a fresh file and stop serving an older cached copy. The initialization marker was advanced to "v3" so the loaded build is verifiable in the browser console. No functional code changes.
5.2.3
- Maintenance: version bump to change the tracker script's cache-busting query string, forcing browsers and CDNs to reload the corrected public bundle from 5.2.2. No functional changes to the plugin.
5.2.2
- Fix: resolve a JavaScript error ("Cannot read properties of undefined (reading 'then')") when sending events; rebuild the public tracker bundle so the corrected code is served.
5.2.1
- COMPLIANCE: Neutralised the worker quota notice. When the managed service pauses a site (after it reaches its plan's monthly event volume), the admin notice now states the service paused tracking and links to the dashboard — the "monthly limit reached / Upgrade your plan" wording and the pricing link were removed. The plugin itself locks no features; all tracking is free and fully functional, and the volume is enforced by the external service, not the plugin.
- DOCS: Added setup/connection and plan-change FAQ entries to the readme.
5.2.0
- COMPLIANCE (WordPress.org Guideline 5 — Trialware): Removed the entire client-side license subsystem. Deleted the license manager and tamper-detection guard, removed the in-WordPress license-key field, and removed all local tracking and caching of event counts and plan limits. The plugin is free and fully functional with no license key.
- Plans, usage, limits, and upgrades are now managed entirely on the dashboard (easyserversidetracking.com). Limits are applied and enforced server-side by the managed worker; the plugin only provisions the site and sends events. The admin "License" screen is now a "Connection" screen that links to the dashboard.
- Cleanup: all obsolete license, event-count, plan-limit, permission, and tamper-hash options are removed on upgrade.
5.1.7
- COMPLIANCE FIX: Two
wp_head outputs (the googletagmanager preconnect hint and the early gtag consent script) were still gated on the provisioning id alone, so they could fire on grandfathered or consent-withdrawn sites. Both now require explicit consent AND provisioning, matching the tracker.
- HARDENING: The page-token REST endpoint now refuses to mint a worker token without consent (defense-in-depth, mirroring the /g/collect proxy).
- RELIABILITY: The browser's collect URL is now normalized to a single /collect path before use, so a stored value without that suffix can't send events to the wrong endpoint. The token-refresh request no longer builds a double-slash URL.
- NOISE: The "Not provisioned" frontend message is now debug-gated instead of warning on every event.
5.1.6
- HOTFIX: The 5.1.4 consent gate replaced the provisioning check on the frontend tracker and the periodic license refresh instead of adding to it. On sites that had a consent record but were not provisioned, the tracker loaded and then dropped every event as "Not provisioned". Both paths now correctly require BOTH explicit consent AND a provisioning id before loading or phoning home.
5.1.5
- MAINTENANCE: Internal refactor (no change to behavior). Centralized all outbound service calls behind a single HTTP helper, extracted the consent logic (site-owner opt-in gate + visitor gcs→consent mapping) into a dedicated, unit-tested class, and split the admin notices into their own class.
- TESTS: Fixed the native unit-test bootstrap (it never defined
WPINC, which silently aborted the suite) and added coverage for the consent mapping.
5.1.4
- PRIVACY/COMPLIANCE: Explicit opt-in consent is now the single gate for ALL connections to the service and ALL tracking. Until the site administrator gives consent, the plugin does not contact the service, does not run the periodic license/usage refresh, does not load any tracking script, and rejects the
/g/collect proxy. The mere presence of a provisioning id (esst_site_id, which can survive an upgrade) no longer enables anything. Legacy installs with a provisioning id but no consent record now stay OFF and show a notice prompting the admin to review and enable. Withdrawing consent fully stops tracking.
- PRIVACY: Server-side event logs forwarded to the worker now carry the visitor's real GA4 consent state (derived from the gtag
gcs signal, defaulting to denied) instead of a hardcoded "granted" value.
- SECURITY:
$_GET WooCommerce variation attributes are now unslashed, sanitized (sanitize_key / sanitize_text_field) and validated before being passed to WooCommerce's variation matcher.
5.1.3
- HOTFIX: Resolves a fatal
Class "JachtSST\\Admin\\GA4_Server_Side_Tagging_Admin" not found on the License page in 5.1.2 — the consent panel referenced the pre-rename class symbol. Fixed to use the real class name Jachtsst_Server_Side_Tagging_Admin.
5.1.2
- PRIVACY/UX: The License page now shows a persistent "Data sharing consent" panel above Re-provision. It lists exactly what is sent and where, with a checkbox that records explicit consent (timestamp + user + the exact disclosure text shown). Grandfathered installs (provisioned by an older version) see this with an unticked box; ticking it records consent retroactively and unlocks the Re-provision button. The Re-provision AJAX now refuses to phone home without a stored or in-request consent record.
- COMPLIANCE: Text domain in source code now matches the actual plugin slug
jacht-easy-server-side-tracking (previously had a stale reference to the slug originally proposed in the wp.org review).
- COMPLIANCE: Restored phpcs:ignore comments on the three settings-handler POST reads so Plugin Check no longer reports false-positive sanitization warnings; the sanitizer callbacks do handle JSON-decode and per-field cleanup.
- DOCS:
Tested up to: 7.0.
5.1.1
- FIX: Page/event tokens now sign with the hashed signing key, matching the ingestion endpoint. Resolves
bad_page_token / HMAC verification failures so events are accepted without re-provisioning.
5.1.0
- Provisioning is now an explicit opt-in; no data is sent until you connect.
- Logs are stored in the uploads directory instead of the plugin folder.
- Stricter input sanitization and unique internal prefixes for WordPress.org compliance.
5.0.4
- FIX: Tracker init no longer throws
TypeError: setupEventCountFlushHandlers is not a function. The orphaned calls (left over from the v5.0.2 client-side limit-enforcement removal) have been deleted, so the tracker reaches the end of its init path again.
- UI: License page no longer exposes the management endpoint URL or the
ESST_MGMT_BASE_URL override note. Customers shouldn't be altering this endpoint.
- Cache-bust: the version bump forces fresh JS to be loaded after the v5.0.3 release that introduced the broken init path.
5.0.3
- SECURITY: Added CSRF nonce verification to the encryption-key regeneration AJAX endpoint.
- PRIVACY: Removed the client-side fallback chain to ipapi.co, ipinfo.io, and json.geoiplookup.io. Geo-resolution is performed server-side by the managed worker from the request IP. No visitor IP is sent to third parties by the plugin.
- COMPLIANCE: Renamed the unprefixed
event_count option to ga4_event_count (with an automatic one-time migration). Sanitized all $_SERVER reads with sanitize_text_field( wp_unslash() ). Removed shipped legacy plugin-v4/ source tree and the wp-admin/includes/upgrade.php test mock.
- README: Added
External services section documenting every external endpoint the plugin contacts, with terms and privacy links. Tags revised to remove trademarked terms.
5.0.2
- REMOVE: Client-side event-limit enforcement. The admin Settings page no longer hides itself when a cached "limit reached" flag is set. Quota is enforced exclusively server-side — the worker returns
429 quota_exceeded, the management server returns allowed: false in report-usage.
- FIX: License page shows the paid-plan name and limit immediately after activation — the management server now propagates
plan_id onto lm_websites on license/activate and report-usage.
5.0.1
- FIX: All events now use a single canonical payload format with top-level
client_id, session_id, user_id, consent, and context — previously some paths (scroll, click, batched events) sent client_id nested under params which the central worker rejected with HTTP 400 missing_client_id.
- FIX: Worker
bad_page_token (401) responses now trigger a token refresh + retry once, so tabs left open across a re-provision auto-heal.
- FIX: Re-provisioning rotates the secret in place on the central worker instead of creating a new
cf_site_id every time — no more orphaned worker sites and no more HMAC mismatches.
- FIX: Gtag /g/collect proxy on the WP site also fires a server-side
log_only POST to the central worker so events are counted even when content blockers block the JS bundle on the customer's browser.
- FIX: License page correctly shows "Unlimited" for paid unlimited plans (was showing the free-tier 10,000 cap).
- REFACTOR: Removed legacy
sendAjaxPayload and sendBatchPayload — esstSendEvent is the single event-sending path. Worker no longer receives batches; each event is one request.
- REFACTOR: Removed all remaining customer-hosted Cloudflare Worker references from the Settings UI.
5.0.0
- MAJOR: Plugin no longer requires a customer-hosted Cloudflare Worker.
- MAJOR: Events post directly to the managed collect endpoint (
collect.easyserversidetracking.com) using a short-lived per-page HMAC token.
- MAJOR: Removed Event Monitor / Event Processor / Tracking Logs admin pages. All event analytics now live on the management dashboard.
- NEW: Auto-provisioning on activation — no license key required for the free tier.
- NEW: Status admin page shows
site_id, plan, this-month usage. (Merged into the License page in a later release.)
- REMOVED:
ga4_event_queue / ga4_event_logs tables (data not migrated).
- REMOVED: Custom transmission method setting, CF Worker URL setting, JWT encryption setting, test mode toggle, "disable all IP" setting.
- The client-side session management setting is now always enabled.
3.7.x
Earlier 3.7.x releases focused on plugin-check compliance and security hardening. See the GitHub release notes for details. The plugin's data flow and admin surface were rewritten in 5.0.0; users on 3.7.x should re-test after upgrading.