How to Track Single Page Applications (SPA) with Google Tag Manager

A SPA or Single Page Application is an app that doesn’t need to reload the page entirely while navigating. This puts our Tracking with Google Tag Manager in front of a problem because no Pageview is generated upon navigation. How can we resolve this? In this video, I will show you the way to use the History Change trigger to track page navigation.

🔗 Links:

The Rogue Referral Problem (Simo Ahava)

Track Single Page Application (E-Nor)

In this video, I’m going to show you how you can track single page applications with the help of Google Tag Manager’s History Change Listener. All the more coming up.

Hey there, measuregeeks. Julian here back with another video. Today we want to talk about single page applications. What are single page applications you might ask? Well, let’s jump right into our demo here. So here I’m on a page that is a single page application. It really looks the same as any other website but when we click around we see that it’s loads super fast and this is made possible by these single page application frameworks. You might have technology running on such websites such as angular JS, react JS or view JS and the premise is really always the same. There is no real page reload every time you go to the next page. Although we see the URL change up here, it seems to be super responsive and that’s because we are not sending actual data, oh well we are sending data to the server but it doesn’t make a complete round trip of the HTML and downloads new HTML.

The page doesn’t have to be completely rerendered. That is also something we can see in the page view page source here that the HTML is very, very small. It’s actually getting replaced with a virtual DOM in the background and this is made possible by these technologies. Now our tracking is a bit more complicated here. Why? Because the page doesn’t really reload and Google tag manager is built on this page reload. So I have a Google tag manager account installed here with a normal pageview tag with all pages trigger. So far so good, but when we go onto the page right here and reload it. And our page reloads, just like normal, we have our pageview here. But if I go to the next page and the next page, you see that the Google tag manager code doesn’t really reload or the preview and debug mode doesn’t really reload.

Now you might be thinking, Oh, okay, but it fire our tag, right? Yeah, it did, but only one time you can see it as also here in our Google tag assistant, we have only one pageview tag that fired our Google analytics code and in Google analytics itself we only have one code after the reload that actually fired. So we are not tracking all the pages on the page when the user goes from one page to the next. And that is a problem for Google analytics because we would only have one page view that is checked throughout the session of the user. This is the complete problem of single page applications already. In a nutshell, there is no page reload and therefore our Google analytics doesn’t get re deployed by Google tag manager. Although the URL changes up here, we don’t have a new page reload and Google tag manager and Google analytics for that matter doesn’t track any data just once, once the user comes to the page.

So how can we circumvent this problem? Well there is something called the history API and this is a browser feature that lets us make use of these back and forth buttons up here. If I go back on these buttons, we see that the page reloads like normally, but it actually is something that has been used by the developer to push new information in every time we change the page here and if you want to go back, we can go back because it’s actually saved in this history API of the browser. Now Google tag manager has a special trigger for this where we can read that information that gets sent to this history API. So how can we make use of it? Let’s go over to Google tag manager and he under triggers, I’m going to just create a new trigger and this will be our history change trigger. This will be a generic one for now. So we’ll go here to history change and let’s try this out. We’re going to go to save and now I’m also gonna go over to our building variables because they are built-in variables attached to this trigger, which are history fragment, all history fragment and so on. Let’s just activate all of these to try them out. Refresh, go back to our page.

And now if I click around, we see that there is new information in the preview and debug mode. Every time we change the page. What information actually gets pushed? There’s actually every time when we change the view, we get to new history events. So the first history event, when we go here to variables, we see that information gets filled. The information that I want to point your attention to is the history source. Here we can see push state. Second one is replaced state, then again, push state and replace state. So every time we go to another view, two events get pushed into the data layer. And these are from the history trigger. Now how can we make use of those? Well, every time we have a new event gives us a new chance to fire a tag. And every time we fire a new tag, we can transfer this over this information over to Google analytics and we can choose one of these events. For example, number four, the number six, the number eight in order to push our new data to Google analytics. And I would say we can utilize the history source push state every time somebody gets pushed into this new state up here to fire our tag. So now we can go back here in our triggers and simply change our history change to a specific one which only fires on push. We go with some history changes where the history source equals it’s be correct here, push state. I’m going to put in push state. Let’s save this and now we simply attach this to our page view tag.

We want to fire this once on all pages because every time the page really reloads, there is no history event. So if I go to this page here and reload, we see it fires once on the page view, but there is no history event once the page really new reloads. Only if you change the view, there will be history events and therefore I want to leave my all pages trigger on here and simply add our history change post as well. Oops, this was an exception. I want to put it in as an exception. I want to put it in as an additional firing trigger and so these will evaluate or so either this is true or this is true. Let’s refresh, refresh our page and our page view fires once, our page view fires twice, three times, well no result found. Let’s go to the cart, five times and so on and we get our pages into our Google analytics just as normal. So here can see that we have now with the help of the history change trigger simply picked up another event every time the view changes.

Now there are some caveats to this method and I want to mention them. First of all, if your developer who built your platform doesn’t make use of the history change API and doesn’t push new states into this feature of the browser, then obviously our trigger won’t be able to pick up any history events and therefore you will not be able to utilize this method. You would need to utilize custom data layer pushes, which is a bit more complicated to set up. I will skip this for here. There can also be more problems that arise with single page applications because not all single page applications has clear URL change up here. They may use something called hashes. They may also use something that is pushed into the query string, for example. You need to account for that and probably would add a virtual page path to your Google analytics tag in order to pick those up. But these are individual issues that I won’t go over here right now.

If you come up with such issues, then definitely leave me a comment down below and maybe I’ll do another video on that. But this is really it. We already have now installed the pageview tracking, the normal pageview tracking on a single page application with the history change listener. Don’t forget, if you want to take this live on your website, simply submit us as a version and deploy this to all your users.

So there have it already. This is how you can track a single page application with the history change trigger within Google Tag Manager. I hope you found this video useful. If you have more questions, always leave me in the comments down below. And if you want to check out our other stuff, we have a pretty good video linked up right here. And if you haven’t yet, consider subscribing to our channel right here because we bring you new videos just like this one every week. Now my name is Julian till next time.

Julian Juenemann
About the author: Julian Juenemann

Julian started and grew venture-backed startups with his unique 'data first' approach to Online Marketing. He then founded to help marketers, like him, the data-driven way of digital marketing.

Leave a Comment

1 Comment threads
1 Thread replies
Most reacted comment
Hottest comment thread
2 Comment authors
Julian JuenemannAmit Recent comment authors
newest oldest most voted

Hi Julian,
I have a question, how we can use GTM “timer” functionality using “history” event.
Thank you