I’ve written this guide for anyone in the first week of a new job in a web team. In my experience there’s seldom a team member whose dedicated to care of the Google Analytics account, so there’s a good opportunity — for you, the new hire — to survey the health of the analytics properties, identify any problems and make updates that will benefit your new organisation.
This checklist has been helpful to me in the past. There’s more detail for each section which I’ll go into in later guides, but this should give you a good starting point to kick off your own Google Analytics account health check.
Bounce rate
The bounce rate for your site can be a good barometer for the health of your analytics configuration. If you see a site-wide bounce rate under 25% that’s a clear sign that something’s wrong.
Head to Google Analytics and navigate to the ‘Behaviour > Overview’ report then switch on the ‘Page views vs Bounce view. Take a look back over the last six months. If you see a value within the 45-55% range then your site is doing fine. The definition of ‘good’ bounce rate varies between industries. For a longer discussion on this topic check out The Rocket Blog’s 'Good, bad, ugly, and average bounce rates'.
Identifying what’s wrong will take a bit of digging on your part, but It will most likely be due to one or more of the following problems:
- Your site has two or more (!) sets of analytic’s code in your template - perhaps one if embedded in the page and another is in the Google Tag Manager code
- Your site’s event tracking is configured poorly, for example your scroll tracking might be set to “non-interaction hit: true”
- Your site is using a poorly configured add-on or plugin
The remedies are pretty straightforward (remove duplicate GA code, set “non-interaction hit” for events that aren’t really interactions), but should be done as soon as possible. Remember you can’t fix your data after it’s been (incorrectly) processed by Google.
Accounts, properties and views
Your Google Analytics is divided into three levels:
- Account: one account for all your organisation’s properties
- Property: usually pertains to one website or app, but one property can track multiple sites if those sites appear to be one contiguous journey to the visitor — for example, www.example.com > shop.example.com
- View: Each property can have up to 25 views per property. Your views contain your data and your reports
It’s a good idea to maintain at least three views for property:
- Unfiltered: a view untouched by filter or configuration. An unadulterated benchmark to which you can always refer back to if you see something odd in your other views
- Test (with filters and config): The view in which you test any new filter or configuration that might affect how data flows into your reports
- Main (with filters and config): Your live production view with proven and tested filters and configuration. Give non-web team colleagues and agency staff access to this view
If your site only has one view— the default view that was created when the account was first set up —rename it to ‘Main’ and create a your two new ‘Unfiltered’ and ‘Test’ views. Never delete your original view. Once your data is gone, it’s irrecoverable.
User access and privileges
Your health check should include a survey of who has access to your organisation’s Google Account. The amount of people with access might surprise you! I recommend reducing the number of accounts down to a minimum number of essential staff and agency partners.
Start by emailing the lists of account holders to let them know you’re tidying up access to the Google Analytics account and will be removing access for unused log-ins in, say, two weeks time. Ask people to get back to your if they still need access the Google Analytics account for their project, otherwise they need not respond and their log-in will be closed.
This advice might sound a bit hard-nosed, but having lots of people with access to your Google Analytics account is a risk for your organisation — especially if those people no longer for your organisation or are contracted to it.
Once you’re whittled down the number of people with access to an essential few the next step is tidy up the permissions that person has.
Google Analytics permissions a granular. People can have access at the Account, Property and View levels. I recommend you grant access to only those views your staff need to do their work (and that view should be the Main view).
Giving people Account or Property level access might make it possible for them to traverse into properties (if you have many) and views they probably don’t need, or shouldn’t have access to.
If someone needs higher access (usually an agency) then grant them that access long enough time to do their work and then return them to a sensible default like ‘Read & Analyze’.
Finally a word about log-ins. Only grant access to people using your organisation’s email domain, rather personal addresses That way it will be easier to check if that person still works for your organisation. It’s easy for people to register an existing email company address with Google.
Google Tag Manager
If your organisation isn’t already using Google Tag Manager, then arrange to move your analytics implementation over to tag manager as soon as you can. It’ll make your life so much easier. All you tracking can be managed in one place and make it a lot faster to deploy analytics to your site be removing the developer / development bottle-neck.
The same rules about access and security I mention above also apply to your Google Tag Manager account, plus one more:
- Give access to only those who need it
- Give only those permissions people require
- Make you and the rest of the web team the publishers of your Google Tag Manager account. If you don’t know what’s in your GTM account, taking on this lead role will force you to become familiar with all the tags, triggers and variables.
If you find this daunting then check out the many clear and helpful resources on Simon Ahava’s blog and Julius Fedorovicius’s Analytics Mania.
Set up your new Google Tag Manager account with a set of useful default tags. Dana DiTomaso explains what those tags should be in a Whiteboard Friday over on the Moz blog and I’ll show you how to do that in a follow-up article. For now the short answer is:
- a page view tag for all pages
- an event to track scroll distance for all pages — don’t forget to set it to “non-interaction hit: false”!
- an event to track outbound link clicks
- an event to track all file downloads
- an event to track contact link clicks on telephone numbers and email addresses
- an event to track contact form submissions
by Gareth de Walters