Event Tracking Overview (Beta)

The following documentation is for our upcoming Event Tracking feature. Event Tracking reporting is currently available only to beta test participants. Feel free to read through this beta documentation for a sneak peek at how Event Tracking will work. Keep an eye on our Google Analytics Blog for further updates on Event Tracking availability, and other new features.

A feature extension to the ga.js tracking code, Event Tracking records events on your website separately from pageviews. For example, if you use ga.js to track Flash UI interaction, your users' engagement with the Flash UI is calculated and displayed as an event, and pageview calculations are unaffected. You configure event tracking using standard JavaScript method calls and a hierarchical structure of objects and actions, which you can easily extend across your site. By contrast, Event Tracking using the urchin.js tracking code relies on flat namespaces and virtual URL creation. With this legacy code, Event Tracking is calculated and displayed as part of total page views to your site, and no distinction is made between actual and virtual pageviews.

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

This document assumes familiarity with Google Analytics Tracking Code (GATC) configuration. Additionally, you must have the ga.js tracking code installed on those pages where you configure event tracking as described here.

Design Philosophy

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 object 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 interface, but might also be interested in latency tracking for the load time of the video.

• Adopt a consistent and clear naming convention.

  In the process of implementing event tracking, every name you supply for objects, actions, and labels appears in the reporting interface. In addition, object/action pairs are treated uniquely, so duplication of names can be confusing in the reports.

The rest of this guide describes the data model in detail and how to implement event tracking for your website.