What Does '(not set)' Mean in GA4 (and How to Fix It)

Few things in GA4 cause more quiet frustration than opening a report and finding that one of the biggest rows is "(not set)". It is not an error message. It is GA4's way of saying it recorded an event but has no value for the dimension that report is built on. The event happened; the label is missing.

The fix depends entirely on which report you are looking at, because (not set) has a different cause in each one. This page goes through the common cases.

(not set) as a landing page

The landing page dimension is filled from the first page_view event in a session. If a session starts without one, the landing page stays empty and the report prints (not set).

That happens more often than you might expect. If a custom event fires before the page_view, GA4 can open the session on that event and never get a landing page. It also happens when a session times out: GA4 closes a session after 30 minutes of inactivity by default, and if the visitor then scrolls or clicks without loading a new page, a fresh session begins with no page_view in it. Single-page apps are especially prone to this, because a long visit on one URL can span several GA4 sessions while only ever sending one page_view.

To reduce it, make sure the GA4 configuration tag fires before any event tags, check that page_view is not accidentally blocked by consent settings while other events go through, and consider lengthening the session timeout in the property settings if your content holds people on one page for a long time.

(not set) in source / medium and campaign reports

Traffic source dimensions come from the referrer and from UTM parameters captured when the session starts. When GA4 stitches events into a session but cannot recover that attribution, you get (not set) instead.

Typical causes are the same session-restart behavior described above, manual tagging mistakes such as a typo in utm_source, and Google Ads traffic in a property that is not linked to the Ads account, so the auto-tagging click ID arrives but cannot be resolved into campaign names. Events sent through the Measurement Protocol also carry no traffic source of their own, and if they cannot be joined to a normal session they surface as (not set).

The checklist here is short: link Google Ads if you run it, keep auto-tagging on, spell UTM parameters correctly and always in lowercase, and avoid sending server-side events with session IDs that never existed in the browser.

(not set) in content group and custom dimension reports

This one is usually the simplest. Content group is empty unless you actively send a content_group parameter with your page_view events, so every untagged page reports (not set). The same applies to any custom dimension: pages or events that fire without the registered parameter fall into the (not set) bucket.

If you only recently added the parameter, remember that GA4 is not retroactive. Historical events keep their empty value forever, so the (not set) share only shrinks going forward.

The scope mismatch quirk

Sometimes (not set) appears in explorations even when your tagging is clean. GA4 dimensions and metrics have scopes, meaning user, session, or event level, and combining a dimension from one scope with a metric from another can produce rows GA4 cannot attribute. A user-scoped dimension crossed with event counts is a classic example. The data underneath is fine; the combination is the problem. Rebuilding the exploration with dimensions and metrics of matching scope usually makes the phantom row disappear.

How to investigate a spike

When (not set) suddenly grows, work backwards from the date. Compare the report week over week and find the day the share jumped. Then ask what changed: a consent banner update that delays page_view, a new tag manager container version, a migration to a single-page app framework, a new email campaign with hand-typed UTMs. In most cases the spike maps cleanly to one deployment.

It also helps to segment the (not set) rows by device, country, and hostname. If the missing values cluster on one subdomain or one app platform, you have found where the tagging gap lives.

Why this doesn't happen in Analyse

Most (not set) rows exist because GA4 assembles sessions from loose events and hopes the labels arrive in the right order. Analyse takes a simpler path: every pageview is recorded on the server with its URL, referrer, and UTM parameters attached at that moment, so a visit always has a landing page and a source. There is no session-restart edge case and no scope system to trip over. Reports in Analyse's website analytics show real page paths and real sources, and when a value genuinely is unknown, such as a visitor with no referrer, it is labeled as direct rather than hidden behind a placeholder. The GA4 comparison covers the other differences.