How to Prevent Tags from firing after a Page Reload with Google Tag Manager

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
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.

Comments 13

  • Great video tank you

  • Hi Julian, can you help me with setting up dataLayer.push for my site its on opencart and i have signal page checkout,

  • Thanks Julian. What if the user arrives at the order confirmation again e.g. via bookmarking or email. How would you prevent the tag from firing again?

  • In my case, when I''m using scroll tracking and when the user is at the bottom of the page the tag fires. Then if they reload, it fires again, this fixes that. Thanks! Since I use this as a Google Ads Conversion, I'd rather not inflate them. And this is super easy, my little sister could do this…maybe 🙂

  • Julian, thanks for thar video: it's very insightful! I have got a scenario: why at the end of the video not to play guitar for a few seconds? Kind of… memorable intellectual distraction 🙂

  • Cool, Du spielst auch Gitarre und Ukulele? Sehr fein 🙂

  • Thanks for this. I was looking for a solution to detect page reloads for a slightly different purpose. An alternative approach to this is to use the HTTP referrer variable with the path segment and compare it to the Page Path variable. If they both match this would indicate that a reload or a postback occurred on the page (what I wanted to detect which the JavaScript API doesn't). You'll still need a Custom JavaScript variable to return true or false on this condition but it should provide the same outcome.

  • Thanks for sharing. This was really helpful.

  • Works like charm

  • == and != are already boolean, no need for any operators

  • Great video but i need HELP: This works on our "normal webpages". If i want to refresh our checkout-site, there is a pop-up warning with following message: "Confirm new form transmission. The page you are looking for has used or processed the information you entered. When you return to this page, an action you have already performed may be repeated. Do you want to continue?" Then you have only 2 options – cancel or ok! If you go with ok, the java script does NOT work. It does not count as a reload. How can i fix this? Looking forward to your ideas… Thank you so much!

Leave a Reply

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