10 Things You Should Do When Setting Up Google Analytics

Your website needs web analytics for many reasons, not just to produce dashboards for reporting! I’ve been involved in many implementations, either doing them myself or using data specialists to handle more complex projects. Over many years I’ve learned that there are some golden rules to follow to ensure the set-up and tool configuration is as accurate as possible.

Get the initial set-up and configuration wrong, and you face future headaches, such as inaccurate or incomplete data that can’t be retrospectively fixed. This can also be costly, as inaccurate data leads to false conclusions and may obscure problems that need urgent attention.

This blog discusses 10 tips for setting up your web analytics tool and is based primarily on experience with Google Analytics as more and more organisations are using this tool. Please do add to the tips via the comments, as this is by no means exhaustive.

1. Understand the implementation options

There are two key considerations:

(i) What is the best technical implementation option?

The traditional route is to add tracking tags to each webpage, with the base code plus custom code for events, custom dimensions etc. However, there is also the data model approach, which demands greater technical understanding of the underlying data model and input from the developers.

This (old) blog from Justin Cutroni is a good read for people new to data layers and sets out the key advantage over the standard tagging option.

(ii) What type of site do I want to enable tracking for?

Choose this carefully. A default setup of Google Analytics is designed to track content and visitor data for a single domain. If you have sub-domains that also need tracking, or 3^rd party checkout pages and iframed content, you have to make sure you define this and ensure the tracking code supports it.

If you have an existing GA account and are updating the platform, or migrating to a new platform, check to ensure you have the most recent version of the tracking script. With frequent updates, it’s important to check the code supports important features like Enhanced Ecommerce.

A good example is synchronous vs. asynchronous code – the old version (synchronous) means the GA code has to finish executing before the rest of the page assets can be loaded. This will slow down page load speed.

2. Use a dev account

Make sure there is a standalone dev account that is used on the dev site to test the set-up. This allows the dev team to test the tracking code and custom tags to ensure all tags are firing correctly and reports are being populated as expected.

It also allows you to isolate developer access to a specific account to minimise the risk of test data worming its way into active profiles.

3. Create a master profile and don’t edit

I’ve seen GA accounts with only one profile, where lots of filters and configuration changes have been applied and then something goes wrong with the data. By creating a master profile that is never changed, you have a control data set to reference against should you discover any data integrity questions on customised profiles.

4. Set-up multiple views

Typically, there are multiple GA users in an organization, each with slightly different data/report requirements. A neat way to customise to suit each person is to create custom profiles that tailor elements like dashboards, custom reports and segments to the user group, rather than trying to do everything in one profile.

You can set user permissions at profile level to give people flexible access and greater control over their own profiles, whilst maintaining a master view that is the preserve of the insight team.

5. Use filters wisely

Once you apply a filter and it starts affecting reports, you can’t undo that filter for the time period it was active. So you need to be sure that the filter is doing what it is intended to and doesn’t have any negative impact on the data being collected. A good example is using URL re-write filters – get it wrong and you can screw up content reports.

This links with 2. above – testing configuration on a dev profile lets you iron out errors and inconsistencies before deploying to the master profile.

6. Exploit custom variables

Custom variables help you get more out of your data. Custom variables need to be in your code before a pageview or event is tracked, or they won’t work. An example of using custom variables is tracking author performance on a multi-author blog site. By placing a custom variable on the blog page and assign the author value to it, you can drill down into sessions that include a specific author and compare how each author contributes to key KPIs.

Another use could be tracking people who comment on blogs. There has long been a debate on the value of driving comments – do commentators really add value? Is there a benefit to increasing blog engagement and conversation? By tracking people who comments and assessing their behaviour vs. non commentators, you can start to answer these questions.

7. Set-up custom reports

One of the best ways to make data meaningful is to customise reports to show you exactly what you want to see, rather than trying to fudge by cross-referencing lots of individual reports within GA. A well-structured custom report can save a lot of analysis time.

Avinash Kaushik wrote a post recently on this, giving five examples of useful custom reports and how to set them up in GA.

8. Link to relevant data sources

GA has extended its ability to connect to other data sources over the years. The basic starting point is to connect up AdWords and Search Console (formerly Webmaster Tools).

You can also use the API to connect GA data to other data sources, like CRM. To align with other data sources, you need a primary key for each user. This can be stored in GA using a visitor-based custom variable.

It’s also possible to import product data to support enhanced ecommerce analysis and reporting.

These blogs by Dorcas Alexander and Justin Cutroni provide more context and examples uses.

9. Set-up alerts

A common problem I encounter is analysis siestas. This is where ecommerce teams drop off their analysis intensity when daily trading pressures peak, so what used to be a daily exercise becomes every 2-3 days, or people revert to reporting rather than analysing.

One way to tackle this is to use alerts to send nudges to people based on triggers. For example, send the SEO Manager an alert if brand traffic falls by more than X%. The challenge is to make alerts meaningful – if the information is simply ‘interesting’, it won’t provoke action. The alerts should be tied to the primary KPIs that people are measured on, that way if the KPI spikes/falls, action is more likely.

10. Test convincingly

Testing an analytics set-up deserves proper attention and input from all key users. The following are important checkpoints:

• The data layer is being rendered correctly on all pages
• The tags are firing correctly on all pages
• Reports are populating with accurate data
• Custom Dimensions are working
• Custom reports are working
• Filters are working
• User access controls are correct
• Data sources are linked

Your view

Do you agree with these recommendations? What else should people do as part of a web analytics implementation plan? I’m not talking platform specific, more general good practice to avoid future heartache.

We’d love to hear your thoughts in this.

Thanks, James