Cookieless pings under denied consent are aggregated, modelled estimates — not user-level data (Google Developers, 2026). That’s the line in Google’s own documentation, and it’s the one most WooCommerce store owners miss. When a UK shopper rejects cookies, your GA4 dashboard probably keeps showing numbers that look normal — because Google fills the gap with modelled traffic, not because your tracking is actually respecting the rejection. Under the UK’s Data (Use and Access) Act, an auditor asking “what did you record when consent was denied” is going to want a different answer than “GA4 still showed traffic”.
Why “GA4 Looks Normal” Isn’t the Same as Consent Compliance
There are two distinct architectures for handling denied consent on a WooCommerce store. Both can satisfy PECR. They produce wildly different audit evidence — and most stores can’t tell you which one they’re running.
The first architecture is Google’s cookieless pings model. When a user denies consent and your tags are wired through Google Consent Mode, the tag does not stop firing. It strips the user identifier and sends a reduced ping containing the timestamp, the page URL, and event metadata to Google’s servers, which use it for aggregate-level modelling. Your GA4 reports keep showing traffic. That traffic is modelled, not measured.
The second architecture is true server-side silence. When consent is denied, no network request fires. Nothing reaches Google. Your reports show a real gap — the size of your consent denial rate — and your audit logs prove the data never left.
Both architectures can be PECR compliant. They are not the same compliance posture, and an auditor can tell them apart in seconds.
How “Denied” Consent Actually Behaves Under Google Consent Mode
This is where most stores get caught. Google Consent Mode’s default state is “denied” — meaning a missing or misconfigured CMP results in modelled-only data flowing to Google by default (Google Developers, 2026). You don’t need a user to actively reject consent for your GA4 to fill with modelled pings. You just need a slow-loading CMP, a misconfigured plugin, or a region detection that fails.
Under PECR, valid consent must be freely given, specific, informed, and involve unambiguous positive action (Information Commissioner’s Office, 2026). Pre-ticked boxes don’t count, and neither does silence. The default-denied behaviour of Consent Mode is technically aligned with this — the absence of consent is treated as denial. The catch is that “denial” still triggers cookieless pings, and most store owners don’t know that.
You may be interested in: The Mike Teasdale 90% Drop: When a Cookie Banner Lies to Google — what happens when the banner says one thing and the tags do another.
Side-by-Side: What Each Architecture Records
Here’s what flows in each case when a single shopper visits a product page and denies consent:
| What flows | Cookieless Pings (Google Consent Mode default) | True Server-Side Silence |
|---|---|---|
| Network request to Google | Yes — a cookieless ping with timestamp, URL, event params, no user ID | None — the request is blocked at the server before sending |
| What appears in GA4 | Modelled traffic, modelled conversions, normal-looking reports | A real gap — reports drop by the size of the denial rate |
| What’s in BigQuery export | Cookieless event rows flagged with consent_state metadata | No rows at all for denied sessions |
| What an auditor sees in network logs | Outbound traffic to google-analytics.com on every denied session |
Zero outbound traffic to Google for denied sessions |
| Compliance evidence value | Modelled data is evidence of measurement — not direct evidence of consent respect | Logs directly evidence non-collection — the strongest possible compliance proof |
Modelled data is evidence of nothing on the user-level question. That’s the framing that matters under the new accountability regime, and it’s where most WooCommerce stores fail their first DUAA-era audit even though their dashboards look fine.
What Auditors Actually Look For Under DUAA
The Data (Use and Access) Act has shifted the ICO from reactive complaint-driven enforcement to proactive systemic oversight (DAC Beachcroft, 2025). The auditor’s first question is no longer “did you have a banner”. It’s “show me what fired and what didn’t, per session, with consent state attached”.
That question lands in three places, in order:
- The CMP audit log. What consent state did the user actually have at the moment of each event? Granted, denied, or default-denied because the CMP didn’t load in time?
- The network request log. What outbound calls did the browser or server make for that session? To which domains? Carrying what payload?
- The raw event store (BigQuery, your data warehouse, your server logs). Does each row include the consent state at the time it was recorded? Can you reconstruct what was collected from a denied session vs a granted one?
None of those questions can be answered from the GA4 reporting view. The GA4 dashboard is the wrong instrument for proving compliance — it’s downstream of the modelling, not upstream of it. Under DUAA accountability rules, organisations must evidence what fired and what didn’t (DAC Beachcroft, 2025), and modelled data is structurally incapable of being that evidence.
You may be interested in: GA4 Predictive Audiences Need 1,000 Buyers in 28 Days — modelled data has thresholds and caveats most stores never check.
The Choice — and Why “I Don’t Know” Is the Wrong Answer
Either architecture can be made PECR compliant. The cookieless-pings model preserves some aggregate measurement at the cost of more complex audit evidence (you have to prove the pings carry no user identifier, and you have to demonstrate the modelled portion of GA4 is clearly distinguishable from the measured portion). The server-side silence model gives you cleaner audit logs but accepts a real reporting gap on denied sessions.
The architecturally wrong answer is not knowing which one you have. A WooCommerce store running an off-the-shelf CMP plugin plus the standard Google tag is almost certainly in the cookieless-pings model — but most owners describe it as “we don’t track when people say no”. Those two statements are not the same. Under DUAA, the gap between what you say and what your network logs show is exactly what the ICO is looking for.
How To Actually Implement Server-Side Silence on WooCommerce
Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com) and only fires events to Google, Meta, BigQuery, or Klaviyo when consent state at the moment of the event is “granted”. When consent is denied, the event reaches the Transmute Engine server, gets logged with the denial state for your audit trail, and stops there — no cookieless ping, no modelled estimate, no outbound network call to Google. That gives you BigQuery rows with explicit consent metadata for granted sessions, audit-log rows proving non-collection for denied sessions, and a network log that matches the compliance posture you actually claim.
Key Takeaways
- Two architectures, both PECR compliant. Cookieless pings (data flows, modelled) and true server-side silence (no data flows). Pick one and know which one you have.
- “Denied” still pings under standard Consent Mode. Default state is denied; cookieless pings still fire. Reports keep looking normal because Google models the gap.
- The audit evidence is in the logs, not the dashboard. CMP audit log, network request log, and raw event export — not GA4 reports.
- Modelled data isn’t compliance evidence. It’s evidence of measurement. Under DUAA, those are not the same thing.
- “My GA4 looks normal” is not a proof point. It’s a sign Consent Mode is working as designed — which says nothing about whether your consent collection actually met the PECR standard.
Frequently Asked Questions
A cookieless ping is a network request that fires to Google when consent is denied, carrying timestamp, page URL, and event metadata but no user identifier. No tracking means the request never fires at all — the server or tag manager blocks it before any data leaves. Both can be PECR compliant, but the audit evidence is completely different: cookieless pings produce modelled data in GA4, while no-tracking produces a real reporting gap and clean compliance logs.
Under standard Consent Mode v2, the denied-consent portion of your GA4 traffic is modelled — Google estimates it from cookieless pings and aggregate signals rather than counting individual users. Genuine user-level data only exists for the consenting share. If your CMP isn’t installed correctly, the default state is denied, so a much larger fraction of your reports may be modelled than you realise.
No. Google Consent Mode is designed to keep showing modelled traffic even when users deny consent — that’s the feature, not a bug. Normal-looking GA4 under denied consent proves modelling is working, not that consent is being respected. PECR and DUAA evidence lives in your CMP audit log, your network request log, and your BigQuery raw export, not in GA4’s report view.
Either can be PECR compliant if implemented correctly. Cookieless pings preserve some aggregate measurement under denied consent at the cost of more complex audit evidence. True server-side silence produces a real reporting gap but gives the cleanest possible compliance proof. The wrong answer is not knowing which architecture you have — that’s the failure mode auditors flag.
Audit your store this week: take a single denied-consent session and trace what fired. If your network log shows outbound traffic to Google, you’re running cookieless pings. If it shows nothing, you’re running server-side silence. Either is defensible — not knowing the answer isn’t. See how Seresa builds audit-grade consent silence on WooCommerce.
