[UA] About Events (Universal Analytics) [Legacy]

In Universal Analytics, Events are user interactions with content other than page loads (pageviews). Downloads, link clicks, form submissions, and video plays are all examples of actions you might want to analyze as Events.

In this article:

See Event data in reports

To see Events reports:

1. Sign in to Google Analytics.
2. Navigate to your view.
3. Open Reports.
4. Select Behavior > Events.

Anatomy of Events

An Event has the following components. An Event hit includes a value for each component, and these values are displayed in your reports.

• Category
• Action
• Label (optional, but recommended)
• Value (optional)

For example, you might set up a video "play" button on your site so that it sends an Event hit with the following values:

• Category: "Videos"
• Action: "Play"
• Label: "Baby's First Birthday"

Category

A category is a name that you supply as a way to group objects that you want to analyze. Typically, you will use the same category name multiple times over related UI elements that you want to group under a given category.

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

• Category: "Videos"
• Action: "Downloaded"
• Label: "Gone With the Wind"

In this case, there would be only one category—Videos—in your reports, 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 measure, and it's worth considering how you want to categorize your reporting before you implement the call. For instance, you might want to analyze 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 could see the total combined event count for all three categories in your reports. The Total Events metric displays all event counts for all categories that you have supplied in your 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 object model is entirely flexible, you should first plan your desired reporting structure before deciding upon your category names. 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 category "Video" and later forget and use the plural "Videos," you will wind up with two separate categories. Additionally, if you decide to change the category name of an object that has already been recorded 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.

Action

Typically, you will use the action parameter to name the type of event or interaction you want to measure for a particular web object. For example, with a single "Videos" category, you can analyze 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.

Label

With labels, you can provide additional information for events that you want to analyze, such as movie titles in videos, or the names of downloaded files.

• Category: "Downloads"
• Action: "PDF"
• Label: "/salesForms/orderForm1.pdf"

As with categories and actions, there is a report that shows all the labels you create. 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 embedded videos on your page that you want to analyze. 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.

• Category: "Videos", Action: "Play", Label: "Gone With the Wind"
• Category: "Videos", Action: "Play", Label: "Huckleberry Finn"

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

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

Action and Label best practices

To achieve the best possible reporting, keep in mind the following suggestions for using actions:

• Action names should be relevant to your report data. Event measurement 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 measurement 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 measurement 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 interfaces. You can use the action name to distinguish the different player interfaces without having to create separate video categories. The report can then distinguish between the two players without losing the benefits of aggregate data on all videos for your website.
  
  Category: "Videos"; Action: "Play - Mac Chrome"
  Category: "Videos"; Action: "Play - Windows Chrome"
• Action does not always mean "action". You can supply any string for the action. In some situations, the actual event or action name is not as meaningful, so you might use the action parameter to analyze other elements. For example, if you want to analyze 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.

 

Value

The value component is an integer, and is used to assign a numerical value to a page object. For example, you could use it to provide the time in seconds for a player to load, or you might trigger a monetary value when a specific playback marker is reached on a video player.

Category: "Videos", Action: "Video Load Time", Label: "Gone With the Wind", Value: 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 Event 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

Your reports would then compute these as follows, with the numbers in this example illustrating download time in seconds:

• Sessions with Events: 5
• Value: 53
• Average Value: 10.6

Negative integers are not supported.

Non-Interaction Events

The term "Non-interaction" applies to an optional boolean parameter that can be passed to the method that sends the Event hit. This parameter allows you to determine how you want bounce rate defined for pages on your site that also include event measurement. 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 optional non-interaction parameter steps in. Remember that a bounce is defined as a session containing only one interaction hit. By default, the event hit 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 measurement will not be counted as a bounce if the visitor also triggers the event during the same session.

Implicit Count

In Event measurement, each interaction with a targeted 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 targeted 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.

Event analysis for "Videos" category

Action	Label:"Gone With the Wind"	Label:"Mr Smith Goes to Washington"	Totals
Play	22 clicks across 10 sessions w/Event	7 clicks across 5 sessions w/Event	29 total events and 15 unique events "Play"
Pause	3 clicks across 2 sessions w/Event	16 clicks across 8 sessions w/Event	19 total events and  10 unique events "Pause"
Stop	2 clicks across 2 sessions w/Event	4 clicks across 3 sessions w/Event	6 total events and  5 unique events "Stop"
Totals	27 total events and 14 unique events for GWTW	27 total events and 16 unique events for Mr Smith	54 total events and 30 unique events for category "videos"

Implementation considerations

Keep in mind the following when implementing Event measurement.

Bounce Rate Impact

In general, a "bounce" is described as a single-page session 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 measurement for your site, you might notice a change in bounce rate metrics for those pages where Event measurement is present. This is because Event measurement, like page measurement 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 measurement for the page. If you subsequently set up Event measurement 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 measurement calls, which disqualifies their session as a bounce.

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

Events Per Session Limit

ga.js

The first 10 event hits sent to Analytics are processed immediately, thereafter processing is rate-limited to one event hit per second. A maximum of 500 hits per session are processed.

analytics.js and gtag.js

The first 20 event hits sent to Analytics are processed immediately, thereafter processing is rate-limited to two event hits per second. A maximum of 500 hits per session are processed. This limit applies to all hits except ecommerce item or transaction hits.

To keep your hit count below session limits:

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

Event-implementation best practices

The design model for Event measurement 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 measurement reports require collaboration with your report users and good report planning.

• Determine in advance all elements for which you want to analyze data. Even if you initially monitor only a single object on your website, having an overall sense of the various objects/events you want to analyze will help you establish a report structure that scales well with an increase in the number and types of events you analyze.
• Work with your report user to plan your Event measurement reports. Knowing in advance how the reports should look will direct the structure of your Event measurement 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 measurement 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 measurement, 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.

Events vs. event goals

An event is a user interaction with your site or app that you specify and collect data about by modifying your tag code as described in the body of this article.

An event goal is a goal you define that identifies a specific event as a conversion.