Back in 2017, we first noticed that Google Analytics was able to show data for the year 2029 in various different reports.
We wondered, is this a bug or is Google trying to predict future traffic statistics?
It’s taken us a while but, after much research, we have now come to a conclusion on the conundrum. We believe this is a bug and here’s why
Note – Before you continue reading please note, part of this bug has been fixed in 2020 but we believe that part of it is still there three years later!
It is also worth noting that we have tried to replicate this data at a later date using different websites. However, since the updates, this has been unsuccessful.
If you don’t want to read our initial findings about this bug from back in 2017, you can view our recently updated 2020 version here – Is Google Analytics Predicting Traffic in 2033?
This bug can be seen in different sections in the Google Analytics Software and most of the screenshots shown below are the result of the bug in action. We gathered the normal traffic data from Nov 1, 2016 – Feb 27, 2017, and compared it with data from Nov 1, 2015 – Feb 28, 2017. Please note, the dates supplied here are out by one day. More information on this will be given later on in this post when we explain how to recreate the data.
We will now aim to explain and demonstrate the extent of this bug through screenshots taken from various areas around Google Analytics.
First of all, let’s look at the Audience Overview Section and the areas where we discovered unusual data.
In the screenshot shown below, the dates are accurate but the data that has returned looks unusual. This shows traffic right up until the end of 2017 and, from what we can see, the information is incorrect. We believe this is the bug in action and does not represent data that would be returned from a normal, filtered query.
Let’s take a second and remember the purpose of the ‘Compare’ feature. It is designed to show how your traffic has improved compared to previous years, months, days, etc. It is not. however, designed to compare current traffic to predicted future traffic that does not already exist.
We have noticed the same pattern of report data in the following reports:
We have also noted that this data is duplicating across multiple sections showing the traffic for future dates.
One thing to point out is that in the screenshot above, there is a similarity of data between the normal data in blue (around Feb 2017) and the comparative data in orange (around Feb 2018).
To us, this looks like a duplication of data which is becoming mixed in with accurate information. We also believe the normal data is being copied across to the comparative data. This is a clear demonstration of the impact of this ‘bug’ and the significance it could have on your reports.
Let’s move on and see the other reporting areas where we have noted unusual behaviour.
In the screenshot below, you can see an Active User Report. Here. the data appears even more unrealistic, showing a significant increase in users in 2018. However, the report has only been taken from the available data from 2016-2017. Therefore, this information has not been generated yet and cannot be accurately predicted. If you take a closer look, you can also see a duplication in traffic between the two high spikes for normal traffic in blue (Feb 2017) and comparative traffic in orange (Feb 2018).
The screen shot below shows an Acquisition Overview Report. Here, it is more difficult to determine whether the data shown is incorrect. However, what is evident is that the report, which was pulled in 2017, shows a comparative date range of Nov 1, 2015 – Feb 27, 2019. This puts the information 2 years ahead of the existing date, creating incorrect data. Again, we believe this is the result of this Google Analytics bug that we have identified.
Let’s take a look at yet another report where this bug seems to be in play. Here, the report data for this Acquisition AdWords Accounts shows the same discrepancies for (Acquisition – AdWords (Accounts, Campaigns, Final URLs, Keywords, Search Queries, Sitelinks). Again, it becomes evident that the traffic metrics is duplicating itself as mentioned above.
The comparative date roughly dates back to Feb 2018 and is exactly a year on from the normal filtered traffic from Feb 2017. The information shown is entirely identical which, even if reverse, seems highly unlikely and more realistically a result of said bug.
Here again, although the information varies slightly, the same principle applies. The information from both 2017 and 2018 has been replicated and is therefore inaccurate.
In the screenshots below which showcase Acquisitions – Social Overview / Social Conversions, data has been returned for transactions that have not happened yet. This is not something Google Analytics would have the ability to predict and therefore is, once again, returning incorrect data.
We have also noted the impact of this bug within the Social Media section of Google Analytics. Here, it has reported incorrect data regarding activity on social media buttons from 2018. This report was pulled in 2017 so, once again, it is not possible that this information could be generated accurately.
Once again, these reports are showing transactions and conversions from a future date of 2018 when the report was run in 2017. We believe the bug is to blame for this incorrect information.
By showcasing our findings across various areas of Google Analytics, we hope to help you understand the impact this bug can have on reporting. It is important to note that we have identified these issues on many more sections, of which we will list below.
Now, we will walk you through the steps to reproduce this bug for any website in Google Analytics. This gives you the chance to research and experience it’s impact for yourself without just taking our word for it.
Step 1: Select your date range to view your traffic. As you can see, we have selected Nov 1, 2016 – Feb 27, 2017. Click the apply button to return to the report. Please note, this will work with any date range.
Step 2: Select the Compare option to look at data from a previous date range. We chose the same dates but altered the years, using Nov 1, 2015 – Feb 27, 2016, to compare data from the year before. As you can from the screenshot below, the data looks accurate and seems to be what you would expect it to be.
Step 3: This step and the next is where the bug comes into play. All you need to do to activate the bug is make a simple change to the comparative date. As you can see below, it looks like we have gone to change the compare date to Feb 28, 2017. For the keen eyed readers, this is the same date provided in the original date range section.
Step 4: The end date for the compare date is very misleading. If you change this to 2019, the Apply button will become active once again. Therefore, you can ask Google Analytics to return data from the future within this report.
If you go ahead and click the apply button, the compare end date resets to the current date. For the purpose of this report, our date was Feb 28, 2017. Look at the screenshot below. Google Analytics has somehow managed to return data from the future, past January 2018. This is the bug in action.
Now, we understand this is a lot of information to take in. And, you may be wondering how a simple bug like this causes so much incorrect data. However, before we delve into this, let’s look at how the bug can impact data much further into the future.
Step 1: Keep the normal traffic date the same (Nov 1, 2016 – Feb 27, 2017). Then set the compare traffic date to Nov 1, 2000 – Feb 28, 9999. Yes, this isn’t a typo. We do mean 9999.
We have demonstrated this in the screenshots below. Here, we have not applied the date range yet.
Step 2: Click the apply button and boom! Google Analytics has now returned data for a yearly date range of roughly 2024 – 2029. This shows the full extent of the bug and its ability to impact data for many years to come. For the purpose of accuracy, it is vital that this bug be fixed urgently.
We have applied this data to an Audience Overview and Active Users report, as you can see in the screenshots below.
Below you can see an Acquisition Overview report that we have run with the same compare date set. This returned correct data for the report graphs, but note that the compare date range is now showing Nov 1, 2000 – Feb 28, 9999.
We decided to try to take this a step further. By the time we ran these next reports, we were into March 2017 so this report shown has a different report date range. We changed the normal date to Jan 1, 1002 – Mar 6, 9999 and the compare date to Jan 1, 1001 – Mar 6, 9999.
When we click the apply button, the normal date and compare dates reset to Jan 1, 2005 – Mar 6, 2017, shown by the image below.
The report graph data looked OK, but the dates for the report were showing our original dates. This was Jan 1, 1002 – Mar 6, 9999 for the normal date and Jan 1, 1001 – Mar 6, 9999 for the compare date.
This Google Analytics bug is having a significant impact on the data we have been able to pull for the specified website. With this bug implemented, we are able to move our comparative dates far into the future. And, essentially, this means that Google Analytics is somehow predicting the activity we should expect to see.
In short, the bug allows us to:
Please, note the list above is what we consider the most important takeaways from our findings. It is not extensive.
So after this long blog post, you may be asking yourself one question:
“What is happening and why are you able to create these reports?”
We will try to answer this the best we can and hope this post gets some exposure. Our hope is that it will come to the attention of Google and be fixed.
The following points are areas that we have researched.
From our testing, we have identified a suggested method to fix this bug and prevent inaccurate data being generated. We suggest that Google:
1. Stop the normal date field from showing dates on reports before Nov 14, 2005 and showing dates after the current date. A simple date validation should be able to sort this out.
2. Only allow filtering data on the normal date from Nov 14, 2005. At present, this goes back to Jan 2005 when the product had not been released. Yet again, a date validation will solve this issue.
3. The compare date will need the same rules applied as the normal date, but there will need to be extra validation to stop the date range being applied and showing data in the future. We believe that checking that the compare date is not set to the future should fix this. However, this will need further investigation by Google on their end.
Going through this process of identifying a problem, what is causing it and briefly documenting a suggested fix is a great way to improve new programs. In this example, we have delved into the issues this bug can cause, showcased it in action, explained how to recreate it for yourself and given, what we believe to be is valuable information on how Google can resolve this.
Don’t forget to read the updated version here – Is Google Analytics Predicting Traffic in 2033?