You added the consent banner, watched 30-60% of EU visitors click "reject," and now your GA4 reports describe a fraction of your actual traffic. So you searched for cookieless tracking in GA4, and you found a swamp of half-answers.
Here is the honest version up front. GA4 has no cookieless measurement mode. What it has is consent mode: a mechanism that sends anonymous pings for visitors who decline cookies and then statistically models what those visitors probably did. That is genuinely better than losing them entirely, and this guide shows the exact setup. But you should know before you start that you are configuring an estimate, not recovering the data. The last section covers what to do when the estimate is not enough.
What "cookieless GA4" actually means#
When a visitor declines analytics cookies, standard GA4 simply stops. No cookie, no client ID, no events. That visitor does not exist in your reports.
With consent mode v2 configured, GA4 does something smarter: it sends cookieless pings. These are anonymous, stateless requests that carry no client ID and set nothing on the device. Google's servers receive them, discard any way to link them into sessions, and later use them as raw material for behavioral modeling: a machine-learning estimate of how declining visitors behaved, extrapolated from the visitors who accepted.
The result in your reports is a blend. Consented visitors are measured. Declining visitors are modeled. GA4 does not flag which rows are which.
Step 1: Set consent defaults before the GA4 tag loads#
Consent mode only works if the default state is declared before any Google tag fires. If you load gtag.js first and set consent after, the first hit already tried to set cookies and you have a compliance problem, not a configuration.
Place this above your GA4 snippet, as the first script in <head>:
<script>
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag("consent", "default", {
analytics_storage: "denied",
ad_storage: "denied",
ad_user_data: "denied",
ad_personalization: "denied",
wait_for_update: 500
});
</script>
The four keys are the consent mode v2 set. analytics_storage governs the GA4 _ga cookies. The three ad_* keys became mandatory in March 2024 for anyone using Google's advertising features in the EEA; set them even if you only use analytics, because Google treats an absent signal as a red flag, not as a denial.
wait_for_update gives your consent platform half a second to answer before pings fire with the default state.
Step 2: Wire your consent banner to update the state#
When the visitor makes a choice, push the update:
<script>
function onConsentAccepted() {
gtag("consent", "update", {
analytics_storage: "granted"
});
}
</script>
Every major consent platform (Cookiebot, OneTrust, Usercentrics, CookieYes) has a built-in Google consent mode integration that does this push for you. Turn it on there rather than hand-wiring callbacks; the platforms also handle the regional logic, like defaulting to granted outside the EEA:
<script>
gtag("consent", "default", {
analytics_storage: "denied",
region: ["EEA", "GB", "CH"]
});
gtag("consent", "default", {
analytics_storage: "granted"
});
</script>
Region-scoped defaults let you keep full measurement where no banner is legally required and restrict only where it is.
Step 3: The same setup in Google Tag Manager#
If your GA4 runs through GTM, do not mix inline gtag consent calls with GTM tags. Instead:
- In GTM, open Admin, then Container Settings, and check Enable consent overview.
- Add a consent mode template from the Community Template Gallery (your consent platform almost certainly publishes one) and set it to fire on the Consent Initialization trigger. This trigger exists specifically to run before all other tags.
- On your GA4 tag, open Advanced Settings, then Consent Settings, and confirm it requires
analytics_storage. GA4 tags handle this automatically through built-in consent checks; you do not need blocking triggers. - Preview, decline the banner, and confirm the GA4 tag still fires but the hit contains
gcs=G100(denied) rather thangcs=G111(granted).
That gcs parameter in the network request is your ground truth. G1 followed by two digits encodes ad and analytics consent; if you decline the banner and see no request at all, consent mode is not active and GA4 has silently dropped the visitor.
Step 4: Verify the pings are flowing#
Three checks, two minutes:
- Network tab: decline the banner, browse a few pages, and filter requests to
google-analytics.com/g/collect. You should see requests withgcs=G100and nocidpersistence between page loads. - No cookies: confirm no
_gaor_ga_*cookie exists after declining. If one appears, some other tag is setting it; hunt it down, because a single stray cookie defeats the entire legal point. - GA4 DebugView: consented sessions appear normally. Declined sessions do not appear individually anywhere, which is expected. You are looking for the absence of errors, not the presence of data.
Step 5: Wait for behavioral modeling to activate, or not#
This is the step nobody warns you about. Modeling is not a switch; it is an eligibility gate, and Google holds the key. Your property must sustain, at minimum:
- 1,000 events per day with
analytics_storagedenied, for at least 7 days - 1,000 daily users sending events with consent granted, for at least 7 of the prior 28 days
Check your status under Admin, then Reporting Identity: if "Blended" is offered, modeling is active. If your property never crosses the thresholds, GA4 quietly reports consented traffic only, forever, and nothing in the interface tells you the rest is missing.
For a mid-sized site, 1,000 denied events per day means very roughly 10,000+ EU sessions per month before declining visitors are estimated at all. Smaller properties get nothing from this entire setup except legal correctness.
What modeling does to your numbers#
Assume you cross the thresholds and modeling activates. Here is what changes in practice:
Your totals become estimates you cannot audit. Users, sessions, and conversions in standard reports now include modeled visitors. There is no per-row flag, no confidence interval, and no way to inspect a modeled session, because it never existed as a session. When a stakeholder asks why conversions moved 12% last week, part of your answer is a model retraining you cannot see.
Anything session-level breaks for declined traffic. Funnels, path exploration, and audience building work on measured sessions. A visitor who declined and then abandoned your checkout contributes a ping, not a journey. The exact drop-off you most want to investigate is in the unmeasured half. We measured how large this blind spot gets in the GA4 traffic gap, and it distorts funnel drop-off analysis in GA4 in ways the reports never disclose.
The banner stays. This surprises people every time: consent mode does not remove the consent banner. GA4 still sets cookies for visitors who accept, so ePrivacy rules still require you to ask. You have done all of this work and the banner, with its measurable conversion cost, is still on your site.
The transfer question is still open. Consent mode addresses cookie consent, not data residency. Pings and measured hits still flow to Google's infrastructure, which is what EU regulators objected to in the first place in the Austrian, French, and Italian rulings. Our GDPR analytics checklist covers where that risk currently stands.
When this setup is the right answer#
Being fair to it: consent mode GA4 is the right call if you are contractually tied to the Google stack, if your media team depends on GA4 audiences and Google Ads conversion modeling, or if you have the traffic for modeling and only need directional aggregate numbers. Modeled totals are strictly better than a 40% hole in your data, and the setup above is the correct, compliant way to get them.
When you actually want measurement, not modeling#
If you searched "cookieless tracking in GA4" because you want to see what all of your visitors do, rather than a modeled guess about the missing ones, no GA4 configuration gets you there. That takes an architecture where no identifier touches the device at all, so there is nothing to consent to and nothing to model.
That is how purpose-built cookieless platforms work, Grain included: sessions are measured server-side from information the browser already sends, nothing is stored on the device, every visitor is captured, and no banner is required for the analytics itself. The difference shows up exactly where consent mode is weakest. Every funnel step is real sessions you can open, including session replays of the visitors who dropped off, and Grain's AI analyst Kai reads those complete sessions to name what broke. In one case it found 700+ form interactions with zero submissions in four minutes, from sessions a consent banner would have hidden.
How the underlying mechanics work is covered in cookieless tracking explained. If you are weighing a full move, the GA4 migration guide walks through events, goals, and history, and the EU-hosted alternatives roundup compares the market. Many teams run both in parallel for two weeks and let the traffic delta make the argument.
The decision in one paragraph#
Set up consent mode v2 if you are staying on GA4; the steps above take under an hour and modeled totals beat missing ones. But be clear-eyed about what you built: a banner that still costs conversions, an eligibility gate your traffic may never clear, and reports that blend measurement with estimation for precisely the visitors you most need to understand. If the goal was seeing every session, the fix is not a GA4 setting.
Measure every visitor instead of modeling the missing ones
Grain is cookieless by design and EU-hosted. No consent banner for analytics, 100% of sessions captured, with funnels, replay, and Kai reading the sessions for you. Start a 14-day free trial, no card required.