I’m one of those odd people who has a very analytical brain.

I guess that’s why I’ve always loved Google Analytics.

I don’t think there’s a website I’ve worked on without Google Analytics, and on the odd chance they didn’t have it, I soon changed that.

The funny thing is, everyone uses it, but it’s one of the hardest reporting tools to use and understand.

I’ve spent over 4 years working with Google Analytics. In that time I’ve worked with numerous Drupal developers to implement and configure it, product owners to gain insights into their website traffic, and marketers to train them how to use Google Analytics and gather their own insights.

In this post, I want to share a few key things I’ve picked up over the years which I wish I’d known earlier.

Hopefully, I’ll help speed up your learning curve.

1. A Bounce is a 00:00:00 duration page view

It’s embarrassing how long I’ve gone in my career without knowing this.

Page duration is based on the last click on the website.

If someone hits a page for 4 minutes, hits another page for 3 minutes, then hits a third page for 2 minutes and leaves, that session will be counted as 7 minutes since the last page was not counted.

This means that all bounces don’t register a duration and can seriously skew your time on site metric, depending on your bounce rate.

Try segmenting traffic without bounces and then look at the time on site/page to get a more realistic figure.

Mind = Blown.

2. Bounce rate is more often than not a useless metric

Talking of Bounce Rate, let’s get this one straight.

Unless understood well, the Bounce rate metric is as useless as a chocolate tea pot.

I’m often asked, “What’s a good bounce rate?”

The answer?

Completely different to every user.

I can understand how it’s easy to get carried away with it. It’s one of those metrics that’s in your face from the very first page.

But the problem is bounce rates are entirely different per industry and are entirely dependant on your site goals.

Let’s take an example…

A user lands on site A after googling “How to build a website”. They spend a few minutes browsing the site, reading a number of posts to get some starter tips, then leave the site to go put their new skills to the test.

Good time on site, not counted as a bounce.

The user then sees an article on Facebook about “Top tools to get started building a website”. They click the link through to the post on site B, skim through the post, then leave by clicking an affiliate link through to a Domain provider where they start their journey by purchasing a domain.

Which do you think is the more desired scenario?

3. Defining and adding Goals should be an absolute necessity

It amazes me how many Google Analytics accounts I have access to which don’t have any worthwhile Goals setup.

What’s the point in analysing your traffic if you can’t track conversions? In fact, do you even know what counts as a conversion on your website in order for you to setup a Goal?

On my own website, Calisthenics 101, a conversion to me is somebody clicking an affiliate link. By tracking these specific link type clicks as a Google Analytics Event, I’m able to in turn set this Event up as a Goal.

For each landing page on my website, and also each traffic source sending users to those pages, I’m able to see the conversion rate of this Goal, and therefore which content and traffic sources I should focus my energy into.

4. Use consistent Properties and Views within each Google Analytics Account to improve data quality and improve administration

Each account should relate to a specific company or client.

Within that, each property should relate to a specific website or application within that account where traffic is unique.

When you have numerous Properties within your Account, name each with a number so you can order them in a way that makes sense to you at a glance, e.g.”1. Main website name”, “2. Campaign website name”. Google Analytics lists these alphabetically, which makes administration much clearer when dealing with large numbers of Properties.

Analytics data cannot be historically modified, meaning if your data isn’t right due to recent configuration changes then you can’t get that back.  If you screw up, well, you screwed up.

For this reason, you should have at least 3 Views within each Property: “All Website Data”, “Test”, and “Raw Backup”, which should be used as follows.

All Website Data – Use this as your main View. Add whatever Filters and Goals you want to it, and set it as the default View so it’s the go to View when visiting the parent Property.

Test – Apply any advanced configurations, such as Filters, to this View first. Once you’re confident they work, then add them to the main View without risk of data loss.

Raw Backup – You should also keep a single View which has absolutely no configuration on it at all. This should log all website traffic unfiltered, and therefore should be used as a backup View if anything needs to be historically questioned.

Again, you can also number these to get them in a consistent order.

5. Developer implementation is apples and pears

Many developers don’t understand the difference between Google Analytics and Google Tag Manager.

Google Analytics is what you use to gather and report on your traffic data.

Google Tag Manager, on the other hand, is a powerful tool which can save both marketers and developers a lot of time messing about with scripts on the site, since the marketing team can fire all their third party scripts through the Google Tag Manager account.

They’re completely different, yet the confusion lies in the implementation since the Google Analytics code can be added through Google Tag Manager.

In technical terms, the Google Analytics script can be added directly to the website code, or the Google Analytics Property can be fired within the Google Tag Manager Container.

With that in mind, you’d be surprised how many times I’ve seen duplicate Google Analytics tracking present on a website, and in this scenario, Google Analytics shows double page views and an abnormal bounce rate of around 1% whilst the incorrect code is present.

The solution to this is to understand early what tool will be used, and if Google Tag Manager will be used then only fire the Google Analytics script through the Google Tag Manager Container, and don’t add the Google Analytics script directly.

Quick tip: Not sure which to use?

Does the client already use Google Tag Manager? If so go with that and get them to fire Google Analytics and any other tags through that.

If the client doesn’t have Google Tag Manager and appears to have no desire to set it up, then stick with the Google Analytics script.

6. Base your Browser and Device support on your Google Analytics data

This one doesn’t technically refer to tips within Google Analytics, but it’s a bug-bearer of mine that I’m very passionate about anyway.

Ever heard any of the following requests?

“We want our website to be Mobile First”.

“Our Managing Director uses Internet Explorer 6, so we’d like the whole website to be compatible in it”.

Neither are incorrect statements so to speak, I just think they’re all too often uneducated requests.

My point here is if you’ve got the data, then why not use it to backup these decisions? Fear not, Google Analytics to the rescue!

Filter your website traffic for the last 30 days and then head to Audience > Mobile > Overview.

Which device type do most of your users use?

If most of your users are mobile, then you should be using this data to convince your team that all designs should be Mobile-first, i.e. design the page for a mobile phone, then think of how it looks on a desktop as an after thought.

Now head to Audience > Technology > Browser & OS.

What portion of users are using old versions of IE, such as IE 6-8?

If it’s less than 1%, do you really think the additional development spend is worth it?

On a high portion of your users are on these older browsers, have you ensured you are testing your website on these to ensure your website looks and functions the same for your key user base?