Google Analytics Real-time Reports Not Working? Here’s How To Fix It

Updated: January 3rd, 2019. Here’s a situation. You have just set up Google Analytics tracking, open a GA Real-time reports and nothing. You don’t see anything. No page views, no events, nothing. Sounds familiar? Relax, you’re not alone.

In fact, this issue is getting more and more popular these days as people have been contacting me through various channels (Facebook messages, comments, emails) with pretty similar issues: I’ve set up GA tracking but no events are displayed in the real-time reports or just My Google Analytics Real-time reports are not working, etc.

Today was the last straw when I received a comment under a blog post regarding this issue, and at the very same time in the Facebook GTM community Simo Ahava mentioned that today alone he helped at least 3 people with this issue.

To save you (and others) some time, I’ve decided to compile a list of most common mistakes why Google Analytics real-time reports are not working.

Quick side note: if you’re also struggling with Google Tag Manager, check this list of most common GTM mistakes.

#1.  Google Analytics Settings Variable is inserted in the wrong field

This one is related to Google Tag Manager. When you create a Universal Analytics Tag, you need to set the destination GA property which will receive those events/pageviews/hits. There are two options how to do that in GTM:

• You can enter the tracking ID (UA-XXXXXXX-XX) in the Tracking ID field
  
• Or you can set that ID in the Google Analytics Settings Variable and then pick that variable in the designated field within Universal Analytics Tag.
  

Both options are correct and will work fine. However, some people tend to mix them and, therefore, break the tracking implementation. Usually, they insert a Google Analytics Settings Variable in the Tracking ID field and that will never work.

Tracking ID field supports only values of the following structure: UA-XXXXXXX-XX.

Google Analytics Settings Variable must be inserted ONLY in the GA Settings drop-down.

Remember, the fact that Universal Analytics tag was fired with Google Tag Manager does not mean that the

This issue is especially common among those who download GTM Recipes, don’t follow the instructions and just insert GA Variable in the Tracking ID field. Unfortunately, I didn’t have time to update all the recipes to include GA Settings Variable by default but I guess this will have to be tackled sooner rather than later.

#2.  Google Analytics Filters are excluding internal traffic

By saying Internal Traffic I mean your own traffic. It might be your company’s IP address, your home IP address, and other addresses which clearly indicate that it’s you or your colleagues. Since nobody wants to distort their tracking data with fake/useless traffic (of their own), it’s common sense to filter it out.

However, sometimes people forget about this configuration and are desperately looking for answers why their interactions are not displayed in Google Analytics Real-time reports.

In order to check this hypothesis, go to Google Analytics Admin settings, choose the view you’re currently working on and click Filters. Keep looking for a filter which excludes traffic and its title is related to the “internal traffic”, “home IP address”, or something else.

Once you find your suspect, click it and double-check. Usually, the Internal Traffic filter looks like this:

If you found it, keep it. My suggestion would be to create a new Google Analytics view with no filters or with a filter which includes only traffic from your IP address. You can call such views Sandbox. Feel free to test your interactions there.

#3. Real-time report’s quick filters are not cleared

When you’re analyzing real-time data, you might want to dig deeper and check only its subset. How can this be done? Simply by clicking any link in the report, e.g. a page URL, a blue bubble appears at the top of the page.

This is a quick filter which indicates that you’re now currently monitoring a particular segment of users that are on your website.

Even if you go to another section of the Google Analytics Real-time reports, that filter still persists. Sometimes this causes a misunderstanding when people simply forget about it. Correspondingly, GA users might think that event/pageview tracking is not working even though everything is fine. The events are being received without any issues, they’re just not displayed due to quick filter configuration.

Allow me to illustrate this with an example: you’re checking Real-time event reports and click the Event Category Click. After that, you decide to check another event, Form Submission. You try to submit a form multiple times on a website but events do not appear in the RT report. Why?

This has happened because your Real-time filter is set to display ONLY events of Click category and form submission does not meet this criterion (it belongs to the Form Submission Event Category).

The solution is pretty simple, keep an eye on the top bar of the Google Analytics Real-time report and, if needed, remove unused/unnecessary filters by clicking the white X icon.

