• Courses
    • Courses
    • Course bundles
  • Blog
  • Resources
    • Youtube channel
    • E-books and Guides
    • GTM Recipes
    • View All Resources
    • GTM Community
    • GA4 community
  • Services
  • About
    • About
    • Contact
  • Login
  • Courses
    • Courses
    • Course bundles
  • Blog
  • Resources
    • Youtube channel
    • E-books and Guides
    • GTM Recipes
    • View All Resources
    • GTM Community
    • GA4 community
  • Services
  • About
    • About
    • Contact
  • Login

June 16, 2025

No, user_engagement before page_view does not cause “not set” landing page

It’s time to break some myths. We had something similar in Universal Analytics when people believed that if you have any event tracked before page view (in the same session), this will cause “not set” landing page. Simo debunked that a while ago.

Now, we have a different version of Google Analytics, but the same myth.

Here’s the thing. If you fire *any* event tag before Google Tag (a.k.a. Google Config tag), it will cause not set problems. You should do your best to make sure that Google Tag fires before all other Google Analytics tags.

But this “not set” problem is not directly tied to the page_view event. If you fire Google Tag first (with send_page_view set to false), then track some event (e.g., user_engagement) and only a bit later the page_view event fires, the landing page dimension will still be fine.

Landing page dimension fetches the data of the first page_view event in the session. If the session does not have a page_view, then you get “not set”. For example, if a visitor keeps the browser tab open, the session times out, and then a user_engagement fires (which starts the session and is the only event in that session), it will cause Landing Page to be not set (because there is no page_view).

But if a session has a page_view, then the order of the events does not matter (as long as Google Tag fires first, before all other Google Analytics tags).

I run several experiments, and the results confirm this. Let’s take a look.

 

Table of Contents

Here’s what you will learn in this article

  • Experiment #1: no page_view in a session
  • Experiment #2: scroll > user_engagement > page_view
  • Experiment #3: user_engagement > go to 2nd page > page_view
  • Final words
Subscribe and Get the Ebook - working with reports in ga4

Experiment #1: no page_view in a session

In this and all subsequent experiments, I was using a Google tag with send_page_view set to false.

In this GA4 data stream, I have enabled Enhanced Measurement, so we can expect events such as scroll.

The idea of the first experiment was to not fire a page_view at all, while other events can happen. The page height was not high, thus the scroll event is triggered very soon.

Also, I decided to send a user_engagement event after the scroll.

The easiest way for me to trigger the user_engagement event was to use consent mode. When I landed on a page, all consent groups were set to denied. Then I change the consent state to granted, and this triggers a user_engagement event.

Two hits were sent to Google Analytics in total (in this particular order):

  1. scroll
  2. user_engagement

After waiting for 72+ hours, here are the results. The landing page is not set because there was no page_view in the session. That’s the main reason why landing page is not set.

 

Experiment #2: scroll > user_engagement > page_view

Let’s take the next step. This time, I started another session and here’s what happened (in this exact order):

  • I land on a homepage
  • Google Tag fires first (without a page_view)
  • Then the scroll event happens (because of enhanced measurement)
  • Then I grant consent, this triggers user_engagement
  • Then I fire a Google Analytics event tag to send the page_view event (on the same page).

The order of the events in the preview mode (scroll happened first):

And here are the results after 72+ hours:

The landing page is present because there was a page_view. I started a session on the homepage, thus we see the “/”.

Everything works fine here as long as we have a page_view event and it fires at some point later (after the Google Tag).

Subscribe and Get the Ebook - 20 GA4 mistakes

Experiment #3: user_engagement > go to 2nd page > page_view

Let’s take this even one step further. I was curious: what happens if page_view is tracked only on the 2nd page? Since the landing page is a session-scoped dimension, I would expect it to catch that 2nd page_view as a landing page.

The flow of the experiment:

  • I land on a homepage
  • Google Tag fires (no page_view)
  • Scroll happens (because of enhanced measurement)
  • I give consent (this triggers user_engagement)
  • I go to another page of the website (page path: /category/uncategorized/)
  • Google Tag fires (no page_view)
  • The page was taller, thus scroll did not happen
  • I send fire a page_view event

And here are the results after 72+hours. Google Analytics processed the page_view on the second page and treats it as a landing page.

Of course this is not accurate (because 2nd page is not the actual landing page) but your goal here is to make sure that at some point of the first page, the page_view is sent to Google Analytics.

But it does NOT matter whether user_engagement fired before page_view it or not. What matters is that none of your event tags fire before the Google Tag (config tag).

Note: but this does not mean that user_engagement never causes (not set) values. In his blog post, Doug Hall shares an example where multiple Google Tags + user_engagement can mess up your attribution. Read more here.

 

user_engagement before page_view: Final words

I don’t know who’s to blame here for the initial confusion. Maybe someone assumed that user_engagement before page_view is causing the problem, but did not verify it.

Perhaps someone trusted AI too blindly, published an article, and it triggered a chain reaction (of people reusing content without verifying it). Maybe something else.

But what I can tell is that when I published this blog post, at least 30% of the top 10 articles in Google search under the keyword “Landing page not set GA4” mention the myth that I debunked here.

So be careful with what you read. Trust but verify. Unfortunately, with the boom of AI and half-assed content, the quality will continue to decline.

Subscribe and Get the Ebook - Mastering GA4 event tracking
Julius Fedorovicius
In Google Analytics Tips
3 COMMENTS
Leonardo Lourenço Crespilho
  • Jun 20 2025
  • Reply

Hi Julius. Thanks for the debunking. :)

What is the reason the Google Tag must be fired before the page_view? I know Google Tag sets dimensions, but what is its role in landing page = "(not set)"?

Thanks in advance.

M86
  • Jun 23 2025
  • Reply

Thanks for doing this work to debunk such myths!
What I'd hope to see is also the same in regards to unassigned sessions. During your testing you should also mark and write down on which event the _ss (session start) and _fv (first vist) and the sid (session id) which value was observed, which would help to further understand the logics behind the session and all session related data exactly (channel groups, etc).
Hope to see a round 2 of this, as unassigned channel to my experience is even more interesting than the not-set-landingpage :)

Paul
  • Jul 7 2025
  • Reply

Thanks for the article, but does this change in anyway when sending out of order to ssGTM?

Leave a comment Cancel reply

Your email address will not be published. Required fields are marked *


 

Hi, I'm Julius Fedorovicius and I'm here to help you learn Google Tag Manager and Google Analytics. Join thousands of other digital marketers and digital analysts in this exciting journey. Read more
Analytics Mania
  • Google Tag Manager Courses
  • Google Tag Manager Recipes
  • Google Tag Manager Resources
  • Google Tag Manager Community
  • Login to courses
Follow Analytics Mania
  • Subscribe to newsletter
Recent Posts
  • Setting up cookie consent for Microsoft Clarity (V2)
  • Conversion rate in Google Analytics 4
  • Google Tag Manager Data Layer Explained
Analytics Mania - Google Tag Manager and Google Analytics Blog | Privacy Policy
Manage Cookie Settings