Why GA4 Shows '(not set)' in Source/Medium and How to Fix It

What (not set) Actually Means

In GA4, (not set) is not the same as “direct / (none).” Direct means GA4 received the hit and determined there was no referrer or campaign parameter - the user typed the URL, used a bookmark, or came from a source GA4 couldn’t detect. (not set) means GA4 received the hit but couldn’t classify it at all.

The distinction matters because (not set) indicates a data collection problem, while direct/(none) is an expected classification. Treating them as interchangeable leads to misdiagnosis.

Where It Appears

(not set) can show up in multiple dimensions: session source, session medium, session campaign, first user source, and more. The location gives you a diagnostic clue. If it appears in session source/medium but not in first user source, the issue is session-level - probably consent or referral exclusion. If it appears in both, the problem is at the data collection layer.

The 6 Most Common Causes

1. UTM Parameter Stripping

Social media platforms are the worst offenders. Meta’s in-app browser, TikTok’s webview, and LinkedIn’s mobile app all modify outbound URLs in ways that can strip or corrupt UTM parameters. Even when UTMs survive the initial click, JavaScript redirects in your own marketing stack (link shorteners, redirect services, landing page tools) can drop them.

Test every ad platform by clicking through your own ads on mobile devices. Check that UTM parameters arrive intact in the browser’s address bar on the landing page. You’ll often find that UTMs work on desktop but break on mobile - which is where the majority of social ad traffic lands.

2. Consent Mode Blocking

When a user denies analytics consent, Consent Mode v2 prevents GA4 from setting the cookies it needs to determine traffic source. The page_view event still fires (as a cookieless ping), but without the _ga cookie, GA4 can’t associate the session with any source data. The result: (not set).

In regions with consent rates below 50%, Consent Mode alone can push your (not set) traffic above 30% - and there’s no GA4 configuration that fixes this without compromising privacy compliance.

3. Referral Exclusions Misconfigured

GA4’s referral exclusion list tells the platform to ignore referrals from specific domains - typically your own domain, payment gateways, and SSO providers. If you’ve added a domain that actually sends you real traffic (a common mistake with multi-domain setups), those visits lose their source and show as (not set).

4. iOS and Safari Privacy Features

Safari’s Intelligent Tracking Prevention (ITP) caps first-party cookie lifetimes at 7 days (or 24 hours for cookies set via JavaScript with tracking query parameters). This means returning users from Safari frequently lose their original source attribution. iOS Private Relay, available to iCloud+ subscribers, also masks referrer information for some traffic. Check your first-party data strategy to mitigate these effects.

5. GTM Misconfiguration

If your GA4 configuration tag in Google Tag Manager fires before the page URL is fully resolved - or if it fires on a virtual pageview without passing through the original URL - the source/medium data gets lost. This is especially common when using single-page application (SPA) routing or custom history change triggers.

6. Dark Traffic and App-to-Web Transitions

Traffic from native apps (email clients, messaging apps, news readers) often arrives without referrer headers, a problem closely related to cross-domain tracking challenges. iOS Mail, Slack, and WhatsApp all have different behaviors - some pass referrers, some don’t, and the behavior can change with OS updates. Without UTM parameters, this traffic falls into (not set) or direct.

Systematic Diagnosis Process

Rather than guessing at the cause, work through this diagnostic sequence. Each step either confirms or eliminates a potential root cause.

Step 1: Quantify the Problem

In GA4, go to Reports > Acquisition > Traffic Acquisition. Add a secondary dimension of “Device category” and filter for (not set) sessions. If (not set) is overwhelmingly mobile, UTM stripping and iOS privacy are your likely culprits. If it’s split across devices, look at consent and GTM issues.

Step 2: Check the Time Pattern

Did (not set) spike on a specific date? Compare that date against your GTM publish history, consent banner changes, and any site deployments. A sudden increase in (not set) traffic almost always correlates with a specific configuration change - gradual increases suggest privacy feature rollouts or organic traffic shifts.

Step 3: Use DebugView

Enable GA4 DebugView and visit your site through different channels - search, social, email, direct. Check whether the page_view events carry the expected source/medium parameters. If they don’t, the problem is upstream of GA4 (UTM stripping or referrer loss). If they do but reports still show (not set), the problem is in GA4’s processing layer (attribution settings or data thresholds).

Step 4: Examine Server Logs

If you have access to server-side logs, compare the referrer headers and URL query strings against what GA4 reports. This is the definitive way to determine whether data is being lost before it reaches GA4 (browser-level stripping) or after (GA4 processing issues).

Prevention Checklist

Once you’ve diagnosed and fixed the current issue, put these safeguards in place to prevent (not set) from creeping back.

• UTM validation script. Add a JavaScript snippet to your landing pages that logs when UTM parameters are present in the referrer but absent in the landing URL. This catches stripping in real time.
• Monthly UTM audit. Pull your top 20 campaigns by spend and verify that each has properly formatted UTM parameters arriving on the landing page across desktop, iOS, and Android.
• Referral exclusion review. Quarterly, review your GA4 referral exclusion list against your actual domain architecture. Remove any domains that send legitimate traffic.
• Consent rate monitoring. Track your consent acceptance rate weekly. If it drops below 60%, your (not set) percentage will climb - consider server-side tracking or a population-based analytics approach.
• GTM version control. Use GTM’s built-in versioning to tag every publish with a description. When (not set) spikes, you can quickly correlate it with container changes.
• Cross-browser testing. Test your tracking in Safari, Chrome, Firefox, and at least one in-app browser (Meta, LinkedIn) every time you change your analytics setup.

For teams that want to eliminate (not set) entirely, the answer isn’t better GA4 configuration - it’s moving to an analytics approach that doesn’t depend on third-party cookies or client-side consent for attribution. Tools like KISSmetrics reports tie every event to an identified user, making source attribution a solved problem.

Frequently Asked Questions

What does (not set) in GA4 source/medium actually mean, and how do I fix it?

(not set) means GA4 received the event but could not determine where the user came from. Unlike “direct / (none),” which is an expected classification, (not set) indicates a data collection failure. The most common fix depends on the root cause: validate that UTM parameters survive your redirect chains, review your referral exclusion list for over-broad entries, and check whether consent mode is preventing source attribution for users who decline cookies.

Why is direct traffic spiking in GA4 when I know users are coming from campaigns?

A spike in direct traffic usually means GA4 is losing attribution data somewhere in the user journey. The most common causes are UTM parameter stripping by in-app browsers (Meta, TikTok, LinkedIn), iOS Safari’s Intelligent Tracking Prevention capping cookie lifetimes, and dark traffic from email clients and messaging apps that do not pass referrer headers. Compare your GA4 data against server logs to quantify how much attributed traffic GA4 is misclassifying as direct.

Key Takeaways

(not set) is a solvable problem, but it requires systematic diagnosis rather than guesswork. Here’s what to remember.