Event Tracking Guide

This document assumes familiarity with Google Analytics Tracking Code configuration. Additionally, you must have the ga.js tracking code installed on those pages where you configure Event Tracking as described here. For more information on tracking your site using the GATC, see the Tracking Basics guide.

Introduction Setting Up Event Tracking

Anatomy of Event Tracking Categories Actions Labels Values Non-interaction Events Implicit Count

Implementation Considerations

Introduction

Event Tracking is a method available in the ga.js tracking code that you can use to record user interaction with website elements, such as a Flash-driven menu system. This is accomplished by attaching the method call to the particular UI element you want to track. When used this way, all user activity on such elements is calculated and displayed as Events in the Analytics reporting interface. Additionally, pageview calculations are unaffected by user activity tracked using the Event Tracking method. Finally, Event Tracking employs an object-oriented model that you can use to collect and classify different types of interaction with your web page objects.

With ga.js, you would commonly apply Event Tracking to:

• Any Flash-driven element, like a Flash website, or a Flash Movie player
• Embedded AJAX page elements
• Page gadgets
• File downloads
• Load times for data

The design model for Event Tracking is highly flexible, and its use can be extended well beyond the common model of user-triggered events—the design decision is up to you. For this reason, useful Event Tracking reports require collaboration with your report users and good report planning.

• Determine in advance all elements for which you want to track data.

  Even if you initially track only a single object on your website, having an overall sense of the various objects/events you want to track will help you establish a report structure that scales well with an increase in the number and type of Event Tracking.

• Work with your report user to plan your Event Tracking reports.

  Knowing in advance how the reports should look will direct the structure of your Event Tracking implementation. For example, if the reports only need to show video UI interaction, your category structure will be quite different than if the reports need to track other Flash UIs like menus, embedded gadgets, and load times. In addition, you can inform the report user about the different tracking possibilities available with Event Tracking to get the most out of your implementation. For example, the report user might be interested in tracking user behavior on a Flash video interface, but might also be interested in latency tracking for the load time of the video. In that case, you can plan ahead to have meaningful names in your event calls.

• Adopt a consistent and clear naming convention.

  In the process of implementing Event Tracking, every name you supply for categories, actions, and labels appears in the reporting interface. In addition, a category/action pair is treated as a unique element in the report statistics, so consider first how you want your metrics to be calculated for all objects belonging to a similar category.

Setting Up Event Tracking

Before you can view event tracking results in your reports, you must set it up on your site following these steps.

1. Set up tracking on your site. Make sure you have set up tracking for your website. For information on setting this up, see Tracking Sites.
2. Call the _trackEvent() method in the source code of a page object, widget, or video.
   

   The specification for the _trackEvent() method is:

   _trackEvent(category, action, opt_label, opt_value, opt_noninteraction)

   • category (required)

     The name you supply for the group of objects you want to track.

   • action (required)

     A string that is uniquely paired with each category, and commonly used to define the type of user interaction for the web object.

   • label (optional)

     An optional string to provide additional dimensions to the event data.

   • value (optional)

     An integer that you can use to provide numerical data about the user event.

   • non-interaction (optional)

     A boolean that when set to true, indicates that the event hit will not be used in bounce-rate calculation.

3. View the reports. Once event tracking has been set up and working on your site for a day, go to the Content section of the reports and view Event Tracking.

Anatomy of Event Tracking

The Event Tracking data model has the following components which map directly to elements in the Analytics Reports interface:

• categories
• actions
• labels
• values
• implicit count

A simple example illustrates how you might use the Event Tracking method to record user interaction with a video Play link on your page. It assumes that pageTracker is the name used for your tracking object.

<a href="#" onClick="_gaq.push(['_trackEvent', 'Videos', 'Play', 'Baby\'s First Birthday']);">Play</a>

In this scenario, the reports for Events would display Videos as the Category, Play as the Action, and Baby's First Birthday as the Label. The rest of this document describes these components in detail. Bear in mind that when you implement Event Tracking, you can use this data model as a guide, or you can simply use the _trackEvent() method to segment user interaction in any way that works for your data.

Categories

For Event Tracking, a category is a name that you supply as a way to group objects that you want to track. It is the first parameter used in the _trackEvent() method and it is required.