Are Google Analytics Real-time reports still not working for you? No worries, maybe other tips will help you. Let’s continue.

#4.  Opt-out Extensions

Another option how website owners want to exclude their own traffic is Google Analytics Opt-out add-on, Block yourself from analytics, or other browser extensions which tell the Google Analytics JavaScript not to send information to Google Analytics.

In order to start seeing your events/pageviews/etc in GA Real-time reports, you’ll need to either temporarily remove the extension or disable it (depends on extension’s functionality).

#5.  Events are set to “non-interaction hit: true”

Sometimes people ask why they are seeing pageview real-time data but no events. Turns out, non-interaction hit setting causes this “problem”.

Firstly, let’s remember what is a bounce in web analytics. A bounced session is a single-interaction session when a visitor landed on a page, did nothing, and then left. In a very basic Google Analytics tracking, only a pageview is an interaction. But if you implement GA event tracking, you start sending more interactions to Google Analytics, therefore your bounce rate will be lower.

When a visitor lands on a page, submits a form (which is tracked as a GA event) and then leaves, this session will not be counted as a bounce because there were two interactions, page view, and form submission. You can learn more about the bounce rate here.

However, not all events should be treated as actual interactions, therefore not all events should affect the bounce rate. For example, scroll tracking. A person can land on a page, scroll down for a second, realize that there’s nothing useful for him, and leave.

If you treated scroll event as an actual interaction, your bounce rate would be distorted and unrealistically low. Google Analytics has a solution for such events, you can set them as non-interaction hits. This means that events will be tracked and displayed in Google Analytics event reports but they will not affect the bounce rate.

Anyway, a fun fact is that non-interaction hits are displayed a bit bizarrely in real-time event reports. They are visible as little dark blue lines in the right section of the real-time report, however, you’ll not see them in the Active users tab.

On the other hand, you can see those events in the Events (Last 30 minutes) tab of the real-time event reports. So some people get confused and don’t know that non-interaction events are hidden a bit deeper in the report.

How can you check if your events are sent as non-interaction hits?

If you’re using Google Tag Manager, open a Universal Analytics event tag and start looking for a non-interaction hit drop-down. If it’s set to Yes, this event will not affect your bounce rate and will not be visible in the All users tab of RT event reports.

The default value of all newly created Universal Analytics event tags is non-interaction hit: false.

Another option to check this configuration is by using a GA Debugger browser extension. Download it, enable (by clicking the icon), then go to the browser tab where you’re currently working, open browser’s JavaScript console, and refresh the page.

You should see something like that.

That’s the data that was sent to Google Analytics. If nonInteraction parameter is set to 1, this means true. If you cannot find the parameter at all, this means that its value is 0 (false).

#6.  Ghostery or other tracker-blocking extension is preventing GA data from being sent

Another reason why Google Analytics Real-time reports are not working might be browser extensions. Are there any related to ad-blocking or web-tracking-blocking (e.g. Ghostery)? If yes, try disabling them, refresh the page that you’re currently trying to track and check GA real-time reports.

#7.  Google Analytics Events are sent to the Wrong GA property

Sometimes sh*t happens and I’ve caught myself several times committing this “crime”, especially when I have 50+ open browser tabs across multiple screens. We are all mortals, we do mistakes.

So double check your Google Tag Manager settings and compare the Google Analytics tracking ID to the actual property you’re monitoring in the GA Real-time reports.

If you don’t use GTM, use the aforementioned GA Debugger plugin and look for trackingId parameter in the JavaScript console.

That’s the ID of the Google Analytics property that you’re actually sending data to.

#8. Is Google Analytics installed at all?

I know, this might sound like a stupid question but Are you sure Google Analytics tracking code is installed at all? If you’re not sure, it’s pretty easy to check. One of the options is to install Google Tag Assistant browser extension.

By default, Tag Assistant is in the “sleep mode”, meaning that it does not check anything that’s happening on a page. In order to activate it, click the blue tag icon and then Enable.

Now refresh the page. If any Google’s products (including GA) are implemented on that page, you’ll start seeing a particular number within that blue tag icon which represents the count of tags found. In fact, tag Assistant’s icon works like a litmus, its color changes according to the context.

