4 Ways to Test and Validate Your Tags Fire in GTM

How to ensure all your marketing tags are sending the right data and firing on the right pages and events before publishing them.

Brad Redding:

Now that you’ve gone through the effort to implement all of your third party marketing tags, or maybe you added a new tag and you’ve done it through the built-in tags, through custom HTML tags, or even custom templates, now’s the time to go through and QA and validate your tag before ultimately publishing or potentially you’re QAing and validating after a tag has already been published, you might be troubleshooting or just verifying that it’s reporting as expected. I’m going to show you four different ways that you can go through and QA and validate that your marketing tag is sending the right data and ultimately firing on the right pages or the right events that you are expecting it to.

Option number one to QA and validate marketing tags is using the built-in preview mode that comes out of the box with Google Tag Manager. Inside of GTM, you’ll see this preview mode or preview button in the top right hand corner. And once that’s enabled, you’ll have this bright orange call out stating that you’re now in previewing the workspace. What that allows you to do is navigate to the front end of your site. And as I just clicked through a few different pages here, you’ll see how this GTM or the Tag Manager debug mode pops up in the bottom and has a bunch of different things going on. But ultimately what this is doing, this is the eyes into your Tag Manager tags and variables and triggers and how that’s being rendered and ultimately executed on your site.

Once in preview mode, it’s really simple just to go through and browse your site, just like I showed going through our homepage and then a collection page and now our product page. This is going to show all of the different events that have triggered or ultimately executed in GTM. One clarification there is that this isn’t showing every single trigger that exists in your GTM account. This is just showing events that have executed, whether it’s a page view event, whether it’s a custom event that I’ve created through the data layer, like this product detail view event, or some of the other custom events that we’ve seen in previous chapters, like our Zendesk event or a timer event, a click event. As you can see, just click through here. This is ultimately going to help us go through and QA.

Let’s refresh here one more time. We want to validate that a few marketing tags that we’ve assigned to our product detail view trigger. Let’s go back to GTM and let’s just look at our product detail view trigger here. We have three events, three tags that we’ve assigned to this trigger; our enhanced eCommerce event, our Facebook product view event, and a Klaviyo product view event. Now what you can do on the front end, you can actually navigate through to these different events. You’ll see if I start at the bottom, starting at page view, you’ll see all the tags that are assigned to a general page view tag, then our DOM ready, where we have none, we have a few additional custom pushes to the data layer and now we have our product detail view where we have our four different tags that we have assigned to this particular event.

Now let’s look at how we can validate the data that it’s contained in here. I might look at this and say, “Okay, great. I see enhanced eCommerce firing. I see Facebook firing. I see Klaviyo firing.” This event is actually something that we’ll look at in our Google Analytics advanced event tracking where this is actually tied to a variable in our data layer. But if I were just to look at this, I might say, “Okay, great. I see three tags firing. That’s what I’m expecting, so I’m good to go here.” But one thing that we need to look at within all of our tags and even just going through and previewing and debugging our GTM account, is what the variables are when this event executes.

When I look at the product detail view event, we can click in to view the individual tag, and now we can see in this Facebook event, we can see the content category, our content IDs, content type, value, currency. These are all the variables that I have set inside of my tag in GTM. These are the variables, this is what I’ve mapped to, and this is what I would expect to see on the front end here.

Now, not every single tag is ultimately going to look this clean, so you won’t always see how the variables output. We can look at Klaviyo’s as an example here. This we’re actually not going to see that clean output of, okay, here is a price that was sent, here is a product name that was sent, here’s a skew, et cetera. So hold onto this and I’m going to show you one of our next options, how we can actually validate this through a couple other steps.

Just backing up here. Again, we want to look at the event, confirm the tags that we are expecting to fire on that event and then we want to validate that the variables that are assigned in that tag are also populating as we’d expect.

Another neat trick here is sometimes you’ll end up with circumstances where tags are executing, but you’re not seeing any variables populate. They might come back as undefined. Let’s say that we had the Facebook product view tag, instead of assigned here we had this assigned in the page view, going back to GTM, we can see a couple of these variables; our DLV, product view of the name, product views, skew, et cetera. If we go down to our page view, we can click either on variables or data layer. If we just click on a data layer we’ll see there’s basically nothing here. And if we were to click on variables and scroll down to our product view, you’ll see all these variables right here are all undefined.

