Yes, in one specific setup: a visitor who denied consent on a site with Consent Mode v2 wired. GA4 still receives the event, sent as a cookieless ping carrying no identifier, so event counts and modelled conversions survive. What you lose is continuity. Users, sessions, funnels and audiences all need an identifier, and without one nobody can be told apart.
What a cookieless hit still carries
A GA4 cookie is not the thing that sends the data. It is the thing that remembers who sent it. Strip the cookie away and the request still leaves the browser, still reaches Google, still names the page, the referrer and the event. What it no longer carries is the client identifier that lets Google say this hit and that hit came from the same person.
That single missing value is what decides which of your reports survive.
Three different things people mean by this
The question hides three setups that behave nothing alike, and most of the confusion online comes from answering one while the reader is living in another.
A visitor denied consent, and Consent Mode v2 is wired. The GA4 tag still loads and still fires. No _ga cookie is written, no client identifier is attached, and the ping goes out anonymous with the consent state on board. This is the state most sites are actually asking about, and it is the one where the answer is a genuine yes.
Storage is switched off deliberately. Some teams deny analytics_storage for everyone, or use the older pattern of generating a fresh random identifier on every page. The reports fill up, which feels like success, and we will come back to why it is not.
Server side tagging with a first party cookie. This one is not cookieless at all. The cookie is written by your server instead of the browser, which changes its lifetime and who sets it, not whether it exists. We pulled that apart in do you still need a cookie banner with server side tagging.
The trap: making the reports look normal
The pattern worth naming is the second one, because it is still recommended in guides written before Consent Mode existed: fire GA4 with a randomly generated identifier per page view and no storage. Technically it works. Data lands, dashboards populate, nothing looks broken.
What it quietly does is make every hit its own person. Users climbs until it tracks page views almost one to one. Engagement rate collapses because no visit ever has a second event attached to it. Returning customers appear as strangers, every time, and any comparison against last quarter is meaningless because the two periods count different things. A cookieless ping under Consent Mode leaves a visible gap that Google will partly model back. A fake identifier fills the gap with numbers that are wrong, and nothing in the interface tells you so.
There is a second thing dropping the cookie does not do. Consent rules cover storing or reading information on someone's device, and separately cover what you then do with personal data. Going cookieless answers the first half only. It is not a route around asking, and treating it as one is how sites end up with neither compliance nor usable numbers.
How to tell which one you are running
Look for the cookie after a denial
Open your site in a private window, reject everything, then check stored cookies for
_ga. If it is there after a rejection, something in your stack is not honouring the answer, and you are not in the state you think you are.Find the request anyway
With consent still denied, open the network panel and filter for
collect. A request that leaves despite the rejection is not a fault. That is Consent Mode sending the cookieless ping, and it is the mechanism the whole answer rests on.Decode the consent state
On that request, read the
gcsparameter.G100means both storage types denied,G111means both granted. It is the one value that names your state without guesswork, and we walk through the full decode in which Consent Mode your site is actually running.Check the ping for an identifier
A denied ping should carry no client identifier at all. If one is present, something put it back, and the usual culprit is a server container managing its own cookies. That single setting turns anonymous pings into counted sessions.
Compare users against page views
In GA4, put users and page views side by side over the same period. If they move almost one to one, you are not cookieless in the Consent Mode sense. You are minting a new identifier per hit, and your user counts are noise.
What modelling gives back, and what it never does
Google fills part of the gap by modelling: it learns the behaviour of consented visitors and estimates what the anonymous ones did. That is real recovery and it belongs in the answer. The limits belong in it too, and they are rarely stated.
Modelled data lives in the GA4 interface and nowhere else. It is not in the BigQuery export, so your warehouse still sees consented users only and can never be reconciled against the standard reports. It cannot build an audience, populate the user explorer, or feed cohorts and predictive metrics. And modelling switches on only above a traffic threshold Google does not publish, so a smaller property can do everything right and still see the raw gap with nothing filled in. We went through the full picture in what happens to your GA4 data when users reject cookies.
The size of the gap is worth knowing before you decide how much any of this matters. Across Amplio Data client implementations we typically see around 34% of sessions sitting behind the banner, and 20 to 40% of the lost conversions recoverable once Consent Mode v2 is wired the way Google expects. Figures are measured ranges across Amplio Data client implementations, not a guarantee. Recovery depends on your traffic mix, regions and how your tags are configured.
The short version
Google Analytics without cookies collects fine and recognises nothing. Events, parameters and modelled conversions survive; users, sessions, funnels and audiences do not, because every one of them is built on knowing that two hits belong together. The setup worth having is the honest one: a real consent choice, cookieless pings when the answer is no, and Consent Mode v2 wired properly so Google models back what it can.
That is the shape Velo ships by default, which is why the gap in your reports stays a gap you can reason about rather than a number quietly filled with something else. The mechanism is on the product page.
Common questions
Can Google Analytics work without cookies?
Yes, with a real limit attached. Under Consent Mode v2 a denied visitor still triggers a cookieless ping, so GA4 receives the event, the page, the traffic source and the consent state, and can model conversions from it. What it cannot do is recognise anyone. Without an identifier there is nothing to group hits into users or sessions, so anything built on continuity, including funnels, returning visitor reports and audiences, stops working.
What data does GA4 still collect when cookies are denied?
The event itself and its parameters, which covers the page, the event name, the referrer and campaign values present on that hit, plus the consent state carried in the gcs parameter. Google can then estimate conversions from consented behaviour. What is missing is the client identifier, so the hit arrives complete but unattached to any person or prior visit.
Does cookieless tracking mean you do not need a cookie banner?
No. Consent rules cover storing or reading information on a device, and separately cover what you do with personal data afterwards. Removing the cookie addresses the first half only. Whether you need a banner depends on what your site actually uses and the regions your visitors are in, not on whether one particular identifier is stored.
Why do my GA4 user counts look wrong without cookies?
Almost always because something is generating a fresh identifier on every page view instead of sending a genuinely anonymous ping. Every hit becomes its own user, so users climbs toward page views, engagement rate collapses and returning visitors never appear. Compare the two metrics over the same period: if they track each other closely, that is the cause.