Tell HN: Subdomains and Google Analytics don't mix | Hacker News Reader

Tell HN: Subdomains and Google Analytics don't mix

13 pointsjacquesm8 comments

For a bit over a year now I've been using google analytics on one of my websites. The logs have been seriously at odds with the analytics statistics, which could be used, but only for relative measurements.

We're completely reworking that site and so I finally got around to tackling the analytics problem.

Apparently analytics is not playing nice when you give your users subdomains. It's 'debatable' whether this is expected behaviour or it isn't, but analytics seems to interpret every user visiting a part of the main site from a subdomain as an 'external visit' and every visit of a users page from main site as a bounce!

Also all the uniques and visits are double counted, and if a users visits more than one subdomain the situation gets worse.

I was planning to get rid of the subdomain scheme for different reasons (the extra dns lookup slows down the user when moving between pages) and I'm happy to report that the analytics statistics are now much more in line with the log files.

So, if you have a huge discrepancy in your logs versus your google analytics statistics and you are using subdomains, this is probably happening to you too!

What we do is a top level filter to map subdomains into a group of top level folders:

Filter: Group pages by hostname

Filter type: Custom Filter

Field A -> Extract A: Hostname (.)

Field B -> Extract B: Request URI (.)

Output To -> Constructor: Request URI (/subdomains/$A1$B1

Field A Required: Yes

Field B Required: Yes

Override Output Field: Yes

Case Sensitive: No

"/subdomains/" can be any arbitrary top level grouping that makes sense to you. We use an additional filter to strip /subdomains/domain.com and /subdomains/www.domain.com back off, so the primary site's URLs appear in the report normally.

This is expected (and documented) behaviour - GA won't correctly track subdomains out of the box, as even though the (uncustomized) GA has subdomain-accessible cookies, the user id depends on a hash of the hostname (less any 'www.') (thats the first section of the utma cookie). This can be fixed by either turning off the hostname-hash-in-id, or setting the cookie-domain/hashed-hostname (but turning off the hostname-hash-in-id will then require setting the cookie-domain such that the subdomains & main domain can touch the GA cookies, as by default this doesn't strip the leading www. from the cookie domain).

The doco is pretty good, but you need to verify what's really happening, so Firebug's Net panel is really useful (but don't try and read the latest GA javascript unless you need a migraine for some reason).

Let's debate whether it is expected behavior or not.

I propose that there is no other way for Analytics to handle subdomains than what you describe, because there is no way for Analytics to be certain that domain.com and sub.domain.com belong to the same site.

Of course, an option to inform Analytics of this fact would be nice, but out of the box I really don't see how it could work differently.

As far as I know the code to do exactly this is:

pageTracker._setDomainName(".example.com");

Warning, warning: when you start playing with Google Analytics you will quickly learn that it is Enterprise software: built to be infinitely customizable using massive amounts of work to just short of your actual needs but no farther, and filled full of sharp edges to cut yourself on.

That said, it is a very impressive piece of software in a lot of ways. (My internal analytics are a lot more useful to me, but my heart aches for how easy it is to dig into arbitrary things in GA.)

Yes, that's it exactly.

https://www.google.com/support/googleanalytics/bin/answer.py...

That's the relevant page in the support area.

My mistake, I should have realized their default is set to treat subdomains as different sites because that is probably a more common use case.

Keep in mind that if you have existing tracking goals set up and you implement URI filtering like this, your goals will need to be rewritten to accommodate the domain being appended to the beginning of each URI. This will also break the site overlay/clickmap, if that's something you use.

> .. appended to the beginning ..

Or, of course, prepended.

I would go crazy if it were any other way.

www.yoursite.com.sites.servee.com is our temporary URL scheme. If I had to sort through that to figure out my conversion funnel for www.servee.com It would be miserable.

That being said, i think that yes, moving your users for your app to yourapp.com/user is better than user.yourapp.com for most cases. Freshbooks, basecamp, and other non-connected apps work better the other way.

Reply on news.ycombinator.com