Now if you navigate through the different events, we can actually see when these start to populate. So there’s our first, and now we have our product detail view, which is our second. This is where we have the tags executing that contain the different product data layer variables that we’re expecting to populate. So at this point, we can actually have our tags execute on this event and feel confident that the data is going to pass as we’d expect.

You can go through every different page throughout the site. If we go back to our collection page, we can do the same thing. We’ll see our different events that are triggered here. As we work our way through, we can see when the data layer is ultimately populating. So again, let’s just start back at our page view. Clicking through here, we can see all the pushes to the data layer. And now in the collection view is when we’re getting some of that impression data on the collection page.

Another little nifty tool here within the native built-in preview mode is we can actually share this preview mode. By sharing preview and entering the URL that you’d want to have someone test, you can actually enter your destination URL here. So in this case, I could just take our Elevar Gear sample store, and through that you can actually copy this URL, send it to somebody that has zero access to your Google Tag Manager account, or you can send it to yourself too and go incognito to test. But you can send this to somebody else to go through and validate. With GTM in preview mode, without publishing, they can go through, test and validate that their marketing tags that they’re expecting to execute, they work fine and then they can give you the go ahead that everything is good to publish.

Option number two to go through and QA and test your tags is pixel helpers. This one is super simple. You probably have used this already and might have a few installed in your Chrome browser or potentially other browsers. We have our Facebook Pixel Helper. This is going to pull in the different Facebook data that we’re sending for a specific event. Very helpful. We also have our Google Tag Assistant. This will pull in most of our Google property data, like our Google Analytics tags, our Google Tag Manager account, our Google Ads remarketing account. We can click into here and actually see the data that’s being passed through the tag.

Now keep in mind these pixel helpers, they’re not necessarily 100% accurate. I’ve seen the Facebook Pixel Helper have some bugs where it doesn’t actually work for a few days. Google Tag Assistant I’ve seen where it will show things are firing twice. Just keep that in mind that the tag assistants, they are not 100% accurate. If you do see an anomaly and you are convinced that the Tag Assistant is wrong, then if you go through a couple of these other methods to QA and validate, that you might be able to ignore some of these false positive errors.

Another pixel helper, which is very, very helpful is the Google Analytics Debugger. It’s another Chrome extension that you can see here. I have enabled it, our GAD bug on. Basically what this will do is this will write all of your Google Analytics events to the console. We’re going to just show this in action here. I’m going to reload the page and I’ll start to see my different Google Analytics events execute. We can scroll up and we’ll see our page view, which will be our first. So we have our page view hit type that executed. Now we have our product detail view that executed. And we’ll see all the data that’s being sent with a product detail view. This is very useful and very helpful if you’re going through and debugging issues with enhanced eCommerce or just Google Analytics in general.

Finally, we’ll see we have a custom event. This is that low inventory event that we saw earlier in the preview mode. This is a custom event, so action event category, event label. This is also showing that we recorded and is being sent to our Google Analytics property. Very, very nifty tool, especially when you are honing in on issues with Google Analytics.

Option number three is using our development tools. We are looking at our browser here. We have our console open. Now let’s actually look at how we can validate data being sent through our DevTools. Let’s say you don’t have access or potentially you don’t necessarily trust the data that’s coming out of the pixel helpers. Or in that example, if we looked at our product view, our Klaviyo product view, we’ll see that our product detail view event here, we’re not seeing the data as we would want to. This isn’t really giving me a yes everything’s good or everything is not good. Ultimately, all of the tags that we are executing and firing are being sent as query parameters on a URL that’s being sent back to Facebook, etc.

Let’s take a look at Brevite. Inside because we have the Chrome DevTools open, we have our network panel selected here, and if you’re just opening this on your own site, I’m just going to clear out everything right here, reload the page with our network panel active and now our product page is loaded. You can see all these different requests that are running in the background. These are either JavaScript, CSS, etc.

You can actually type in the script URL that you want to validate as passing as you’d expect. In this example, I want to look at Facebook. By typing Facebook into this network filter, you’ll see all of the different events that are being sent to Facebook. Let’s look at the view content. In the view content event, you can actually click into this and scroll down and you’ll see the query string parameters that are being attached to this Facebook JavaScript event.

Now these query string parameters, some of you might recognize, and depending on the marketing channel it might look like voodoo, but we can see the view content, we can see the URL. Ultimately we can start to see the different content IDs. Our content IDs, our content type, the content name, currency, value, et cetera. This is all of the data that we had set in the Facebook tag, we validated that’s executing as we would want it to and now we can actually see this data being attached to the script that’s ultimately executed and this data’s being sent to Facebook.

