Not set in Google Analytics 4. How to fix it?

Updated: July 7th, 2025

If you have been working with Google Analytics 4 for a while, you probably have already noticed a mysterious (not set) appearing in some reports. In this blog post, I will explain what not set in Google Analytics 4 is and what to do with it.

But I want to set the expectations right:

• In some situations, it is possible to fix and remove not set in GA4
• In other situations, it is possible to reduce how often it appears
• And in the rest of the situations, it’s just something we’ll need to accept (until Google changes/updates certain things)

Ready? Let’s go

Table of Contents

Here’s what you will learn in this article

• This is still a developing topic
• What is not set in Google Analytics 4?
• Wait up to 48 hours
• Landing page is (not set)
• Measurement protocol
• Source/Medium is (not set)
• Campaign is (not set)
• Google Ads is (not set)
• Page location is (not set)
• Page title is (not set)
• Content group is (not set)
• Language is (not set)
• Country is (not set)
• Event-scoped and item-scoped dimensions are (not set)
• User-scoped custom dimensions are (not set)
• Technology dimensions are (not set)
• Final words

Video tutorial

If you prefer video content, here’s a tutorial from my Youtube channel.

This is still a developing topic

The more people use GA4, the more we learn about it. About its possibilities and about its drawbacks. (not set) is one of the areas where there are still many unknowns. The article you’re reading now contains the learnings I have found to this day.

But I am sure there are more things to unveil in the future. So if I learn anything new, I will update this article.

If you know anything additional, please share your findings in the comments below the blog post. I might include them in the article too. Sharing is caring!

What is not set in Google Analytics 4?

(not set) appears in the interface if a dimension (that you’re using in the report) does not contain a value. It’s like a placeholder.

For example, if you use GA4 to measure only websites, then app-related dimensions, such as App store, will be (not set). Makes sense, right? But the problem starts when you get (not set) in places it shouldn’t be (or at least not expected). And that’s what I will tackle in this blog post.

First, I will start with several general tips, and after that, I will dive into various situations where not set in Google Analytics 4 appears.

Wait up to 48 hours

Google Analytics 4 needs more time to process data. So if you have configured something today, don’t expect that data to appear sooner than after 24 hours or even 48 hours.

It is helpful to understand why this delay happens. Google Analytics 4 processes a lot of data and needs time to properly attribute every event to its correct source, session, and user. Think of it like a massive digital mailroom sorting countless letters into the right mailboxes. This sorting process does not happen instantly. Giving GA4 up to 48 hours to complete its work is often the simplest “fix” of all, preventing you from trying to solve a problem that isn’t actually broken yet.

So when you see (not set) in GA4 reports, ask yourself this: was X configured/modified in GA4 less than 48 hours ago? If yes, then wait longer. If not, then go ahead and continue reading this article.

Landing page is (not set) in GA4

Session timeout. We had this problem in the previous GA version (Universal Analytics). We have it in GA4, too.

Landing page is (not set) in Google Analytics 4 if a session does not have a page_view event (that tracks the page_location) parameter. No pageview = no landing page. But how can that happen? Your GA4 setup probably tracks pageviews automatically.

It’s still possible. Here’s the scenario:

• You did not modify the default session duration settings in GA4, which means that after 30 minutes of inactivity, your website visitor’s session will expire.
• A visitor opens your website in a browser tab and leaves it open for 30+ minutes (for example, he/she went to grab some lunch)
• The session times out
• The person comes back to the laptop (your website is still opened in the tab) and then does something (e.g., scrolls, initiates a user_engagement event, etc., and that event is tracked by GA4). But the user does NOT go to another page or reload the page
• This starts a new session. But not page_view happened in it.
• Then the visitor closes the browser tab with your website in it

The result? After a timeout, a new session starts with no pageviews. No page_view = no landing page.

What can you do about it? While you cannot eradicate this issue completely, you can reduce its impact to some extent. Extend the default session duration. The default is 30 minutes. Why not change it to 4 hours or even a maximum (7 hours 55 minutes)?

Go to GA4 > Admin > Data Streams > Select web data stream > Configure tag settings > Show all > Adjust session timeout.

Then, change the default session duration to some longer period and click save.

As I said, this will not completely solve your (not set) Landing Page problem (because some sessions will still time out), but it should reduce the scope of the problem over time to some extent.

But it’s important to understand the consequences of this change. If your session duration becomes longer, it means that your Analytics will report fewer sessions, the average session duration will be longer, and other session-related metrics will be affected. If you are ok with this, then change the duration.

