Easy Server Side Tracking

A large share of your visitors never show up in Google Analytics. Ad blockers stop the tracking request before it leaves the browser. Visitors who refuse your cookie banner are dropped by most setups on purpose. Commonly that is 30-50% of your traffic — and those people still browse, still add to cart, and still buy. So your reports are wrong in a way you cannot see. Revenue in Google Analytics is lower than revenue in your shop. Channels that actually work look mediocre. Every decision you make from that data is made from a partial picture. Easy Server Side Tracking closes that gap in two ways. 1. Blocked visits come back The tracking request no longer goes to google-analytics.com, which is the address blockers are built to recognise. It goes to a tracking endpoint that is not on any blocklist, and Google Analytics is fed from there. Nothing on the visitor's side has to change. 2. Refused consent no longer means nothing This is the part most setups get wrong. When someone rejects your cookie banner, the usual answer is to send nothing at all — so the visit, and the order, simply disappear from your numbers. Here the event still arrives in Google Analytics, with everything that identifies the person removed first: no client id, no advertising click id, no campaign, location or browser detail. You keep the visit and the sale in your totals. The visitor stays anonymous. That is exactly what Google Consent Mode is designed for, and it is switched on for you. The short version: an order is measured whether the visitor blocks trackers, refuses cookies, or closes the tab before your thank-you page loads. What you get back

• Visits, add-to-carts and purchases that used to be invisible
• WooCommerce revenue in Google Analytics that lines up with your actual orders
• Channel and campaign reports based on nearly all of your traffic instead of the part that got through
• A count for every visitor, including the ones who said no — anonymously
• A dashboard showing every event received, so you can see what arrives instead of guessing

WooCommerce Product views, add to cart, checkout steps, shipping and payment, and the purchase itself are tracked out of the box. The sale is sent from your server the moment the order is paid, so it does not depend on the customer returning to your thank-you page — a customer who closes the tab at the payment provider is measured just the same. What you need

• A GA4 Measurement ID and a Measurement Protocol API Secret, both from your own Google Analytics property.
• Nothing else. No Google Tag Manager, no server to rent, no container to configure, no licence key.

Setup is a short guided flow: agree to what is shared and create your free account, paste those two credentials, and tell us which cookie banner you use. Complianz, Cookiebot, CookieYes and Iubenda are recognised automatically; anything else can be pointed at your accept and reject buttons. Most sites are done in a few minutes. Free, and honest about it The free tier covers 10,000 events per month, does not expire, and is not a trial. No feature is locked or degraded on it. Paid plans only raise the monthly event allowance and how long the dashboard keeps your events. What we do with your data We are a proxy, not a data broker. Your events are forwarded to your own Google Analytics property, and a copy is kept so you can see your own event stream. Nothing is sold, shared with third parties, used to build profiles, or combined across customers. Raw IP addresses are never stored. The IP is used for country lookup and rate limiting, then hashed with a salt that rotates daily and truncated. It cannot be reversed, and the same visitor produces a different hash tomorrow. Nothing is sent anywhere until you connect. Installing and activating contacts no external service at all. You see exactly what will be shared, tick a box, and press a button.

1. Install the plugin from Plugins → Add New, or upload the folder to /wp-content/plugins/.
2. Activate it. Nothing is transmitted at this point — the plugin does not contact any external service until you ask it to.
3. The guided setup opens automatically. Step one shows exactly what will be shared and asks you to agree before your free account is created.
4. Enter your GA4 Measurement ID and Measurement Protocol API Secret. Both are in Google Analytics under Admin → Data streams → your web stream.
5. 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.9.3

• The plugin page now opens with a diagram of the route an event actually takes, from the visitor to your own Google Analytics property, and where each of the two problems is solved along the way.
• Wording: refused consent is described as the event arriving anonymised rather than being sent. Arriving is the thing that counts, and it is what happens.

5.9.2

• Fix: the plugin's internal development notes were being packaged into the WordPress.org download and installed on your site. They are gone from this version. Nothing about tracking changes.
• The plugin page has been rewritten to explain, in plain terms, the two things this actually solves: visits hidden by ad blockers, and visits lost because someone refused the cookie banner.

5.9.1

