This document assumes familiarity with Google Analytics Tracking Code
configuration. Additionally, you must have
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
Event Tracking is a method available in the
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
ga.js, you would commonly apply Event Tracking
- 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
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
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.
Before you can view event tracking results in your reports, you must set it up on your site following these steps.
- 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.
- Call the
_trackEvent()method in the source code of a page object, widget, or video.
The specification for the
_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.
- category (required)
- 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:
- 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.
<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.
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
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.
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.
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']);
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
_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
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|
Negative integers are not supported at this time.
The term "Non-interaction" applies to the final, and
optional, boolean parameter that you can use with
_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
is considered an interaction hit, which means that it is
included in bounce rate calculations. However, when this value is set
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.
In Event Tracking, each interaction with a tracked web page object is counted and 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.
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.
|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"|
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.
Events Per Session Limit
In addition to general
collection limits and quotas, the
following limit applies to event tracking in
- The first 10 event hits sent to Google Analytics are tracked immediately, thereafter tracking is rate limited to one event hit per second.
As the number of events in a session approaches the collection limit, additional events might not be tracked. For this reason, 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