Midnight. Another reason for (not set) is when the session is happening. If it starts before midnight (depending on your property’s settings) and continues past midnight, GA4 reports will treat that as two separate sessions.

If the session_start event happens before midnight, then that session’s landing page will be displayed properly. But after the session crosses midnight, GA4 looks at this as a new session (which no longer has the session_start event), and that’s when the (not set) landing page can appear. If you want to learn more about this phenomenon, read this article.

Currently, there is no workaround for this. That’s just how GA4 processes the data.

GA4 event tag fires before the Google Tag (config tag). Be careful with the triggers of your GA4 event tags. If they fire before the Google Tag (e.g., you send a view_item event before Google Tag loads), this can cause issues with the Landing page dimension.

However, if your Google Tag fires first (compared to other GA tags), you should be fine. For example, there is a myth that if a user_engagement fires before the page_view event, it will cause the landing page to be (not set). That is false, and I debunked that myth here.

No page_view. This one is related to a couple of previous tips. In Google Tag, you can enter a parameter called send_page_view. If it’s set to false (and you don’t have a separate page_view event in your setup), this means that no page views will be tracked.

No pageview = landing page is not set.

Measurement protocol

Measurement protocol is one of the ways how you can send data to GA4. It is designed to send data from your server (e.g., CRM) to Google Analytics 4. However, it is designed to enrich the data you have collected on a website. Not initiate new sessions or create new users/visitors.

This means that if a visitor was on your site and started a session, you can send some additional events from the server and attach them to that session. You can do that up to 72 hours in the past. Here’s a tutorial on how to work with it.

However, there’s one nuance. Measurement protocol hits do not reuse what was already tracked by your web tracking code. For example, if a visitor lands on a particular page, GA4 automatically tracks page_location. But if you send an event via Measurement protocol (MP) at that exact moment, the event sent via MP does not inherit neither page_location, nor other parameters/dimensions that were available during the session.

For example, if you don’t send the user agent, those MP events will not inherit things such as device category, browser version, etc. This means that those dimensions will be (not set). The main problem at the moment is that there is no way (at least officially documented) that would allow us to send the user IP address or browser data (user_agent) to GA4 via MP. I will talk more about this a bit later in this article.

So, if your GA4 setup utilizes Measurement Protocol to some extent, it’s very likely that (not set) is caused by it. MP can be the reason for any of the problems I will mention later in this article.

Source/Medium is (not set) in GA4

Another fairly common situation is when you open your Traffic Acquisition reports, switch to Session Source / Medium dimension, and you see (not set) there. As a result, such traffic will be included in the Unassigned session default channel group.

There are several reasons for the not set Session source/medium that I have noticed.

Measurement protocol is not implemented correctly. The developer is sending events to GA4 without including a correct session_id. And if the event is sent to the past (up to 72 hours), then timestamp_micros parameter is not included (or it contains an incorrect value).

session_id parameter must contain a value of a session that was already tracked by GA4 on the website (client-side). If a developer randomly generates the session_id, the source/medium will be (not set).

If the event is sent to the past, the developer must include a valid session_id and it must include the timestamp (with timestamp_micros parameter) of when that session was actually happening on the site.

Watch this tutorial to learn how to implement measurement protocol properly.

Missing session_start event. Traffic-source-related dimensions, e.g., Session source / medium, take it from the session_start event. If that event is missing in the session, you will get a (not set) value. The first reason why this might happen is because of server-side tagging.

You might have a setup where this event is excluded and not sent from your tagging server to GA4.

Unfortunately, I could not identify other reasons why GA4 setups still occasionally miss the session_start event. Usually, it’s a very small percentage of sessions, but that happens.  If I ever find out the reason, I will update this guide.

Even though GA developers published some fixes on November 2nd (2023), this problem still persists.

Audience triggers. When Google Analytics 4 launched this feature, I was excited. It allowed us to create more complex audiences, and when a visitor enters the audience, GA4 will automatically dispatch the event.

But later, I noticed that audience triggers also increase the amount of (not set) traffic sources. This does not always happen, so the results/scope of this issue will vary across different properties.

I noticed that if your audience trigger is related to a predictive audience, then most likely, the event will not be added to any existing session. Thus, the source/medium will be (not set) / (not set).

Sometimes, even regular audience triggers (without the “predictive” part) cause this problem.

