: What Are 20 Common Reasons for Incorrect Pageviews Having gone through a large number of unanswered questions on here as well as going through some new questions asked I have come across the

@Berumen354

Blame Your Expectations:
This one hasn't really been a big issue on here in the past but still deserves an honourable mention. If your only reason for thinking that your pageviews are wrong are that they aren't at the level you expect them to be, especially when first starting out, don't panic, this doesn't mean there is anything wrong to be fixed. Definitely go through the list below in case there is a problem to be fixed but be prepared to live with a lower page view that you may expect, want, or thought was reality.

Using Old Code:
There is a large amount of old code for Google Analytics out there, especially in pre-canned plugins where you simply add your tracking code and leave it at that. Google Analytics has gone through several version changes over recent years and older versions are simply not as accurate as some of the newer code. If you are using older Google Analytics code (such as the old ga.js code) then you will want to upgrade to Google Tag Manager or Universal Analytics.

Bad Code Location:
Along with old code there are old code placement methods. Some developers will tell you that Google Analytics code should be placed at the bottom of the page and insist on doing this (arguably for page load time and non-blocking reasons), but those rules are a number of years old. Universal Analytics and especially Google Tag Manager are designed out of the box to be placed right after the opening body tag, this is in fact the recommended placement for the code snippets by Google themselves (and you would assume they would know best).

Missing Tracking Code:
It actually helps to have the correct tracking code on all the pages you want to track. I have spoken to some developers in the past who have thought that by adding it to the main homepage Google automatically knows to track all pages under that domain, unfortunately that is not the case. The only way Google has to know that a page needs to be tracked is to add the tracking code to each and every page that needs to be tracked. Google Analytics does have a fancy admin feature on this though, which is powered by the standard Googlebot crawling. Using Googlebot Google checks all the known pages under the domain and identifies pages which don't have the tracking code added, now while Google can't track the pages yet, they do show an alert on your Google Analytics console to inform you that there are a number of pages on your site that are missing the tracking code and not being tracked, but don't depend on this, make sure to add it to each and every page, and if using a content management system, add it to the core template so that it is automatically included on each and every page under the CMS.

Incorrect Tracking Code:
Sometimes the tracking code on the page is just plain wrong. Somehow an error has been inserted into the code, and it just breaks. Sometimes the wrong Google Analytics property is listed and data is being sent to the wrong Google Analytics account. If the code is wrong for whatever reason you are not going to collect data from it so open your Google Analytics and take a look at the Google generated property code and then compare it to the code already on your pages, is there a difference, if so fix it.

Double Tracking:
If your code is great, and in the right place, and is reporting without a problem, but you have it on the page more than once that is what is known as double tracking. The tracking code will fire two pageview events. This is often caused by adding the updated Google Analytics code to the page without removing the old code. This can be some of the worst news to a marketing executive, needing to tell them "Hey, you know how you where wrong about our pageviews, well you where right to be worried, they are actually half what the reports say".

Custom Code:
Custom code isn't all that bad but you can easily do bad things to it. When you send a hit you can pretty much change anything about it including the URL that Google Analytics sees. There are numerous problems that can crop up because of custom code being used instead of the actual Google Analytics or Google Tag Manager code. I have seen this done before for a 0'000 government website redevelopment and it took months to identify the issue.

