Three years ago I ran a MeasureCamp discussion session entitled “Track everything, measure what matters“; a concept that was the norm in 2016. Back then, the challenge with this concept, as it still is today, is the issue of “time” to implement tracking.
Discussions, highlighted a range of instantly deployable GTM tags to capture “essential” tracking. Followed by more tags to capture “further” tracking that either had to be thought about or took time to deploy. In total and over a relatively short period, we nearly had tracked “everything”.
In 2019 things have moved on. The need to track, to measure, to gather insights is even more than before. This has accelerated the “track everything” mentality and we can often find our setup overloaded, mismanaged and in danger of being inaccurate.
So at this years MeasureCamp (London 14) I ran a session to look at the features of your setup that you need to keep a handle on. More of which in a bit.
It’s worth noting that other factors can influence your GA setup and the features you use:
- History/ legacy. It’s unlikely that you are starting from afresh, more often we inherit an instance. Over time we naturally develop this instance and approach features in different ways.
- People. GA users come and go with different ways of working. Be it segments, goals, reports, through to dashboards and exports (google sheets/ Data Studio) we tend to work in isolation. When a new analyst comes in we ultimately recreate the created and this leads to duplication and inconsistencies.
- External input. Whether it’s via a tag manager or direct to the code, we can add GA features from outside the tool. For example events. Once in the hands of others, we open the door to mismanagement.
- GA itself. Finally, we have the limitations placed within Google Analytics.
GA Features; best practice and limitations that you need to consider
Account, properties and views
So let’s start with the simplest. It goes without saying, as does for most of the features, to have a naming convention! Something that everyone can understand.
Overall we normally have one account. The only reason for more than one is if you have 2 independent websites, services or apps. The logic of containing them in one account is to leverage the shared functionality of other features below.
Properties are usually for your environments (limit 50 max). So were talking websites, apps etc but also test and developer instances of a website. The key here is separating your data. Ask yourself do we need to separate this data? You should want to separate your live and test data. You might also want to separate a global suite of websites (where traffic is isolated to a geographical region). If you have a suite of websites but they are connected through a user journey (campaign site to sales site) then keep these in the same property so you can see this journey.
Views (25 max) should be few in number. Ideally a vanilla view (nothing changed or amended), a test view (to test out a new filter, goal) and a master view. Test and Master should be in sync unless you are in the process of testing. Views go hand in hand with filters and your GA users. So the only other reason for additional views is ADD
TIP: Don’t use views to give users a play zone. If users want filtered information, then think about custom reports or sharing data via the GA api to google sheets or data studio.
Goals
We only have 20 goals per view, so very limited, but when we talk goals, they should be limited in use. Using a Measurement framework you will quickly focus on Macro and Micro goals for your service/ website/ app. Often the line between a goal and an event (be that a click or a pageview) can become blurred. We need to focus here on what is going to get reported, what is going to be sliced and diced to uncover insights. Goals really align to objectives so think a purchase, a sign-up, or getting to a certain valuable page.
Segments
We can have lots of segments, but sharing them between views is very important. A naming convention again is key so we can understand them at the drop of a hat. Segments come hand in hand with goals as well. They are the way to dig deep and gain insights. Was it a browser that converted, was it a certain medium, a returning user or a specific custom dimension (eg user ID)? Because of this, you might want to include goal numbers when name segments too.
TIP: Segments can be shared from anyone. If you import some remember to rename them.
Filters
Use of filters is ultimately to enable clean data in GA. So uses include:
- remove PI, (some url strings can contain personal information)
- remove internal and bots (obvious, but make sure your data is genuine users)
- unify caps (Search queries is an obvious one, but best to unify cap use so we get collated data)
Filters, in conjunction with views, should not be used to present unique sets of data, for example, certain pages of a website to Larry in Sales. Segments and reporting can do this adequately enough.
Users
Think long and hard about this one. My advice is to have minimal users in your GA instance. With the brilliant connections to Google Sheets and Data Studio, you can share interactive reports very easily now. Their additional bonus is they are customised too, meaning we can amend the language, the design and the data to fit the audience.
TIP: Giving access to GA throws opens differences in interpretation to reports and charts which can be harmful in the wrong hands.
Events
Events are great. Without them, we lack real behaviour activity on your website, eg what element of a page did a user click on or what error messages were presented to them.
So you’re probably thinking the more events we track, the better your insights will be? Right? Maybe not.
Looking at your measurement model, we need to measure what matters, what really matters. And so, to do that we need to understand and trigger what events are important rather than a nice to know.
With GA we have some fundamental limits with Hits. We have a cap on hits per month (which can be upped for those using 360). If you go over this limit your data will be sampled. We also have hits per session (500). If a session has more than 500 hits, that journey stops getting tracked, meaning anything after the 500 isn’t in GA. Now logically for most sites with a purpose (a sale or a download…), your final activities are goal-related. And thus it is these goals that won’t be recorded. Not good! Remember track the events that really matter.
Naming protocol is again key. Not only being understandable but logical as well. Categories, actions, labels and value all have a purpose. We need to be consistent in use. For example, actions represent what a user is doing a download, a click, a watch…
Custom dimensions
GA provides standard metrics and dimensions out the box (sessions, pageviews, browser…); however, you might want some new ones. Examples here could be personas, a/b variants or even external factors such as the weather. These new dimensions/ metrics provide insights, and more importantly a great way to segment data. Given the above examples, you could see which persona, or a/b test converts or what type of weather it was when sales in summer holidays spiked. Dimension again are limited. 20 in standard GA or 200 in 360.
TIP: Be clever when using custom dimensions. When they can be merged do so eg test variants.
Content groups
Each view has 5 of these. They are ideal for websites with defined areas; for example, in eccomerce you could group on product pages, search, cart or post-purchase. Other sites with a differing audience, you could group “internal” pages.
TIP: These aren’t retrospective, so best test them in your “test view”, then implement them in your live view.
Channel groups
By default, GA gives you “Default Channel Grouping” This is google’s way of grouping your acquisitions. From time to time though, you might want to amend or create your own alternative to highlight/ separate important traffic. Examples could be affiliate traffic, partner traffic, email campaigns…
TIP: You can create your own channels first and then share them with the view if appropriate.
Attributions
Attribution modelling is a feature of GA instances where ecommerce is switched on. It allows you to assign credit for conversions to a touchpoint in the conversion journey. Along with standard models, you can also create your own (10 are possible per view). Normally the latter is when you have a very bespoke user journey where the other models don’t suffice (first interaction, last interaction, time decay, linear).
TIP: Have a real good test of the other models first. This feature is probably the hardest to understand.
Eccomerce
Finally, eccomerce itself. The takeaway here is just to set this up right from the start. Like some events and custom dimension, you will need a developer to hard code this or add commerce variables to the datalayer.
TIP: Eccomerce has set fields (ID, SKU…) so it is important we hook the right information to the right field.
Conclusions
Ultimately we need to make sure that any GA instance/ Analytics eco-sphere is manageable. This goes from big global organisations to small independents and startups. Along with tracking and measuring is the important step of planning. By planning, we can be more efficient in our use of GA and the features mentioned above. This, in turn, caps tracking in a positive way, whilst ensuring we still measure what matters.
NB Big thanks to all those who attended and fed into the discussion at MeasureCamp London 14. This post is from all of us!
Web Analytics and Measurement 
Leave a comment