Unfortunately, there is no solution for this. Audience triggers are handled in the backend of Google Analytics 4. So if you are using triggers (do not confuse this with Google Tag Manager triggers), then accept the fact that you will get more (not set) traffic sources than usual.

Review your UTM parameters. Typically, if UTM parameters are missing, GA4 would then attribute the traffic source to direct, referral, or something else that is available for it to track. But if UTM parameters are set incorrectly (e.g., their syntax is invalid or they are missing values), there’s a chance that you will get (not set) in your traffic reports.

Unfortunately, I cannot give you more specific tips here because this area would be full of edge cases. Review your UTM parameters, the links that you (and your marketing team shares on various channels), and check if they contain valid values.

You can get familiar with UTM parameters in this tutorial.

Your GA4 event tags in Google Tag Manager fire *before* the main config tag. When you install GA4 in Google Tag Manager, you have to use a “Google Tag”.

If you want to send some additional events to GA4, you have to use the GA4 event tag.

It’s important that your Google Tag (also known as GA4 config tag) fires first, before any other Google Analytics tags.

Commonly, this mistake is seen on ecommerce websites where an event tag for view_item, view_item_list, or purchase fire earlier than the Google Tag. Use GTM preview mode to verify that.

Incorrect server-side GTM implementation. When you migrate GA4 to server-side Google Tag Manager, you have to update all your Google Analytics 4 tags to send data to your server-side end-point.

You can do it by adding a “server_container_url” to all GA4 tags:

