Tips To Decide Which Events To Track

This guide is part 4 of a 5-part series titled Understanding First-party Data.

{{line}}

To decide which events to track, you need to first list down all the questions you’d like to answer about your users and their product usage.

You will realize that there’s so much you want to know once you begin listing your questions down. Questions beget more questions, and when that happens, you will probably want to get all the answers at once.

Due to how this process makes most people feel, let’s refer to these questions as burning questions.

If you don’t feel that way, you are probably not keen to know much or have a strong conviction in your assumptions. However, don’t let that hold you back from asking questions — you might be pleasantly surprised or utterly disappointed when you find out the answers.

It is much easier to ask questions of data once you’re able to visualize the data — but this can also be counter-productive if you keep building reports or visualizing data without first asking any burning questions.

Burning questions

Burning questions can be straightforward like “how many users signed up in the last 7 days?” or complex like “how many users from the SaaS industry signed up in the last 7 days and invited another user to their organization?”

When thinking about burning questions, it helps to start listing down the following actions:

• Actions a user must perform in order to reach the aha moment (activation event)
• Actions that indicate that a user is ready to make a purchase or upgrade an account
• Actions that fuel user engagement and keep a user retained
• Actions that signal that a user is not deriving enough value from the product
• Actions that potentially lead to a user getting churned

It’s also a good time to start questioning the product experience and mull over your core offerings. The following questions are applicable to a majority of tech products:

• What is the time to value or how long do users take to reach the aha moment?
• What are the various paths that users take after signing up?
• What are the points of friction in the user journey?
• What are the features most used by active users?
• What are the least-used features by paying users?
• What features lead to the conversion of free users to paying users?

Events and event properties

Once you have a list of the burning questions (between 5 and 10 is a good number to start), you can move on to the most critical step—defining events and event properties.  

This is where you finally start creating a data tracking plan.

Besides the core events, you should also start thinking about the various pieces of data that you would like to gather when a particular event takes place. This guide contains examples of some common events and associated properties that will provide some context into how to think about this process.

There are a few more things covered below that you must know before you start creating a tracking plan.

Clicks, views, and processes

It’s very important to be mindful of the differences between clicks, views, and processes that take place inside your product — every button that is clicked, page that is viewed, or process that is completed can be tracked as a unique event.

Also, in some cases, an event can be tracked as any one of the three — a page view, a button click, or a process completion.  

Let’s take a closer look using a hypothetical sign up flow:

First, the user clicks the sign up button on the homepage to visit the sign up page.

Here, the event performed can either be tracked as a button click (sign up button on the home) or a page view (sign up page).

Next, the user fills up the registration form, clicks the submit button, and lands on the thank you page. If everything goes well, the submission reaches the database and a new row is created.

Here, the event performed can be tracked as a button click (submit button), a page view (thank you page), or a process completion (new row in the database).

Therefore, how you choose to track events completely depends on your use cases, and sometimes, it might even make sense to track a button click as well as a page view or process completion at the same time.

That said, if your objective is to understand user behavior, you should avoid event redundancy by making sure that a user action is not tracked multiple times (sign up button clicked and sign up page viewed).

{{button}}

Page viewed

To track page views, you may specify a unique event for each page such as Sign Up Viewed. However, that will make your event list ridiculously long when you want to track page views for every unique page.

Instead of defining a separate event for each page, you can specify a generic event called Page Viewed with event properties as follows:

Button clicked

Like page views, button clicks should also be tracked via a generic event such as Button Clicked with associated properties as below:

Process completed

Processes take place as a result of an interaction with a database where data is either written (in a specific table) or retrieved (from a table)—if the interaction fails, the process fails.

Hence, tracking the completion of a process is the most reliable way to track events that rely on the completion of an interaction with the database.

Here’s a scenario that is far too common:

A user clicks the submit button after filling up the sign up form only to be presented with a validation error such as “the password must contain a special character.” Here, the user performed the event Button Clicked but actually did not complete the sign up process.

Similarly, if the user clicks the submit button but a server-side error occurs, then the process fails and the user data does not make it to the database. So even though the user submitted the sign up form successfully, the sign up process was left incomplete.

Therefore, it’s crucial to think about the entire process (or the database interaction) that should be completed when an event takes place.

Additionally, you must also know if a user signs up for your product but doesn’t verify their email address—one way to do this is to check if users log in after signing up (which can only happen after the email is verified). But then there could be users who do verify the email but never log in.

Thus, a better approach could be tracking 2 separate events—Signed Up (sign up process completed) and Email Verified (email is verified).

This will also tell you how many people sign up but don’t verify their email, enabling you to resend the verification email after a day or two.

Client-side vs. server-side events

Events such as clicks and views that don’t rely on database interactions (or backend processes) are essentially client-side events.

Client-side events take place exclusively on the client (or the user’s device) and are also referred to as frontend events.

On the other hand, events that rely on backend processes are referred to as server-side events. As the name suggests, server-side events take place on a server when a database interaction is successfully completed.

Server-side events are also referred to as backend events.

Knowing the difference between client-side and server-side events helps in the instrumentation process as the two types of events are usually implemented by different people in an organization.

It’s always helpful to specify the event source in your tracking plan even if a full-stack developer is tasked with the implementation of both types of events.

Event tracking next steps

This brings us to the end of the five-part series.

And if you’re ready to apply everything you know to create a data tracking plan and learn about the benefits and best practices of doing so, this guide covers it all.

{{line}}

This is the latest version of this guide. The original version was published on Data-led Academy in 2020 and was updated and moved to the Amplitude blog in 2022. Please be aware that you might find plagiarized versions of this guide when searching for related keywords.