When Google Tag Assistant is enabled and the page is refreshed, the color of its icon can change to one of the following 4 options:

• Red
• Yellow
• Blue
• Green

Red color means that at least one Google Tag (let’s say, Google Analytics) has a major issue that needs to be addressed as soon as possible. Click the red icon to find out more, what is the issue and how to fix it.

Yellow color means that at least one Google Tag has a minor issue and the issue should be addressed, otherwise you might face some tracking discrepancies.

Blue icon means that some non-standard implementation is found. While usually, such issues are not as serious as major (red) or minor (yellow) problems, you still might want to take a look at your implementation.

Green is the color you should be looking for, it means that all tags highlighted with green color are working perfectly.

Now, let’s try to diagnose your GA implementation. First of all, check if Google Analytics Tag is visible in the list of Tag Analysis. If not, try to find the reason why there’s no GA Tracking Code on the website. Maybe developer forgot to push changes to the website? Maybe you’re working with wrong GTM container?

If Google Tag Assistant found Google Analytics, what is the color of that tag icon next to it?

If it’s red or yellow, click the tag for further inspection. Tag Assistant is pretty good at providing answers or at least giving hints what’s wrong.

If you’re not sure what a particular error means, google it. Chances are pretty high that you’ll find the answer in Google Forums or another place.

You can learn more about Google Tag Assistant in this guide.

#9. You’re checking User-ID view in GA but not passing the actual User-ID to GA

This one came up in one of the discussions in our GTM community on Facebook. In case you did not know, a User-ID view is a special reporting view that only displays data from sessions in which you send unique ID and related data to Analytics. User-ID views include a set of Cross-Device reports, which aren’t available in other reporting views. You can learn more about them here and here.

If you carefully re-read the previous paragraph you’ll notice that this view displays only those pageviews/events/transactions, that contain a User ID. By default, User ID is not some default dimension in Google Analytics. You need to do additional configurations to do send it to GA.

How can you check if you’re looking at the User-ID view (and not a regular view?).

Go to GA Admin > Choose the View that you’re currently working on and go to View Settings. If you see User-ID Reports: Enabled, this means that the view is indeed only for analyzing data with User ID.

What options do you have here?

1. Switch to another view in that property. There should be at least one another regular view.
2. Or do additional configurations in your GTM container to start sending the User ID as a {{variable}} to GA.

#10. Only the first page view is tracked? Or maybe not all parts of the URL are visible in real-time reports?

This is, most likely, happening because you’re tracking a single-page application. Such applications/websites mean that whenever a visitor navigates from one page/view/state from another, the page, technically, is not reloading.

Visually it might look like it is reloading but actually, it does not. And that is the problem, because, by default, Google Analytics tracks the page view only once, when the page loads. All the subsequent interactions must be configured/tracked additionally.

This is why only the first page view is tracked by GA.

1. The page loads
2. Google Analytics is loaded, meaning that the page view is tracked
3. The visitor continues to browse pages but GA does not catch such interactions and no subsequent page views are tracked (unless the visitor actually refreshes the page with his/her browser.

So what should you do? In such a case, you should send virtual page views every time a visitor navigates to another page. I’ve published a guide on this topic if a website’s URL contains the hashmark (#) and it is changing.

If your single page app/website does not utilize #, then read this guide by Bounteous.

One more thing that you should know is that if your website’s URL contains a hash mark (#), Google Analytics will not display that. Just like in the screenshot below.

What’s the solution here? Send the value of the hash mark as a page parameter with all Google Analytics hits. Like in the screenshot below.

In my guide on how to track single page applications, you’ll learn how to do that precisely.

Google Analytics Real-time Reports Not Working: Final words

GA Real-time reports is a great feature which enables you to check if the data from your website is passed correctly to Google. However, sometimes analysts and marketers fall into a trap when tracking data (or a part of it) is missing.

There are many reasons why Google Analytics real-time reports might not work and in this guide, I’ve listed the most common mistakes which can cause that. Obviously, this list is far from complete (and I’m sure I’ll update it in the future) but these bloopers are the ones I deal with the most often.

Did I miss anything? Got anything to add? I’d be more than happy to hear your thoughts/experience.