Where this becomes very helpful in this example, so again using the network panel as part of your Chrome DevTools is for marketing tags that don’t have pixel helpers. You might ask, “Brad, why would I go ahead and test query string parameters for the Facebook view content when I just have the Pixel Helper?” You probably wouldn’t, unless it’s rare circumstances where there are Facebook errors. What’s more likely is it’s going to be another third party marketing channel that doesn’t have a pixel helper and the output in the preview mode, like with the Klaviyo product view, is not giving us that validation.

Let’s look at another site example, which is going to be Listrak. Listrak is another email provider. On StriVectin we have our network panel filtered by Listrak, and we have one of the events that has executed on the page. We can see the query string parameters here, and we can see the data that’s being attached to this event that they have set to fire on product pages. We have the page browse, we have our URL, and ultimately we can go through the different events that we have that are attached to this product page or others and we can view that.

One more example here, looking at Cariumar. On their product page again, they have what looks to be another marketing partner, marketing channel. You can just pull out that script URL. We can click on the event here and we can see the query string parameters that are passing the product ID, potentially different price information or whatever it might be, this is being attached to that marketing tag and sent back to that marketing channel.

This is probably the most foolproof way to really validate that data is being sent back to the marketing channel that they’d expect. The only thing that you really have to know in order to validate this is what the URL is that’s included in the script. Many times, it’s going to be the name of the channel. Looking at Facebook, and if you look at the tag here, you can see the script. So we’re .JS. The domain URL includes Facebook. That’s why when we were looking at our network panel and all the different event data that was going, we’re just typing in Facebook, we’re looking at Facebook that’s being filtered.

Let’s say this was a different name. Rakuten is an example here, where their URL is actually not rakuten.com; it is linksynergy.com. We would want to look for that URL and their script. Let’s actually just take a look at that here real quick. We’ll see if we can pull up our Rakuten. I’ve pulled up the Rakuten conversion tag example. We can just go through all of this stuff and you can actually just look for any .com within the script. You can see our track linksynergy.com. This is what we would want to take, or even just linksynergy.com. We want to take this domain, add it into this filter and that would filter down to the Rakuten script and show us the query parameters that are being sent.

Hopefully that makes sense. Again, just to do another recap on that. If you’re wondering what to filter by in this network panel, go to the actual script that is in your tag or in the template, find the domain that the script is being attached to and use that to filter. Hopefully 90% of the time it’s the actual domain of the service, like what we looked at with Listrak, Facebook, etc.

Last but not least option number four to go through and test is our channel testers. This is looking at the obvious ones are going to be Facebook and then AdWords, Audience Management Report. Inside of Facebook, this is just looking at our own Facebook account. You can actually go through and test your events in real time. I have set up our homepage. I’m just going to go through and start navigating here. So just start clicking a few things and we’ll go to our pricing page. You’ll see I have my GA Debugger open as well. That is showing all the events that are being attached.

We’ll click on one more here. You’ll see, as I’ve been navigating through the site, these different events are executing. We can see our page view events, our different conversion events, our view content events. This is showing exactly what data I’m personally sending. This is not everyone on the site; this is just me going through and testing, sending that data back to Facebook where I can actually go through and start validating the content name or any other custom parameter data that we are attaching to that tag.

Lastly, looking at our AdWords. Inside of our Audience sources, and we’ll have our Google Ads tag or potentially Google Analytics tag. Looking at a Google Ads tag, this is really going to be the source of truth. We click into our Google Ads tag. You’re going to see hopefully a green, but you might see some yellow or red failures. But this is ultimately going to show us all of the parameter data that’s being sent with the tags and with our hits sent to AdWords. And if we click into any of these different parameters, this will actually show the values that are being sent with the hit or the tag that is executing on your site and sending data to AdWords.

Again, in our Google Ads tag, this is going to show the total events, it’s going to show all of our different parameters that we’re sending and ultimately it’s going to show the values of the parameters that we’re sending as well. You can use this graph to go through and validate. The table below will show you a quick overview on the one day, 30 day hits and percentage of tag activity. And then you can actually, like I showed, just go through and click into each parameter to see the data that’s being sent.

That’s four ways to go through and test and validate and QA your tags. There’s a lot here to uncover. And usually it’s going to be a combination of using at least two of these ways to test, so the preview mode and then potentially using your Pixel Helper or ultimately in the channels here to validate that the data is ultimately sending as you’d expect.