This post explains a number of the most common “gotchas” that trip up even experienced users.
Now that I have your attention, check which may have confused you and let us know of others that GA users should know about. Go on! Take one for the team or tell us it confused a friend.
Google keeps things simple and minimal. That works well for Google Search, but does it also work well in more complex applications like GA?
Now, of course they’re not “lies”. I was just keeping the title simple. 🙂
To keep this post brief, I mention where users typically go astray and “expose” the correct path. However, feel free to ask for more info. Also, here is a link to a Webinar Back to Basics: Google Analytics Setup and Configuration Best Practices. Keep in mind, though, that while much of it is still current, some of its content is dated.
Here are important ways the complexity gap misleads users through their growth of GA knowledge
GMail email accounts, Google Apps accounts & GA
One does not need a GMail account and address to use GA.
Like almost every other service on the web, one can sign up for any Google Service (except GMail) with any email address, including your company email. It is the same with GA.
One also does not need to have a GApps account for the company’s domain name to use its email addresses for GA logins. In fact, CP recommends using only company email addresses for company accounts as a best practice. A long list of nondescript Gmail addresses in an account’s list of users indicates a serious security hole
One GA account per domain
GA is not the only Analytics tool to ask for a domain name when creating an analytics account or Profile.
I’m not sure that could be avoided.
However, without complicating things by referring to a help article explaining the concept of a web property, users can internalize this one-to-one relationship and, for companies with multiple domains, land up with one Web Property ID (e.g. UA-XXX-Y) per domain.
In some cases, this might be correct, but we’ve seen in many that a nightmare scenario has evolved.
The way in which multiple domains and sub-domains ought to be tracked is a subject deserving of its own post.
Effect of domain name in the GA Interface
By simply asking for a domain name without more explanation, the impression is given that it has something to do with how the data is tracked.
In truth, the only aspects that matter are the Web Property ID (UA-XXX-Y) to which data is sent and the filters on each profile within that Web Property. Any domain on the net can use your UA # to send data to your Web Property. Profile filters are relied upon to keep out unwelcome data.
“Not an Ecommerce Site” setting
This profile setting is fraught with “lies”. It implies that ecommerce data is not collected into the profile.
At one time, the only affect the option had was to hide ecommerce from a profile but the data was still being collected into the profile. If one changed the setting, the data would show. That is not the case any longer. Now, the setting “Not an Ecommerce Site” (the default), prevents ecommerce data from being collected.
The use of ecommerce tracking functionality is limited to ecommerce sites.
Ecommerce tracking can be creatively used on non-ecommerce sites. E.g. Sites earning income by the display of ads or from click-throughs can use ecommerce to track revenue earned per visit to determine the characteristics of high value visits.
Simply because GA asks for a profile’s currency does not imply that Google will automagically convert currencies for you. Like the original ecommerce setting, it gives users grandiose expectations. In spite of the setting clearly stating “Currency displayed as”, Google does no automatic currency conversion. It only affects the User Interface currency symbol.
Note: If you see some products selling for ridiculous prices, you probably have them reporting in a currency like YEN or KRW but showing US$.
“Include” does not mean “Include traffic from x.com” and “Include traffic from y.com”. These two filters are mutually EXclusive, not INclusive. They will interfere with each other, blocking all traffic to their profile(s). Each Include filter means “Allow traffic from X and exclude everything else”.
Calm yourself if you see your site’s “Conversion Rate” shoot up or run above 100%. The profile-wide Conversion Rate is simply a sum of all the Goals’ conversion rate. Conversion Rates can therefore go above 100% if goals, that are more easily achieved, have been added to a profile. These are typically Event Goals and the engagement goals such as Time on Site and Pages per Visit.
Goal Sets don’t help much either – they are great for grouping goals together logically but have no affect on the metrics. E.g. there is no Conversion Rate by Goal Set.
Nothing but the Best
Now, don’t get me wrong. None of this is a criticism of GA. It’s among the best Analytics tools out there and, for many SMEs, GA is the best tool for their requirements. (Others will lead you astray for double the price!) This article is simply pointing out where we see users being tripped up, particularly in our training courses.
What aspects of GA have tripped you up?