GA4 fills the Landing page dimension from the page where a session started. When it can't find one, it shows (not set). That doesn't mean the visitor arrived from nowhere. It means the session's data didn't include a usable page view.
A little (not set) is normal on almost every property. When it reaches a noticeable share of sessions, or jumps after a change to the site, it's worth tracing, because those sessions also tend to have broken source and key event attribution.
How GA4 decides the landing page.
Every GA4 session has an ID, and every event in it carries that ID. The landing page is taken from the page the session started on, which in practice means its first page view and that page view's page_location.
If the session contains no page view, or its first events carry no page information, there's nothing to use. The landing page becomes (not set).
Google doesn't document every edge case, so the causes below are the ones that most often explain it in practice.
Cause 1: Session timeout followed by a non-page event.
GA4 ends a session after 30 minutes of inactivity by default. If someone leaves a tab open, comes back and scrolls, clicks or watches a video, those events start a new session. No page loaded, so there's no page view, and the new session's landing page is (not set).
The same happens with events that fire when a tab is hidden or closed, such as user_engagement, if they arrive after the timeout.
How to diagnose it: In an exploration, look at which events occur in (not set) sessions. If they're mostly scrolls, clicks, video events and user_engagement, with few page views, timeouts are the likely cause. Long-read content and pages left open in background tabs show it most.
How to fix it: Extending the session timeout (in the data stream's tag settings) reduces it. Some (not set) from real timeouts will always remain, and that's fine.
Cause 2: Measurement Protocol and server-side events.
Events sent from a server with the Measurement Protocol, such as a purchase triggered by a payment webhook, never load a page. If they don't carry a session_id that matches an existing browser session, GA4 may treat them as their own session, and that session has no landing page.
A server-side GTM container can cause the same thing if it sends events that were never tied to a page view, or strips the page parameters on the way through.
How to diagnose it: Check whether (not set) sessions are dominated by purchase, lead or other key events with almost nothing else in the session. That pattern is typical of server-sent events.
How to fix it: When sending a Measurement Protocol event on behalf of a browser user, include their client_id and the session_id captured from the browser. In server-side GTM, check the page location and page referrer are passed through to the GA4 tag. The GA4 revenue reconciliation guide covers server-sent purchases in more detail.
Cause 3: Consent granted after the first page view.
With Consent Mode, the first page usually loads before the visitor has answered the banner. What happens next depends on the setup.
In advanced mode, the page view is sent as a cookieless ping with no client ID. When the visitor accepts, later events carry a client ID and a session ID. Most often the page view isn't sent again, so the identified session begins with a click, scroll or other event, and its landing page can show (not set).
In basic mode, a badly ordered setup can do the same: tags waiting for consent fire their events on the consent update, while the page view never fires because its trigger has already passed.
How to diagnose it: Compare (not set) sessions with your consent rate over time. A rise that starts with a new banner or a Consent Mode change is a strong sign. Test by clearing cookies, accepting on the first page and watching DebugView for a page view after consent.
How to fix it: Make sure the page view fires after consent is granted on the page where the visitor accepted, and that no event tags fire ahead of it. The GA4 and UK GDPR guide covers how consent should gate the tags.
Cause 4: Events firing before the page view.
In GTM, an event tag can fire before the tag that sends the page view: a click listener on page load, a data layer push from the site's own code, or a consent update event. If that happens at the start of a session, the first event has no page view ahead of it.
How to diagnose it: Use GTM Preview and step through the first few events of a new session. The page view should be the first GA4 hit. If it isn't, the order is wrong.
How to fix it: Fire the Google tag, which sends the page view, on GTM's Initialization trigger, and keep the consent banner itself on Consent Initialization. Trigger event tags no earlier than the page view.
Cause 5: Single page applications.
Sites built with React, Vue, Next.js and similar frameworks don't reload the page between screens. If virtual page views are sent from history changes but the first real page view is suppressed or sent late, sessions can begin without one.
Enhanced measurement's history-based page views also fire on some URL changes that aren't new pages, which can confuse the picture further.
How to diagnose it: Check (not set) by hostname or page template. If it's concentrated on the app part of the site, this is the likely cause.
How to fix it: Send one page view on the initial load and one on each route change, with the correct page_location, and switch off the overlapping history setting in enhanced measurement if you send your own.
Cause 6: Other data in the property.
Some data never had a web page to begin with. App data streams report screens, not pages, so app sessions in a combined property show (not set) as the landing page. Data imported or sent from other systems (offline events, CRM uploads, events sent from Google Ads or other tools through the Measurement Protocol) usually has no page either.
How to diagnose it: Add Stream name and Platform to your exploration. If the (not set) sessions come from an app stream, or from a source you know imports data, the landing page is simply not applicable.
How to diagnose it in an exploration.
Go to Explore and start a free-form exploration. Then:
- Add Landing page + query string as a row dimension, with Sessions and Key events as metrics. Filter to
(not set). - Break it down by Session source / medium. Heavy (direct) / (none) or Unassigned in these sessions points to timeouts or server events.
- Swap in Event name. This shows which events happen in (not set) sessions, not strictly the first one, but the mix is usually enough to see the pattern.
- Add Device category, Browser, Stream name and Platform to rule out app data and browser-specific problems.
- Plot it by Date. A sudden step usually lines up with a release, a GTM publish or a consent banner change.
If you export GA4 to BigQuery, you can find the exact first event in each session by ordering events within each ga_session_id. That removes the guesswork.
What's normal and what isn't.
There's no fixed threshold. As a working judgement, a small, stable share of (not set) sessions made up mostly of engagement events is normal timeout behaviour. A large share, a sudden rise, or (not set) sessions carrying lots of key events usually means one of the tagging faults above.
The key event case matters most, because those sessions also tend to lose their source, which feeds straight into unassigned traffic.
If you'd rather have it checked, the GA4 mini audit covers tag order, consent and session attribution, and shows where your (not set) sessions come from.