Locally Hosted analytics.js:
Regardless of whether you are using ga.js, analytics.js, ua.js, etc, don't save it to your own web server and host it from there, let Google serve the latest correct version for you. If Google makes a change to the javascript file (which they do quite often) and don't tell you what they changed (which the often don't) then you will be sending data to Google using an old file when Google is expecting data in another format or to another endpoint being sent through the correct code, and in this instance everything just breaks.

AJAX Frameworks:
Sites that use AJAX frameworks such as Single Page Apps or custom variations on the same can do a variety of things where page content changes but a pageview event is not fired, usually through the page rewriting itself instead of reloading. If your site uses AJAX in this way then you need to plan for this and fire virtual pageviews when the page changes, rather than relying on a normal page load that's not going to happen for Google Analytics to detect. Page views are fired when the page loads, if the content is swapped or substantially altered without a page reload then no additional pageviews are recorded.

Virtual Pageviews Instead of Events:
Sometimes a developer or webmaster may use virtual pageviews where an Analytics Event is more appropriate. If you're firing pageviews when someone scrolls down the page or clicks on a banner, your pageview figures are going to artificially skyrocket when the vast majority of them are not actually pageviews. Remember a pageview should be fired when the substance of the page changes, such as new content being on the page, anything else is an event.

Frames, Frames, and IFrames:
If you put your code on every page but then use frames heavily on your site you could be loading one page but wind up with multiple pageviews all firing thanks to the frames. Google Analytics doesn't automatically reject analytics from frames as you may actually be wanting to track them.

META Refresh:
I encountered a strange problem which had me laughing after a few hours of searching. A company dashboard which was still in staging and not deployed to the public yet was recording a new pageview every 5 seconds on the nose and yet no one was meant to be using this dashboard yet at all. Of course this was initially flagged by security as a hacking attempt but after I reviewed server logs and checked the site HTML I found that one of the developers had added a META refresh tag to the top of the dashboard page to save them from needing to click refresh each time they updated something minor in the UI (live code changes to staging at this time).

Bad Filters:
Bad filters in Google Analytics can destroy otherwise amazing reports. Incorrectly using an exclusion or inclusion filter can cause you to loose significant traffic from your reports, even all of it, even though the traffic is actually going to the site with no issues.

Query Parameters:
Query parameters in your URL will cause the data to be split into different buckets. Where appropriate use the exclude URL query parameters feature to remove any query parameters that aren't meaningful to your analysis. As a hint pageview reports generally don't need to be broken up by page number query parameters.

Bad Triggers:
If you are using Google Tag Manager, your analytics tag may not be firing on the right pages because you set up a bad trigger. If your triggers are bad then your tags won't fire and your pageviews won't get tracked. There are lots of ways you can have triggers setup so the best option is to go back to the Google Tag Manager console and follow their step by step guides to suit your own specific implementation.

Container Version Not Published:
So you have made sure your triggers are all good, but what use is it if your tag container version is not published and the published version contains something else. Make sure you are working with the correct version of the published container.

Robots, SPAM, and Spiders:
There is a ridiculously huge amount of traffic on the internet these days originating with robots, spam, and spiders. Using a robots.txt file you can control access to your site from robots and spiders which follow the rules and are legitimate (most search engines), additionally Google Analytics is generally intelligent enough to differentiate between a search engine robot and a user if the robot is following the rules. Spiders on the other hand indiscriminately crawl the internet scanning entire websites (often to download the entire site to the local disk such as HTCopy), unfortunately there is no practical way to prevent this as these spiders often don't respect a robots.txt file anyway. SPAM is more of a concern for web forms but can still cause pageview inconsistencies due to it not being a genuine visit. While you generally can filter this out based on hostnames there is no real way to prevent it in advance so you need to be prepared for it.

User Disabled Javascript and/or Cookies:
Not much that can be done about this one, when users disable javascript and cookies (usually for security reasons) there is no way to track the users due to the fact that analytics depends on javascript and cookies to properly work.

Sampling of Data:
I have answered that many questions for clients, questions on Stack Exchange, and on other sites regarding sampling you would be amazed. As a quick explanation sampling occurs where you have so much data that whenever you look at anything other than a standard report, by adding another dimension for instance, you will get sampled data. Why is this, it is because while the standard reports are already compiled by Google compiling an analytical report of the raw data takes a fair bit of computational power and hence time, when you have a huge amount of data the way Google speeds this up is to sample the data only instead of compiling all of the data. The important thing to remember is that when you are looking at sampled data the numbers will not be accurate, and how inaccurate they are can vary. I am not personally a fan of sampled data, especially in traffic analysis, but as long as you realise that the data is sampled you can start to work with the data treating it as such.

Real Time Data:
Pageviews take time to process, anywhere up to a few hours depending on how well Google is doing at the time and how much data from other clients Google is processing at the same time. If you are wanting to get a better understanding of how many hits your site got at a specific time of day the best thing to do is wait until the following day to give all the data a chance to be processed. You can look at the real time reports to see if hits are coming in, but don't read the standard reports as accurate until the following day (and that doesn't mean midnight, that means start of business the next morning when the sun is up).

The important thing to note here is that while this is a fairly comprehensive list these are just the more common issues. For every single reason on this list there are dozens more which have not been covered. In most cases the problem will be with how analytics has been implemented on your site or how you have configured the interface to read the reports.

Vote Up Vote Down