The role of events in product analytics
In the second article of our behavioral analytics for products series, we’ll talk about the role of events in product analytics. Events give your data structure and consistency and allow comparisons across the various possible interactions that might happen within a product.
What’s an event from a product analytics perspective?
From a functional level, everything that can be described in product analytics begins with an event. This is to say that events are the inherent unit of data capture. Without events, we are unable to understand anything about users, sessions or any description of what has occurred.
How to write events
Events are bits of supplementary code, known as a snippets, that are inserted into the larger code base of an application. For example, if an application’s code displays a button that submits a form under certain conditions, the code for the event can be attached to this item, triggering information to be sent to an analytics tool, referencing something that happened, in this case, that a form was submitted.
Concretely, what does the event above look like? In terms of code, it would look something like this.
You’ll notice that within this code, there is an explicit reference to the submission of a form. In the snippet, this appears as submitted_form. The best practices for naming events have not yet been widely established or normed, but here are a few tips:
1-) When naming an event use a verb followed by an underscore, then a noun to explicitly name the action that has taken place;
2-) Give names to events in the past tense. Because events are logged after an action is taken, it’s important to reference an interaction in the past;
3-) Avoid using verbs and nouns that are too general. If you use an event called clicked_button, you’ll quickly find that almost all of your events have the same name.
4-) Be careful about being too specific as well. Using a name such as submitted_request can help you identify an event that specifically relates to submitting a request form, but you may well want to identify and view events for all form submissions on your website or application. In this case, you will likely find yourself struggling to translate each type of form into an adequate event name;
5-) Define interactions by common groupings. You might have several forms that can be submitted. An event such as submitted_form can be reused across all forms, offering specificity about what was submitted without restriction. But then how do you distinguish between forms?
Every event has the ability of being elaborated further by event properties. Event properties add specificity to an event and give it additional context. Whereas an event defines something that happened, a property defines the characteristics and descriptions of what happened.
We now know that Homer is trying to build his own nuclear plant, but in order to have access to the content of the website, he has to submit a form with his personal details. When we use event properties in code snippets, the event above would look like this.
You can see that the same event, submitted_form appears in the snippet above. However, this time, there are several additional lines, each citing a unique variable. Each variable in the snippet above represents a field in the form. If we wanted to, we could even add an additional variable such as form_type, in case we wanted to specify the type of form being submitted when this event is logged.
Event properties are particularly important because they are also used for defining the other main components of product data, notably, users and sessions. Most product analytics tools will do this in some standardized, automated way, but it is nevertheless important to understand how this works.
Imagine that we have a page on our site for a user to create an account. This generally resembles a form, so we could name the associated event submitted_form, or because of the event’s importance, we could use a more unique event name, created_account. Within this event, we could gather information such as a unique user ID, a username, a password, an email address and other identifying information as event properties. These data are then used to define a user and the user’s properties, but are necessarily captured through an event.
Similarly, when an event is logged, so too is a timestamp. A timestamp is the event property that establishes when the event occurred. Most analytics products will automatically use timestamps and collect this data using a standardized time format called Coordinated Universal Time (UTC). This format can be converted to more familiar formats such as Augustan time. All events need timestamps so that we can place them on a timescale and compare them to each other in an order or sequence.
Remember the example we used in our last article?
In the match England vs. Argentina in the 1986 World Cup Quarter Final (the session), Maradona (the user), scored a goal (the event) using his hand. The match was played in Mexico City, on the 22nd of June 1986 and started at 12:00 CST. Maradona scored the goal at 6 minutes of the second half, so approximately 1:15 PM CST. If we converted it to UTC we would have 7:15 PM.
Here’s how we would describe the whole event.
In the next article, we’ll talk about the second component of behavioral analytics for products, the user. To get notified when our next article is out, please sign up for our newsletter.
Originally published at www.metriq.io on November 24, 2017.