How to Prevent Tags from Firing After a Page Reload with Google Tag Manager

There could be several reasons why a user reloads a web page. And this could lead to duplicate information sent to your tracking tool. But you can prevent this with the use of Google Tag Manager. In this video, I will show you how you can detect if a user reloaded a page with the help of Google Tag Manager and prevent your tags from firing again.

UPDATE: The Performance navigation API has been replaced by another API. You can now use this code for your Custom JS Variable instead:  https://gist.github.com/measureschool/623a0507d3498b02d54a28b12932c2e2

In this video, I’m going to show you how you can detect if a user reloaded the page so you can prevent your tags from firing again. All and more, coming up.

Hey there. And welcome back to another video of measureschool.com teaching you the data-driven way of digital marketing. My name is Julian. And on this channel, we do marketing tech reviews, tips, and tricks, videos, and tutorials just like this one. So if you haven’t yet, consider subscribing. Now today, we want to talk about how we can detect with Google Tag Manager if a user reloaded this page. This is particularly important if you have a page view trigger on your certain tags, and want to prevent them from firing again and again if the user clicks on that reload button. Now to do all this, we will utilize a browser API, write a little bit of custom JavaScript, and then put this all into our trigger condition so we can prevent our tags from firing again on a reload. Now we got lots to cover so let’s dive in.

All right, back in our demo shop. We now want to detect whether somebody reloads the browser up here or just presses Enter here again, which will also reload the page. How would we be able to do this? Since Google Tag Manager has many JavaScript we can make use of the JavaScript APIs that the browser provides. Nowadays a browser API called the navigation timing API, which provides a method called the performance and navigation. If we wanted to try this out, we can just open up our developer tools, the under more tools and developer tools, navigate to the console and type in here our performance navigation.

Here we go, we get an object back with two keys in here type and redirect count. Now I’m interested in the type. So just going to put in the dot and then type and we get it number 1 back. Now, there’s number 1 actually represent if we have reloaded this page, or if he navigated onto it through another way. So let’s reload this page. And I’m going to press the up arrow to get my last command back, press enter, and get a number 1. What if I go to a different page right here and press the up arrow again? You get a zero. Again, let’s try this out inside of our demo shop here. If I navigate to any page and try out this command in our developer tools, I get a zero. If I reload the page, I get a number one. So we can use this indication if it’s zero or one to determine whether somebody reloaded this page or navigated to it by another way through a normal link. Now, before we build this into Google Tag Manager, I need to make you aware that this technology is something that is already being phased out. So in future iterations of browsers, we will need to use navigation time level two specification, which is currently developed. But for now, our navigation timing API is still valid. It is supported by the major browsers, unfortunately, not by Opera on a mobile device. So you need to be aware of this downside if you want to use this technique. For me, it’s good enough, there are a lot of browsers that support this. So let’s build us into Google Tag Manager. Since we have here one line of code, which really just accesses the global namespace and our browser API, we can utilize a variable that simply accesses that. So let’s go over to Google Tag Manager. And we go over to our variables. And here we are going to define a new user-defined variable. This will be a JavaScript variable to detect our reload as a type will choose the JavaScript variable, not the custom JavaScript variable, but the JavaScript variable. And here is where we can input our global variable name. And as we have done so before, we can just use our performancenavigation.type. Let’s try this out and save this. Refresh, refresh our page.

And since we refresh just now, we can see our JS reload is number one. Notice that the variable already gets filled on the first event here, so we’ll be safe to use it at the earliest point in our triggers later on, which is the page view normally. Let’s try the negative case, I’m just going to navigate to any page. Check the variables again, and we see js reload is now zero. So we can already detect whether somebody reloads the page, our variables should show the number one. Now, maybe that’s a little bit inconvenient because you need to remember, okay, one is reload, zero is not real. But you could use it like this already. If you want to have it a little bit more convenient, we can utilize a custom JavaScript variable. So let’s go over to variables and build another variable. This is our custom JavaScript variable for the reload. I’m going to choose custom JavaScript. Will input our anonymous function. And we simply going to put in an if statement. So if our performance navigation type equals one, let’s say equals zero, so we do the opposite case, then we want to return the value of false. Or else we want to return the value of true. So if it’s one or any other number, it will return true. This will come in handy in a second. Now if you’re well versed in JavaScript, you might notice that this could be shorter. We could use a ternary operator, which would simply be to return the performance navigation equals zero with a question mark. And if this is true, we want to return false. Otherwise, we want to return true. And that’s exactly the same expression as it is here written in five lines, whichever you prefer. I’ll delete this and make this really short for us. Let’s try this out. Let’s save this, refresh, and refresh our page. And we can see our JS reload is one and our custom JavaScript is now turned to true that means a reload has happened.

