Should You Manually Set the Page_View Event in an App + Web Property Using GTM?

NOTE: If you have not already set up your App+Web property within Google Analytics, check out THIS previous post.  

Let me start this post by stating that Google, Krista Seiden, and Simo Ahava have all done a thorough job of documenting how you should set up the App + Web Configuration Tag.  In some cases, you can just check the box that says “Send a page view event when this configuration loads” in your GTM tag settings and you’re done.

However, there are many reasons why you might opt to set up a “page_view” event that is separate from your configuration tag (see below).  The purpose of this post is to explain why you might need to do this, and share some best practices to make sure you’ve done it correctly.

Who Should Avoid the Checkbox?

It’s really all about timing, and there are two things to consider:

  1. When should my pageview event fire?
  2. What parameters and user properties should be set with my pageview event?

(question1 == “any time a page loads” && question2 ==“none”) ? Use the checkbox : Keep reading;

Consideration #1: When Should My Pageview Event Fire?

To keep your Google Analytics for Firebase data similar to the traditional Google Analytics data you are familiar with, I recommend firing a pageview according to the same logic that we previously applied to Universal Analytics: whenever the user views a new page.

So, do not use the checkbox if your site is a single page app.  With Single Page Apps (SPAs), how we define a “page”, however, can get a little tricky.  On a traditional website the user is presented with a series of pages, and each page loads sequentially as the user navigates the site.  However, traditional websites are slow, and many developers prefer to dynamically modify the content on a single page rather than send the user across multiple pages as they navigate.  This is why the web is rapidly moving toward SPAs.

In 2020, most of my clients are using SPA’s somewhere.  If you have a checkout flow, there’s probably a 90% chance that it was built with a SPA.  Since a single page app does not load an entire page when the user navigates through content, you will not see your App + Web Configuration tag and pageview fire either.  So what’s the solution?

Solution #1: Fire a Pageview Event to the Data Layer

Google Tag Manager should not be used as a way to get around your development team.  The absolute best practice here is to collaborate with your dev team to have them fire pageview events to your data layer, like so:

dataLayer.push({'event': 'page_view'});

You can then create a trigger using the “Custom Event” type, like so:

Now, if your dev team is lost at sea, Google Tag Manager does offer alternate approaches to identify when the user navigates between pages in a Single Page App.  If you absolutely must use one of these, check out the history API and with polling until an element exists.

Before you run off and start creating tags in GTM, review consideration #2 as well.

Consideration #2: What Parameters and User Properties Should Be Set with My Pageview Event?

I do a lot of planning before I create anything in GTM.  The reason is because you need to be very thoughtful about what business questions can be answered by Google Analytics data and how that data will be visualized.  Once you have that plan, you need to reverse engineer it by creating the combinations of events and parameters that are necessary to power your visualizations.

Maybe I’ll discuss more about that in a later post, but for now just be aware that you need to be thoughtful about what attributes should be set with your pageview.  Typically these attributes will fall into two categories: those that describe the event (like “page title”), and those that describe the user (like “authentication status”).

Validate that your pageview will not fire until after your event parameters and user properties are available.  This can be simple in many cases, but it can be difficult if you have an asynchronous service that is supplying this data.  This is common when you are pulling information from your CRM for authenticated users, and it may cause you to leverage promises or get creative.

Manually Setting Up a Pageview Event

If you’re still reading I’m going to assume it’s because the checkbox will not apply to you (probably because of one of the reasons listed above).  So, you’re going to need to create a new “Google Analytics: App + Web Event Tag” to pass your pageview to GA4F.  Here’s how to do it:

  1. First of all, you’re going to need that configuration tag.  Just make sure that the “Send a page view event…” checkbox is unchecked (obviously).
  2. Create a new tag, and select “Google Analytics: App + Web Event Tag”
  3. Make sure your event name is “page_view”, because this is the Recommended Event that unlocks some additional features in the UI (although it’s not documented).  Avoid “pageview”, or “pageView” or anything else.  
  4. If you’re setting a User ID for your authenticated users, you’ll set this as a Field.  If you would like to learn more about the User ID and why you should use it, read THIS post.
  5. Finally, under “Advanced Settings” > “Additional Tag Metadata” there’s an option to set the tag name as a parameter.  I always recommend that you should use this for 2 reasons: 1) if you see any strange data in reports this will make it easy to determine which GTM tag is responsible, and 2) because I asked the engineering team for this feature after the GA Summit in 2017 and so I feel a little responsible for it.

Add your trigger to this tag according to the notes we discussed in consideration #1 above, and you’re ready to go.

Leave a Reply

Your email address will not be published.