Google Analytics is an excellent and powerful tool to help you understand how people interact with your website. Understanding how your website users behave and how they try to look to get value from your website is key to evolving your website to improve their experience on your site, and by extension the value you get back from your users.
You might have an ecommerce website, you might have a subscription website, or you might have a simple information website, but getting your users to complete the key actions on your site is vital to its success.
Unfortunately, far too frequently Google Analytics accounts and tracking are not used correctly, and the effect of that is that the data stored is misleading, incomplete, difficult to access, or just plain wrong!
Here are a few pointers of the common mistakes I come across time and again when reviewing Analytics installations.
Badly structured accounts
Google Analytics has a very well defined structure for account set-up. However, I frequently hear even seasoned Analytics users using the words profile and account interchangeably. The reality is that these are very different things.
A common mistake some agencies make when setting up properties for their clients is to add them under their own agency account. This isn’t correct, each client should have its own account.
Furthermore, your log-in details do not belong to the account, they belong to you as a user, and are completely separate from the account.
If the account is set up correctly, there should never be any need for the request “can you send me the log-in details for Google Analytics?” The question should be “Can you add me as a user to the Google Analytics account?”
The structure of the accounts should be:
The account should reflect the business itself. Let’s imagine a newspaper publisher. They would have one account, in which all their websites would reside as “properties”
The property is the website or mobile app. We’ll see later that sometimes two websites might be considered as one property in some circumstances, but usually property is equivalent to website. Each property should have a number of profiles. In our example, one newspaper website would have one property in Analytics.
The profile is the data collected and consequently the reports generated by Analytics. A website might have a number of profiles because profiles can filter the data as it is collected, as we will see shortly. You should always have one profile with no filters at all for a number of reasons that I won’t go into here – suffice to say it is best practice, and some! In our example, one newspaper website might have many profiles.
You control who can log-in to see your profiles by adding their Google accounts as users or administrators, which brings me neatly onto the next common mistake.
Confusing administrator and user roles
Users are able to see the reports and data for the profiles for which they are added. This should be the default way you add someone who only needs to view reports. They can only see the profiles they are added to.
Administrators, on the other hand, have access to the entire account, and can make changes to how the account is set up. Clearly this isn’t ideal if an inexperienced user takes it into their head to start adding profile filters, or changing other people’s user roles. However, you need to be an administrator to do certain other tasks, such as creating custom reports, or setting up goals. Administrator roles should be assigned only to people for who the additional functionality is required.
Confusing profile filters and advanced segments
Administrators can add a number of filters to a profile, I’ll suggest a few in a moment, but first of all it is important to consider whether what the account needs is a filter or an advanced segment.
Advanced segments are used to filter the reports in Analytics on the fly. For example, they can be used to see how website viewers located in the UK used the website, or how viewers on mobiles devices interacted. They are useful for segmenting the data in the reports, hence the name.
Profile filters, on the other hand, are used to filter the data as it gets collected. This enables the overall reports to exclude data such as all users from one IP address (e.g. all the people in your office who are looking at the website as they administer it), or perhaps to only include one section or sub-folder of a website. Once data is excluded by a filter, it is lost in that profile and can’t be recovered. This is one reason why it is best practice to have at least one profile with no filters – it is your insurance against profile filter cock-ups!
Therefore the use cases should be clear – use advanced segments where possible to segment your reports. Use profile filters to structure data as it is collected.
Some common filters I like to use include:
- Exclude our office IP address – this is especially useful for small boutique sites with relatively low traffic levels, as our traffic might significantly skew usage data
- Exclude the client’s IP address likewise
- Convert all URIs to lowercase – this is because it is common on IIS (which is not case sensitive) to see URLs sometime capitalised and sometimes not, but Analytics (correctly) treats URIs as case sensitive. This is only for sites with case-insensitive URIs, obviously.
Not tracking site search
Surprisingly, I find that site search is not tracked much more frequently than you would expect. It is tracked on a profile by profile basis, and is set-up on the profile settings tab under ‘Admin’ for the profile.
The questions is whether to strip the search parameters from the URI. My preference is to strip them from the URI in all profiles except the unfiltered back-up profile. I still track site search in the unfiltered profile, though, but simply leave the strip search parameters checkbox unticked.
Not linking AdWords correctly
If you are running an AdWords campaign (and if you’ve got a good business model, why wouldn’t you be?) then it is important to make sure that your AdWords account and your Analytics account are linked. This is done in a three-step process – first add your AdWords account log-in as an administrator to Analytics, second, link your Analytics account from within the AdWords interface (Tools and Analysis > Google Analytics), and thirdly, tick the checkbox to import cost data from AdWords within Analytics (Admin > Profile Settings > Apply Cost Source Settings).
By doing this, you will achieve a number of benefits. You will be able to access Analytics data while logged into AdWords, which makes it easier to optimise the PPC traffic, as you’ll be able to see user behaviour post-click. Also, you’ll be able to understand ROI better within Analytics, as you’ll see cost data for traffic sourced from AdWords as well as revenue and completed goal values from Analytics itself. This helps you understand which landing pages work best, which ad groups in AdWords work best, and which keywords work best, and also perhaps why some are not working as well as you would like.
If you don’t link AdWords correctly, though, especially if AdWords is not set for auto-tagging, data from AdWords can become confused with other data. In the worst case scenario, it is mixed in with organic search data, and this disrupts not only your understanding of AdWords, but also of organic search.
Other paid search providers like Bing currently don’t link directly to Analytics. However, it is possible to link other cost data sources via the Analytics API and setting up custom data sources. At the very least, other paid search providers should use campaign tracking URL attributes (utm_source etc.) to identify themselves as paid search.
Not setting up goals or funnels correctly
You know what you want your users to do on your website. It might be to buy a product, to complete an enquiry form, to subscribe to a newsletter or whatever. In each case there is a clear point at which the user has done this desired action. Google Analytics allows you to set up such completion points as goals.
Surprisingly often, we see this isn’t done at all, or that it is done, but the tracking isn’t done correctly, and so the figures are wrong.
Frequent ways in which this can be broken include using a URL as the goal, but that URL is not unique to the completion point (e.g. if a form redirects to the same URL as itself on completion), or using the wrong match type on the goal meaning more than the completion point might be tracked by accident.
Occasionally, workarounds might need to be done on your website to enable goal tracking. For example, using virtual pageviews for goal completions to ensure their uniqueness.
Once you have a goal set up, if there is a clear linear path that a user must take to complete that goal (e.g. a form they have to fill in, or a payment pipeline they must go through) then you can also set up the funnel, i.e. the steps the user must go through to complete the goal. This helps identify the sticking points in the process a user has to go through, and helps inform you about what you might do to increase conversion.
However, if the funnel is set up incorrectly, then the information it gives you might be incorrect, and this can lead to wasted resources either fixing problems that don’t exist, or not fixing ones that do.
A common mistake when setting up funnels is not understanding that the match type used for the goal is also the one assumed for the funnel steps. This can be tricky if your goal uses a head match, but your funnels steps are identified by URL parameters rather than entirely new URLs, for example, especially if your URLs also include other potentially random URL parameters.
If your funnel is complicated by the platform you are using, it might be easier to use a third party add-on for Analytics, such as Paditrack (update: this tool has been discontinued 🙁 ).
Not considering linked sites as one unit
The last common mistake I’ll list here is one that many sites fall down on. Consider a website with an ecommerce site and a blog. The blog is linked to frequently in the ecommerce site (perhaps in the main menu) and vice versa. Essentially, they are one big website, but the blog exists on blog.website.com and the ecommerce site lives on www.website.com.
In this example, clearly a user journey can switch from one site to the other and back again, perhaps more than once in the same visit.
However, what we see frequently is that the blog is set up with its own separate Analytics account. This means that when a user goes from the ecommerce site to the blog, they are tracked as being referred by the ecommerce site rather than by the original channel (e.g. organic search) by which they came to the website. Of course the original channel is tracked on the ecommerce site. Not a massive inconvenience in this direction, but similarly if the user lands on the blog first, and then goes to the ecommerce site and makes a purchase, all you know about that purchase is that the user was on the blog first. It is difficult to tell which blog content drives sales, and which doesn’t. This can make you content strategy quite hit and miss.
What you should consider is having one Analytics property covering both the blog and the ecommerce site. Using profile filters set up multiple profiles:
- One to look at the blog only
- One to look at the ecommerce site only
- One to look at both combined (you might want to use filters to prepend something to the blog URLs to ensure they are unique).
- One unfiltered master profile (see earlier point about account structure).
By setting up the property in this manner, the user journey is preserved, and you can look at either site in isolation, and a combined version. This should make understanding the user journey considerably easier!
Of course, these seven examples aren’t the only mistakes people make with Analytics, but I do see these crop up over and over again.
If you need some advice about your Analytics set up, or if you’d like an agency to help look after Analytics and performance reporting for you, please get in touch.
Ask me Analytics questions on Twitter @indicium