What four parameters can you include with an event hit for reporting?
Category, Action, Label, Value
Event, Category, Action, Label
Category, Action, Label, Unique Events
Category, Action, Label, Total Events
Events are user interactions with content that can be tracked independently from a web page or a screen load.An Event has the following components. An Event hit includes a value for each component, and these values are displayed in your reports.
- Label (optional, but recommended)
- Value (optional)
Read more here: https://support.google.com/analytics/answer/1033068
Use Events to collect data about interactions with your content.
Events are user interactions with content that can be tracked independently from a web page or a screen load. Downloads, mobile ad clicks, gadgets, Flash elements, AJAX embedded elements, and video plays are all examples of actions you might want to track as Events.
In this article:
See Event data
Anatomy of Events
Event-implementation best practices
See Event data
You need to add Event tracking code to your site or app in order to see data in your Events reports. Read Set up Event Tracking. To see Events reports:
Sign in to Google Analytics.
Navigate to your view.
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.
Label (optional, but recommended)
For example, you might set up a video “play” button on your site so that it sends an Event hit with the following values:
Label: “Baby’s First Birthday”
A category is a name that you supply as a way to group objects that you want to track. 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 track how many times the video is downloaded. You could use:
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 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 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 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 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 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.
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.
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.
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 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.
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 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 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 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.
Value differs from the other components in that it is an 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.
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:
Your reports would then compute these as follows, with the numbers in this example illustrating download time in seconds:
Sessions with Events: 5
Average Value: 10.6
Negative integers are not supported.
The term “Non-interaction” applies to the final, and 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 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 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 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.
Event tracking for “Videos” category
Action Label:”Gone With the Wind” Label:”Mr Smith Goes to Washington” Totals
Keep in mind the following when implementing Event Tracking.
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 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 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 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
The first 10 event hits sent to 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
Event-implementation best practices
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 types of events you track.
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.