Fix Unassigned Users in GA4 – Diagnosis and Solution

Dec 4

The Case File

Your GA4 acquisition reports reveal a troubling anomaly: users arriving at your site with no source attribution whatsoever. Not (direct) / (none). Not (not set). These are users explicitly marked as "Unassigned"—visitors who triggered tracking events, but GA4 captured zero information about where they came from.

Unassigned users represent a complete failure in first-touch attribution. When GA4 fires the first_visit event for a new user, it should capture first_user_source and first_user_medium parameters. When these remain empty, the user becomes permanently unassigned in your acquisition reports. Unlike temporary data processing delays, this attribution loss is irreversible—you'll never know which marketing channel brought these users to your site.

Industry best practice: Keep unassigned users below 3% of total users. Anything higher signals fundamental tracking failures that corrupt your entire attribution model.

The Root Causes

Unassigned users don't emerge from a single point of failure. They result from specific technical breakdowns in how GA4 captures first-touch attribution data. Here's the comprehensive breakdown:

1. GA4 Configuration Tag Firing Delays

The most common culprit: your GA4 configuration tag fires after critical user interactions have already occurred. GA4 captures first_user_source and first_user_medium during the first_visit event. If this event fires without referrer context, attribution fails permanently.

Common scenarios:

Asynchronous GTM loading: The GTM container loads after users have already interacted with the page, missing the initial referrer information
Consent Management Platform (CMP) blocking: GA4 tags wait for user consent, but by the time consent is granted, the browser has already lost referrer context
Page redirects in SPAs: Single-page applications execute client-side redirects before the GA4 tag initializes, stripping referrer data

2. Cross-Domain Tracking Misconfiguration

When users navigate between your domains (e.g., yoursite.com → checkout.yoursite.com), GA4 must pass the Client ID via the _gl URL parameter. Without proper cross-domain configuration, each domain treats the visitor as a new user—but without referrer information from the previous domain.

The failure point: If you haven't configured Admin > Data Streams > Configure tag settings > Configure your domains, GA4 creates a new session on the second domain. Since the referrer is your own first domain, GA4 should recognize this as internal navigation—but without the _gl parameter linking the Client ID, it treats the user as new without capturing the original source.

3. Measurement Protocol Events Without Session Context

Server-side events sent via the GA4 Measurement Protocol require both client_id and session_id parameters to maintain attribution. When developers send events (e.g., subscription renewals, offline conversions) without including a valid session_id, GA4 cannot link these events to any session with known source/medium data.

Result: These events appear as unassigned traffic because they exist outside any attributed session context. According to Google's official documentation, Measurement Protocol events without proper session linking will show as (not set) / (not set) in source/medium reports.

4. Referrer-Policy Headers Stripping Attribution Data

Your server's HTTP Referrer-Policy header controls what referrer information browsers send to your site. Overly restrictive policies break GA4's ability to capture where users came from.

Problematic configurations:

Referrer-Policy: no-referrer – Completely blocks all referrer information
Referrer-Policy: same-origin – Only sends referrer for same-origin requests, breaking external attribution
Referrer-Policy: strict-origin – Strips path information, reducing attribution granularity

The GA4 impact: When the browser doesn't send referrer information, GA4's first_visit event fires without page_referrer data, making it impossible to determine the traffic source.

5. Single-Page Application Race Conditions

React, Vue, and Angular applications present unique attribution challenges. The initial page load may fire the GA4 tag correctly, but subsequent client-side route changes can create new "first visits" if not properly tracked.

The technical issue: When your SPA's router changes the URL before GTM's History Change trigger fires, or when the data layer updates after the GA4 tag has already read it, attribution parameters get lost. The page_view event fires, but without proper page_location or page_referrer values.

6. Server-Side GTM Claim Rule Failures

Server-side Google Tag Manager must receive and forward referrer information from client-side requests. If your GA4 client in the server container doesn't properly claim and process the Referer HTTP header, attribution data never reaches GA4.

