Common event tracking pitfalls and how to avoid them

Editor’s note: this article was originally published on the Iteratively blog on February 19, 2021.

Data collection is the foundation of your data stack, but it’s often overlooked—unloved even—and so many companies don’t spend the time and resources needed to get it right.

Analytics tracking pitfalls can easily happen when event tracking is not getting the love and care it deserves. Luckily, knowing what these pitfalls are, you can more easily avoid them. Plus, you can improve your data collection strategy and process with some of the concrete tips shared below.

What is event tracking?

Before we dive in, let’s quickly get on the same page about what we’re covering here: Event tracking is the process of capturing and collecting data about your users’ interactions with a digital product, such as a website, web or mobile app.

Any user-initiated action can be encoded as an event, such as page views, button clicks, form submissions and search. What events you should capture depends heavily on your product, business model and data maturity. Every product will have its own set of user behaviors and the teams working on improving or selling the product will have their own analytics metrics and goals. If you’re just getting started with event tracking, check out our guide to creating a tracking plan.

The core building blocks of data

To get the insights you need about your product performance, user behavior or customer acquisition strategy, there are four fundamental data building blocks you need to consider:

Events‍

Any user or server-initiated action is an event. This includes everything from page views and button clicks to account deletion and application crashing.

Event properties

Event properties further describe the particular event and the context it was invoked in. You leverage properties to capture additional information around the event such as browser information or what information was submitted in a form field.

Users

Users are the individuals who perform the events. They’re your unknown web visitors, app users or logged-in customers.

User properties

User properties make it easy to record traits on a user. This could include data like their subscription plan, geographic location, user ID, and browser or device type.

Common event tracking challenges and tips to avoid them

Now that we’ve covered the basics, let’s look at the common pitfalls we experience when talking to many data and product teams out there.

Too many event types

While you may have a large amount of events collected (could be billions a day depending on your company size and business model) we recommend you limit your total number of event types. Sprawling event dictionaries will leave you to look for a needle in a haystack and data consumers, such as analysts and PMs, will have difficulty figuring out what events they need to perform their analysis.

Tip: We recommend that your tracking plan should contain anywhere between 10 to 200 event types. Obviously complex multi-products might have a need for more, but we often see that companies can greatly slim down their data model by tidying up their event types.

Overcomplicating the data model

Related to the point above, we often see companies get too specific with their data model, which makes it hard to keep it consistent and scalable (and therefore results in too many event types). As an example, we’ve seen companies using a unique event for each of their landing pages, instead of a catch-all event, “Page View,” that contains property values for context (e.g. UTM parameters and URLs).

Tip: Proactively ensure you’re creating a structure that’s scalable as you grow and focus on the data you need today.

Missing properties

We see teams spending a lot of time on defining their events, but thinking less about what properties should be associated with them. Arguably event and user data only become really useful when you have the context around them as well—without them your analysis will be limited.

Tip: Make sure to treat properties with the importance they deserve. To help your teams make best use of properties you can create property templates for people to leverage: “If I’m firing this event, what properties could I send along with the event?” You can even specify which properties are required and which are optional. This is easy to do in Amplitude but you can also create these in a Google Sheet or Notion page.

Events firing incorrectly

We often see downstream data quality issues that are related to events not firing correctly, e.g. firing too often, not firing at all or at the wrong time. This is largely because event tracking is left untested and not treated like the code it is.

Tip: Best practice is to treat your tracking like any other code and test it. Extend your QA to include event tracking as a part of your existing CI/CD and unit testing workflows.

ButtonClicked, button_clicked or Clicked Button?

Event naming conventions can turn into the wild west even at the best companies. You might have your iOS and Android teams following one convention, while your web and product teams are following another. Couple that with human error during instrumentation and your data consumers are left with tons of data munging before the data can be used for analysis.

Tip: Use a framework like Object Action as a best practice for governing the structure of your events (i.e. each event is associated with an Object in your application (e.g. Button) and an Action (e.g. Clicked). And use a system like Amplitude to enforce your naming convention across teams and during instrumentation.

Timestamp complications

This one is super simple, but time zones matter. Consider the complexity when you want to book a meeting with people across multiple time zones. You don’t want that complexity in your data.

Tip: Don’t overthink this one, stick to UTC.

Incorrect data types on properties

This is not something we see often, but it does happen to teams and it’s usually always when numbers are involved. For example, a user ID comprising six digits is not actually a numerical value but rather a string value.

Tip: Pay attention to what the property is describing and how it will determine the correct field type. Keep documentation handy with examples of all property types so it’s easy for your teams to evolve the tracking plan accurately.

Amplitude is here to help you

Overwhelmed by all the hazards and difficulties that come with designing, instrumenting and evolving your event tracking? Amplitude has your back.

Amplitude’s data management capabilities help data teams, product managers, and engineers define, instrument, verify, and collaborate on event tracking. We proactively solve the data quality issues that arise from inconsistent event naming and missing tracking and provide a workflow for managing the evolution of your tracking.

We help you ditch the spreadsheet, schematize your event data, and enforce your tracking plan so you have high quality data to work with, no data munging required. If you’re interested in trying out Amplitude’s data management capabilities, create a free account today, or book a demo with our team to learn more.