

Tell HN: Subdomains and Google Analytics don't mix - jacquesm

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.<p>We're completely reworking that site and so I finally got around to tackling the analytics problem.<p>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!<p>Also all the uniques and visits are double counted, and if a users visits more than one subdomain the situation gets worse.<p>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.<p>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!
======
Skeuomorph
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.

------
janstice
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).

------
mmelin
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.

~~~
patio11
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.)

~~~
jacquesm
Yes, that's it exactly.

[https://www.google.com/support/googleanalytics/bin/answer.py...](https://www.google.com/support/googleanalytics/bin/answer.py?answer=55524&cbid=1beih2v4piof5&src=cb&lev=answer)

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.

~~~
leviathant
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.

~~~
arantius
> .. appended to the beginning ..

Or, of course, prepended.

------
izak30
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.