• Fix: the setup wizard told you that visitors who reject your cookie banner are not tracked at all. They are. Their events are still sent, with everything that identifies them removed first: no client id, no advertising click id, no campaign, location or browser detail. You keep the visit in your totals and the visitor stays anonymous. The wizard, and the "I do not use a cookie banner" option, now describe what the plugin actually does — the same behaviour this readme has always described. Nothing about tracking changed; only the text was wrong.
• Fix: an unused second copy of the anonymisation routine inside the tracker had drifted from the one that runs. Had it ever been reached it would have relabelled organic and direct visits as "(denied consent)", erasing your channel data for every visitor who refused. Both copies are identical again.

5.9.0

• Fix: sales were disappearing from your reports and never coming back. The plugin recorded a sale as measured the moment it started sending it, not when it arrived — so a single blocked or interrupted request removed that sale from Google Analytics permanently, and reloading the page never retried. On one live shop this cost roughly three sales in every ten. A sale is now only recorded as measured once the service confirms it arrived; anything unconfirmed is sent again.
• New: the sale is now sent from your server the moment the order is paid, instead of waiting for the customer's browser on the thank-you page. A customer who closes the tab at the payment provider, or never returns to your shop at all, is measured just the same. Their identity, the advertisement that brought them and their cookie choice are captured when the order is placed, so nothing depends on them coming back.
• New: a safety net runs in the background and re-sends any paid order the immediate send did not deliver, so a temporary outage costs a delay rather than a sale.
• Fix: an order from a visitor whose browser blocked the analytics cookie used to be dropped in silence. It is now sent without any identifying information, so your revenue in Google Analytics lines up with your shop. Visitors who refused consent are still sent anonymously, exactly as before.
• Fix: the advertisement, search or link that brought a customer is now stored with the order, so a sale re-sent later still reports where it came from. Previously a recovered sale reported "direct" even when it came from an advertisement.
• Note: sales that were already lost before this version are not recovered. This stops the loss from here on.

5.8.1

• Fix: on a site using the administrator consent override, a visitor's events still said their answer about analytics was a refusal. The override wrote the two advertising answers but not the third, so the service fell back to assuming a refusal and Google Ads would not use the conversion. Five places built a consent record this way; all of them now state all three answers. A new check refuses any future consent record that leaves one out, so this cannot come back.

5.8.0

• Fix: sales were reaching Google Analytics without any record of the advertisement, search or link that brought the customer. Of 155 purchases measured on a live shop, none carried a click identifier and none carried a usable traffic type. A setting meaning "your Google tag manages the visitor's id" was being read as "the plugin does no attribution at all", which switched off storing it, reading it back, and sending it — three separate places. All three now work, so a purchase again says where it came from.
• Fix: every event was rejected once before it was accepted. Each page carries a security token that is valid for thirty minutes, but the token is written into the page, so a cached page hands out the token that existed when the cache was made. On a live shop that token was 48 days old. The plugin refreshes it before sending now, instead of after being turned away — which matters most on the order confirmation page, where the visitor is often gone before the second attempt.
• Fix: visitors who ignore the cookie banner were never counted. Their events were parked until they answered, and if they never answered the events simply expired. On the page where that hurts is the order confirmation page, where the parked event is the sale. Those events are now sent when the visitor leaves, counted but with nothing that identifies the person — the same treatment a visitor who declines already gets.
• Fix: a visitor who pressed accept was recorded as having declined. The answer about analytics itself was never stored alongside the advertising answers, so the service fell back to assuming a refusal. This is the signal Google Ads uses to decide whether it may use a conversion, so consenting customers were being treated as refusals.
• Fix: someone who declined cookies still sent the identifier of the campaign that paid for their click. It was removed from one copy of the anonymising code and not the other, and the other was the one in use.
• Fix: the administrator's consent override was ignored whenever a cookie banner was installed — which is the only situation anyone switches it on for. It now applies everywhere, including to events that were waiting to be sent. It remains a testing setting and should not be used on a live site.
• New: utm_id is now read from your links and sent as the campaign id, so a campaign can be identified rather than only named.
• Fix: updating the plugin now clears your page cache and PHP's compiled code cache. Without that, visitors kept receiving the previous release for days — one shop was serving five different versions of the plugin within the same 48 hours, which is why earlier fixes appeared not to work.

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.