If you are reading this blog post, there are two possible reasons for that: you stumbled upon it by following your curiosity or you have recently hit certain limits in Google Analytics (or maybe you are about to hit them).
Anyway, here’s a situation. One day, when you are about to make a coffee, you get this warning from Google Analytics (the wording might change eventually):
“Your data volume (XXX hits) exceeds the limit of 10M hits per month as outlined in our Terms of Service. If you continue to exceed the limit, we will stop processing new data on XXX.”
What to do? You can start panicking but, eventually, you’ll need to take care of this.
Just like pretty much any tool, Google Analytics has also some limits. But when you think about the fact that you are using the free version, 10 million hits a month is a pretty darn large limit. If you are reaching it for the first time with a certain property, then there is (most likely) some room for improvement.
Nevertheless, if you are reaching that level, you need to make choices and implement solutions.
There are several options (paid and free) for how you can approach this. In this guide, I will explain how to deal with two Google Analytics Limits, 10M hits/month and 500 hits/session.
Table of Contents
+ Show table of contents +
- What are the usage limits in Google Analytics?
- What is a hit in Google Analytics?
- How can you identify whether you are close to reaching Google Analytics hit limits (or already hitting them)?
- What are the solutions to the hit limit in Google Analytics?
- Upgrade to Google Analytics 360
- Reduce the number of hits sent to Google Analytics
- How to reduce the number of hits in Google Analytics?
- #1. Stop tracking scroll events (or vastly reduce the usage of it)
- #2. Video tracking
- #3. Hover tracking
- #4. Time-related events to adjust the bounce rate and measure time on page
- #5. Double tagging
- #6. Combine Ecommerce product impressions and promotions views with other actions
- #7. Combine Ecommerce product impressions and promotions views into larger batches
- #8. Send the product impressions and promotion views then they are actually displayed
- #9. Single-page application? Check how the pageviews are being tracked
- #10. Tracking JavaScript errors?
- #11. Move some websites to other properties
- #12. Check your most popular events in GA reports
- Thoughts on solutions that count pageviews per GA session and later start a new session
- Final words
What are the usage limits in Google Analytics?
There are various limits in Google Analytics. For example, collection limits and quotas:
- 10 million hits per property (free plan)
- 200 000 hits per user per day (free and paid)
- 500 hits per session, etc. (free and paid)
We can also talk about dimensions, metrics:
- 20 custom dimensions (free plan)
- 20 custom metrics (free plan)
- 5 calculated metrics (free plan)
And these are just a fraction of the limits that are applicable to GA. There are also account limits, property limits, row limits, etc.
Just like (probably) everyone else, I wish we could have more custom dimensions and metrics for free. But hey, you are already getting a suite of powerful features at no cost. When you think about that, then the limits start to look more generous (at least most of them).
In this article, I wanted to focus more not on the negative side of the limitations (while crying in the corner and mumbling HOW can I continue living with these limits?). Instead, I wanted to focus on two particular numbers and how to deal with them: the monthly 10 million hit and 500 hits/session limits. We need to look for possibilities and solutions.
But before that, you might be wondering what are the possible implications of those two Google Analytics limits:
- If a session has more hits than 500, then the 501st and all the subsequent hits will not be recorded by GA (unless a new session starts)
- If you reach the 10 million hits/month limit, you should be eventually reached by the Google’s sales reps and will be asked to upgrade to the paid version 360. To my knowledge, even if you exceed the limit, the data collection will not stop immediately. Therefore, you probably still have time to tackle this issue.
Important: these limits apply to Universal Analytics. I am not talking about the new App+Web version. These are two very distinct GA versions with their own structure and limits.
What is a hit in Google Analytics?
A hit is a request that is sent to Google Analytics with the hit type of:
- pageview
- event
- screenview
- social
- timing
- transaction
- item
- exception
The more data you send to Google Analytics, the faster you are approaching towards the 10M limit (of course if your traffic volume is significant).
When it comes to the 500 hits/session limit, not every hit type is counted here. Item and Transaction hits (that are a part of the Standard Ecommerce implementation) are not counted. But this applies just to the Standard Ecommerce. Enhanced Ecommerce is using pageviews or events, hence those hits apply to the 500 hits/session limit.
I am not sure about the exception type here. I, honestly, have never used it in any of my setups + I could not find the info about it in any official docs. I have to admit I was a bit lazy to try this on my own. Most likely, you are not using it anyway, right?
How can you identify whether you are close to reaching Google Analytics hit limits (or already hitting them)?
The good news is that it is fairly simple to check whether you are close to them. First, let’s start with the 10M.
Are you close to the 10M limit in Google Analytics?
Go to the Admin section of your Google Analytics Property > Property Settings and scroll down a bit. Eventually, you should see the Property Hit Volume section that looks like this:
See the Last 30 Days number? Is it close to 10 million? If yes, then continue reading to learn some tips on how to tackle this situation. If not, then think about your growth rate. Is your monthly traffic steady or growing? You can check your standard pageview and event reports to see that.
If your numbers are constantly growing, you might get a rough idea of when you will be approaching the 10M limit (if you ever do that, at all).
Are you close to the 500 hits/session limit in Google Analytics?
If you think that “it is impossible for my visitors to have more than 500 hits per session” but you also have implemented the full setup of the Enhanced Ecommerce, think again.
Normally, I’d say, that 500 hits/session limit is indeed quite large but if you are also tracking things like product or promotion impressions with Enhanced Ecommerce, scroll tracking and maybe even button hovers, then that risk is much higher.
To verify your hits/session numbers, you will need to do some additional configuration in GA, then collect the data for a week or so and then check the results.
Here is the recipe:
- Create a “session ID” custom dimension in Google Analytics
- Create a custom report in GA that will output session IDs and the number of hits
The first ingredient is borrowed from Simo Ahava’s blog post. Go to Google Tag Manager container of your website > Variables > New > Custom JavaScript and paste this code:
function () { // Public Domain/MIT
var d = new Date().getTime();
if (typeof performance !== 'undefined' && typeof performance.now === 'function'){
d += performance.now(); //use high-precision timer if available
}
return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function (c) {
var r = (d + Math.random() * 16) % 16 | 0;
d = Math.floor(d / 16);
return (c === 'x' ? r : (r & 0x3 | 0x8)).toString(16);
});
}
You can name this variable cjs – session id.
Then open your Google Analytics > Admin > Custom Definitions (in the Property column) > Custom Dimensions. Create a new Custom Dimension, name it “Session ID”. Choose “Session” as a scope.
Save the dimension and memorize the Dimension Index that you’ll see afterward.
Finally, go to the Google Tag Manager container of your website, open the Google Analytics Settings Variable, go to More Settings > Custom Dimensions > Add Custom Dimension. Enter the number (index) of the recently created dimension and then insert the Custom JavaScript variable.
Save the variable. The idea of this setup is that the variable will always keep returning random values for every hit. However, since we are dealing with the session-scoped custom dimension, the value of the last hit in the session will be applied to all the hits in that session. In other words, all hits within the same session will eventually get the same session id.
After you test the variable and publish these changes, you will need to wait for a while. If you are getting, say, 10 000+ sessions per day, I think it should be enough to wait for several days. If your traffic is lower, then wait for a week or maybe even more.
Once the time has passed, create a custom report to verify whether the 500 hits/session limit is actually a problem for you.
In Google Analytics, go to Customization > Custom Reports and click New Custom Report. Then enter the following settings:
- Title: Hits per session ID
- Metric groups > Add Metric > Hits
- Dimension Drilldowns > Add Dimension > Session ID (this is your custom dimension)
Save the report and then sort the Hits column from largest to smallest values. Do you see any sessions that reached the 500 session limit? Every row is a separate session.
Do you see any sessions that are close to that limit?
If you got just several of them, that is not a big deal. But if you see a lot of them, then you need to take action. I’ll give you some tips.
Update: while writing this blog post, I also noticed that Mehdi Oudjida has created a Data Studio Dashboard that helps you see these limits in a single place. The report displays the 10M/month, 500 hits/session, and 150 000 hits/user/day limits. Check it out! Also, you can see how the number of your monthly hits has been changing over the last 13 months.
What are the solutions to the hit limit in Google Analytics?
There are mainly two approaches here:
- Upgrade to the premium version of GA
- Reduce the data sent to GA or move some websites to a different property
Important: GA filters do not solve the hit limits
If you are thinking of implementing GA filters to exclude certain events, that will not work. Filters work on the View Level. The 10M and 500 hit Google Analytics limits apply to the property.
Solution #1: Upgrade to Google Analytics 360
This is a paid option that costs $150 000 per year. I am not a reseller, therefore, I will not do a pitch here. Just keep in mind that with the paid version, you are getting MUCH higher monthly hit limits (2 billion hits per month), more custom dimensions, more metrics, more integrations, etc.
However, the 500 hits/session limit applies even to the 360 version. I have heard some people mentioning that it is possible to talk to the people from Google to increase that limit (manually) on 360 but I am not sure these claims are real.
Solution #2: Reduce the number of hits sent to Google Analytics
If you don’t have $150 000 lying around in your pocket, the free (or a much cheaper) option is to audit your current setup and reduce the number of hits that are sent to Google Analytics. You can either do that by yourself (this might also require developer’s input) or you can hire someone to do the job for you (or at least give you concrete recommendation on what to do). For example, you can hire me for that.
How to reduce the number of hits in Google Analytics?
Here are some of the ideas on how you can reduce the number of hits in Google Analytics. By doing so, you will solve two challenges at the same time:
- 10M hits/month limit
- 500 hits/session limit (if you have this problem at all)
#1. Stop tracking scroll events (or vastly reduce the usage of it)
With the rise of Google Tag Manager, scroll tracking was popularized among the Google Analytics users. Everything started with Custom JavaScript code and then continued with the built-in scroll tracking functionality.
While this might sound cool and exciting, you need to keep in mind that usually, marketers/analysts are implementing the following scroll tracking thresholds: 25%, 50%, 75%, 90% (or 100%). This means that if a visitor scrolls down past a threshold, an event will be sent to Google Analytics. If a visitor lands on your site, scrolls till the bottom, that’s 5 hits (one pageview and 4 events). If the same happens on the 2nd pageview, that’s additional 5 events.
If you are heavily tracking a lot of interactions, the numbers add up quickly.
Also, when was the last time you actually found the scroll data useful and made a decision based on that? Have you ever made a decision based on the scroll data? If yes, then do you need to track scrolling on every page? Or maybe you should track just on landing (and other key) pages?
If you enabled the scroll trigger just on a certain set of pages, then this would reduce the number of hits sent to Google Analytics.
If you have never used the scroll data in GA (even though you collect it), maybe it’s time to get rid of that at all?
If you think that scroll data is still valuable in your reports, do you really need to track the scroll every 25%? Maybe it would be enough to track 50% and 90% thresholds?
There is no single correct answer here. I just wanted to raise questions and make you think about the usefulness of the scroll data in Google Analytics. Consider removing it from your setup or reducing the number of events by having larger gaps between scroll thresholds.
#2. Video tracking
Video tracking is another popular type of events among Google Analytics users. You can track Youtube with the built-in functionality and also you can implement custom solutions for non-google-owned players.
But what kind of events are you tracking? Play? Pause? Progress (10%, 20%, etc.)?
Do you need ALL of those events in your reports? When was the last time you draw some conclusions and took some action based on the video data?
Don’t get me wrong. I think that video data is much more useful than scrolling but try to look for ways of how to reduce the number of hits.
What are the thresholds of video progress that you are tracking? If you track every 10% and a visitor watches, say, 90% of it, that’s 9 hits just from one user. Maybe it would be ok to reduce the number of thresholds to 10%, 25%, 50%, 75%, 100%? Or maybe use even less? Like 10%, 50%, 90%? This decision is up to you. Just food for thought.
Speaking of the Youtube trigger, there are also other types of events that you can track in Google Tag Manager: Pause, Seeking, Buffering.
If you have enabled them, think – do you really need them? Have you ever found “Pause” event valuable? It is much more important to track whether a visitor started watching a video (rather than pausing it), right?
That is why my personal preference is this:
#3. Hover tracking
Are you tracking when a visitor hovers a mouse cursor over certain website elements? Because you can do that. Are you tracking hovers only on a small set of important elements (most likely, buttons)? Or are you more on the track-all-the-things side? Because if it is the latter, this is definitely a problem.
Think about:
- Have you ever used that hover data at all to take some action?
- If yes, then maybe there is just a set of elements that should be tracked with this method? If your current tracking is too broad, your pile of hits sent to GA is growing.
#4. Time-related events to adjust the bounce rate and measure time on page
Even though it’s 2020, people are still boasting about their bounce rate being less than 20% when in reality, this metric is incredibly easy to manipulate. And to do that, they send additional events (or at least one).
Some marketers like to send an event to GA after a visitor has spent 10 seconds (or so) on a site. If you do that, that’s an additional hit. On. Every. Pageview (if the user keeps the window open for 10 seconds).
If you have 1 000 000 pageviews per month, then you will probably have at least 500 000 additional hits (of course, this depends on your traffic quality). You could easily get rid of that.
Other marketers/analysts send an event to GA every one minute (so that they would have “more accurate time on page metric” which still does not become accurate enough even after that setup).
These events mean that you are increasing the number of hits to Google Analytics. Do you really need them?
First of all, an artificially low bounce rate is a bad thing. You basically destroy the metric and render it useless.
Additionally, have you ever taken some action based on that super low-bounce rate or an artificially increased time on page in your Google Analytics reports?
#5. Double tagging
Let’s continue the topic of artificially lowered bounce rate. This “phenomenon” does not always happen because a marketer/analyst did it intentionally. Sometimes, that happens because of a misconfiguration.
I have posted another blog post where I cover several reasons why your bounce rate might be broken and some of those reasons result in multiple hits sent to Google Analytics. Here are the links to specific chapters if you are interested to learn more:
- Double tagging
- Poor migration from hardcoded GA to GA via GTM
- Some e-commerce hits fire together with a pageview
- Some other events are fired together with a pageview
- In the single-page application, the virtual pageview is sent right after a regular pageview
#6. Combine Ecommerce product impressions and promotion views with other actions
If you have ever implemented Enhanced Ecommerce in Google Analytics, you should know that there are two ways how to EE send data. It’s either to attach the EE data to the pageview or to an event.
Enhanced Ecommerce allows you to track various funnel steps (a.k.a. actions), such as product detail view, add to cart, checkout, purchase, etc. However, people often do one mistake. They try to send multiple Enhanced Ecommerce actions with a single dataLayer.push.
If you try to send the add to cart and the checkout with the same hit, that will not work (I have described it in the tip #7 here). One hit = one EE action.
But there are some exceptions. You can send the product impression data (when products are displayed in the list) and promotion views together with other EE actions.
So, if you have one dataLayer.push with the product impression…
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
'event': 'eec.productImpression',
'ecommerce': {
'currencyCode': 'EUR',
'impressions': [
{
'name': 'Citizen - SUPER TITANIUM. MODEL: AW0060-11P',
'id': 'CIT30283',
'price': '330.00',
'brand': 'Citizen',
'category': 'Watches',
'variant': 'Silver',
'list': 'related products',
'position': '1'
},
{
'name': 'Citizen - BUSINESS CLASS. MODEL: BC0099-11Z',
'id': 'CIT30288',
'price': '290.00',
'brand': 'Citizen',
'category': 'Watches',
'variant': 'Silver',
'list': 'related products',
'position': '2' }]
}
});
and then another dataLayer.push that is activated immediately after the first push and that push contains the product detail…
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
'event': 'eec.productDetail',
'ecommerce': {
'detail': {
'actionField': {'list': 'homepage'},
'products': [{
'name': 'Citizen - SUPER TITANIUM. MODEL: AW0060-11P',
'id': 'CIT30283',
'price': '330.00',
'brand': 'Citizen',
'category': 'Watches',
'variant': 'Silver'
}]
}
}
});
…you can ask a developer to combine them into a single dataLayer.push. That way you will send one hit instead of two. On high-volume e-commerce websites, that is quite a significant optimization when it comes to GA hit limits.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
'event': 'eec.productImpression',
'ecommerce': {
'currencyCode': 'EUR',
'detail': {
'actionField': {'list': 'homepage'},
'products': [{
'name': 'Citizen - SUPER TITANIUM. MODEL: AW0060-11P',
'id': 'CIT30283',
'price': '330.00',
'brand': 'Citizen',
'category': 'Watches',
'variant': 'Silver'
}]
},
'impressions': [
{
'name': 'Citizen - SUPER TITANIUM. MODEL: AW0060-11P',
'id': 'CIT30283',
'price': '330.00',
'brand': 'Citizen',
'category': 'Watches',
'variant': 'Silver',
'list': 'related products',
'position': '1'
},
{
'name': 'Citizen - BUSINESS CLASS. MODEL: BC0099-11Z',
'id': 'CIT30288',
'price': '290.00',
'brand': 'Citizen',
'category': 'Watches',
'variant': 'Silver',
'list': 'related products',
'position': '2'
}]
}
});
But this is a slippery slope. If your single request to Google Analytics is too large (larger than 8kb), then the hit will also not be sent. Read tip #10.
#7. Combine Ecommerce product impressions and promotions views into larger batches
How often are the product impressions or promotion views sent to GA? Every 10 products? Every 6 promotions? One of the possible ways to reduce the number of hits sent to Google Analytics is to include more products in a single request.
But this is a slippery slope too. If the product is not displayed on the screen and from now on, it will be sent with a larger batch to GA — that is also not good (and will cause data inaccuracies).
Also, the same warning about the maximum size of 8kb per request applies.
Therefore, you will need to find the balance on your own.
#8. Send the product impressions and promotion views then they are actually displayed
Here’s another case: a visitor lands on a product page and at the bottom of that page, there is a section called “You might also like” with related products.
I have seen many cases where the data of those related products was sent to Google Analytics even when the visitor did not scroll down to actually see them.
If that is exactly what’s happening with your website/project, consider implementing this solution (or at least borrow the idea) and send the data of the product impressions/promotions when they are actually displayed on a screen.
#9. Single-page application? Check how the pageviews are being tracked
If you are dealing with single-page applications and you track them with Google Tag Manager, I highly recommend navigating through that website/app (while having the preview mode) enabled) and see whether every pageview is visible in the preview mode just once.
I have seen some cases when I navigate between one page and another and instead of one History event (or some custom virtual pageview event), I see two (or maybe even three).
If you are not careful about it, this might cause multiple pageviews sent at the same time. There are several options here:
- If pageviews are pushed to the data layer by your developer, then consult with them how the number of those duplicate events can be reduced in the data layer. In general, they should fix the dataLayer.push on their end.
- If you are tracking pageview with the History Change trigger, then check this guide
Also, it is a good practice to check whether on page refresh you are not sending two pageviews, one on “All pages” trigger and one on “History” event. Read more about this here.
#10. Tracking JavaScript errors?
If you are tracking JavaScript errors with Google Tag Manager, check the GA reports – are there many events of this type? If yes, then sit down with the developer and prioritize those errors:
- When can they fix those most common errors?
- If you decide that a certain error is not critical (but you don’t want to litter your reports with it), you can update the JavaScript error trigger and exclude certain errors based on their text. Yes, in the perfect world, all errors should be fixed. But in this case, think about the possible impact those fixed errors might bring. If the impact is trivial, maybe indeed it is worth exclude some of them and simply ignore.
Another alternative might be to move the JavaScript error tracking from GA and use specialized tools for this, like TrackJS. But in this case, you might lose some data needed to debug the missing transactions, for example.
#11. Move some websites to other properties
If you are dealing with multiple websites that are owned by the same business, you might be tracking them in a single property. If you want to see how visitors interact with different parts of your business, this approach is correct.
But if you are hitting Google Analytics limits (10M), maybe it is worth considering moving certain websites (less important) to a separate Google Analytics property?
Listen, I know that in most cases, this is not a good idea but I am here to provide options that you can choose from. You (or your colleagues/stakeholders/clients) will be the ones who make the final decision.
This is just food for thought.
If you decide to actually move out a certain website to a separate property, keep in mind that you cannot move the historic data. Everything that was already processed by Google Analytics stays in the current property and the new property will start collecting only new data that it receives.
#12. Check your most popular events in GA reports
If none of the tips above rang the bell for you, you can do a research of your own. Go to Google Analytics > Behavior > Events > Top events. Select the last 30 days and check which event categories get the largest counts.
If needed, click on those categories one by one to drill down. You might find some skeletons and cobwebs there. Write down a list of events that:
- You have no idea what they mean
- Or you haven’t used in the last 3-6 months
- Or they look like duplicates or very similar (for example I’ve seen setups where two similar events were tracked at the same time but their names were different. This was caused because of the hardcoded GA & GA+GTM being on the same website)
- Or you just feel they are not valuable (yes, I know, that is a very vague tip, but if you get the feeling, follow it)
These are the top candidates to remove. Now, talk about these events with your colleagues/clients/stakeholders. Try to figure out their importance and get rid of them (this will require changes in GTM or in the code (a developer can help with the latter).
Consider this a spring cleaning.
But before you get rid of them, check thinks like:
- Goals (because maybe some goals are using the events that you are about to throw away)
- Data Studio reports or some dashboards
- Anything else that comes to your mind
Maybe you will find out that those events are not so useless after all (or maybe you should just update your goals, dashboards, etc. to get rid of them completely).
This is a very tedious process that requires a lot of detective skills. But it is something that needs to be done eventually.
Thoughts on solutions that count pageviews per GA session and later start a new session
When it comes to the 500 hits/session limit, I have seen some workarounds: they count hits in the session and once the 500 hit limit is approaching, start a new GA session.
Starting a new session is possible with the parameter called sessionControl but there is one problem behind those solutions. It is impossible to replicate the Google Analytics session logic with JavaScript on your website with 100% accuracy.
Sessions in Google Analytics are affected by various factors. Some of them can be identified by the client-side JavaScript (such as UTMs, ad ad parameters, referrer). But there are also things that are happening in the backend of Google Analytics and your scripts in Tag Manager cannot know that, for example, referral exclusion list, midnight of the timezone that is configured in your GA view.
That is why I am pretty skeptical of those solutions. You can make them work to a certain extent but they are less accurate than you think.
Final words regarding Google Analytics limits
I hope that you have learned something new today. In a nutshell, if you are dealing with the 10M hits/month limit, you have two options:
- Upgrade to premium GA (that’s $150 000 per year)
- Or reduce the number of data points that you are sending
But when it comes to the 500 hits/session limit, you have to optimize your tracking. Remember, it’s not about who can track more. It’s about who tracks important things.
Speaking of hits, in this blog post, I have focused mainly on events and pageviews. As I’ve said in the beginning, timing and social are also hits. So it might be a good idea to check if you have some data in:
- Acquisition > Social > Plugins (that is where you can find all the hits with the event type “social”, although (in my experience) most businesses don’t use these reports/features)
- Behavior > Site Speed. Page Timings are tracked by default but there is a chance that User Timings will contain some data like form completion times, etc.
If you found social or custom timing data, it is up to you to decide whether that is useful and should stay in your reports.
Source: analyticsmania