This applies to the “Google tag” and “GA4 event tags”. The value of this parameter should be whatever the URL of your tagging server is (e.g., https://measure.mydomain.com). Read more about SGTM here.

If you accidentally leave some Google tags (or Google Analytics 4 event tags) without server_container_url, it will mess with your attribution (because some requests will be sent to measure.mydomain.com while others will be sent to google-analytics.com).

I have also seen some situations where all GA4 tags in GTM were updated with server_container_url properly, but someone accidentally forgot about a hardcoded GTAG in the website’s source code.

While GTM tags were firing properly, the hardcoded GTAG sent data directly to google-analytics.com (or some other GA domain). This must be avoided at all costs.

Campaign is (not set) in GA4

All the above tips (related to source/medium) apply to campaign dimensions, too (e.g., Session campaign). But I just wanted to point out that UTM parameters, utm_medium, and utm_source are required for your traffic acquisition reports to function properly. If you don’t use utm_campaign, that’s fine. However, remember that the Session campaign, First user campaign, and Campaign dimensions will contain more (not set) values because of that.

The same principle applies to other dimensions, such as Session manual ad content, Session manual term, etc.

If, on the other hand, you have linked Google Ads with Google Analytics (and the Session Campaign of Google ads is displayed as (not set) or (organic), then a workaround would be to use both: autotagging and also add UTM parameters to your Google Ads campaigns.

Google Ads is (not set) in GA4

Google Analytics 4 supports a bunch of Google-Ads-related dimensions, e.g., Session Google Ads campaign, Session Google Ads keyword text, etc. If you try to use them, but they are (not set), here are the possible reasons for this (and solutions).

Google Ads account is not linked with Google Analytics 4. GA4 can get data out of Google Ads only it that account is connected with a GA4 property. So make sure you have done it correctly. Read this documentation to learn more. Also, it’s possible that your organization has multiple Google Ads accounts. If at least one of them is not connected (while it sends traffic to your site), you will have (not set).

Auto-tagging is not enabled. Auto-tagging automatically imports Google Ads data into GA. Combining Google Ads data with what you have in Google Analytics allows you to see what happened on your site after people clicked on your ads. It’s highly recommended to have this feature enabled.

Alternatively, you can manually tag your final URLs with tracking variables. But that is cumbersome and prone to errors. If auto-tagging is disabled and you haven’t manually tagged your URLs, you’ll get (not set). If you have manually tagged URLs, but that is done incorrectly, you will also face (not set). Manual tagging is a more advanced feature that goes out of the scope of this blog post. So if you want to learn more, go here.

You have connected multiple Google Ads accounts to GA4, and some have auto-tagging disabled. Google Analytics 4 can get data from Google Ads only if they are connected. If one (or more) accounts are not linked, and a visitor lands on your site from a Google Ads campaign (where the gclid parameter is still in the URL), GA4 cannot retrieve the campaign data. This will result in (not set).

Page location is (not set) in GA4

This was identified recently in the community, and I am not sure if/when Google would fix it. But even if it’s a bug, I will mention this anyway (maybe this will save a couple of gray hairs on your head).

Jules Stuifbergen shared this issue on Linkedin. If URLs on your website are very long and they exceed more than 500 characters (this includes https, query parameters, etc.), then page_location will not be tracked at all (this applies to GA4 reports and BigQuery export).

What can you do here? Technically, you could overwrite the page_location parameter in your GA4 tags (or GTAG) and come up with a shorter option. For example, you could exclude unwanted URL parameters as I do here.

Page title is (not set) in GA4

There are two main reasons for this.

Missing <title> in page’s HTML. If the website is poorly maintained, it’s possible that this reason applies to you. But how can you find out which exact pages are missing the title? Go to Reports > Engagement > Pages and screens and have two dimensions:

• Page title and screen class (or Page title and screen name) as the primary dimension
• And Page Path and Screen class as a secondary dimension

This will help you identify which pages do not have the title. Once you do that, cooperate with a developer of the website to add proper <title> to all those pages.

If you cannot find the report under Reports > Engagement > Pages and Screens, it is probably located somewhere else on the left sidebar. Just keep looking.

GA4 loads before <title>. If Google Analytics 4 tracking code is added at the very top of the page’s HTML and the <title> tag is somewhere lower, then there’s a chance that when GA4 loads, it cannot find the title (because it hasn’t loaded yet (for a brief moment)) and then it becomes (not set) in the reports. This situation is pretty unlikely to happen, but there’s still a theoretical chance, thus, I am mentioning it here.

Content group is (not set) in GA4

Here are the reasons why Content Group is not set in Google Analytics 4:

content_group parameter is not sent to GA4. Even though Google Analytics 4 has a built-in Content group dimension, it will remain (not set) unless you specifically send that data to GA4 (via GTAG or GTM).

Watch this tutorial to learn how to send that data to Google Analytics 4.

You are sending the parameter incorrectly. The parameter that is related to the Content Group dimension is content_group. It must be named exactly like this (and it’s case-sensitive), so Content_group, content_category, etc., will not work.

You are sending content_group as an empty (or another falsy) value. This is possible in several occasions. Maybe you are using a DOM element variable to scrape content group from the website. If your GA4 config tag fires before the content group element is rendered, the content_group’s value will not be properly sent to GA4.

Another example is related to the Data Layer. If you fire a GA4 config tag before content_group is pushed to the Data Layer, you will send undefined value to GA4. Hence, the (not set) will start appearing in the reports.

Or maybe some pages don’t have the content_group in the data layer at all. In that case, consult with your developer.

Language is (not set) in GA4

Google Analytics fills in the Language dimension based on your browser settings. Based on what I have seen, in most properties, the percentage of (not set) Language dimension is very small, so you should not worry too much about it.

However, the most usual reasons for that are:

• The event is sent via Measurement Protocol. You have to send a language parameter with all events.
• The visitor has some browser settings/extensions that hide/modify the language parameter, and GA4 cannot retrieve it.
• You’re using server-side tagging and that setup removes the ul parameter (User Language) from the request.
  

Country is (not set) in GA4

This applies to all geography-related dimensions, e.g., City. Here are the most common reasons you are seeing (not set) in your demographics data (related to geography).

The event is sent via Measurement Protocol. Here’s what I have learned so far. In Measurement Protocol, there is no way to send/override the user IP address or user agent. This means the location or browser data is unavailable for events sent via Measurement Protocol. If you have different findings, please share them in the comments.

For example, I did the test where the events were correctly attributed to the existing GA4 session (and the traffic source was displayed correctly), but browser data was (not set). The same applied to dimensions such as “Country”.

I also found this conversation where people from Google say that MP does not support overriding of the user agent or IP address, which is a shame and still limits MP to just very basic use cases. However, keep an eye on that thread. Maybe eventually, Google will change this. But, currently, event GA4 MP documentation does not say anything about the IP address or user agent.

IP anonymization is enabled in GA4 by default (which means that the last number of the IP address will be changed to zero. This reduces the accuracy of how GA4 can identify the user location. In most cases, GA can still identify the country but more specific regions (like cities) might be (not set).

Server-side tagging (SGTM) is removing or overwriting the IP address. SGTM can be used to completely remove the user IP address or to modify it into some other value (like 0.0.0.0)

VPNs, proxies, and other tools that obfuscate the IP address. Some visitors of your website might be using tools that alter or obfuscate their IP address, which prevents GA4 from accurately identifying the country, city, etc. In that case – you guessed it. You get (not set).

Event-scoped and item-scoped dimensions are (not set) in GA4

They do not persist. Event-scoped dimension applies only to that particular event with which it was sent. Subsequent or previous events will not inherit that value. So if some events have (not set) values, double-check if you are sending the dimensions with all events that you need.

Also, there is no proper attribution in item-scoped dimensions (this is related to e-commerce tracking). If you send item_name and item_id with an view_item event, but then you send just the item_id with a purchase event, you will get a (not set) item name in reports related to purchases.

When you’re implementing e-commerce tracking, be consistent. Send the same parameters throughout the entire user journey.

The same applies to things such as item list names. If you send an item_list_name parameter with the view_item event and want to see how many purchases you got based on the item_list_name, you must also send that parameter with the purchase event.

You are not sending their values correctly. If you are using data from the Data Layer in your GA4 tags, ensure that the data there is pushed before you fire your tags. If you fire your GA4 config or event tag first but, say, pricing_plan is pushed to the data layer later, you will send an undefined value, which means (not set) in reports.

You registered the custom dimension much later than you started sending the event parameter to GA4. Here’s the thing with Google Analytics 4: if you send custom parameters to GA4 and want to use/see them in the interface, you must register them as custom dimensions as soon as possible.

Custom dimensions in GA4 are not retroactive. So if you have been sending the event parameters for a week (say, between April 1st and 7th) but registered the dimension only today, the dimension will be showing (not set) for the April 1-7 date period.

User-scoped custom dimensions are (not set) in GA4

They don’t work as well as we would expect. Based on Google’s documentation, user-scoped custom dimensions should work like that: you send the dimension once, and all subsequent events will inherit the same dimension.

But I (and others) have noticed that they don’t work as well as they should. There are many situations where user-scoped custom dimensions are still showing (not set) even if they were definitely sent.

I would say that this is a bug, and the values don’t persist. Hopefully, Google will address this issue at some point. But in the meantime, I see two options:

• You need to set the user property not only in the config tag but also on all event tags as well
• Or you could switch to the event-scoped custom dimension and set it in all tags (config and event tags) as well. For example, if you want to use a User Type custom dimension, you could register a user_type event-scoped custom dimension and send a user_type parameter with all events.

You registered the custom dimension much later than you started sending the user property to GA4. It’s the same principle as it was with event-scoped custom dimensions. Once you start sending the user property, register a user-scoped custom dimension as soon as possible. Otherwise, you will get (not set) for the previous time period (when the property was being sent but the dimension was still not registered).

Technology dimensions are (not set) in GA4

The event is sent via Measurement Protocol. As I have already mentioned here, the Measurement Protocol does not allow us to send the user agent (that is used to extract things such as browser name, version, etc.).

Server-side tagging (SGTM) is overriding the user agent. SGTM can be used to change or remove the value of a user agent. This can be done for privacy reasons. But as a result, you would not have things such as browser, browser version, etc. in your reports.

Browser extensions or some other privacy-related tools might obfuscate/hide the browser details. Some visitors of your website might be using tools that alter or obfuscate their user agent, which prevents GA4 from accurately identifying the browser version, browser name, etc. In that case, you guessed it. You get (not set). I am not aware of any solutions in this case.

One final but important note: a fix you apply today will only affect data collected from this point forward. Google Analytics 4 will not go back in time and retroactively fix the data that has already been recorded as “(not set)”. Do not be discouraged if you look at historical reports and still see the issue. The true test of your solution is to monitor your reports over the next several days and weeks to confirm that new, incoming data is being categorized correctly.

Not set in Google Analytics 4: Final words

I wish that more paragraphs in this blog post would contain actionable solutions. Unfortunately, in many cases, the answer was just “well, that’s how GA4 works now“. However, we still have much control regarding custom dimensions and working with traffic sources.

The key takeaways of this blog post are:

• (not set) means that GA4 does not have a value for that particular dimension in that particular context
• Measurement protocol is one of the most common reasons why you might have (not set)
• Server-side tagging might be used to strip certain data from being sent to GA4. So if you are using SGTM (or something similar), that’s one of the first places I would check
• GA4 has some bugs that have no workarounds. But keep an eye on them, maybe Google will address those issues eventually.
• Privacy-related tools/extensions that your visitors use might affect certain dimensions and cause (not set) to appear
• When you send data to GA4 via GTM, make sure you fire your tags when that data is already available (in the Data Layer, DOM, etc.)