About Tom Bennet
With a proven record of driving performance for prominent international clients, Tom is responsible for keeping companies on the cutting edge of organic digital marketing and helping them understand, attribute and report on their data. As a web developer, conference speaker, workshop trainer, and published writer, Tom has a uniquely diverse skillset that bridges the technical and creative sides of the field.
In his Learn Inbound talk, Tom will demonstrate five ways marketers can use Google Tag Manager to yield profitable insights for their business. While your competition fumbles with thoughtless event tracking and hastily configured click triggers, you’ll come away equipped with actionable techniques to apply immediately. Learn how to make yourself indispensable to your development team with valuable data on usability issues and browser incompatibilities, and supercharge your ecommerce tracking with dynamic goal values and granular product data.
- Learn why it’s not enough having accurate data, you need the right data.
- How to use Google Tag Manager to identify usability issues and browser incompatibilities
- How to improve your ecommerce tracking with dynamic goal values and granular product data
Good evening everyone. My name's Tom. I work at Builtvisible. Today I would like to talk to you about Google Tag Manager, and the ways in which it can help you to measure, and demonstrate success in Google Analytics. If you only take one thing away from my talk this evening, I want it to be this idea of understanding, and investing in your data. Google Analytics is used on approximately 60 million websites worldwide, and out of necessity, it's designed to work well with as many of those as possible. This is one of the reasons why it's so popular, it's because an out of the box implementation with zero customization is very easy to set up and will be okay.
But let's be honest, the one size fits all approach to digital marketing, it's rarely the best. The needs of your business, and the KPIs of your website are unique. It doesn't always make sense to rely on a piece of software written to suit 59,999,000 other businesses. Data collection is also crucial for the entirety of the analysis process as well. It doesn't matter how many segments you build, or how many goals you define, if you mess up your data collection, then it will scrub every other stage too. The level of insight that you'll be able to glean will always be limited.
The value of the insights that your analytics software will give you are directly tied back to the investment that you have made in data collection, that first stage of the whole process. Today I'm going to run through a few examples of how a smart implementation of Google Tag Manager, can help you dramatically improve the relevance, and the quality of the data that is available to you in Google Analytics.
There are no magic bullets of course, but I hope that everyone here will be able to take away at least one technique that they weren't previously aware of, and that they'll be able to get some value from it. We're going to start with engagement tracking, specifically content engagement, because so many organizations are stuck trying to answer meaningless questions like, "Why is that bounce rate so high? Get it down." The problem with that is that you see reports saying things like, "Our content is really good, because our site-wide average bounce rate is down by 10%." But that's worse than misleading, it's often inaccurate as well. The cause for this is many of the people who use bounce rate as their primary KPI don't actually understand what bounce rate is measuring.
The effect of that is that individuals are encouraged to fix the metric rather than the underlying problems, which are of course unique to your site. We'll return to the definitions for a moment, just refresh exactly what is a bounce. Google defines it as a single page session. Specifically it's one that's calculated as only being a single request to the analytic server. What that typically means in practice is that a user arrives, and leaves your site via a single page without viewing any other pages in between. It's a single page session. But it's important to remember that sessions are rarely just this fictional construct that Analytics comes up with when it does the processing of your data.
Analytics doesn't know how long a user spent looking at a particular page. It doesn't set any kind of timer to measure when a session started, and when a session ended. All it has is this raw hit data, page views, events, transactions, and then from that, it extrapolates, and it builds this kind of arbitrary notion of a session. They start and end fairly arbitrarily. Typically, either 30 minutes of inactivity, so a gap of 30 minutes between hits, or midnight, or a campaign change. Now incidentally this is why if you commit the cardinal sin of tagging your internal links with UTM parameters, you'll typically see a very high bounce rate on those pages, because navigation via those links will result in a new session starting.
In order to calculate what it provides as the average time on page, it actually just measures how long it takes until the next hit is received. Then to get session duration, it's just measuring the time between the first, and the last hit in that session. The Analytics then reports on these arbitrary metrics, that it's calculated when the data was processed. But really, a session is just the model that Google Analytics uses to make more sense out of its world of raw hit data. When a user bounces, Analytics doesn't have enough data to generate all of those metrics that it'll often report on, like average time on page for example, there's no second hit that it can measure against, and calculate a time on page. Which is why it's really not a good metric to use as your sole KPI, especially when viewed as an aggregate, because it can become meaningless.
The questions that we can answer are pretty substantial. We don't know what the user did on the page. We don't know how valuable they are as a potential customer. We don't know what they did. We don't even know if our website functioned properly on their device, or alternatively, if they read every single word of our content, and bookmarked, and thought, "I'll come back to that later, 'cause that was great." We don't know. A default, out the box implementation of Google Analytics won't tell us that.
Ultimately, we lack good data, and GTM, a smart implementation of GTM can help us to improve our data collection. We'll stick for a little longer with the bounce rate analysis, 'cause I think it demonstrates some really good points. You do have control over the bounce rate calculation. You can control which hits will effect bounce rate, and which don't. To illustrate this point, this is an example from a client that I recently onboarded, they were seeing a zero percent bounce rate on most of their pages, and they couldn't figure out why.
Ultimately what had happened was their development team had configured their implementation to fire not just the standard page view, on every page, but also an event, which fired when all the dependent resources on the page were ready, like images, your star sheets, scripts and so on, and the effect of that was that it's kind of impossible to have a single hit session, because every page viewed was firing two hits. That's kind of the same principle why really bad WordPress implementations will often see a very low bounce rate, because you get duplicate tracking code, and you get two page view hits per page.
You can control which events effect the bounce rate by using what's called the non-interaction hit flag. You can set this very easily in GTM when you're configuring your event tag. By setting non-interaction hit to True, the bounce rate for the page on which this event fires will be calculated as if the event wasn't there. For example, if you absolutely have to fire an event when an auto-play video starts for whatever reason, just set non-interaction hit to True, and the bounce rate will be calculated as if that second hit wasn't there. So it'll be more accurate.
This idea of using events to kind of control our bounce rate, plays quite nicely into the whole idea of on page engagement tracking in a single page view session for example. A lot of people have started using some of GTMs built in triggers to try and manipulate the bounce rate calculation. For example, GTM has a timer trigger, and by using that, it is kind of possible to avoid reliance on GTMs arbitrary time on page calculation.
You can set for example, a trigger of one minute, and that will fire when someone's been on a page for one minute, and that event hit will negate the bounce. But that's just as arbitrary, there's nothing inherently special about one minute, it doesn't really make much sense. The scroll depth trigger as well, it can be very powerful, when used correctly, but again, there's nothing inherently special about 50%, there's no reason why people who reach that scroll depth shouldn't be counted as a bounce, if they didn't then go on to view another page.
One of the triggers in GTM, which I'm really fond of, it's fairly new as well, is the element visibility trigger. To illustrate this point, I've picked a random example from the Learn Inbound website. Let's say, for sake of argument, you have strategically distributed throughout your longer pieces of content calls to action like this email signup widget for example. You might be interested in who is getting to that position in your content, or you might even want to prevent people who got that far through one of your guides for example, from being counted as bounces. Doesn't matter what the element is, but if you've strategically positioned these kinds of elements at different positions throughout your various page types, then the element visibility trigger can be really powerful way to take advantage of this.
We'll set up a trigger now. As you can see, it lets us define an event based on either an ID, or a CSS selector. We have control, we have very fine grain control over when this trigger will fire, so we can set it to fire when the element is on screen for a certain duration. So if it's dwelled on, as the user is scrolling through your content, or it has to be visible for a certain percentage of the element has to be visible in the viewpoint for the trigger to fire, and you can even control how many times it will fire if the element appears multiple times per page.
In this example, we've used this and other triggers to fire an event when someone starts scrolling through our content, obviously that would be a non-interaction event hit, when they view the call to action, and then when they reach the footer. By drilling down to a particular page, and then viewing this kind of event data, it can be very powerful in allowing us to get a sense of who's actually reading our content, versus just bouncing immediately. It can also be segmented by audience type and page to give us insights that we can use to actually steer our strategy, whether that's our internal linking strategy, or our content strategy based on what we learn about which pages people are engaging with.
It can also be specific, not just to your business, and your website, which obviously is very important, but also to your different page types. Needless to say, this goes much further than just tweaking the bounce rate. My next point is that your data collection methods need to be tailored, not just to your business, but to the different page types, the different types of content that you have on your site.
As an example, we're going to look at interactive content. Now this is an example, which I picked randomly, which is very similar to a project I worked with a client with recently. It's an interactive piece of content marketing, which in this instance, it lets users calculate the heating costs for their home. You can select your room type, sizes, and glazing, and what have you, and then it will give you an approximate cost for heating that.
Now, in a classic example of the marketing team, and the development team not communicating effectively, this was pushed out the door with very little consideration given to its tracking requirements, which is a shame, because GTM is really, really good at letting us track the kinds of highly relevant interactions that will be taking place on a piece of content like this. Interactions which are very relevant to the kind of audience we're trying to appeal to with this content. One of the best ways that allows us to do that is with a custom event trigger type.
We can then use this to fire our GA event tag, so we know how many people are using the interactive content. The natural next step of course, is to get more granular. We want to know how people are using this content. If the purpose of it is to appeal to our wider audience, and drive more revenue ultimately, we want to know how people are engaging with this piece of content that we've built. Let's say for example, we want to know which options users are selecting when they use our calculator, we can supplement our data layer event with two data layer variables. In this example, we've gone for room type, and glazing type. These simply populate the data layer with variables which reflect the users choices at the moment they hit Go.
We set these up in GTM as a data layer variables, which means they're then available for us to use in our tags, so in our GA event tag for example. Here, we've referenced our variables as the event action, and the event label respectively, and what that will give us is relevant data about our audience, and what they are using our interactive content for, what they're looking for. We can use this to iterate not just on the layout and the functionality of the page, but we can also use it as the basis for guiding our content strategy, or even improving our lead nurturing process based on what we learn our audience is looking for, it's gold as far as data goes.
The really cool thing is that you can extend this approach quite a long way by using goals. By segmenting to a particular campaign for example, we can then see how people are engaging with this content, and then analyze that in isolation. Thanks to GTMs native variable types, we can then get quite creative. I'm a big fan of defining goals, which are not overtly commercial. So for example, with the heating costs calculator, we could set an event value which fires when someone engages with our piece of content, and we can set the value based on what we know about them as a user.
The last area that I want to explore is using GTM to better group our content. A good example of that is by setting up a content grouping. For example, if we wish to segment our content strategy into different groups based on authorship, we can do that with a content grouping. It's very easy to implement using GTM, and the data layer. We create the content grouping at the view level, we enable a tracking code based implementation, and we give it an index number of one. We can then set up the actual author using a data layer variable.
This is the point at which marketers who might rely on GTM as a way to bypass their development team entirely might try to screen scrape. You can set up variables of a dom reference, or what have you. By using the data layer, we can work much more smartly. We'll get our development team to implement the blog author as a data layer variable, same principle as we did earlier, for our interactive content, and then we can reference that in our page view tag. So under More Settings, you can reference your content grouping by its index number, and then reference the data layer variable in there, so that every page view hit will fetch the author from the data layer, and then fire that as the value for that content grouping.
The result of that is that you can view aggregate performance of pages by particular authors, and get a sense of how they perform as a whole. That's very useful data when it comes to assessing how well your content strategy is performing. But I'm quite interested at the moment in looking more at segmenting our users, not just our content, looking at particular groups of our audience. We're going start by looking at behavior based segmentation. If for example, we've decided that we are particularly interested in users who engage with our content, we might decide to track users who comment on our blog, and then view that audience group as a separate segment of traffic.
The way that we can do that is with a custom dimension. Just to refresh on the difference between grouping and dimensions, whereas content groupings allow us to organize our pages into logical groups, custom dimensions let us record extra, like non-standard data on top of GA's standard dimensions. They're very flexible in how they let you do this as well. Remembering that every hit, which goes to GA, has a different scope, for example, the page view hit has a scope limited to that page view, it's the page that was viewed, but landing page has a scope which applies to the whole session, because sessions have a landing page for example, just like products have a price.
Now, it's the user level scope that we're interested in here. Because the user level scope will let us apply the data from that hit, not just to that session, but to the user and all of their subsequent interactions on our website. To use our blog commenting example again, we set it up at the property level, the free version of GA gives you 20 custom dimensions per property, which is quite a lot to play with, we'll give it an index number of one, and we'll set the scope as user.
Back in GTM, we're going to fire this custom dimension as part of an event hit, that fires when someone comments on our blog. We set our standard GA event attributes, the category in the action, blog comment, whatever, and then under More Settings, we can set the custom dimension. We put in an index number of one, and the dimension value of commenter. In terms of a trigger, we can once again use a data layer event. Same as our interactive content example, from earlier, we can define blog comment as our data layer event, and listen for that in GTM.
To run through what will happen off the back of this, a user will submit a comment, and that action will push an event to the data layer, which we're listening for in GTM. GTM detects that, and it fires our normal GA event tag, but that hit, that event hit that goes off, includes a custom dimension which defines the user as a commenter, and that will apply to all their subsequent interactions on our website as well. The result of that is that we can then view the behavior of our engaged users as a segment in Analytics, and we can see how they differ from our wider readership. Also, because it's a dimension, we can also use that as the primary dimension in a report like goFlow, and we can see how they engage with our funnel.
We can fire an event to GA, every time this happens, and thanks to the variables of error message, error URL, error line, information which the user wouldn't be seeing, but that we're interested in, we can then fire information to GA on real world usability issues. Don't forget to set non-interaction hit to True, because we don't want this to effect our bounce rate. The result of implementing this, which is a five minute job really, is that you will get real world testing data about what's breaking on your website, where, and for who. You can cross-reference it with the other built in dimensions as well, like, operating system, and browser, and you can then give that information to your developers segment by page, and you can make your website more accessible, and more functional as well.
The value of the insights that you can get from your analytic software are tied to the investment that you make in data collection. There's a lot to play for as well. By demonstrating success, and by unlocking the kinds of actionable insight that you need, you can justify whatever it is you're looking for. Be that bigger budgets, more innovative projects, more development time for your team, and ultimately whatever you need to do your job better. Thank you very much, and enjoy the rest of the conference.