Struggling with “(not set)” landing pages in GA4? We got you covered
Dan Jennings | 29 March 2023
If you have GA4 I bet you have “(not set)” landing pages. You do, don't you? Go on, check, I'll wait… (And while you check make sure you’re not including today or yesterday in your date range because GA4 data can take between 24 and 48 hours to process which could increase the number of “(not set)” landing pages you’re seeing)

Background on "not set" in GA4
You might see a value of "(not set)" in your Landing Pages report for a couple of reasons but the most common reason has a simple answer. Have you included today or yesterday in your date range? If so, remove that from your analysis and you should see the issue go away or at the very least diminish. This is because GA4 can take up to 48 hours to finish processing data it receives, before it's finished processing it will resolve some fields as "(not set)".

Investigating the problem of "not set"
You might find though that even when you remove the last 48 hours of data you still see "(not set)" landing pages, so why does this happen?
You'll still see "(not set)" landing pages if one of the following scenarios happens:
- Your page_view tag fired before the config tag: Trying to fire events before the google tag has a chance to initialize can cause problems, namely (not set) landing pages but it can also impact the attribution of traffic sources.
- The session didn't contain a page_view event: This can happen if your setup is incorrectly configured but it can also happen organically. I am certainly guilty of leaving 100 tabs open, and if I don't interact with a website for 30 minutes and come back only to scroll and then close the tab, a new session is created and it only contains a scroll event. Without a page_view, no landing page dimension can be set.
At it's core, we need to ensure that the Google Tag (config tag) is fired before any event but also that every session has at least 1 page_view event.
The latter condition is a tough nut to crack when you consider the scenario where a user leaves their window open for 30 minutes only to interact and leave immediately, so we'll go to the drawing board for that scenario and update this blog at a later date to cover that case.
Fortunately this problem can be mostly mitigated by following some simple steps.
What you can do to mitigate the problem
If you're using Google Tag Manager, you're in luck, most of this problem can be mitigated by checking a few simple parts of your setup.
First, does your Google Tag fire before everything else?
The Google Tag (often referred to as config tag) loads the JS library required to make other GA4 events function, it's
VERY IMPORTANT that this tag fires before all other GA4. The config tag loads configuration settings from your data stream and tells future events what common parameters they share so if you send a page_view event before all of that happens it doesn't get tied to the rest of the session and the result is again ("not set)" landing pages.
With that said your first check needs to be that your Google tag has a trigger that is before any other events. Generally speaking this means that firing the config tag should happen on initialization:
Next up, does your page_view event fire everywhere?
The eagle eyed among you may have noticed that the screenshot above has a parameter "send_page_view" set to false. This prevents the page_view event from being sent by the config tag. This kind of set up is usually adopted when you want to send the page_view event only after a specific dataLayer push. Perhaps you want to send custom page groupings or user provided data on a page_view event, if so, you'll want to make sure the page_view event is fired only when that data is available. If that dataLayer push doesn't exist on some pages then you won't be firing a page_view event and will end up with "(not set)" landing pages.
You might also want to send your page_view event at a specific time if you use timestamp as an event ID for Conversion APIs and want to ensure all events have the same ID.
If you have an implementation like this you'll need to be confident that the event exists on all pages because if it doesn't and a user only interacts with a page where it doesn't exist... you guessed it, "(not set)" landing pages. It can be hard to determine if all of your pages have the same push, you could try navigating to each page type to check but a much better approach would be to use a tool like ObservePoint to scan your pages and read your dataLayer to confirm you have 100% coverage.
If however, you don't send custom page level data, or use CAPIs then setting the "send_page_view" parameter to "true" will mean your tag takes care of the page_view event for you and gives you one less thing to worry about.
If you've followed all of the above instructions and you still see "(not set)" landing pages what next?
One last thing to check is if you're loading more than one Google tag on the same page. From my reading this generally seems to lead to interference between the tags but I'm yet to find a technical explanation to this only hunches and anecdotal evidence. If you still see "(not set)" landing pages and are deploying more than one Google tag on a page it could be worth considering a different approach. For example, you can deploy one Google tag on the client side and use GTM server-side to send the same events to multiple locations, saving on code bloat and removing the need for multiple google tags. We talk about server-side GTM in more detail in our blog.
And if that fails you can always reach out to us!
Want to have a chat?
Chat through our services with our team today and find out how we can help.