Getting useful information out of Google Analytics can be quite an undertaking. With a standard installation (i.e. dropping in the
analytics.js code), it's possible to track page views and learn a great deal of other information about the people visiting your site, but without intervention from you it can be difficult to see how this information relates to your goals. Often the information you want will be in there, but it can be overwhelming to try and get it out in a format which means something to you. It's all too easy to settle on the default pageviews line chart and leave it at that.
This isn't to disparage page views - they can be interesting and worth keeping an eye on - but it's easy to hide in their endless ups and downs without thinking critically about how people are using a site and how it can be improved.
The key to tracking meaningul data on a website is to define what actual actions you want users to complete on your site, then track these actions over time. Perhaps you're looking to get people to sign up to your newsletter, or reach you through a contact form. Establish what these key actions are for your site up front, and when you do get data it will really mean something to you and help you improve.
To begin, make sure the universal analytics.js code is embedded on the pages you want to track Events from. The Events themselves are sent by calling the
ga('send', 'event', YOUR_EVENT_CATEGORY, YOUR_EVENT_ACTION, YOUR_EVENT_LABEL, YOUR_EVENT_VALUE);
In our case, the first two parameters (
event) will always be the same, so we won't worry too much about them.
For basic tracking,
YOUR_EVENT_ACTION are the most useful. With them, you can track and display data for most common user interactions. I've found
YOUR_EVENT_VALUE are often still required to output data or create goals, so should be included (the docs seems to indicate these aren't required, but that's been my experience)
Let's assume the key action we want to track is a successful newsletter signup by a visitor to your site. Here's an overview of the values each field might have:
YOUR_EVENT_CATEGORY is, unsurprisingly, the category of the Event. For example, this could be
forms for our newsletter submission tracking.
YOUR_EVENT_ACTION is what's actually being done. In our example, this could be
YOUR_EVENT_LABEL will be the text that is shown on the events tracking page. However as we're going to be showing our data via a Custom Widget, we won't be using this. For our example let's just use "Newsletter Form Submission".
YOUR_EVENT_VALUE is an integer which indicates a value your Event might represent. This is useful for tracking numeric events (e.g. e-commerce purchases), however we're not interested in that so we'll just use the value
With all those values plugged in, here's what final our Event tracking code for the newsletter submission will look like:
ga('send', 'event', 'forms', 'newsletter_submission', 'Newsletter Form Submission', 1);
To fire this Event, you just need to pop this function call wherever you want to track the event in your code (for example in an AJAX function callback).
To see that things are hooked up correctly you can use the Real-time Events tracking view provided by default in the Google Analytics control panel. To access it, open up Reporting > Real Time > Events. The quickest way to make sure you are sending events correctly is to send the Event through the console. With the Real time event control panel page still open, open your site in a new tab, open up the console and paste in the tracking code below:
Press return and all being well, you should then see the event pop up in your Real-time dashboard:
This is all well and good, but how can we keep an eye on these events over time? Enter, the custom dashboard. Custom dashboards are basically a way of pulling the data you care about into one place so you can see it at a glance.
To create one, go to the Reporting Tab and click "Dashboards > New Dashboard". Choose blank canvas (we'll create the charts ourselves) and give it a snappy title.
You'll then be prompted to create your first widget. Widgets are just charts which show Event data. We want our new widget to show a line graph detailing signups over time, so we click the "Timeline" tab in the "Standard" list of charts.
Now we need to get the relevant data into the chart. To do that we want to filter our Event data so we only show the Events we want to track. To do this, select "Total Events" in the "Graph the following metric over time" dropdown, then add a filter so we only show Events where the Event Action is the one we want to track (in this case the
newsletter_submission action, as above).
Click "Save" and behold, your mighty chart comes to life:
Hint: if you don't see any data yet, change the date in the dropdown to be todays date (by default it will show data from yesterday and earlier).
Let's take the concept of filtering a step further and add a second chart to show the popularity of different types of form actions on the site. Say our site has two forms and we want to see how many people fill in one form compared to the other. This is what bar charts eat for breakfast. Bar charts allow you to compare different events with something in common and see how they stack up against each other.
ga('send', 'event', 'forms', 'contact_form', // As opposed to newsletter_submission 'Contact Form Submission', // As opposed to Newsletter Form Submission 1);
In the same way that we previously filtered all the events to only show
newsletter_submission actions, we now want to show all actions within the
forms category. Because we want to see a bar chart which shows all the different actions, we set the "Grouped by" field to "Event Action". Then we create a filter to only allow through data in the
With this setup you'll have a bar chart which shows everything which happens in the
forms category, grouped by action:
From here you're set up to track a huge variety of interactions through a relatively simple interface.
There may be instances where you'd like to track events from the server as well as the client as we've been doing up to now. If you use Ruby I can thoroughly recommend the Gabba Ruby Gem, which makes sending events a breeze. You can even use the same client side cookies so actions will be tied to the same user whether sent from the front or the back end.
Custom Events can provide a simple, flexible way of tracking user interaction and help you improve your sites and apps. Thoughtfully applied, they can help you think critically about what a successful site means to you, and give you the information to work toward improving it over time.
Neither do I. You're busy, and so is your inbox. I'll only be in touch when I publish something new. And of course it goes without saying your email will be kept completely private.