Unassigned and not set traffic source in GA4

Unassigned traffic in GA4 can be a confusing issue for many website owners and marketers. Understanding why this happens and how to address it is crucial for accurate data analysis. 

In this article, we'll explore the causes of unassigned and not set traffic and provide practical solutions. By the end, you'll know how to ensure your traffic data is correctly attributed.

Unassigned traffic in GA4 includes sessions or events that don’t align with any Default Channel Group, often due to non-standard UTM parameters or missing attribution data. To resolve this, standardize UTM usage and set up Custom Channel Grouping for better traffic classification. A proper setup ensures more accurate data attribution and reliable tracking.

GA4 determines the particular traffic source of session traffic using two parameters: first, the presence of UTM parameters in the URL at the start of the user session. If these are absent, it checks the referrer to determine the source of traffic to your site. If the referrer is also empty, then the traffic is categorized as Direct.

A growing cause for Direct traffic spikes is traffic from AI browsers like Comet or Atlas. They mimic Chrome but strip referrer headers. You can find more in our guide on how AI browsers impact data tracking.

When UTM parameters are present, Google Analytics 4 uses utm_source and utm_medium to determine which channel group to assign the traffic source to. If you don't have custom channel groups in GA4, the Default channel groups are used. You can find the official list of rules for values in utm_source and utm_medium to determine their respective groups here: https://support.google.com/analytics/answer/9756891?hl=en.

For example, if you use utm_source=facebook&utm_medium=paid in Facebook ads, this source will automatically be categorized as 'Paid Social' according to the standard rules.

However, if you use something custom, such as utm_source=stape&utm_medium=sst, these values don't match any standard rules, so this session will fall into the "Unassigned" category.

1. Ensure that the issue is indeed with non-standard values in the UTM parameters. 

To do this, you can switch your Traffic acquisition report to Session source/medium or add this as an additional column.

2. Check that your source/medium does not have a large number of (not set) values. If everything’s alright, you can see what actual sources and mediums are being used.

3. Go to Google Analytics 4 → Admin → Channel group. Add your new custom channel group that will correctly account for and distribute your UTM parameters into the necessary groups.

We recommend not creating it from scratch (this will take much longer), but copying the Default channel group, renaming it, and adding the necessary source distribution rules.

In Google Analytics 4 (GA4), "(not set)" appears when GA4 lacks data for a specific dimension. This often happens due to tracking misconfigurations in your Google Analytics 4 setup, missing parameters, or unclassified traffic sources. Common causes include improperly set UTM tags, multiple GA4 script initializations, or events firing before the configuration tag loads. Fixing these issues ensures more accurate reporting and attribution.

This is the most common reason for most users. This issue often becomes noticeable after switching to server-side tracking, although you might not have noticed it earlier.

Symptom: Some GA4 events are sent to your server-side GTM container, while others are sent directly to google-analytics.com.

Causes: In Google Tag Manager, you initialize gtag with the server_container_url parameter, but this setting is overwritten by another initialization done in the site code or through a plugin/integration. Since server-side tracking and web tracking in Google Analytics 4 use different cookies to determine the client id (‘_ga’ cookie is used for web events, FPID is used for server events), events sent by the same user through web and server will be considered by GA4 as events from different users, one of whom did not have a session_start event to determine the session source, resulting in such a session being (not set).

How to check this:

Open the network dev tool in your browser, activate the ‘preserve log’ option so you don't lose any events when switching between pages. In the filter, for convenience, specify the measurement id of your GA4 to make it easier to find the necessary requests.

Here is an example of an event that works correctly and is sent to the url of the server container:

And here is an event that is sent directly to GA due to configuration issues:

Check that all your GA4 events are sent to the URL of your server container, not to google-analytics.com.

How to fix this:

• Check the code for inline code with gtag initialisation or events, it usually looks something like this:

If you find gtag scripts in your site code, completely remove them.

• Check if you have any active plugins/integrations that also send data to Google Analytics 4. Disable these functions in them.

Ideally, use a single Google tag with GA4 configured through your GTM container.

This is either because some data layer events fire too early or often due to incorrect tag operation setup relative to consent.

Symptoms and checks are exactly the same as in the first point: some events are sent directly to google-analytics.com. 

Check this in the preview mode of your web GTM container; you can often see a situation like in the example below:

In this example, Google tag with GA4 config uses a consent update trigger to operate when consent state is already known, this event appears quite late in the page.

But before that there is another event in the data layer (view_item in the example above) on which the event tag is fired. Due to the fact that at the moment of triggering the event there is no setting from the config to send data to the url of the server container - this event will be sent directly to the analytics, which will lead to problems in determining the source of sessions for such an event.

If you have similar situations, make sure that your Google Analytics 4 event tags are always triggered later than the Google Tag. 

Using a trigger group can often help to resolve this. For example, to fix a problem like the one above, you can use a trigger group that includes view_item and cookie_consent_update - this will ensure that the GA4 view_item event is always fired after the config.

If you use the measurement protocol to send some events, ensure that client_id and session_id are used in the correct format and with the correct cookies. This way, events sent via the measurement protocol will be associated with the user's session and will have the correct source.

Often, this point is overlooked when switching to GA4 server-side and continues to use the _ga cookie in measurement protocol events.

‘FPID’ cookie is used for server-side tracking to determine client_id. Use the value without its first part.

Example of FPID User ID Cookie:

Format for MP Use:

The ‘_ga_yourMeasurementId’ cookie is used to determine session_id. Use only the part after the second dot.

Example of Session Cookie:

Format for MP Use:

Also make sure you are using the correct decode/encode of the cookie value.

Usually the easiest way to check this is to look in GA4 Explore reports at the cookie values for web events and for server events to make sure everything is correct. 

In case of unexplained problems, additional logging of data to a third-party database and checking it there can always help.

Understanding and correctly configuring GA4 to accurately track and categorize your traffic sources is essential for effective digital analytics. Ensuring that your UTM parameters are properly set, and avoiding the pitfalls of (not set) values in your source/medium reports, will allow you to have clearer insights into where your traffic in Google Analytics is coming from and how it behaves on your site. 

By addressing issues such as additional gtag initialization, timing of event tags, and proper use of session and client IDs, you can improve the accuracy of your analytics data. This will ultimately enable better decision-making and more effective marketing strategies. Taking the time to set up your GA4 correctly ensures you get the most out of your analytics, driving better outcomes for your business.

We hope this article will be helpful for those struggling with unassigned GA4 traffic. By understanding its causes and applying the suggested fixes, you can improve your data accuracy and gain better insights into your website's performance. 

However, it's important to remember that sometimes the issue might resolve itself over time as data collection processes normalize. Patience can often be just as effective as immediate action. Thank you for reading, and we wish you success in managing your traffic in Google Analytics.