Common misconfiguration: Not all tags in server-side GTM have the server_container_url parameter configured in the client-side GA4 tag. Without this, events route directly to Google instead of through your server container, bypassing your server-side enrichment and potentially losing attribution context.

7. Browser Privacy Features

Safari's Intelligent Tracking Prevention (ITP) and Firefox's Enhanced Tracking Protection don't directly cause unassigned users, but they create conditions that exacerbate attribution loss:

Cookie lifetime restrictions: Safari caps first-party cookies at 7 days, potentially creating "new" users who lose their original attribution
Referrer truncation: Cross-site referrers are downgraded to origin-only (e.g., https://example.com/page becomes just https://example.com)
Third-party context blocking: Any tracking that relies on third-party contexts fails entirely

The "So What?" – Business Impact

Unassigned users aren't a cosmetic reporting issue—they represent systematic destruction of your marketing intelligence:

Attribution Collapse

If 5% of your users are unassigned and you're spending $100,000/month on paid acquisition, you have zero visibility into $5,000 of marketing spend. Your ROAS calculations are fundamentally wrong. You're making budget decisions based on incomplete data, potentially cutting effective channels while scaling ineffective ones.

Audience Segmentation Failure

GA4 audiences built on source/medium dimensions (e.g., "Users from Paid Social," "First-time visitors from Organic Search") completely exclude unassigned users. Your remarketing pools are fragmented, your Lifetime Value analyses are skewed, and your predictive audiences in Google Ads lack critical training data.

Multi-Touch Attribution Breakdown

Every attribution model—data-driven, last-click, first-click—requires accurate first-touch data. Unassigned users corrupt these models because GA4 literally cannot assign credit to any touchpoint. Your attribution reports show inflated "Direct" traffic as GA4 attempts to backfill missing data.

Executive Trust Erosion

When leadership sees a growing "Unassigned" category in acquisition dashboards, confidence in data-driven decision-making collapses. You'll spend more time explaining data quality issues than extracting actionable insights. Budget approvals get delayed while stakeholders question whether any of the data is reliable.

The Investigation – How to Debug

Without an automated GA4 audit tool, here's your manual diagnostic process:

Step 1: Quantify the Problem

Navigate to Reports > Acquisition > User acquisition in GA4
Change the primary dimension to First user source / medium
Look for the row labeled Unassigned (or (not set) / (not set))
Note the user count and calculate the percentage against Total users

Benchmark: If unassigned users exceed 3% of total users, you have a critical tracking issue.

Step 2: Check Temporal Patterns

In the same report, adjust the date range to compare recent vs. historical data
If unassigned users spiked recently: Look for recent changes (GTM updates, site redesigns, new consent banner implementations)
If it's long-standing: You have a systemic configuration problem, not an incident

Step 3: Segment by Platform

Add a secondary dimension: Platform / device category
Check if unassigned users are disproportionately from:

Mobile: Suggests app tracking issues or mobile-specific redirect problems
Desktop Safari: Points to ITP-related attribution loss
All platforms equally: Indicates a universal configuration failure

Step 4: Validate Tag Firing

Open Google Tag Manager Preview Mode on your site
Navigate to your site as a new user (incognito/private browsing)
In the GTM Preview panel, verify:

GA4 Configuration tag fires on Container Loaded (not later)
The first_visit event appears in the GA4 DebugView
page_referrer parameter is populated (if you came from an external site)

Step 5: Test Cross-Domain Tracking

If you have multiple domains:

Navigate from Domain A to Domain B
Check the URL on Domain B—it should contain _gl=<hash> parameter
If missing, your cross-domain configuration is broken

The Solution – How to Fix

Fix 1: Ensure GA4 Configuration Tag Fires First

In Google Tag Manager:

Open your GA4 Configuration tag
Set the trigger to All Pages (or Initialization - All Pages if available)
In Advanced Settings > Tag Sequencing, ensure no tags are set to fire before this tag
Critical for CMP users: Configure your consent mode to fire the GA4 tag immediately upon consent grant, not after subsequent user interactions

Verification: Use GTM Preview Mode to confirm the GA4 config tag appears in the Container Loaded section, before any user interaction events.

Fix 2: Configure Cross-Domain Tracking Properly

In GA4 Admin:

Navigate to Admin > Data Streams > Select your web stream
Click Configure tag settings > Configure your domains
Add all domains users traverse (e.g., yoursite.com, shop.yoursite.com, checkout.external.com)
Click Save

In Google Tag Manager:

Open your GA4 Configuration tag
Scroll to Fields to Set
Add field: linker with value: {"domains":["yoursite.com","shop.yoursite.com"]}
In Configure tag settings, add domains to Ignore Referrals list (these should NOT break sessions)

Verification: Navigate between domains and verify the _gl parameter appears in URLs.

Fix 3: Include Session Context in Measurement Protocol Events

For developers sending server-side events:

When using the GA4 Measurement Protocol, always include:

client_id: Extract from the _ga cookie (format: GA1.1.XXXXXXXXXX.YYYYYYYYYY)
session_id: Extract from the _ga_<measurement_id> cookie

javascriptCopy code

// Example: Extracting session_id from cookie

const gaCookie = document.cookie

.split('; ')

.find(row => row.startsWith('_ga_'))

?.split('=')[1];

const sessionId = gaCookie?.split('.')[2]; // Third segment is session_id

Open in CodePen

In your Measurement Protocol request:

jsonCopy code

{

"client_id": "XXXXXXXXXX.YYYYYYYYYY",

"session_id": "1234567890",

"events": [{

"name": "purchase",

"params": { ... }

}]

}

Fix 4: Audit and Fix Referrer-Policy Headers

Check your current policy:

Open Chrome DevTools > Network tab
Reload your page
Click on the main document request
Look for Referrer-Policy in Response Headers

Recommended configuration:

Use strict-origin-when-cross-origin (browser default, balances privacy and tracking)
Avoid: no-referrer or same-origin (these break external attribution)

If you must use restrictive policies: Implement comprehensive UTM tagging on all external links to your site as a fallback attribution method.

Fix 5: Implement Proper SPA Tracking

For React, Vue, Angular applications:

Method 1: GTM History Change Trigger

In GTM, create a new trigger: Trigger Type = History Change
Set it to fire on All History Changes
Create a GA4 Event tag with Event Name = page_view
Add parameters:

page_location: {{Page URL}}
page_referrer: {{Referrer}}

Set this tag to fire on your History Change trigger

Method 2: Data Layer Push (Preferred)

In your application's router:

javascriptCopy code

// On route change

window.dataLayer = window.dataLayer || [];

window.dataLayer.push({

'event': 'page_view',

'page_location': window.location.href,

'page_referrer': document.referrer,

'page_title': document.title

});

Open in CodePen

Critical: Ensure this push happens after your application updates the page title and URL.

Fix 7: Implement UTM Fallback Strategy

For traffic sources where referrer information is unreliable (email, social media, paid ads):

Standardize UTM parameters across all campaigns:

utm_source: Platform (e.g., facebook, newsletter, google)
utm_medium: Channel type (e.g., social, email, cpc)
utm_campaign: Specific campaign identifier

Use UTM builders and enforce tagging standards across marketing teams. UTM parameters override referrer-based attribution, providing a reliable fallback.

Case Closed

Manually diagnosing unassigned users requires navigating multiple GA4 reports, cross-referencing date ranges, testing tag firing in Preview Mode, and calculating percentages across dimensions—a process consuming 15-20 minutes per property that must be repeated regularly to catch new attribution failures before they corrupt months of data.

The Watson Analytics Detective dashboard identifies this Warning-level issue instantly, displaying both the absolute count of unassigned users and the critical percentage of total users affected. Watson continuously monitors this check alongside 60+ other data quality issues—from PII exposure to eCommerce tracking gaps to referral spam—delivering a comprehensive GA4 audit in seconds, not hours.

Stop investigating data quality issues one report at a time. Let Watson handle the detective work: Explore Watson Analytics Detective

Ali Izadi