views:

129

answers:

2

We have an ajaxy sort of html based app framework thing and want google analytics to work with it. And I believe we have set things up properly to manually call _trackPageview where needed.

However things don't seem to be getting reported. Now either I don't have it working right, or GA tracking from javascript with a file:// protocol on the url silently violates some cross domain policy I'm not aware of.

So does GA work with local html via file://? Or is there something wrong with my GA usage?

Note that the domain we are using doesn't actually exist. We want to use something like the mobile app tracking but from JavaScript rather than a native library. And in order to do this, it looks you setup a fake domain, and tell the tracker what domain it should be reporting as.


At the end of my <head>:

<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXACCOUNTID-XX']);
  _gaq.push(['_setDomainName', 'myfake.domain.com']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = 'http://www.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();
</script>

And in our JS framework we call:

_gaq.push(['_trackPageview', '/some/path/here']);
+2  A: 

OK, I think I have this one solved. It's been dogging me for a few days.

According to Google Analytics Help Center,

Visitors must have JavaScript, images, and cookies enabled in their browsers in order for Analytics to report their visit.

Here's my theory: In my tests on Mac OS X Snow Leopard, documents run from file:// are not able to set cookies. This is because cookies are proprietary to HTTP, and when you run something from file://, you're not using the HTTP protocol.

Since you're not able to set cookies, ga.js refuses to send the _utm.gif request to Google's servers. No cookies get set; no request is sent to google, so nothing is logged in GA.

Solution: Use a development environment where you can set your domain as http://localhost (something like MAMP, if you're on a Mac and need a LAMP stack)

(Weird footnote: I observed some weird behavior where the GA cookies would set as third-party cookies of the domain of an unrelated imported script from a third party non-CDN domain. This could be because since the server sends HTTP cookies with the file, ga.js is attaching itself to that domain. However, this won't serve as a backdoor, since it still won't send the _utm.gif hit to Google's servers ).

========

EDIT:

You could try one of the various work arounds people have created for cookie-less GA tracking.

You might get some success out of this tool: http://code.google.com/p/google-analytics-js/downloads/list, explained here: http://remysharp.com/2009/02/27/analytics-for-bookmarklets-injected-scripts/

Instead of all of that GA code, you would include the script, and then call it using the following code:

gaTrack('UA-XXXACCOUNTID-XX', 'myfake.domain.com', '/some/path/here');

Its designed for bookmarklet/injected script tracking, but if I put in a file:// type setup, its able to successfully send the __utm.gif hit, meaning it SHOULD track successfully in GA.

The drawback is that cookieless means that it won't be able to track visits accurately, just page-view level data.

yc
I see. And obviously cookies being set for `file://` would be weird, since there is no domain. But in my case running a local server wont really work. I guess I can't use this via JS, dang.
Squeegy
Right. Also, see my edit for potential hope.
yc
A: 

Ended up with a complex bounce through an iframe via the resize hack message passing mechanism.

Local file include an iframe on our server. When we want to track a GA call we changes it's url hash with the info we need #_trackEvent,foo,bar, and then change the width of the iframe. In the iframe the onresize() function gets triggered and allows us to submit GA calls by inspecting the hash.

As much as I hate this hack, it works flawlessly!

Squeegy