20+ Reasons Your Google Analytics Pageviews Are Wrong
[If you came here, you may be in a situation where your pageviews in Google Analytics aren’t matching your expectations. We often hear clients questioning the validity of their data, and specifically, the count of pageviews.
Why are my pageviews wrong in Google Analytics?
Sometimes the entire site’s pageviews are wrong. They’re much higher than expected, or much lower. Or maybe there was some sort of dramatic change and they don’t understand why. Sometimes it’s just a single page that isn’t tracking, or an entire folder, or a subdomain, or set of landing pages, or goal conversion page. Why is it wrong?
The heart of Google Analytics is the Pageview.
The most basic default hit that gets sent automatically on the load of a page is the pageview. Many other metrics, such as Bounce Rate, depend on an accurate accounting of the pageviews on your website.
Yet, there are so many ways that you can get incorrect information, and it’s usually not the fault of Google, but someone else’s. Sometimes it’s the developer’s fault for implementing something incorrectly, sometimes it’s the analyst’s fault for configuring Google Analytics incorrectly, and sometimes it’s someone else affecting your data and you need to do something to protect yourself.
Ready? Ok, let’s go through some of the more common, and uncommon, ways that your pageviews can get messed up.
BLAME YOUR EXPECTATIONS!!!!
0. Your Expectations Don’t Matter
This doesn’t even deserve a number, but it does deserve a mention. If your pageviews aren’t meeting your expectations, that doesn’t necessarily mean that the tracking is faulty. Definitely look for the problems below, but your first step is humility. Be prepared to accept a lower pageview count than you might expect, or want, or thought was reality.
BLAME THE DEVELOPER!!!!
1. Using Old Code
There’s lots of old code out there. Multiple versions of Google Analytics have been released, and older versions are simply not as accurate as the newer code. If you’re using old code on your site, you’ll want to upgrade to Google Tag Manager and Universal Analytics to improve the accuracy of your pageviews.
Published: March 23, 2017
2. Bad Code Location
Along with old code, there are also old ways of implementing the code. Sometimes developers remember that the Google Analytics code should be put at the bottom of the page, and insist on doing that, but those rules are more than 6 years and 2 versions of Google Analytics old. We have a few posts about this including:
Published: November 22, 2016
3. Missing Tracking Code
Dorcas mentions this in her post 5 Common Mistakes in Your Google Analytics Tracking Code. It helps to actually have the tracking code on the page. We frequently see tracking code completely missing from entire sites, or from specific pages or subfolders of sites, or from specific subdomains. If the tracking code isn’t on the page, it’s not going to track any pageviews.
4. Incorrect Tracking Code
Sometimes the code is on the page but it’s just wrong. Somehow errors were inserted, and the code now has “smart/curly” quotes instead of standard ones, and it just breaks. Sometimes the wrong Google Analytics property is listed and the data is getting sent nobody knows where. If the code is flat out wrong, for whatever reason, you’re not going to collect the data from it.
5. Double Tracking
Too much of a good thing? Even if the code is great, and in the right place, and on all the pages, if you have it on the page more than once then you’re going to get what we call Double Tracking, that is every time the page loads, it’ll fire two pageviews. Often this is caused by adding new updated code to the page, but not removing the older legacy code. This is also some of the worst news to deliver to a client. “Hey you know how you were already concerned about your traffic… Well hold onto something… It’s actually half what you thought.”
6. Custom Code
Custom code itself isn’t bad, but you can easily do bad things to it. Like rewrite all your pagenames. When you send a hit you can change pretty much any information about it including the URL that Google Analytics sees. You could literally re-write all the URL’s on your site to look like they were hits to the home page. There are numerous problems that can crop up because of this.
7. Locally hosted analytics.js
This is just generally dumb. Don’t do it. Let Google Analytics serve the most up to date code to you.
8. Ajax Frameworks
Sites that use an Ajax framework can do a variety of things to not fire the right pageviews, usually with the pages rewriting themselves rather than reloading using a variety of techniques. If your site uses Ajax, you need to account for this, and fire Virtual Pageviews when the page changes, rather than relying on the normal page load for Google Analytics. Pageviews fire when the page loads. If the content swaps out but the page isn’t reloaded, then no additional pageviews.
9. Virtual Pageviews Instead of Events
Speaking of Virtual Pageviews, sometimes these can be fired on a page instead of using a Google Analytics Event. If you’re firing a pageview when someone scrolls the page, or clicks on a banner, your pageview numbers will be affected. Use Events where it’s appropriate, rather than Virtual Pageviews. I wrote before about when you can appropriately Fire a Virtual Pageview in Google Tag Manager.
10. Iframes
If you put your code on every page, but then use Iframes heavily on your site, you could load one page, but get 2 or more pageviews thanks to all your iframes firing their own. Be careful when firing pageviews within iframes.
11. Meta Refreshes
Other sites will automatically refresh the page every so often, sometimes for content, but usually to serve new ads. This can fire another pageview, and suddenly it’s like you have double tracking on the page.
BLAME THE ANALYST!!!!
12. Bad Filters
Bad filters in Google Analytics are a great way to destroy your data. The incorrect use of an include or exclude filter can cause you to lose significant traffic, even all of it. Any filter that is including only certain traffic, excluding other traffic, or using a search and replace or advanced filter to modify your data can destroy it. Make sure your filters are correct, and always maintain an Unfiltered View that never has any filters applied to it, ever. We have some oldie but goodie blog posts on mistakes with filters including Mistakes with Include Filters as well as newer post about Basic Google Analytics Filters for Every Site.
13. Lack of Good Filters
Good filters can make your data better. Filters to clean your data and lowercase everything to combine pages with different capitalization into a single row of data. Advanced filters to change or clean up other bad data which is otherwise dispersing your pages into different row of data. Here’s Jonathan’s post about Cleaning URL’s in Google Analytics.
14. Default Pages
Incorrect use of the default page feature can also cause pages to be split up in your data. Consider whether you want, or don’t want, to use this feature, and be consistent. The amazing Jon Meck wrote about The Google Analytics Default Page.
15. Query Parameters
Query parameters on your URL’s will split your data up into different buckets, so you want to use the Exclude URL Query Parameters feature when appropriate to remove any query parameters that aren’t meaningful to your analysis. If they’re important, but disparate, you also move them out of the URL when appropriate and into a custom dimension instead, so that you still have the data for analysis, but your page rows are condensed. Samantha wrote about Methods to Strip Queries from URLs in Google Analytics.
BLAME BRIAN KUHN!!!!!!!
16. Bad Triggers
If you are using Google Tag Manager, your tag might not be firing on the right pages, because you’ve set up bad Triggers. If your triggers are bad, your tags won’t fire, and your pageviews won’t get tracked. Lots of ways you can have triggers, but good ole Jon Meck wrote about some double negative trigger exceptions in GTM, which is just one way in many people could get tripped up.
17. Container Version Not Published
Another common thing is to have great tags and triggers, but they actually aren’t published, and the published version of your Google Tag Manager container has something else. Be sure that you are working with the right published container.
BLAME THE EVIL OF HUMANITY!!!
18. Robots, Spam, & Spiders: Oh my!
Lots of traffic can be generated by Robots, Spambots, Spiderbots, bots, bots, bots. Follow as many ways to restrict this bad traffic as you can. We’ve written extensively on this subject, and have the ultimate guide to eliminating bot traffic from Google Analytics that Alex Moore wrote up. (Note the date…)
19. Someone Else is Doing #4
Instead of you sending your data somewhere else, someone is sending theirs to you. Or maybe you’re sending the data from one of your sites, to the wrong property. Either way the Google Analytics property is getting data from somewhere it’s not supposed to. Usually this can be filtered out by excluding hostnames.
20. Third Party Widgets
Sometimes you’ll feed your Google Analytics property id into a third party widget that gets inserted onto your page to track it. Unfortunately, this often results in something technically similar to #10 where the widget inserts an iframe onto your page, firing pageviews, and suddenly your on page events look like they’re being fired from /modal/emailform.html
21. User Disabled JavaScript and/or Cookies
The security conscious, or even paranoid, may turn off their browser’s automatic use of javascript and/or cookies on a website. If that’s the case, then Google Analytics won’t work, and you won’t be able to track them. Generally this is a small number, even when combined with #22 below, but on certain sites, in certain segments the number could be significant, particularly on tech or security websites where the audience is more knowledgeable/paranoid.
22. Adblockers and Script Blockers
Some users rather than turning of JavaScript and Cookies, because they realize the modern web relies on them so heavily, will instead turn to Adblockers and other browser extensions that will block the loading of certain files. Particularly Advertising and display ads, but often they’ll also block tracking scripts. Some extensions will even block Google Tag Manager. Like #21 often this is a small number, but depending on what your site is, and who the audience for it is, the number could climb and you could be missing out on significant numbers.
BLAME GOOGLE!!!
23. Sampling
We’ve written before about sampling. That’s where you have so much data that whenever you look at anything other than a standard report, by say adding a secondary dimension or custom segment, you will get sampled data. When you are looking at sampled data, the numbers will NOT be accurate, but it’s really just a matter of HOW inaccurate. I’m not a fan of doing ANYTHING with sampled data. Find a way around sampling in Google Analytics however you can, and realize that sampled numbers are not exact numbers. I put together some solutions to get around Google Analytics Sampling.
24. Real Time Data
Pageviews take time to process. They might show up in 5 minutes, but they might show up in 4 hours. If you’re dealing with a mobile app, the dispatch process might not take place until HOURS later, so if you want to get a better understanding of how many hits your site/app got at a specific time of day, it’s best to wait till the following day after all the data has had a chance to be processed, and in some cases re-processed. You can look in the Real Time reports to see if hits are coming in, but don’t consider anything in the standard reports set until the following day. (And I don’t mean at midnight, I mean by say 8am the following morning).
AND THAT’S NOT ALL!!!!!
25. These are just the highlights
There are other ways your pageviews could be wrong. Lots of specific custom ways you could be getting your data wrong. In most cases though if you’re seeing data that doesn’t jive with your understanding, then don’t jump and blame Google Analytics. In almost all cases the problem is with how you’ve implemented Google Analytics or how you’ve configured the interface.
And in some cases, you can blame Brian Kuhn.
Love ya Brian!