The term Category appears in the reporting interface as Top Categories in the Events Overview page. In this model, a category represents the "root level" of the hierarchical structure of Event Tracking, and you can use that structure in any way suitable to your reporting needs. Typically, you will use the same category name multiple times over related UI elements that you want to group under a given category.

For example, you might track user interaction on three separate controls on a single video interface using:

_gaq.push(['_trackEvent', 'Videos', 'Play', 'Gone With the Wind']);
_gaq.push(['_trackEvent', 'Videos', 'Pause', 'Gone With the Wind']);
_gaq.push(['_trackEvent', 'Videos', 'Stop', 'Gone With the Wind']);

Suppose you also want to track how many times the video is downloaded. You could use:

gaq.push(['_trackEvent', 'Videos', 'Downloaded', 'Gone With the Wind']);

In this case, there would be only one category—Videos—in the Events Overview page for Top Categories, and you could see aggregate metrics for user interaction with the total set of elements for that single video object.

However, it's likely that you will have more than one single object that you want to track using Event Tracking, and it's worth considering how you want to categorize your reporting before you implement the call. For instance, you might want to track all separate movies under the main category of "Videos" so that you get aggregate numbers for all video interaction, regardless of which one users interact with.

On the other hand, you might create separate categories based on the type of video—one for movie videos and one for music videos. You might also want a separate category for video downloads:

• Videos - Movies
• Videos - Music
• Downloads

In this scenario, you can determine the total combined event count for all three categories via the Total Events dashboard. The Total Events metric displays all event counts for all categories that you have supplied in your Event Tracking implementation. However, you will not be able to view combined metrics for all Videos separately from Downloads, because detailed event metrics are combined under their respective categories.

While the Event Tracking object model is entirely flexible, you should first plan your desired reporting structure before calling the _trackEvent() method for similar web object elements. If you plan to use the same category name in multiple locations, be careful to correctly reference the desired category by name. For example, if you plan to call your video tracking category "Video" and later forget and use the plural "Videos," you will have two separate categories for video tracking. Additionally, if you decide to change the category name of an object that has already been tracked under a different name, the historical data for the original category will not be re-processed, so you will have metrics for the same web page element listed under two categories in the reporting interface.

Actions

The term "Action" in the Event Tracking model refers to the second parameter in the _trackEvent() method. It too is required.

_gaq.push(['_trackEvent', 'Videos', 'Play', 'Gone With the Wind']);

Typically, you will use the action parameter to name the type of event or interaction you want to track for a particular web object. For example, with a single "Videos" category, you can track a number of specific events with this parameter, such as:

• Time when the video completes load
• "Play" button clicks
• "Stop" button clicks
• "Pause" button clicks

As with categories, the name you provide for an action is up to you, but keep in mind two important features of how an event action is used in the reports:

• All actions are listed independently from their parent categories.
  This provides you with another useful way to segment the event data for your reports.
• A unique event is determined by a unique action name.
  You can use duplicate action names across categories, but this can affect how unique events are calculated. See the suggestions below and the Implicit Count section for more details.

To achieve the best possible reports for extensive Event Tracking in your site, keep in mind the following suggestions for using actions:

• Action names should be relevant to your report data

  Event Tracking combines metrics for the same action name across two different categories. For example, if you use the action name "Click" for both the "Downloads" category and the "Videos" category, the metrics for the "Click" in the Top Actions report appears with all interactions tagged with that same name. You could then view a detailed break-down of the "Click" action by category in the next report level. However, if you use the action "click" indiscriminately across your Event Tracking implementation, the usefulness of that segment will be diminished in the reports. Consider choosing action names that relate to your data categories if you plan to use Event Tracking extensively on your website. For example, you might choose to reserve the term "click" for gadget interactions, while keeping the action terms, "Play," "Pause," and "Stop" reserved for video player interactions.

