Events in Google Analytics

July 2015

Track what matters

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.

Receiving events from your site

In Google Analytics, tracking these key actions is done by sending Events. Events are small messages you can send to Google Analytics from your website when someone does something you want to track. The most common way of sending these Events is via JavaScript.

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() function from within your JavaScript when something has happened. The basic syntax is as follows:


In our case, the first two parameters (send and event) will always be the same, so we won't worry too much about them.

For basic tracking, YOUR_EVENT_CATEGORY and 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_LABEL and 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)

Anatomy of an Event

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 newsletter_submission.

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 1.

With all those values plugged in, here's what final our Event tracking code for the newsletter submission will look like:

   'Newsletter Form Submission', 

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).

Verifying Events

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:

"Real time console test"

Press return and all being well, you should then see the event pop up in your Real-time dashboard:

"Analytics real time preview"

Setting up a custom dashboard and a basic widget

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.

"Analytics 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).

"Analytics snappy title"

Click "Save" and behold, your mighty chart comes to life:

"Analytics newsletter signups demo"

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).

A bar graph and two columns

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.

Supposing our second form is a contact form, you could track it by sending a JavaScript event like so:

   'contact_form', // As opposed to newsletter_submission
   'Contact Form Submission',  // As opposed to Newsletter Form Submission

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 forms category.

"All forms widget"

With this setup you'll have a bar chart which shows everything which happens in the forms category, grouped by action:

"Two up demo"

From here you're set up to track a huge variety of interactions through a relatively simple interface.

Bonus: Tracking events from the server

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.

In summary

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.

Ever wish you got more email?

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.