GA4 Unassigned Traffic: Causes and How to Fix It

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London delivering solutions for agency and in-house clients.

A growing Unassigned row in the GA4 traffic acquisition report is one of the faults we get asked about most, usually a week after a campaign launch or a tracking change. We fix GA4 and Google Tag Manager (GTM) setups for agencies and in-house teams most weeks, and this is the order we work through it for clients: what the rules expect, which faults break them, and how to trace the rows back to the link or tag responsible.

What is unassigned traffic in GA4?

GA4 unassigned traffic is the set of sessions whose source and medium match none of the rules in the default channel group. Google’s channel group definitions describe Unassigned as “the value Analytics uses when there are no other channel rules that match the event data”. It is a leftover bucket, not a channel.

Google’s own page on tagging best practices gives two routes into it: a source or medium you defined yourself that has no predefined categorisation rule, and traffic missing session or user identity information. In our audits the first route is the more common one; the second is harder to spot. The two need different fixes, so the first job is working out which one you have.

Unassigned vs direct traffic in GA4: what’s the difference?

Direct traffic and unassigned traffic look alike in a report, but GA4 files them by different rules. The default channel definitions only count a session as Direct when the source exactly matches (direct) and the medium is (not set) or (none). In plain terms, GA4 had no referrer and no campaign data at all.

Unassigned is different: GA4 either had a source and medium that no rule recognised, or it lost the session details it needed to attribute the visit. High Direct traffic usually points at referrers being stripped on the way in, which our guide to GA4 direct traffic running too high covers. High Unassigned usually points at your own campaign tagging or tag setup, which is what the rest of this guide deals with.

Why is traffic showing as unassigned in GA4?

Traffic shows as unassigned for one of five reasons, and in accounts we audit the first two cause most of it. Here they are in the order we check them.

1. The utm_medium matches no channel rule

Every default channel is a rule on source, medium or campaign name. Google lists them on its default channel group page: Email needs the source or medium to be email (or e-mail, e_mail, e mail); Affiliates needs the medium to equal affiliate; Referral needs referral, app or link; Display needs display, banner, expandable, interstitial or cpm. A medium your team invented usually falls through all of them, unless the source happens to be on one of Google’s lists of search, social, video or shopping sites. Google also states the definitions “aren’t case sensitive and can’t be edited”, so Email versus email is not your problem.

Link tagged with	Where GA4 files it	Why
utm_source=mailchimp&utm_medium=newsletter	Unassigned	Neither value matches the Email rule
utm_source=mailchimp&utm_medium=email	Email	Medium matches the Email rule
utm_source=partnerco&utm_medium=affiliates	Unassigned	Affiliates needs medium to equal affiliate, singular
utm_source=poster&utm_medium=qr	Unassigned	No default rule covers print or QR codes
utm_source=facebook&utm_medium=paid-social	Paid Social	A paid medium plus a source on the social list

A paid-looking medium on an unknown source is a special case. Google’s Paid Other rule matches any medium containing “cp” or starting with “paid”, so utm_medium=cpc from a source GA4 has never heard of lands in Paid Other rather than Unassigned. Our guide to Google UTM parameters and how GA4 reads them has the full medium-to-channel mapping.

2. Events fire before the Google tag

Tag order matters because, in Google’s words, “the config command can affect user and session identity for the rest of the page”. Google’s tag ordering guidance says to initialise the Google tag before calling any event, and warns that custom events fired before the config command “will be batched with the session_start event”. The same page notes that a Google tag firing after other events “may cause inaccurate reporting”. In GTM this usually means an event tag on a trigger that fires earlier than the Google tag’s own trigger.

3. Server-sent events carry no session

Events sent from a server through the Measurement Protocol do not come from the visitor’s browser, so the session details travel in the payload or not at all. Google’s Measurement Protocol guide shows session_id sent as an event parameter, and says events meant to join up with gtag.js data should arrive within 48 hours of the original client-side event. When we audit server feeds that land in Unassigned, the session details are nearly always the missing piece: the “missing session or user identity” case from Google’s tagging page. Our Measurement Protocol walkthrough shows how to capture client_id and session_id in the browser and send them with the server event.

4. Identity settings conflict across the site

Google’s tagging best practices page lists three configuration faults that damage session and user identity. It says not to run a server-side and a standalone client-side implementation on the same page for the same property. It asks for one consistent cookie prefix across the site. And it says not to customise the client or session ID. We see the first one most often after a half-finished move to server-side tagging, where the old gtag.js snippet was never removed.

