How Google Analytics duplicated code affects metrics – FULL guide
August 31, 2020
- How can you end up with duplicated code?
- How to check if your tracking code snippet is duplicated?
- What’s the damage and what data is reliable?
- How do I fix it?
- Can damaged data be corrected and recovered?
You might be an analytics-savvy marketer – or maybe not. Either way, I’m sure you check your Google Analytics data every now and then.
Especially if you just launched a new marketing tactic, you probably check to see if you have more sessions, more conversions, or probably, better engagement. And as you look at the data, you probably feel confident that it’s 100% accurate.
Bad news. That’s rarely the case.
I recently had a client who had duplicated analytics tracking code on their website – for 2 entire years!
At that time, the first question that came to mind was this – which metrics are affected by the duplicated code?
I didn’t have much luck in finding any comprehensive information about it online, so I started to test, debug and deduce some of the negative effects by simply gathering data both with and without duplicated code. I started comparing the results.
From there, I found the answers I needed.
Now, I know how you can make sense of past data, which metrics are still reliable, which ones aren’t, and why. And I want to share that with you so that you won’t have to go through the same tedious process (and headaches) that I went through.
How can you end up with duplicated code?
There are several ways to implement tracking:
• By simply pasting the latest version of the analytics code into the section of your website’s code. This code is taken directly from your Google Analytics Account.
• By implementing Google Analytics through Google Tag Manager.
• By implementing Google Analytics through a plug-in.
Any combination of 2 implementation methods (like the one below or maybe moving your tracking to GTM without deleting the GA snippet you originally had) will prove deadly for some of your metrics.
And there’s one more thing to watch out for: Google’s tracking code updates.
Once every few years, Google updates their tracking code, which means that you would need to update it on your website as well. This is where one common mistake comes in.
Sometimes, people add the new tracking code but forget to delete the old one. As a result, you end up with two hardcoded GA tracking codes on the website, each filling up your reports with data.
We’ll go through the process of finding each code and how to eliminate one of them a little bit later. First, let’s check if your code is indeed duplicated.
How to check if your tracking code snippet is duplicated?
There are at least 3 ways to check for this. We’re gonna talk about each of them and their specific use cases.
2.1. Google Tag Assistant
Now, this is a tool of many talents. If you don’t have it yet, you can get it here. If we had to choose just one method, this would be it. Why? Because it’s fast and accurate.
Start the recording and then load the page you’d like to check. Here’s how it should look like if you do have duplicated code.
If you click on the yellow error signal, you’ll get:
The error “Same web property ID is tracked twice” is the one you should be looking for.
The non-standard implementation error is not really an error from your end. It’s actually Google’s error that shows if your GTM has more than 6 numbers. So feel free to ignore it; Google will probably fix it soon.
2.2. UTM parameters
Create a link with a unique query parameter, let’s say umt_medium=duplicatedcode.
Now access this link and visit 2 or 3 pages on your website.
Important: Don’t reload any page and don’t go back to any previous page. Make sure you only view each page once and as soon as you finish, hit that x button so you don’t duplicate the page views yourself.
Wait 24 hours for the data to show up in your reports, then create a segment in analytics, including the only session that had the aforementioned UTM parameter.
Apply this segment to the All Pages report.
Here’s how it should look without duplicated code:
If there is more than one page-view for any of the pages you visited then… Houston, we have a problem!
2.3. GA Checker
Here you can just introduce the link of your website and the tool will tell you if your tracking code is duplicated.
Yeah, it’s that easy. But of course, there’s a trick:
This method does not work if you are tracking once through GTM and once through any other method because this tool treats GTM separately.
What’s the damage and what data is reliable?
Regardless of how you ended up with duplicated code, the result is the same: significantly skewed data.
It doesn’t just sound bad.
It IS bad.
There are a few metrics you can still rely on though, and here’s how I found out.
We gathered data for 8 days.
19th July to 22nd July
During these first 4 days, there was just one piece of code. (The way God meant it!)
23rd July to 26th July
During these 4 days, the code was duplicated. (May God have mercy on your data!)
Let’s analyze what changed.
But before that, let me emphasize that I’m 100% sure the data was not caused by fluctuations in traffic. Here’s a screenshot of the sessions throughout the whole period:
As you can see, these are pretty much constant.
Now, the first step would be to look at an overview. To be more precise, Behavior → Overview.
See that not-so-tiny bump in page views?
How ‘bout that unrealistic drop in bounce rate and exit rate?
Yeah, they’re both fake.
Let’s understand why:
Check #1 – Pageviews
According to Google, “A page view (also called page view hit or page tracking hit) is an instance of a page being loaded (or reloaded) in a browser.”
The problem? Each one of your code snippets is sending a hit to Google whenever a page is loaded (or reloaded).
The result? You’re seeing a highly inflated number of page views in all of your reports.
Hint: You can no longer trust page depth. Don’t create segments with it.
Nor look at reports with this dimension.
Check #2 – Bounce Rate
Google defines bounce rate as single-page sessions divided by the total number of sessions. In other words, it’s the percentage of all the sessions on your site where users only viewed a single page and triggered only a single request to the Analytics server.”
The problem? Since your code is sending 2 page-view requests (see Tag Assistant screenshot), GA believes that the user made 2 separate actions, disqualifying it from being called a bounce.
The result? You see an unrealistic bounce rate, close to 0.
Here’s how these look in your graphs:
Check #3 – Exit Rate
Going back to the source: “The exit rate is the number of exits divided by the number of page views for the page or a set of pages. It shows how often users leave that page or set of pages when they view them.
The problem? The number of exits may remain the same. However, the number of page views is duplicated because each snippet is sending a unique page view.
The result? You’ll be seeing an artificially lowered exit rate.
Check #4 – Pages per session
Letting Google speak its truth, “Pages/Session (Average Page Depth) is the average number of pages viewed during a session. Repeated views of a single page are counted.”
I’m gonna go ahead and assume that the bolded sentence makes it pretty much self-explanatory.
Check #5 – Destination goals
Yes, Google registers 2 hits for any destination goal:
But Google is also smart enough to only register one goal per session, which means that if you have a destination goal set for a thank you page, no matter how many times you refresh it (or how many page views you send) within the same session, Google will only register it once in your reports.
How do I fix it?
Regardless of how you ended up here, something has to give. One of the codes must go.
Hint: If you have a choice between GTM and anything else, we strongly recommend choosing GTM. There are many reasons why GTM is better, but now is not the time to get into that.
The first step will be to discover what combination you have:
1. Open Developer Tools – Press CTRL+SHIFT+I or CMD+I on Mac
2. Look for your GA tracking ID (UA-XXXXXXXX-X) – Press CTRL+F or CMD+F on Mac
3. Did you find it twice? Examine them:
a. The two snippets are different versions of GA. Delete the older version. Hint: The global site tag is the most recent version.
b. One of the code snippets is inserted through a plug-in. It’s up to you which you would like to keep (for example, if you are using the same plug-in for e-commerce also, then it’s probably best to stick with the plug-in).
4. You only found it once? Then the other one is most likely inserted through GTM.
5. Go into your GTM account and check for a page view tag with the same tracking ID.
6. Now decide which one is gonna go. (The recommended path here is to stick with GTM and move all your tracking to it).
As for how to actually delete the extra code snippet, there are, of course, so many different types of websites and there’s no way I can give you a step-by-step guide for all of them. I can, however, offer a step-by-step guide for removing the code from a WordPress site.
In some cases, if you have no technical knowledge at all, it might be safest to ask for the help of a developer.
4.1. How to check for a plugin or remove it if necessary
In your WordPress dashboard, go to plugins. Try to see if you can find any GA or GTM plugins. To remove a plugin, you first need to deactivate it. Once you do this, a delete button will appear. Here’s a screenshot of one of the most popular GA plugins.
4.2. How to remove hardcoded GA
If you have a WordPress site, go to appearances, then to the editor, then to the header file (one time I found it in a client’s footer.php file).
4.3. If you do decide to remove the GTM code (which I don’t recommend) here’s how to do it:
GTM can be installed either through a plugin or just hardcoded into the website. To remove it entirely, follow the same instructions mentioned above for GA.
If, however, you don’t want to remove the whole GTM code (maybe you are using it for Hotjar or any other purpose), then you can just remove any universal analytics tags from your GTM account.
Can damaged data be corrected and recovered?
I’ll be honest with you… nope.
Once analytics registers data, there’s no way of changing it. I know it’s sad, believe me, I know.
If you can pinpoint the exact moment when the code got duplicated, then you can put annotations for that specific timeframe and be aware that you shouldn’t use that data in your reports (at least not if you are planning on checking any of the metrics mentioned above).
If you are faced with a perfect storm and you don’t know when the code got duplicated and the account also has other unreliable settings (like goals that have incorrect settings), then it pains me to say it but the safest route would be to declare data bankruptcy…
…and start over fresh.
Analytics may seem easy – but analytics done right is not.
There are so many mistakes you can make along the way and there’s no turning the clock on data.
Best way to avoid them (besides hiring an expert who’s been working with and studying this for years)?
MAKE A PLAN.
Don’t make any changes to your tracking without having a measurement plan, and without laying out the steps ahead.
Doing this can save you a lot of trouble. If something does go wrong, having a plan for each step will make it way easier to zero in on any specific mistake.
If you’re asking yourself something along the lines “But how do I even start?” here’s an article on how to create a comprehensive analytics measurement plan from scratch.