How To Fix Common Errors in Event Tracking Data Collection
Common issues we’ve seen that impact data quality and data collection.
Now that you’ve learned so many great ways to tag your site, both for Google Analytics Events, as well as pushing additional event data to other marketing channels, like AdWords, Facebook, et cetera. Let’s look at a few common issues that I’ve seen over the last year that impact data quality and data collection. Issue number one, the dreaded non-interaction hit. I won’t tell you how many takes I’ve had trying to explain this. I’m over my life trying to explain this in a very succinct manner. I’ll try again, this is the last take and I’m just going to have to fight my way through it. But this is an event that’s on every Google Analytics Event type that we see here in GTM. It’s a true false flag. I like to look at this as basically the bounce rate setting. If this is set to false and you have that set to false on that scrolled up tag, then your bounce rate in GA is going to look something like this.
A bounce, the way that Google defines a bounce is a session where you sent one hit to Analytics and that’s it. Most of us think of page view, so bounce rate equals one page view. However, now that we’re sending additional event data for interaction on a page, there are many hits that you can be sending to GA that they could potentially use in the evaluation of was this a session that bounced or not? If I just clear out my GA Debugger, refresh this page. You’re going to see a page view hit, a product detail view hit. If I scroll, you’re going to see a couple scroll depth hits, as well. If this setting was set to false, then bounce rate for that landing page, and likely most of the site, is going to be near 0% because anytime a page loads, three events are executing right away and Google is saying, “Okay, great. Well, this session had three hits.” Even if I didn’t do anything else, except close out my browser and move on.
Most of the time, the events within GA, we always recommend setting this to true. By default our event builder always sets every tag that we’re creating, we set this to true. And I’d recommend the same, unless it’s an event like an email signup or something that you are really going to evaluate, if you are using bounce rate as a metric in your evaluation, the success of that landing page, and actually getting someone farther down the funnel issue.
Issue number two, enabling enhanced eCommerce on your event tags. This is the Google Analytics variable that’s within GTM. This is where you’re setting your tracking ID and you’re assigning this variable to your different events, whether they’re enhancing eCommerce events or just your click based tracking events. When this variable that you are assigned has the enable enhanced eCommerce feature set to true, and it’s using the data layer, what’s going to happen is every single event. Any single Google Analytics Event that executes on the page is going to look to see what data exists in the data layer and attach that to the hit. As you can see here, this GA variable, I have both enhanced eCommerce tags assigned to this, and I also have a scroll depth tag assigned to this.
If we go to the front end., let’s clear our console out here and refresh the page. All right. As we go through, we’re going to see our page view event. There’s page view ultimately executed, there really wasn’t a data layer that was available this time. Now we’re going to go to our product detail view. This is our product detail view that is executing, and we would expect this to grab the data layer. Now as we continue to scroll down and see the next event that executes, we see the event action is our scroll depth. We have a scroll depth event of 25% and it’s also attaching a product detail hit, or product detail enhanced eCommerce hit, with it.
If we clear this out, scroll down on the page, you’ll see two additional scroll depths triggered, and they are also attaching another product detail view hit with a scroll depth tag. What’ll happen with this is you’ll have inflated numbers, whether it’s your product detail views or add to carts. These will be inflated inside of Google Analytics. What you’re left with is inaccurate enhanced eCommerce numbers, inaccurate percentages, if you’re looking at ratios of add to carts or product views, et cetera. And it’s very easy to miss that just because of such a small setting. Normally what we recommend is if we look at our Google Analytics setting here, if we are assigning this variable to a mixed set of tags, we will actually have this disabled by default. Let’s save this, and then on the enhanced eCommerce events that we actually want to attach the data layer to, we will select overriding. We’ll override the default settings from this variable. We’ll go down to eCommerce, we’ll set this to true, to use the data layer. We do that for all the enhanced eCommerce events.
And then the scroll depth tag, we actually leave this as default. We won’t override the settings. You might be asking why do it this way, is you’re going to a max of maybe 7 to 10 enhanced eCommerce events that you’re going to have running across the site and really, they shouldn’t change a whole lot. Where you might have 20, 30, 40 custom behavior events that are running on the site and if you have multiple people that are working a GTM, they may not know that they have to select this and disable enhanced eCommerce from running. This one is very common, very easy to get caught in. I’m going to put this in preview mode just so you can see exactly how this happens.
Let’s reload the page here and we’ll see, we have the top of the product page. And let’s just go to our data layer. As we work our way up the events, you’ll see the data layer beginning to grow. Now we have our product detail view, this is where the product detail view data is being created and built out as part of the data layer on this page. We can see our tags that executed on this event, and now let’s go to our scroll depth, where we have our scroll depth tag that executed. Let’s look at the data layer that exists when this particular event triggered. We can see the enhanced eCommerce detail view is still there. That’s why this was ultimately attached to the scroll depth event and sent along with a scroll depth action.
Issue number three, this is more of a reporting and analysis type of issue. This is case sensitivity of your event actions or event categories. Depending on how your site is set up for mobile versus desktop, this is a very common scenario where you’re going to have the same event action. Pajamas and pajamas, and then another set of these. Same event action, one is upper case, one is as it’s set on the tag, and you might be wondering why is it coming in. Many times you’re going to see things that are automatically capitalized on mobile or vice versa. You end up with the same action, multiple rows. You would think the fix for this would be to automatically set all of your tags. If you’re going into our behavior event tag here, and just set everything to be lowercase like we see here.
But really the true fix for this is going to be inside of review settings, you go to filters, you add a new filter and we are going to select a lowercase filter. In this case, lowercase event action, lowercase event category and event label. That way, no matter how the data’s being pushed from the user’s browser, GA is automatically going to lowercase that, and it fixes the issue for you. Issue type number four, syntax errors. I’m going to force a syntax error in my data layer snippet here. We’re going to save the page and you’ll see in our console here, close out our… Leave preview mode. If we go to our console here… And we’ll clear this out. We now have a few events that executed, but we actually have a syntax error. Our unexpected token. You’ll recall when we were looking at this page previously, reloaded it, we saw the product detail view event trigger. We have a syntax error. This will actually link exactly to where the error is, so you can see what the error is.
And ultimately, as we scroll through all of the other events, you’ll see there’s no product detail view hit that ultimately executed. At this point, that syntax error that existed in the data layer broke the product… Ultimately, the data layer. Excuse me, the GTM product detail view event from executing. Now, even though I have a page view event and I have my scroll depth events, I don’t have that product detail view event because I have a syntax error in my data layer. Thus, any tag that was dependent on that product detail view trigger is no longer firing. And really, unless you’re paying close attention to it, you may not know this for a few days or potentially a few weeks. This leads into issue number five, is new code breaks any reporting or analysis. In this one, there’s different potential monitoring that you can set up. But there’s also a very under utilized feature within Analytics, where there’s a custom alert setting where you can actually create an alert.
I have an example here of add to carts drop by 80%, and this is alerting me when sessions percent decreases by more than 80% compared to the previous day. You can create these alerts, especially for your big sessions, page views, revenue, etc., create these alerts. And that way you can get a proactive notice if something is deployed that breaks some tracking that you might have quite a few tags tied to, and you’ll know that, hopefully, within a day or so versus having this spill out over multiple weeks. Issue type number six is when GTM was installed twice on the page, thus resulting in duplicate data being sent. Easy way to look for this is if you view your source code, and we’ll do a quick search. Just do control or command F, and you look for GTM and you should see a no script version and a regular script version.
If you were to do your control F and you’d see GTM. You can even look for your GTM code here. If you saw this three or four or potentially more times in the source code, that means you have GTM implemented twice, and that will likely result in duplicate tracking, duplicate tagged data being sent to either GA or marketing channels. While we’re in here, there’s another common issue that we’ve seen. It’s the incorrect GTM container ID, or if we actually go into Analytics, and you’re using an incorrect Google Analytics property ID. Sometimes you might have a staging property or potentially a different geo properties. The tracking ID here, we’ve seen this be the wrong ID or it’s set to a dummy account ID, it’s attached to multiple vents, but that data ultimately doesn’t make its way to your Analytics account because it has the wrong tracking ID.
Last but not least, if we look at issue number eight, is sort order. Let’s put GTM back into preview mode here. And I have the expectation that on my product pages, I am expecting Facebook to fire before Twitter. When I’m looking at the sort order of all of my tags that are executing on my site, if you recall, on the previous episode, we’re looking at network panel and tracking how tags are ultimately executing in our network panel. I want to be sure that Facebook is always firing first and Twitter is loading and executing after Facebook, because I really want to minimize any delay in my Facebook pixel from executing. So, reloading the page here. You’ll see I have my Facebook site-wide pixel, and actually I need to fix my syntax error.
All right, so we can actually see the product detail view event did not trigger. My product detail events did not execute on this page. If I reload, we should see this working again. Here we go. So, the syntax error is fixed, and now we can see their product detail view event. On the product detail view event, I see my Facebook product view fired, but if I were to look in my network panel, and reload. We’ll look at our Twitter, we have our Twitter script ultimately fired. You can see it queued up at 873 milliseconds. Just under a second. And if I look at Facebook, we’ll see that this started, for our product view, this started at 1.75 seconds. You might be wondering why, or how can Twitter be executing ahead of Facebook?
If I go over to GTM, and let’s take a look at our Facebook tag. We have our Facebook site-wide pixel, which we saw executing just a little bit ahead of Twitter. This is set at a thousand. We have our product view, so our Facebook product view, this does not have a tag firing priority on it. One fix could be adding a priority of, let’s say, a hundred to this. Where if we look at our Twitter tag, this does not have a priority on it either. If I refresh one more time, it will clear out. All right. Here is our page view and we see the page view is still at 1.65 seconds now. We’ll look at Twitter, and this still started at still less than a second. Why is Twitter still firing ahead of Facebook, even though I’ve set the priority higher on the tag?
Our next step is to start stepping through the events. First one, page view, we can see Twitter is executing first before our Facebook product view. As GTM is going through and loading, you’ll see all these different events that are executing. Six events later is when our Facebook product view event is associated to the product detail view trigger, and that trigger is happening after our original, our first event, which is a page view, which is where Twitter is assigned. If we wanted to ultimately fix this, we can see window loaded comes after product detail view. If we go into our Twitter page view and we will create a window loaded, trigger configuration, window loaded, all pages. Now, if we save, refresh, we should see that Twitter is now going to execute after Facebook.
Go to inspect, go to our network panel, and we’ll do a refresh. Now let’s look at our Twitter. So, here is our Twitter tag that fired, and now this is at 3 seconds. It’s 3.36 seconds. We can see our view content for our Facebook tag that’s starting to execute, starting at 3.21. Our general page view tag for Facebook is at 1.27 seconds, our view content for Facebook is 3.21, and Twitter is just a bit after, 3.36 seconds. That is a very common issue and the three things to look at is looking at your sort order within GTM, to make sure that you have your priority setting, if everything is firing on the same trigger. The next is actually stepping through the events, so you can see just one small change of when we are executing the tag or triggering the tag, we were able to complete my goal of having all my Facebook tags fire before Twitter.
Those are eight common issues. If you have any other issues or good ones to share, please send them along to me. Hopefully this will help you prevent some catastrophic issues to your data collection and data reporting, and hopefully we don’t have any other big ones that pop up soon.