“_gat is not defined” Google Analytics Error

Mattias Geniar, Monday, August 25, 2008 - last modified: Wednesday, August 12, 2015

A common problem with Google Analytics is the "_gat is not defined" javascript error, when you try to load a webpage that uses Google Analytics to track visitors behavior.

This happens because the visitor most likely has an AdBlocker installed (such as AdBlock Plus for Firefox), which filters out a javascript file from Google. The code then tries to create an instance of an object it doesn't know (because the definitions are missing, since the file isn't included) and it throws the "_gat is not defined" error.

We wouldn't be showing the problem, if there weren't a solution of course. Just change your code to the following, which will check if the object actually exists before trying to create an instance of that object. The tracker won't fully work (but it didn't in the first place anyway), but at least the user won't be shown the nasty javascript error.

<script type="text/javascript">
if (typeof(_gat) == 'object') {
	var pageTracker = _gat._getTracker("UA-CODE");

This only happens if you try to use the New Tracking Code (ga.js) (the new, and "improved" version) over the old Legacy Tracking Code (urchin.js). The bug's been around for a while, it's strange Google hasn't provided a clear fix for this yet ...

Update: new Analytics code doesn't have this problem anymore. If you edit your Site-details in Google Analytics, and view your Google Analytics code, you'll see something similar to this:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-MYCODE");
} catch(err) {}</script>

Error handling has prevented the error message to be shown. It is advised to use the code that Google provides, instead of the "hack" shown on top of this page.

Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!


Rakotomandimby Mihamina Tuesday, March 17, 2009 at 13:13

This try/catch workaround seems a bit light for me… It silently ignores the problem. A kind of > /dev/null


Chris Friday, May 22, 2009 at 21:01

The “hack” workaround is actually still good advice in many circumstances. Consider that it’s common to have onclick events in the body of the page with a call to pageTracker._trackPageview(‘file.zip’) for file downloads or AJAX calls, for example. Your AdBlock-ing users are going to get more JS errors when they use those links.

I use this code to set up a dummy pageTracker object and fail gracefully:

if (typeof(_gat) == ‘object’) {
try {
var pageTracker = _gat._getTracker(“UA-CODE”);
} catch(err) {}
} else {
var pageTracker = new Object;
pageTracker._trackPageview = function() {}


    Stephen Akins Saturday, November 20, 2010 at 04:59

    Chris: Excellent solution. This fixes all of my _trackPageview calls with one cut-and-paste.


Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links