Title: Easy Server Side Tracking Author: jachtdigital2026 Published: 2026 年 6 月 29 日 Last modified: 2026 年 9 月 22 日 --- 搜索插件 ![](https://ps.w.org/jacht-easy-server-side-tracking/assets/banner-772x250.png?rev =3678027) ![](https://ps.w.org/jacht-easy-server-side-tracking/assets/icon-256x256.png?rev =3592261) # Easy Server Side Tracking 作者：[jachtdigital2026](https://profiles.wordpress.org/jachtdigital2026/) [下载](https://downloads.wordpress.org/plugin/jacht-easy-server-side-tracking.5.9.6.zip) * [详情](https://cn.wordpress.org/plugins/jacht-easy-server-side-tracking/#description) * [评价](https://cn.wordpress.org/plugins/jacht-easy-server-side-tracking/#reviews) * [安装](https://cn.wordpress.org/plugins/jacht-easy-server-side-tracking/#installation) * [开发进展](https://cn.wordpress.org/plugins/jacht-easy-server-side-tracking/#developers) [支持](https://wordpress.org/support/plugin/jacht-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. More information, documentation and pricing: [https://www.easyserversidetracking.com/](https://www.easyserversidetracking.com/) ### External services This plugin connects to the following external services. Each is necessary for the functionality described and is only contacted as documented below. #### collect.easyserversidetracking.com (managed ingestion worker) * **Provider:** Easy Server Side Tracking (operated by Jacht.Digital Marketing). * **What it does:** Receives event posts from the in-browser tracker, normalizes and deduplicates them, applies bot filtering and consent rules, then forwards to Google Analytics 4 and stores a copy for the dashboard. * **What is sent:** Each event payload — event name, page URL, page title, referrer, anonymized client/session IDs, consent state, event-specific parameters, and the visitor IP. The IP is used for country lookup and rate limiting and is ** never stored in raw form** — only as a hash of the IP with a salt that rotates daily, truncated, which cannot be reversed and does not link the same visitor across days. * **When:** Every time a tracked event fires in the visitor’s browser. * **Required:** Yes — the plugin’s core function is to send events here. * **Terms of service:** https://dashboard.easyserversidetracking.com/terms-of-service/ * **Privacy policy:** https://dashboard.easyserversidetracking.com/privacy-policy/ #### dashboard.easyserversidetracking.com (management & provisioning server) * **Provider:** Easy Server Side Tracking (operated by Jacht.Digital Marketing). * **What it does:** Provisions a site ID and signing secret for this site so the ingestion worker will accept its events. Your plan, usage, and limits are managed here when you log in to the dashboard. * **What is sent:** Site URL and admin email (during provisioning / re-provisioning only), and the site ID. * **When:** Only when you click **Create free account** or **Re-provision**. Activating the plugin sends nothing. * **Required:** Yes, but only once you choose to connect. Activation alone sends nothing; the account is created when you press **Create free account** during setup. * **Terms of service:** https://dashboard.easyserversidetracking.com/terms-of-service/ * **Privacy policy:** https://dashboard.easyserversidetracking.com/privacy-policy/ #### Google Analytics 4 (Measurement Protocol) * **Provider:** Google LLC. * **What it does:** Receives analytics events forwarded by the managed worker ( or, when configured locally, sent by the WordPress site directly). * **What is sent:** GA4 Measurement Protocol payloads — event name, parameters, client_id, optional user_id, optional consent flags. Sent to `https://www.google- analytics.com/g/collect` or `https://www.google-analytics.com/mp/collect`. * **When:** Every event the worker forwards (or every event your WP site forwards in direct-mode). * **Required:** Yes if you want events to appear in GA4. The plugin does not function as an analytics tool without GA4 (or another Measurement Protocol target). * **Terms of service:** https://marketingplatform.google.com/about/analytics/terms/ us/ * **Privacy policy:** https://policies.google.com/privacy #### googletagmanager.com (gtag.js) * **Provider:** Google LLC. * **What it does:** Serves the `gtag.js` library to the visitor’s browser for client- side GA4 measurement. * **What is sent:** Standard `gtag.js` telemetry while the script is loaded (page views, automatic events). Its measurement requests are routed through your own site rather than straight to Google. * **When:** On every pageload, **after** the visitor has given consent. No request is made before consent, and none is made at all until you have connected your site. * **Required:** Yes. `gtag.js` provides the GA4 session and engagement signals the plugin cannot reproduce on its own. * **Terms of service:** https://marketingplatform.google.com/about/analytics/terms/ us/ * **Privacy policy:** https://policies.google.com/privacy ### Privacy This plugin does not collect or store personal data on the WordPress site itself. All event data is sent to the external services listed above and stored there subject to those services’ privacy policies. The plugin stores the following non-personal data in WordPress options for its own operation: * `esst_site_id` — the site identifier returned by the management server. * `esst_signing_secret` — the HMAC signing secret for the managed ingestion endpoint( encrypted at rest). * `esst_collect_url`, `esst_plan_summary` — operational state from the management server (collect endpoint URL and the plan name shown in the admin). * `jachtsst_user_opt_in_at`, `jachtsst_user_opt_in_by`, `jachtsst_user_opt_in_text`— the record of who agreed to the data sharing, when, and the exact wording they agreed to. This is kept so the consent can be evidenced later, and includes the WordPress user ID of the administrator who ticked the box. It is never sent anywhere. * `jachtsst_setup_completed_at`, `jachtsst_cmp_choice` — setup progress, so the guided setup does not reappear. The plugin sets one first-party cookie of its own, `esst_click_id`. It holds the Google click identifier (`gclid`, `gbraid` or `wbraid`) from the advertisement a visitor arrived through, so that a resulting WooCommerce order can record which ad it came from. It is set only after the visitor has given advertising consent, expires after 90 days, and is never sent anywhere by the plugin — it is read back on this site only, when an order is created. It contains no personal data. Alongside it the in-browser tracker uses the first-party cookie named `_ga` (the standard GA4 client identifier) when present. When an order is created and that cookie is set, three values are stored on the order: `_esst_click_id`, `_esst_click_id_type` and `_esst_click_id_stored_at`. They stay on your own site. ## 屏幕截图 [⌊What normal GA4 tracking sees, and what arrives instead: blocked visits come back in full, and visitors who refused consent come back counted but unidentifiable.⌉⌊ What normal GA4 tracking sees, and what arrives instead: blocked visits come back in full, and visitors who refused consent come back counted but unidentifiable.⌉[ What normal GA4 tracking sees, and what arrives instead: blocked visits come back in full, and visitors who refused consent come back counted but unidentifiable. ## 安装 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. ## 常见问题 ### How do I set up and connect my site? 1. Install and activate the plugin. 2. Go to **Server Side Tracking – Connection** and click **Create free account**. This sends your site URL and admin email to easyserversidetracking.com and provisions your site (you’ll see a **Site ID** appear on the Connection page). Tracking begins on the free tier. 3. Your site is automatically linked to the dashboard account whose email matches the WordPress admin email used at step 2. So if you sign in to https://dashboard. easyserversidetracking.com/ with that same email, your site already appears under your account — nothing else to do. 4. If your dashboard account uses a _different_ email, link the site manually: on the dashboard go to **Account Websites Add site**, paste the **Site ID** shown on the plugin’s Connection page, and click **Add site**. The Site ID is what proves the site is yours. ### How do I upgrade, or change a site’s plan? Plans are managed entirely on the dashboard — you never enter a license key in WordPress. Buy or change a plan at https://dashboard.easyserversidetracking.com/, then on ** Account Websites** use the **Plan** dropdown next to a site to assign it the plan( or switch it back to the **Default** free plan). The new monthly limit is applied to the tracking service automatically; no change is needed in WordPress. ### Do I need an account? You do not need to sign up anywhere first. During setup you press **Create free account** and the plugin provisions your site for you — that click is the only moment anything is sent. The free tier is fully functional and does not expire. A paid plan at https://dashboard.easyserversidetracking.com/ raises your monthly event allowance and dashboard retention. ### What happens when a visitor refuses my cookie banner? The event still arrives in Google Analytics, but everything that identifies the person is removed first: no client id, no advertising click id, no campaign, location or browser detail. You keep the visit — and the order — in your totals, and the visitor stays anonymous. That is what Google Consent Mode is for. Most setups send nothing at all in this case, which is why their numbers are lower than their actual sales. ### What if I do not have a cookie banner at all? Then every visitor is treated as having refused, so all of your traffic arrives in that anonymised form. You still get counts, but you never learn who would have accepted. Install a banner before you go live. ### Does this replace gtag.js? It can run alongside `gtag.js` (hybrid mode), or you can rely entirely on the server- side path. The script is loaded from `googletagmanager.com` only when hybrid mode is enabled in the Settings screen. ### What data is sent to the managed worker? Each event includes: event name, page URL, page title, referrer, anonymized client ID and session ID, consent state, and event-specific parameters (e.g. WooCommerce order IDs, scroll percentages, click targets). The visitor’s IP address is processed by the worker for geo-resolution and rate limiting but is not stored long-term. No personally identifiable information (name, email, address) is sent unless you explicitly configure user-data fields. ### Where can I see my events? The **Connection** page in WordPress shows your Site ID and links to the dashboard at https://dashboard.easyserversidetracking.com/, where you can see your live event log, this month’s usage, and your plan. ### Can I uninstall cleanly? Yes. Deactivating the plugin stops event collection. The plugin’s options can be deleted via the standard WordPress plugin uninstall flow. ## 评价 此插件暂无评价。 ## 贡献者及开发者 「Easy Server Side Tracking」是开源软件。 以下人员对此插件做出了贡献。 贡献者 * [ jachtdigital2026 ](https://profiles.wordpress.org/jachtdigital2026/) [帮助将「Easy Server Side Tracking」翻译成简体中文。](https://translate.wordpress.org/projects/wp-plugins/jacht-easy-server-side-tracking) ### 对开发感兴趣吗? 您可以[浏览代码](https://plugins.trac.wordpress.org/browser/jacht-easy-server-side-tracking/)， 查看[SVN仓库](https://plugins.svn.wordpress.org/jacht-easy-server-side-tracking/)， 或通过[RSS](https://plugins.trac.wordpress.org/log/jacht-easy-server-side-tracking/?limit=100&mode=stop_on_copy&format=rss) 订阅[开发日志](https://plugins.trac.wordpress.org/log/jacht-easy-server-side-tracking/)。 ## 更新日志 #### 5.9.6 * Docs: bumped Tested up to 7.1, confirmed against a live 7.1 install. No functional changes. #### 5.9.5 * Fix: the plugin’s WordPress.org listing linked to the non-www homepage, which 301-redirects. The link now points straight to https://www.easyserversidetracking. com/, the canonical address. #### 5.9.4 * The plugin page and the Connection screen now link to easyserversidetracking. com, so you can find more information, documentation and pricing without leaving WordPress. #### 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 gcsconsent 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 … ## 额外信息 * 版本 **5.9.6** * 最后更新：**2 周前** * 活跃安装数量 **不到10** * WordPress 版本 ** 5.2 或更高版本 ** * 已测试的最高版本为 **7.1.3** * PHP 版本 ** 7.2 或更高版本 ** * 语言 * [English (US)](https://wordpress.org/plugins/jacht-easy-server-side-tracking/) * 标签 * [analytics](https://cn.wordpress.org/plugins/tags/analytics/)[conversion tracking](https://cn.wordpress.org/plugins/tags/conversion-tracking/) [server side](https://cn.wordpress.org/plugins/tags/server-side/)[tracking](https://cn.wordpress.org/plugins/tags/tracking/) [woocommerce](https://cn.wordpress.org/plugins/tags/woocommerce/) * [高级视图](https://cn.wordpress.org/plugins/jacht-easy-server-side-tracking/advanced/) ## 评级 尚未提交反馈。 [您的评价](https://wordpress.org/support/plugin/jacht-easy-server-side-tracking/reviews/#new-post) [查看全部评论](https://wordpress.org/support/plugin/jacht-easy-server-side-tracking/reviews/) ## 贡献者 * [ jachtdigital2026 ](https://profiles.wordpress.org/jachtdigital2026/) ## 支持 有话要说吗？是否需要帮助？ [查看支持论坛](https://wordpress.org/support/plugin/jacht-easy-server-side-tracking/)