A walk-through of the javascript we use to do some of our event tracking.
This screencast is a little technical
In this screencast I'm going to walk you through the javascript we use to do some of our event tracking. This is definitely one for the geeks out there. Just a heads up, if coding isn't your thing, you might need to show this to a developer.
Transcript
Hi. Just a heads up, this screencast is going to be a little bit technical and geeky. You might want to show it to a developer, if you're not quite up to coding yourself. The script assumes that you already have the Google Analytics tracking code installed on your site. It also assumes that you have the jQuery plug-in loaded — either hosted yourself on your own server, or called in remotely from a content delivery network.
There's lots of them around. You should probably check with your security team though, as to the preferred way for doing that kind of thing for your agency. Hosting it on your own server may be considered a little bit more secure, because it's not a third-party injecting code into your site.
That's really up to your security team. So this script will run in the standard jQuery way, when the documents ready and finished loading, the script will execute. I've got three scenarios that I'll walk you through, and I'll explain the differences between each one.
So scenario one, on the Web Toolkit website, we want to track users that click links that appear in the footer. This is going to give us some numbers to see how many times people might be getting lost and looking for things like contact links, which are often in the footer of the site.
We're going to set the category to be navigation, we're going to set the action to be footer. And then we're going to record the URL of the link that the user clicked. This rule only fires is if the link is inside a block of code that has a class of footer assigned to it.
If it's anywhere else on the page, it will be ignored. We then grab some attributes from the link. In this case, the URL that the link is pointing at, the target, if we're opening a new window or not, and also the text of the link. Now, when it comes to target and opening a new window, I really would question why you're bothering to do that. But just in case you are, the script reflects and respects that that option may need to be preserved.
Now sometimes, links will have on-click events already assigned to them, so just in case they do, we're grabbing the details of that and storing it for later. We'll actually reapply those on-click events after we finish processing the Google code. Now the rule is only triggered when someone clicks the link, but we're going to intercept the link to stop it from being executed in the normal fashion, until we've had a chance to actually build the custom event and send the data over to Google.
So we're building an event using the category, action and label information that we have chosen. To give the page time to actually run this code, you do need to include a timeout, or a slight delay. In this case, we're using 300 milliseconds. That is almost undetectable for most people.
And this gives the browser a chance to actually fire the event before it moves you onto the link that you had originally clicked on. Now we bring back any previous on-click event details, and then we execute the link. You'll see the value of 300, that's where we control 300 milliseconds.
You could make that a little lower, perhaps 200 milliseconds. You would not want to go much lower than that, otherwise, again, the browser won't have time to finish executing the task before moving on to the previous page. And that could cause problems passing data to Google.
So now I've got a second scenario. In this case, we want to know if people are using the flyout menus on the Web Toolkit to navigate around the site. Now, this custom event is only going to trigger if the user expands the menu and clicks one of the items. It won't trigger if they only click on the parent menu itself, or if they just hover their mouse over the menu without clicking anything.
We're going to set the category to be navigation again, but this time, we'll set the action to be Main Menu. And we're going to record the URL that the person clicks from the menu. We're also going to set a variable, a custom variable, that's going to tag the visit — or, the proper name for it — the session, recording it as being a session where a flyout menu was used.
Now, why do we do this? Well, it could actually be interesting. We could use this in various reports, or perhaps some custom segments, and see if users who did this type of action on the site behave differently to other users on the site. For example, if a user was able to choose something from the flyout menu, could they get deeper down into the site content, rather than someone who might actually have to use the navigation structure to find the pages?
Now, we could tag the user as a menu user, but that might not be the best approach, because their behaviour might not be the same on every visit to the site. We're really interested in the behaviour of each visit, rather than the behaviour of the user as a whole.
But we could tag the user, perhaps if they were to subscribe or unsubscribe to our mailing list. And again, does that change up anything in the reports in terms of their behaviour? Now just as before, this link is only going to apply to menus and links that are inside the sub menu, so we're using a particular class to identify that. The data is sent to Google using a different action, so in this case, main menu.
And then we create the custom variable. And there's a few parameters that you need there. You need to identify the value of the variable slot. You only have a limited number of slots available. You give the variable a name, and the value that you're setting, and then you choose whether it's a page, a session, or use a user variable.
Now in this case, we need a session variable, because we're tagging the entire visit. If it was a page variable, you would be tagging just that particular page view. And if we were using a user variable, you would be tagging that user. Now scenario three, we would like to know if people are following links from the Toolkit to the official W3C website.
Now, we're already tracking links, where they're external to the Web Toolkit. But this refines things a little further. We could use the category action pair in a different goal or segment. So the event's only going to be triggered if the link matches a link that goes to the W3C website.
We're going to set a category of navigation and action of W3C content, and we're going to record the text that the user clicked on this time, rather than the URL. This might be more useful in reporting, because some of the W3C URLs can be a little bit complex, and deciphering and making them meaningful can be a little challenging.
This is only going to work for links that have been tagged specifically with the class external. And this has only been individually tagged with that class. Then, if, and only if, the URL matches W3C.org, will we then trigger the custom event and send it over to Google.
So the custom event itself is no different to the other custom events, we're just controlling at what point do they actually get generated. Now even if the custom event is then skipped — so if the link does not match the W3C site — the timeout function — the delay of 300 milliseconds is still going to apply, and will also to reapply any other on-click events that may have already been set for that particular link — just in case there's something else that needs to be recorded or acted on.
Now don't forget, you need to test your code. Preferably on a test view for the Google Analytics account that you're using. Not only do you need to make sure that the jQuery that you've written works, you need to check that the data that's being sent to Google is actually what you expect to see.
If you don't define your rules properly, you may get no data for certain events. You may also get events that are counted twice. So pay careful attention to your category, action and label choices. Be consistent, and make them meaningful, because you'll need to interact with those to do your reports.
You may also need to look at non-interaction events. So for example, if you've got a series of links that point at bookmarked positions on the same page, you can track clicks on those links. And sometimes it's actually useful to do so. But you should probably set the flag to true instead of false in the _gaq.push command options.
Otherwise, your bounce rate might be incorrectly reported. This is getting to a level of detail that probably requires a little bit more conversation and thinking. We'll save this for another post. So that's event tracking in a bit more detail, and I really do hope you found that useful.
If you’ve got questions or feedback, we’d love to hear from you. Email us at info@digital.govt.nz or visit the Web Toolkit for more information.
Other screencasts in this series
See the first post in this series for the full list of screencasts.
Give us your feedback
We’re looking for feedback from agencies on how well these meet their needs, and if they’re popular, we may be able to produce more. If there’s a specific topic you’d like to see covered, let us know. Email info@digital.govt.nz and someone from the Digital Engagement Team will get back to you.