Now if you navigate into this again, we see our reload is false. So this is a regular navigation point. Now, what is also interesting about what we have just written is if we click on the back button here, this will also be counted as a reload, as the JS reload, or the navigation type will change the number to 2, which means that the user has navigated through History API here. So if I go forward again, this is again, a true for reload. So anytime somebody reloads something, anytime somebody presses enter, here again, on the same URL, it will always remain a reload. It doesn’t matter if the user navigates here, clicks the reload button, or types in the URL. Only if there’s a new URL, for example, UTM parameters get attached, then this would be counted as a new reload, and so the reload is false. So this is already pretty convenient that we can now detect our reload with this custom JavaScript variable. Now, when would this actually be useful. For example, if you have conversion codes firing, if you don’t want to fire again, on a page reload as an example, let me go through a conversion here. And we go to get to order received page. Now on all the receipts page, I’ve already fired some tags. These are Adwords, Facebook, and Google Analytics conversion tags, and transfer the information to our tools. Now notice that these all fire on the page view event. So once I reload this page, they actually fire again. Now some systems are smart enough to pick up that there’s a same order ID number being sent over, being transferred to the tool, they will automatically deduplicate this order. So you won’t get double orders in your systems. But some systems are not as smart. And we’ll just produce double orders if a user clicks on the reload button. This is particularly true when you are fine with a very simple trigger, like the page view event if the order is received, and you’re not sending any special information over to the system. So cannot really decide whether this is a duplicate transaction or not.

And therefore, it would be good if we could stop these tags based on our variable inside of Google Tag Manager. So let’s try this out. Let’s look at the trigger that is set up for these tags. It’s always the same trigger, it’s a page view transaction trigger. And it fires on the condition that the page path contains order received. So far, that’s all well, but we could add our just build custom JavaScript reload variable to check whether it contains or is equal to false. So only if these two conditions turn positive. So a user is on the order receive page and the reload his false, we want to fire our tag. Simple as that. Let’s try this out. Refresh. And if I go to our checkout page, order received, reload this our tags don’t fire because our variable custom js reload turned true.

Let’s do a negative example here. I’m going to go through another order. And once I enter the page order received, for the first time, I get my conversion codes fired, and the data is transmitted. And if I reload this page, again, our code shouldn’t fire because we have been reloading our page. So really a simple solution to prevent duplication of any tag firings. You could use this in different other instances. For example, if you really don’t want to fire a tag two times because it will inflate certain numbers, a certain event, then you might want to check for this reload variable. And if it turned true, you don’t want to fire your tags. That could be for example, if you want to be really accurate with your page views, or prevent any kind of events that shouldn’t fire if the page has reloaded. I could also think of the use case that you would explicitly track when somebody reloads the page. So you could fire an event if this actually turned true, just to see which pages get reloaded a lot by the user to maybe install an auto refresh functionality or figure out why the user would like to reload this page. Maybe there’s something wrong on the page itself.

All right, so there you have it. This is how you can detect whether the user clicked on the reload button and landed on this page to the back or reload button and prevent your tags from firing. Now if you try this out, then I’d love to hear from you what are your experience. Leave them down below. And if you have any more questions also leave down below. Now if this video have jobs in the end, and I’d love for you to click that like button and also, subscribe to the channel because we bring you new videos just like this one every week. Now, my name is Julian. Till next time.

JOIN US!

Master Data & Analytics with Measuremasters

Exclusive Courses & Workshops | Ongoing Troubleshooting | Support Resources, Tools & much more
guest
5 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Jared
Jared
3 years ago

Great stuff. I’ve enjoyed your videos. Keep up the good work.

Marcel V.
Marcel V.
1 year ago

You’re awesome! Thank you. That was exactly what i needed!

Chaimae
Chaimae
1 year ago
Reply to  Marcel V.

does it still work today?

Paul
Paul
3 months ago

Julian there is a typo 😀 “relaod” instead of “reload” costed me 30min to find

Blog Categories

Join 50,000+ marketers getting exclusive resources and our latest content!

now it's time to

Start measuring like a master

Itching to jump into the world of MeasureMasters? This is what you have to look forward to.