Cookieless Tracking in GA4: What's Possible Without Consent

Key Takeaway

GA4 can collect data without cookies via consent mode's cookieless pings, but this data is limited to modeled estimates. Fully cookieless setups sacrifice attribution accuracy and audience building, so the trade-off must be intentional, not accidental.
Intermediate

The phrase 'cookieless tracking' is used loosely enough that it means different things to different people. Some use it to mean tracking without third-party cookies. Others mean tracking that works even when users decline consent. Some mean tracking that requires no cookies at all. The distinctions matter enormously in GA4, because each scenario involves different technical mechanisms, different data accuracy levels, and different legal implications. This article explains what GA4 can and cannot measure without cookies or consent, what data is technically collected from non-consenting users, and the realistic limits of cookieless measurement in 2025 and 2026.

GA4's native cookie architecture

By default, GA4 relies on first-party cookies for identifiers such as client and session continuity. That is different from third-party cookie tracking, but it is still cookie-based measurement. Once a banner is in place, seewhy GA4 traffic drops after a cookie banner launchfor the practical impact on session counts.

For analytics teams, the practical distinction is this: browsers and privacy rules treat third-party cookies, first-party cookies, and no-cookie collection differently. If your team says a setup is cookieless, it should be clear whether that means no third-party cookies, no analytics cookies, or a consent-mode setup that still sends restricted pings.

If your work spans regulated regions, this should sit alongside your widerGDPR and GA4 compliancereview rather than replace it.

What GA4 collects from non-consenting users (advanced consent mode)

When advanced consent mode is implemented and a user denies analytics storage, Google documents that Analytics cookies are not read or written, but restrictedcookieless pingscan still be sent. Those pings are not the same as full cookie-based GA4 events, and they should not be described that way in reporting. The full setup is covered in ourConsent Mode v2 guide.

Collected (cookieless ping)
Not Collected (cookieless ping)
Analytics cookies
Not read or written when analytics_storage is denied
Persistent GA4 cookie-based continuity is unavailable
Request context
Google may still receive limited browser and request information in restricted pings
The event should not be treated as equivalent to a fully identified GA4 session
Consent state
Consent-related parameters are still relevant to tag behavior
Teams should not assume every standard GA4 identifier is available
Export behavior
BigQuery export may still contain cookieless pings and some customer-provided data depending on implementation
Exported rows should not be assumed to represent only consented, cookie-based sessions

These pings can support reporting and modeling behavior, but they should be interpreted carefully. The right comparison is usually between restricted browser collection, exported raw data, and business-system truth, not between two dashboards that happen to use the same label.

Behavioral modeling: what it is and what it is not

GA4'sbehavioral modelingis a machine learning process that estimates the behavior of non-consenting users based on observed behavior from similar consenting users on the same property. It is not a method to track individual non-consenting users, it produces aggregate statistical estimates.

Google documents eligibility prerequisites for behavioral modeling, including minimum consented and denied traffic requirements, but also notes that meeting those visible prerequisites does not guarantee eligibility. If you describe modeled data in a stakeholder report, include that limitation.

Need a faster review of consent-mode behavior, BigQuery export differences, and what your team can actually trust in cookieless reporting?

Alternative identifiers for cookieless attribution

User-ID

If users are logged into your platform, you can sendUser-IDto GA4 for authenticated journeys. Google also documents that when consent mode is implemented, BigQuery export can include customer-provided data such asuser_id. That makes implementation review especially important, because teams should know exactly which fields they are sending in denied-cookie states.

First-party data collection

Form submissions, newsletter signups, and account creation create first-party business records that can be reconciled against GA4. That is often a more reliable audit path than trying to make restricted browser collection answer every attribution question on its own.

Server-side first-party cookies

Server-side tagging can improve control over first-party measurement for consenting users, but it does not remove the need for a consent-aware implementation — seeserver-side consent signals and GA4for what still has to be verified. It should be described as an implementation architecture choice, not as a workaround that eliminates privacy constraints.

Practical cookieless GA4 setup

Implement these steps in sequence. Each builds on the previous, starting with the consent framework, then layering in identity and continuity improvements.

1

Implement advanced consent mode

Enable cookieless pings for non-consenting users by implementing Advanced Consent Mode (not Basic). Set all signals to 'denied' by default and update on explicit user consent via your CMP.

2

Enable user-ID for logged-in users

Send User-ID for authenticated users only when that field is intentionally part of your measurement design and governance model.

3

Configure server-side first-party cookies

If server-side tagging is part of the stack, review what it changes for consenting users and what it does not change for denied-cookie states.

4

Verify behavioral modeling thresholds

Check whether the property is actually eligible for behavioral modeling instead of assuming it based on traffic size alone.

5

Document modeled vs. observed data for stakeholders

Explain where the numbers come from: consented browser data, restricted pings, modeled reporting, raw export, and backend truth should not be treated as interchangeable.

Practical cookieless GA4 setup

  • Advanced Consent Mode implemented (not Basic), enables cookieless pings for non-consenting users
  • All consent signals set to 'denied' by default, updated on explicit user consent
  • User-ID is reviewed intentionally for authenticated journeys rather than assumed to be harmless in all consent states
  • Server-side tagging claims are separated from no-cookie or no-consent claims
  • Behavioral modeling eligibility is checked in the property rather than assumed from traffic volume
  • EEA/UK properties are reviewed with legal and privacy stakeholders rather than relying on analytics copy alone
  • Percentage of modeled vs. observed traffic documented and shared with stakeholders

Check your cookieless measurement setup

GA4 Audits helps surface consent-mode behavior, export differences, and identity-related checks so teams can review cookieless measurement claims more carefully.

Audit findings should be reviewed by a qualified analyst before they are used for major reporting, media, or implementation decisions. Review your findings

GA4 Audits Team

GA4 Audits Team

Analytics Engineering

Specialising in GA4 architecture, consent mode implementation, and multi-layer audit frameworks.

Share