Why your GA4 traffic shows as Unassigned after adding a cookie banner

Unassigned is not missing traffic. It is traffic GA4 did receive and could not attribute to any channel. After a banner goes live you usually get it for one of three reasons: consent arrives partway through a visit so the original source is already gone, the session never recorded a session_start, or a server side setup is putting an identity back on pings that were meant to stay anonymous.

Unassigned means collected, not lost

A visitor who never consents, on a site that gates its tags properly, produces no events at all. That shows up as a lower session total, not as a row in the Unassigned bucket. Unassigned appears when GA4 does hold events for a session and cannot map them onto any channel definition: no campaign parameters, no usable referrer, or no session start to hang a source on.

So the reassurance on most consent vendor help pages, that Unassigned proves the banner is doing its job, holds for the first shape below and not for the other two. In those, something is being collected in a form GA4 cannot use, and that is worth fixing rather than accepting.

expectedpartly avoidablea fault to fix

Shape one: consent arrives partway through the visit

Someone lands from an ad or a search result, the banner appears, and analytics_storage stays denied while they read. Nothing that could carry the source is stored anywhere. On the third page they accept. GA4 starts collecting properly from that moment, but the page it starts on is an internal one: the referrer is your own domain and the campaign parameters are two navigations behind. The channel rules have nothing to read, so the session lands in Unassigned.

This shape is genuine and partly unavoidable. It is also the one you can narrow. With URL passthrough switched on, Google's ad click identifiers ride the query string from page to page while cookies are denied, so a visitor who accepts late still arrives with something attributable. Whether that option is even available to you depends on which Consent Mode your site is actually running.

Shape two: the session never recorded its start

Channel assignment hangs off the first event of a session. If the configuration tag and the event tags are gated differently, or the consent default is set after the Google tag has already fired, you end up with sessions whose first collected event is something else entirely: a form submit, a scroll, a purchase.

The tell is Unassigned sessions that contain conversions. Real activity, no origin. That is a wiring fault rather than a privacy outcome, and it belongs to the same family as the sudden drops we wrote about in why your GA4 conversions dropped overnight.

Shape three: the denied pings are given an identity

This is the one nobody writes about, and it is the fastest to flood a property. In a server side Google Tag Manager setup, the GA4 client can manage its own cookies. Left on the server managed setting, the container writes a first party identifier and stamps it onto incoming requests, including the cookieless pings that were sent precisely because consent was denied.

Those pings now arrive carrying a stable identifier. Instead of feeding the modelling that denied traffic is meant to feed, they get counted as sessions. They hold no campaign data, because nothing was permitted to store any, so all of them land in Unassigned. The share tracks your rejection rate, and it appears within days of the banner going live, which is exactly why the banner takes the blame.

We found this on a live consent rebuild after weeks of the client's Unassigned bucket climbing with no explanation. The fix was one setting: switch the GA4 client's cookie management to JavaScript managed, so a denied ping stays anonymous the whole way through.

How to tell which one you have

1. Compare the shape, not the total

   Check whether Unassigned grew, or whether your totals simply fell while the channel mix held steady. A smaller number with the same mix is consent working as designed. A new bucket that was not there last month is a wiring question.

2. Look for conversions inside Unassigned

   Build an exploration on session source and medium and put your key events next to it. A late acceptance produces quiet sessions; whole conversions with no origin point at shapes two and three instead.

3. Read the consent state on a live hit

   Deny everything, open the network panel and find the request to the collection endpoint. The gcs parameter names the state, and G100 means both storage types denied. Now check whether that same request carries a client identifier. A denied ping with an id attached is shape three.

4. Open the GA4 client in your server container

   If you run server side tagging, look at the client's cookie management setting. Server managed means the container is minting identifiers of its own, whatever the consent state said on the way in.

5. Check when the consent default fires

   The default state has to be set before the Google tag runs, on every page including the first one of the visit. Anything later and the opening hit of the session leaves in a state nobody chose.

What you can actually recover

Part of this is the honest price of consent and will not go away. 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 and server side tagging are wired properly. 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.

One thing worth stating plainly, because the vendor pages imply otherwise: modelling does not empty the Unassigned bucket. It fills gaps in the standard reports for traffic you never collected. It does not put a source on a session that arrived without one. If you want the wider picture of what survives a rejection, we covered it in what happens to your GA4 data when users reject cookies.

The short version

Unassigned after a banner is three different problems wearing one label. The first is the real cost of a late acceptance and shrinks with URL passthrough. The second is a tag ordering fault and shows itself through conversions with no origin. The third is a server side setting quietly undoing the denial it was built to respect. Check the wiring before you accept the reassurance.

Velo sends the consent signal in the shape Google expects and shows you what each state is actually transmitting, so a fault like the third one is visible on day one rather than after a month of Unassigned. The mechanism is on the product page.

Common questions