If your WooCommerce store sells in a regulated vertical — health, legal, therapy, religious products, or any category Article 9 covers — your standard GA4 setup is logging special-category data every time someone loads a page. The disclosure is not in a form submission. It is in the URL itself. A page path like /shop/anxiety-support/ tells anyone reading the analytics log that a specific user visited a page about anxiety support. That association is the special-category record. Pseudonymisation does not strip it. The fix is architectural and runs on your server, before GA4 ever sees the path.
Health, Legal, and Therapy WooCommerce Stores Are Logging Special-Category Data in GA4 by Default
The framing most stores work with is that Article 9 data is something you collect deliberately — a checkbox on a form, a question on a quiz, a doctor’s note uploaded to an account. That framing is incomplete. ICO guidance treats inferred data the same as explicit data the moment it is processed in a way that relates the inference to the individual. The URL is one of the most direct inference mechanisms in standard analytics.
What Article 9 Actually Covers
Article 9 of UK GDPR lists 10 special-category data types including health, sex life, sexual orientation, racial origin, and religious or political beliefs (ICO, 2024). The full list also covers genetic data, biometric data used for unique identification, trade union membership, and philosophical beliefs.
The structural shift in Article 9 — versus Article 6 — is the lawful basis requirement. Standard Article 6 lawful basis is insufficient. An Article 9 condition is also required for special-category data (ICO, 2024). That means consent, legitimate interest, or contract performance — the everyday lawful bases that cover most WooCommerce analytics — do not cover special-category processing on their own. A separate, more restrictive Article 9 condition has to apply.
For most retail stores, that condition does not exist for analytics. Vital interests, public health, occupational medicine — none of these apply to a page view on a wellness store’s category page. The processing is unlawful by default unless explicit consent specifically for special-category data has been obtained.
The Inferred-Data Doctrine
The piece most stores miss is ICO’s position on inferred data. Inferred or guessed data still counts as special-category if used or treated as relating to a special category (ICO, 2024). The doctrine is broad on purpose — it stops organisations evading Article 9 by collecting proxy data that, when combined, reveals special-category information.
The /shop/anxiety-support/ URL is the textbook case. The store does not collect a “diagnosed with anxiety” attribute. The URL does the disclosure. A user who lands on that page, paired with any persistent identifier — pseudonymised or not — produces a record that the user is interested in anxiety support. ICO’s inferred-data doctrine treats that record as special-category data.
Why Pseudonymisation Doesn’t Save You
The intuition that pseudonymisation strips the risk is structural confusion about what pseudonymisation does. It replaces the direct identifier (email, customer ID, IP) with a token. The token is reversible if the mapping table is held by the same controller — which in WooCommerce/GA4 setups it almost always is.
More importantly: pseudonymisation operates on the user identifier, not the event payload. The page path travels in the event. A pseudonymised user_id paired with a /sensitive-condition/ page view is still a record that an individual — even if that individual is referenced as user_a4f9b2 — visited a sensitive page. The Article 9 exposure is at the path level, not the identifier level. Pseudonymising the identifier does not remove the path from the log.
You may be interested in: Four German Courts Ruled Meta Pixel Illegal. Your WooCommerce Store Is Next.
Why DUAA Made This More Expensive
The Data (Use and Access) Act took effect on February 5, 2026, and aligned ICO’s PECR enforcement powers with UK GDPR penalty bands. Fines now run up to £17.5 million or 4% of global turnover (Bird & Bird, 2026). The previous PECR cap of £500,000 was the upper bound on cookie-and-tracker enforcement; that cap is gone.
What changes operationally: an Article 9 exposure that used to sit comfortably below the previous fine band is now in the same enforcement bracket as a major data breach. The risk-adjusted cost of leaving sensitive paths flowing into GA4 has gone up by an order of magnitude, even if the underlying technical setup hasn’t changed since 2023.
Why GA4’s Standard Setup Captures This Without Asking
The default GA4 implementation logs page_view events with the full page_location and page_path on every navigation. The path is part of the standard payload. Google’s documentation does not flag any path-level filtering, because GA4 treats the path as a generic dimension — it does not evaluate semantic content of the URL.
The merchant assumption is that GA4 is a measurement tool that captures generic browsing. The regulatory reality is that GA4 captures whatever the URL contains, and in regulated verticals, the URL contains Article 9 disclosures. The two views collide silently. Nothing in the GA4 admin UI surfaces the conflict.
Add the typical companion stack — Meta Pixel, Google Ads conversion tag, Hotjar, advertising remarketing pixels — and the same path lands in five or six third-party logs simultaneously, each subject to its own consent and lawful-basis analysis. 31.5% of users globally run ad blockers (Statista, 2024) — but blockers strip outbound pings, not the URL paths your own server already logged. The merchant-side exposure is not addressed by the customer’s ad blocker.
You may be interested in: UK PECR Fines Just Jumped From £500K to £17.5 Million on February 5
The Architectural Fix: Server-Side Filtering at Ingress
The fix has to operate before the analytics event is forwarded anywhere — not after, not via GA4 admin filters, not via post-hoc data deletion requests. The filtering point is the ingress layer on the merchant’s own server.
The pattern is direct. Every analytics event passes through a server-side processor before it reaches GA4, Meta, or any other destination. The processor inspects the page path against a configurable list of sensitive routes — typically defined by URL prefix or regex. When a sensitive path is matched, the processor takes one of three actions:
- Strip the path entirely and replace with a generic value (e.g., “/shop/[redacted-category]/”) so aggregate page-view counts still work without the sensitive content.
- Redact to a parent category (e.g., /shop/anxiety-support/ becomes /shop/) so navigation patterns are preserved without disclosing the leaf.
- Drop the event entirely if the path discloses something the merchant has no lawful basis to log even in aggregate.
The choice of action is a policy decision, not a technical one. What matters is that the decision is made at ingress, on the merchant’s server, before GA4 or any other logging system records the raw path.
Why Browser-Side Filtering Doesn’t Work
The naive fix is to filter paths in GA4 itself — using GA4 admin’s data filters, or modifying the gtag.js implementation to strip the path before sending. Both approaches fail.
GA4 admin filters operate after ingestion. The raw path has already been logged on Google’s servers; the filter only changes what is visible in reports. The Article 9 record exists; it is just hidden from the merchant’s dashboard view.
Modifying gtag.js to strip the path on the client side fails because the merchant’s server has likely already logged the page request before the JavaScript runs. Web server access logs, application logs, CDN logs, and any APM tooling capture the raw path. The browser-side filter only affects the analytics ping — not the surrounding logging surface.
The only architecture that works is server-side filtering at ingress, applied uniformly to every analytics event before any logging system sees the raw path.
How Seresa’s Stack Fits This
Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin sends events from WooCommerce to your Transmute Engine server, which inspects each event — including the page path — against your sensitive-route configuration before forwarding to GA4, Meta CAPI, Google Ads, and BigQuery. Sensitive paths are stripped, redacted, or dropped at the ingress layer, on your own subdomain, before any third-party destination logs them.
Key Takeaways
- The URL is the Article 9 disclosure. A page path that names a sensitive category, paired with any persistent user identifier, creates a special-category record by default — no form submission required.
- Pseudonymisation does not fix it. Replacing the user identifier with a token leaves the page path in the event payload. The disclosure happens at the path level.
- Inferred data counts. ICO treats inferred special-category data the same as explicit data when the inference is processed in a way that relates to the individual.
- DUAA raised the stakes. PECR enforcement now carries the same £17.5 million / 4% global turnover penalty band as UK GDPR. The risk-adjusted cost of inaction went up an order of magnitude on February 5, 2026.
- The fix is server-side filtering at ingress. Inspect the page path against a sensitive-route list before any analytics destination sees the event. Strip, redact, or drop based on policy. Browser-side filters and GA4 admin filters do not solve the problem.
Frequently Asked Questions
If your URL paths or page names disclose the sensitive category — for example /shop/anxiety-support/ or /products/legal-aid-divorce/ — yes. Standard GA4 page_view events log the page path by default, and that path is the disclosure. The data is special-category the moment it is associated with a user identifier.
Per ICO guidance, inferred or guessed data still counts as special-category when used or treated as relating to a special category. A user browsing such a URL is reasonably inferred to have a connection to the sensitive topic. The URL is the disclosure mechanism, even when no form is submitted.
Data that is not directly stated but can be inferred from context — page paths, product categories, browsing patterns, or any signal that suggests a special-category attribute. ICO guidance treats inferred data the same as explicitly disclosed data when it is processed in a way that relates the inference to the individual.
Pseudonymisation replaces the user identifier with a token, but the page path and event payload remain. A pseudonymised user_id paired with a /sensitive-condition/ page view is still a record that an individual visited a sensitive page. The disclosure happens at the path level, not the identifier level.
Server-side filtering at the ingress layer. Before any analytics event is forwarded to GA4 or any other destination, a server-side processor inspects the page path against a list of sensitive routes and either strips the path, redacts to a generic category, or drops the event entirely. The filter runs on the merchant’s own server, before any logging system sees the raw path.
This article is regulatory analysis, not legal advice — speak with a qualified UK data protection lawyer for your specific exposure. Then audit your paths, build the ingress filter, and stop the disclosure before it reaches the log. Start at seresa.io.