5. The report is reading the wrong scope

Sometimes the data is fine and the report is the issue. GA4 has three scopes of traffic-source dimension, and Google’s scopes page states that for event-scoped dimensions (the ones with no “Session” or “First user” prefix) “the source and medium for non-key events are ‘(not set)’”. A report that breaks every event down by an unprefixed source or channel dimension will show a large empty slice by design. Before chasing a tagging fault, check the report uses a Session-prefixed dimension.

Why did unassigned traffic spike in GA4?

A sudden spike in Unassigned nearly always lines up with a change someone made, so start with the date. Find the day the row jumped, then check what shipped that week. In our experience it is one of three things: a new campaign, email tool or partner sending a medium GA4 does not recognise; a GTM publish that changed tag triggers; or a new server-side or Measurement Protocol feed. A slow, steady rise over months points the other way, towards a tagging habit that has drifted across the team rather than a single release.

How do you find where unassigned traffic comes from?

You find the source of Unassigned traffic by listing the source and medium values behind those rows. Two views get you there, and neither needs anything beyond standard GA4 access.

1. Check the size of the problem. In GA4, select Reports from the left menu, then Acquisition > Traffic acquisition. Google’s traffic acquisition page confirms the report opens on the session default channel grouping, so Unassigned appears as its own row.
2. Build a free-form exploration. Go to Explore and choose the Free form template, as Google’s free-form exploration guide describes. Add Session default channel group, Session source / medium and Session campaign as dimensions, and Sessions as the metric.
3. Filter to the problem rows. Put Session source / medium in Rows and Sessions in Values. Under Filters, add Session default channel group, exactly matches, Unassigned.
4. Read the pattern. Named mediums like newsletter or qr mean cause 1. Rows of (not set) or blank values point at causes 2 to 4. Add Landing page + query string or Device category as a second row dimension to see what the empty rows have in common. If the empty values are on a different dimension from channel, our guide to (not set) in GA4 covers that side.

How do you fix unassigned traffic in GA4?

You fix unassigned traffic at the source: correct the links and tags that produce it, then use a custom channel group for anything you cannot change. Work through these in order.

1. Rename unrecognised mediums. Change each campaign link to a medium the default rules already know. For email, use ?utm_source=mailchimp&utm_medium=email&utm_campaign=september_launch rather than utm_medium=newsletter. For partners, use utm_medium=affiliate, singular. Write the approved medium list down and make every link builder in the team use it; Google’s URL builder page gives the parameter format.
2. Fix the tag order in GTM. Open Tags, find your Google tag, and check its trigger. Google’s GTM setup guide sets it on Initialization - All Initialization Events (or Some Initialization Events). Any GA4 event tag should fire on a later trigger, such as a page view, DOM ready or custom event. Use GTM Preview to confirm the Google tag fires first on the pages that show Unassigned; our GTM debugging guide walks through Preview mode.
3. Pass session details on server events. If you send events through the Measurement Protocol, capture client_id and session_id in the browser and include both, following the Measurement Protocol payload format.
4. Remove duplicate implementations. If a server-side container now sends to your GA4 property, remove the old client-side snippet for that same property from the page, as Google’s tagging best practices advise. Check that every page uses the same cookie prefix.
5. Add a custom channel group for what you cannot rename. QR codes on printed material and links you have already sent cannot be retagged. In GA4, go to Admin, then under Data display select Channel groups, and create a group with a channel for each medium, for example a “Print” channel where medium exactly matches qr. Google’s custom channel groups page says a standard property can create 2 custom groups, that they apply to reports retroactively, and that traffic lands in the first channel it matches in the group’s order. Put your new channels above the catch-all ones.
6. Judge the fix on new data. Renamed mediums and reordered tags only change sessions collected after you publish. Compare the week after the fix with the week before, not the whole year.

What we find when we audit unassigned traffic

Unassigned is rarely one fault. In the accounts we audit it is usually a mix: a few invented mediums from different team members, plus one tag or feed that lost its session details, and the second is the one nobody spots. Tracking faults like these tend to surface when someone reconciles the numbers rather than just presenting them. On one SEO agency engagement, our reporting work caught LinkedIn’s in-app browser stripping tracking tags, which showed up as an 86.6% bounce rate against 47.5% for paid search.

If you want to check what tags a page loads before you start, our free scanner Sonar reads the tags and pixels a site loads from the outside, in one click, with no account access. For the inside of the property, our tracking work covers the full fix. If Unassigned keeps growing and you are not sure which link or tag is behind it, tell us what’s broken, or book a call.