• Use action names globally to either aggregate or distinguish user interaction

  For example, you can use "Play" as an action name to the "Videos" category for all videos on your website. In this model, the Top Actions report would provide aggregate data for events for the "Play" action, and you can see how this event for your videos compares to other events for the videos, such as "Pause" or "Stop."

  However, suppose you want to use one video category for your reports, but you want some information about two different video player UIs. You can use the action name to distinguish the different player chromes without having to create separate video categories. The report can then distinguish the two player styles without losing the benefits of aggregate data on all videos for your website.

  _gaq.push(['_trackEvent', 'Videos', 'Play - Mac Chrome');
  _gaq.push(['_trackEvent', 'Videos', 'Play - Windows Chrome');
  

• Action does not always mean "action"

  You can supply any string for the action parameter. In some situations, the actual event or action name is not as meaningful, so you might use the action parameter to track other elements. For example, if you want to track page downloads, you could provide the document file type as the action parameter for the download event. In this scenario, your reports for the "Downloads" category would then be broken out by file types (pdf, doc, xls).

• Unique events are incremented by unique actions

  Any time a user interacts with an object tagged with a particular action name, the initial interaction is logged as one unique event for that action name. Any additional interaction with the same action trigger for that user's session will not contribute to the unique event calculation for that particular action. This is true even if the user leaves that object and begins to interact with another object tagged via the same action name.
  
  This has two notable results in the reports. First, suppose a user interacts with the "Play" action from two unique video players tagged with separate categories. The Top Actions reports for "Play" will list one unique event even though the user engaged with two unique players. Secondly, each category's Action report will list one unique action, since there is indeed one unique event per category/action pair. See Implicit Count for more information.

Labels

The term "Label" in the Event Tracking data model refers to the third string parameter in the _trackEvent() method. This parameter is optional. With labels, you can provide additional information for events that you want to track, such as the movie title in the video examples above, or the name of a file when tracking downloads.

_gaq.push(['_trackEvent', 'Downloads', 'PDF', '/salesForms/orderForm1.pdf']);

As with Categories and Actions, the reporting interface has its own section for all labels you create for your Event Tracking. Think of a label as a way to create an additional reporting dimension for user interaction with page objects. For example, suppose you have five video players on your page that you want to track interaction with. Each one of these players can use the "Videos" category with the "Play" action, but each could also have a separate label (such as the movie name) so that they appear as distinct elements in the report.

_gaq.push(['_trackEvent', 'Videos', 'Play', 'Gone With the Wind']);
_gaq.push(['_trackEvent', 'Videos', 'Play', 'Huckleberry Finn']);

Values

The term "Value" refers to the fourth, and optional, parameter that you can use with the _trackEvent() method. This parameter differs from the others in that it is of type integer rather than string, so use it to assign a numerical value to a tracked page object. For example, you could use it to provide the time in seconds for an player to load, or you might trigger a dollar value when a specific playback marker is reached on a video player.

_gaq.push(['_trackEvent', 'Videos', 'Video Load Time', 'Gone With the Wind', downloadTime]);

The value is interpreted as a number and the report adds the total values based on each event count (see Implicit Count below). The report also determines the average value for the category. In the example above, the _trackEvent() method is called for the "Video Load Time" action when video load completes. The name of the video is provided as a label, and the computed load time is accrued for each video download. You could then determine average load time for all "Video Load Time" actions for the "Videos" category. Suppose you had 5 unique downloads for your website videos with download times in seconds as:

• 10
• 25
• 8
• 5
• 5

The reporting interface would then compute these as follows, with the numbers in this example illustrating download time in seconds:

# Visits w/Events	Value	Average Value
5	53	10.6

Negative integers are not supported at this time.

Non-Interaction Events

The term "Non-interaction" applies to the final, and optional, boolean parameter that you can use with the _trackEvent() method. This parameter allows you to determine how you want bounce rate defined for pages on your site that also include event tracking. For example, suppose you have a home page with a video embedded on it. It's quite natural that you will want to know the bounce rate for your home page, but how do you want to define that? Do you consider visitor interaction with the home page video an important engagement signal? If so, you would want interaction with the video to be included in the bounce rate calculation, so that sessions including only your home page with clicks on the video are not calculated as bounces. On the other hand, you might prefer a more strict calculation of bounce rate for your home page, in which you want to know the percentage of sessions including only your home page regardless of clicks on the video. In this case, you would want to exclude any interaction with the video from bounce rate calculation.

That's where the opt_noninteraction parameter steps in. Remember that a bounce is defined as a session containing only one interaction hit. By default, the event hit sent by _trackEvent() is considered an interaction hit, which means that it is included in bounce rate calculations. However, when this value is set to true, the type of event hit is not considered an interaction hit. You can use this fact to adjust bounce rate calculations for pages that contain events. Setting this value to true means: a session containing a single page tagged with non-interaction events is counted as a bounce—even if the visitor also triggers the event during the session. Conversely, omitting this option means that a single-page session on a page that includes event tracking will not be counted as a bounce if the visitor also triggers the event during the same session.

Implicit Count

In Event Tracking, each interaction with a tracked web page object is counted, and each interaction is associated with a given user session. In the reports, Total Events are calculated as the total number of interactions with a tracked web page object. On the other hand, where a single user session (or visit) has one or more events, this is calculated as a single Visit w/Event, or Unique Event in the reports.

For example, if one user clicks the same button on a video 5 times, the total number of events associated with the video is 5, and the number of unique events is 1.

The following table illustrates how data is aggregated in the reporting interface for a given event category. In this example, the same category name is called from 2 separate video players, each with a distinct label. These players share the actions "Play" and "Stop," as programmed in the Flash UI for the video player.

Event tracking for "Videos" category

Action Type	Label: "Gone With the Wind"	Label: "Mr Smith Goes to Washington"	Totals
Play	10 visits w/Event	5 visits w/Event	15 unique events "Play"
Pause	2 visits w/Event	8 visits w/Event	10 unique events "Pause"
Stop	2 visits w/Event	3 visits w/Event	5 unique events "Stop"
Totals	14 unique events for GWTW	16 unique events for Mr Smith	30 unique events for category "videos"

The table above makes the assumption that user interaction with "Gone With the Wind" and "Mr Smith Goes to Washington" occurs independently in separate user sessions (visits). However, the table below illustrates how events are calculated for a given action in a more complex and typical scenario, where some users press "Play" on only one video, while others interact with more than one video during a visit. Here, the total unique events reflects the total unique events for the "Play" action across labels. Notice that, even though there are 17 unique events per label/action pair, the reports list the unique events for the relevant dimension. So, for all actions, there are only 16 unique events, and for the "Videos" category, a total of 16 visits included an event in which "Videos" was the category.

Event Tracking Calculation for "Play" Action

Action Type	Label: "Gone With the Wind"	Label: "Mr Smith Goes to Washington"	Totals
Play	10 visits w/event		10 unique events "Play"
Play		5 visits w/event	5 unique events "Play"
Play	1 visit w/event on BOTH movies (two clicks on "Play")		1 unique event "Play"
Totals	11 unique play events for GWTW	6 unique play events for Mr Smith	16 unique events for category "Videos" and 16 unique events for action "Play"

Implementation Considerations

Keep in mind the following when implementing Event Tracking for your site.

Bounce Rate Impact

In general, a "bounce" is described as a single-page visit to your site. In Analytics, a bounce is calculated specifically as a session that triggers only a single GIF request, such as when a user comes to a single page on your website and then exits without causing any other request to the Analytics server for that session. However, if you implement Event Tracking for your site, you might notice a change in bounce rate metrics for those pages where Event Tracking is present. This is because Event Tracking, like page tracking is classified as an interaction request.

For example, suppose you have a page with a video player where the bounce rate is historically high, and you have not implemented Event Tracking for the page. If you subsequently set up Event Tracking for the player, you might notice a decrease in the bounce rate for that page, because Analytics will record user interaction with the player and send that interaction to the server as an additional GIF request. Thus, even though the same percentage of visitors to the page might still exit without viewing any other page on your site, their interaction with the video player triggers Event Tracking calls, which disqualifies their visit as a bounce.

In this way, "bounces" for your event-enabled pages means something slightly different: a single-page visit that includes no user interaction on tracked events.

It's important to keep in mind that any implementation of Event Tracking that automatically executes on page load will result in a zero bounce rate for the page. This is the case if you implement the TimeTracker example, or any other similar Event Tracking utility.

Events Per Session Limit

For each visit (user session), a maximum of approximately 500 combined GATC requests (both events and page views) can be tracked. Keep this in mind when programmatically generating events. Note that—as the number of events in a session approaches the limit—additional events might not be tracked. For example, you should:

• avoid scripting a video to send an event for every second played and other highly repetitive event triggers
• avoid excessive mouse movement tracking
• avoid time-lapse mechanisms that generate high event counts

For more background information on sessions, see the Google Analytics Help Center on this topic.