A visitor hits your site. The cookie banner appears. They click “Reject All.”
Now what?
Your Google Analytics tag is blocked. Your Meta Pixel goes dark. Your attribution data for that session is gone. And if 40 to 60 percent of your visitors are doing the same thing, you are flying half-blind on campaign performance, audience insights, and conversion tracking.
But here is the part most marketers get wrong: “consent denied” does not always mean “zero data.” The answer depends on which consent mode you are running, which legal framework applies, and whether you are using client-side or server-side architecture.
This guide breaks down exactly what data you can and cannot collect when a visitor denies consent, backed by Google’s own developer documentation, GDPR regulatory guidance, and platform-specific rules that took effect in 2024 and 2025.
Two Legal Frameworks Apply at the Same Time
Before getting into what you can send, you need to understand that two separate legal frameworks govern tracking, and both must be satisfied simultaneously.
The ePrivacy Directive (Article 5(3)) controls what happens on the user’s device. It requires prior consent to store or access any information on a user’s terminal equipment. That includes cookies, local storage, tracking pixels, and even JavaScript that reads device-specific information, such as screen resolution.
The only exceptions are cookies that are “strictly necessary” to transmit a communication or to deliver a service the user explicitly requested.
The GDPR (Article 6) controls what happens with personal data after it is collected. It requires a lawful basis for processing. Consent is one of six lawful bases, alongside contract, legal obligation, vital interests, public task, and legitimate interest.
Here is where most tracking teams get tripped up. Even if you have a valid GDPR lawful basis like legitimate interest, you still need ePrivacy consent to set non-essential cookies or read device information. The European Data Protection Board (EDPB) and national regulators, including the CNIL, ICO, and BfDI, have all reinforced this position:
legitimate interest cannot substitute for ePrivacy consent when it comes to analytics, marketing, or advertising cookies.
This means the ePrivacy Directive acts as the gatekeeper. If you cannot pass the ePrivacy test, your GDPR lawful basis is irrelevant.
Basic vs. Advanced Consent Mode: What Changes
Google Consent Mode v2 became mandatory in March 2024 for any site serving EEA, UK, or Swiss users through Google products. It operates in two modes, and the difference between them is significant.
Basic Consent Mode
When consent is denied in Basic mode, no data whatsoever is sent to Google. Tags are completely blocked from firing. No cookieless pings. No signals. Nothing.
Google can still apply general conversion modeling based on aggregate historical patterns from other advertisers, but the results are far less precise because the model has no site-specific behavioral data to work with.
Advanced Consent Mode
When consent is denied in Advanced mode, tags load on the page but operate in a restricted state. No cookies are written or read. Instead, Google tags send what Google calls “cookieless pings” to Google’s servers.
These pings give Google enough signal to build advertiser-specific behavioral and conversion models, which are more accurate than the general models available through Basic mode.
According to Google’s developer documentation, here is the sequence:
- Default consent states are set (typically all denied for EU visitors)
- While consent is denied, Google tags send cookieless pings
- The user interacts with the consent banner
- Only when the user grants consent do Google tags send full measurement data
What Data Is Inside a Cookieless Ping
This is the question most tracking professionals really want answered. When consent is denied, and Advanced Consent Mode is active, Google’s own documentation and consent mode reference confirm the following data points are transmitted.
Data That IS Sent When Consent Is Denied
Consent state parameters. The denied or granted status for each of the four consent types: ad_storage, analytics_storage, ad_user_data, and ad_personalization.
Timestamp. When the user visited the page.
User agent. The browser type, version, and operating system.
Screen resolution. The device display dimensions.
Referrer. The page the user came from before landing on the current page.
Ad-click information indicator. A boolean flag showing whether the URL contains ad-click parameters like GCLID or DCLID. This is not the full click identifier itself (unless ads_data_redaction is set to false).
IP address. Used only to derive country-level location. Google states that IP addresses are “never logged” by Google Ads and Floodlight systems and are “immediately deleted upon collection.” Google Analytics also does not store or log IP addresses.
Random page-load number. A non-identifying random number generated on each page load.
Consent platform information. The Developer ID of the Consent Management Platform being used.
Temporary identifiers. A client ID and session ID are generated for each page, but critically, these are NOT stored in cookies. They change on every page load, making them non-persistent. Google considers this the mechanism that keeps cookieless pings “anonymous.”
Data That Is NOT Sent When Consent Is Denied
No cookies are read or written. No first-party or third-party cookies of any kind.
No persistent client IDs. Nothing is stored that could link one pageview to another across the session.
No Google Ads cookies. The _gcl_* cookie family cannot be read or written.
No third-party cookie data. Requests are routed through a different domain to prevent previously set third-party cookies from being sent in request headers.
No Google Signals data. Cross-device data is not accumulated for this traffic.
No remarketing or personalization data. When ad_personalization is denied, personalized advertising is completely disabled.
No user-provided data for enhanced conversions. When ad_user_data is denied, hashed emails, phone numbers, and similar identifiers are not transmitted.
With ads_data_redaction Enabled
When ad_storage is denied AND ads_data_redaction is set to true, Google takes an additional step: ad-click identifiers like GCLID and DCLID are fully redacted from consent and conversion pings sent to Google Ads. Only approximate traffic measurement data remains.
This is the strictest configuration available within Advanced Consent Mode.
Is Sending Cookieless Pings Actually Legal?
This is the central question, and the honest answer is that it depends on who you ask. Advanced Consent Mode’s cookieless pings sit in a contested legal space, and the regulatory picture has only gotten murkier through 2024 and 2025.
The Case That Cookieless Pings Are Compliant
No cookies are stored or read from the device. Temporary IDs change on every page, making them non-persistent and unlinkable. IP addresses are not logged and are immediately deleted after country-level geolocation. The data is used exclusively for aggregated modeling, not individual identification. Google classifies these events as “anonymized and non-identifiable.”
The Case That Cookieless Pings Are NOT Compliant
The user said no. This is the fundamental ethical issue. A user who clicks “Reject All” has made a clear choice. Sending any data after that explicit denial raises both ethical and legal questions, regardless of anonymization claims.
Combined data points can constitute personal data. IP addresses, user agents, and screen resolution together can identify or contribute to identifying an individual under GDPR’s broad definition of personal data.
The ePrivacy Directive covers more than cookies. Reading screen resolution from the user’s device is accessing information on terminal equipment, which triggers Article 5(3) consent requirements.
A September 2025 ECJ ruling (Case C-413/23 P) clarified that data must be assessed as personal data based on how it was collected before any anonymization. The anonymization step does not retroactively remove the consent requirement.
Custom dimensions, user_id, or other developer-set fields will still be sent normally even when analytics_storage is denied, which could inadvertently transmit personal data.
Regulatory Positions
DataGuard (German DPA perspective): “Using the advanced version would not be compliant with data protection regulations, as from our perspective, this ping data can represent personal data being processed without consent.”
Simo Ahava (industry expert): “The notion of ‘anonymous data’ with all that gets collected with a consent-denied ping is pretty ludicrous.”
A Swedish DPA ruling on Google Analytics found that IP anonymization alone is insufficient because Google has the ability to re-identify individual visitors by combining collected data with its own records.
The practical takeaway: Basic Consent Mode is the safest legal position for EU/UK operations. Advanced Consent Mode introduces modeling benefits but also introduces regulatory risk that should be evaluated with legal counsel.
What Are Strictly Necessary Cookies and What Can They Collect?
The ePrivacy Directive provides two exemptions from the consent requirement. These are the only categories of cookies that can operate when consent is denied, regardless of jurisdiction.
Cookies Exempt from Consent
Communication transmission cookies. Used solely to carry out the transmission of a communication over an electronic network. A common example is a load-balancing cookie that routes traffic across multiple servers.
Strictly necessary cookies. Required to provide a service the user has explicitly requested. These include:
- Authentication and session login cookies
- Shopping cart persistence
- CSRF tokens and fraud prevention mechanisms
- User preference cookies (language selection, accessibility settings)
- Cookies that record the user’s consent choice itself
- Payment processing security cookies
What Does NOT Qualify as Strictly Necessary
This is where many organizations overreach. The following do NOT meet the strictly necessary exemption:
- Analytics cookies, even first-party ones
- Advertising and marketing cookies
- Social media tracking pixels
- A/B testing cookies (generally require consent, though debated)
- Performance monitoring cookies that track individual user behavior
- Retargeting or cross-site tracking identifiers
One regional exception worth noting: France’s CNIL has extended a limited consent exemption to audience measurement cookies, but only under very specific conditions. The cookies must be first-party only, used solely to produce anonymous aggregate statistics, not shared with any third party, not used for cross-site tracking, and limited to the site owner’s audience measurement. This is a French-specific interpretation and does not apply across the EU.
How the CCPA/CPRA Changes the Rules Entirely
If your audience includes US visitors, particularly those in California, the legal framework operates on a fundamentally different model.
Default Position: Collect First, Opt-Out Later
Under CCPA/CPRA, businesses can collect and process personal information without prior consent as long as they:
- Provide a privacy notice at or before the point of collection
- Offer a “Do Not Sell or Share My Personal Information” link
- Honor opt-out requests, including Global Privacy Control (GPC) signals (mandatory in Colorado since July 2024)
What Changes When a User Opts Out
The CCPA operates on opt-out, not opt-in. Click any row to highlight it.
Key Difference from GDPR
Under CCPA, opting out does not stop data collection entirely. It stops the sale or sharing of that data with third parties. You can still collect first-party analytics, session data, purchase history, and behavioral data for your own internal use. The data minimization principle still applies: collection must be “reasonably necessary and proportionate” for the stated purpose.
Does Server-Side Tracking Change What You Can Send?
Server-side tracking has become the go-to recommendation for recovering data lost to consent denial, ad blockers, and browser restrictions. But it is not a consent bypass, and understanding its actual capabilities and limitations matters.
What Server-Side Tracking Enables
Data filtering before transmission. You can strip, anonymize, or pseudonymize data on your server before it reaches platforms like Google Analytics or Meta. This means you control exactly what each vendor receives.
Aggregated conversion signals. You can send conversion counts (“5 purchases occurred in the last hour”) without any individual-level data attached.
Hashed identifiers. Email addresses and phone numbers can be irreversibly hashed before transmission.
IP truncation. The last octet of IP addresses can be removed before forwarding data to third parties.
Selective parameter forwarding. You choose which data points each downstream vendor receives, rather than letting their client-side scripts collect whatever they want.
What Server-Side Tracking Does NOT Change
ePrivacy consent is still required to set cookies. Moving processing to the server does not change what happens on the user’s device.
Reading device information still triggers Article 5(3). If your server-side implementation reads screen resolution, user agent, or other device-specific data from the client, the ePrivacy consent requirement applies.
Processing data on your server is still “processing” under GDPR. Anonymizing data before sending it to a third party does not retroactively remove the consent requirement for collecting it in the first place. The September 2025 ECJ ruling (Case C-413/23 P) made this explicit.
A Swedish DPA case confirmed that IP anonymization alone is insufficient for Google Analytics, because Google can combine the remaining data points with its own records to re-identify visitors.
The default Google Tag Manager server container records screen resolution automatically, which means it always requires prior consent when processing EU user data.
The Defensible Server-Side Approach for Consent-Denied Traffic
If consent is denied, a legally defensible server-side setup would:
- Not set any cookies or access device storage
- Not read device-specific identifiers like screen resolution
- Process only truly aggregated, non-identifiable event counts
- Not forward any data that could, even indirectly, identify a user
- Document the specific legal basis with a formal Legitimate Interest Assessment
- Maintain audit-ready logs of consent collection, data filtering, and third-party forwarding
This approach preserves high-level operational intelligence (total page views, aggregate conversion counts) while staying within defensible legal boundaries.
How Meta Handles Consent Denial
Unlike Google’s built-in Consent Mode framework, Meta’s consent framework does not have a system-level consent mechanism that automatically switches between full and privacy-preserving operation. Instead, Meta relies almost entirely on the implementer to enforce consent decisions.
When consent is denied:
- Meta Pixel should be blocked entirely or prevented from firing by the Consent Management Platform. There is no equivalent of Google’s cookieless pings, the Pixel either fires with full data or doesn’t fire at all. If the Pixel does load without consent, it will attempt to set cookies (
_fbp,_fbc) and transmit data as normal, making proper CMP gating critical. - Conversions API sends exactly what the implementer includes in the payload. There is no automatic filtering of personal data based on consent status. It is the implementer’s responsibility to strip identifiers such as email, phone,
external_id,fbp,fbc,client_ip_address, andclient_user_agentfrom CAPI payloads when consent has not been granted. - Data Processing Options can be passed in CAPI payloads to signal restricted processing, though this was primarily designed for CCPA/CPRA compliance via Limited Data Use (LDU), not GDPR consent flows.
- Aggregated Event Measurement (AEM) exists as a privacy-preserving measurement framework, but was built to address Apple’s App Tracking Transparency and SKAdNetwork restrictions on iOS; not as a GDPR consent fallback.
This fundamental difference means that for Meta, server-side consent logic becomes far more important than it is for Google. Where Google’s Consent Mode provides a built-in middle ground between full tracking and no tracking, Meta offers no such system-level safety net. The burden falls entirely on the tracking implementation to ensure no personal data is transmitted when consent is denied.
The Modeling Thresholds Most Teams Miss
Advanced Consent Mode’s primary value proposition is behavioral and conversion modeling. Google uses cookieless ping data to model what non-consenting visitors likely did, based on the behavior of consenting visitors on the same site.
But this modeling only activates when your property meets specific minimum thresholds.
GA4 Behavioral Modeling Requirements
- At least 1,000 events per day from users with
analytics_storage='denied'for at least 7 days - At least 1,000 daily users with
analytics_storage='granted'for 7 of the previous 28 days
Google Ads Conversion Modeling Requirements
- At least 700 ad clicks per day consistently over a 7-day period
If you do not hit these thresholds, Advanced Consent Mode provides no modeling benefit over Basic mode. The cookieless pings are still sent, but Google has insufficient data to produce reliable modeled outputs.
This is a critical consideration for small to mid-size sites. If your daily traffic is below these minimums, the legal risk of Advanced Consent Mode may not be justified by any measurable analytical benefit.
Jurisdiction Comparison: What You Can Send by Region
What You Can Send by Region
Toggle between regions to compare. Click any row to highlight it.
What This Means for Your Tracking Architecture
The reality of tracking in 2026 is that there is no single approach that satisfies every jurisdiction while preserving all of your data. The practical path forward involves layering multiple strategies.
For EU/UK traffic: Basic Consent Mode is the safest legal position. If you implement Advanced Consent Mode, do so with legal review and make sure your privacy policy explicitly addresses cookieless pings. Enable ads_data_redaction to minimize exposure.
For US traffic: You have significantly more flexibility. First-party data collection continues after opt-out. Focus your architecture on first-party data strategies and server-side processing that keeps data under your control.
For all traffic: Invest in server-side tracking infrastructure that gives you the ability to filter, anonymize, and control data flows before they reach third-party platforms. Build consent rate optimization into your UX. And document every decision, because the documentation itself is your primary defense in any regulatory inquiry.
The organizations that will win the data game going forward are not the ones trying to find loopholes in consent requirements. They are the ones building tracking architectures that deliver actionable intelligence regardless of how many visitors click “Reject All.”
Related Posts
UTM Parameters to First-Party Cookies: How to Stop Losing Attribution Data
UTM parameters vanish after the landing page. Learn how to preserve attribution…
Server-Side Tagging vs Tracking: Know The Difference
What's the difference? Server-side tagging vs server-side tracking explained,…
How to Track Website Data Without Violating User Privacy in 2026
Learn how privacy-compliant tracking works. Discover how to collect valuable…