Easy Server Side Tracking

Istoric modificări

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.