Tracking Event Data for Newbies

Avoid these 6 common mistakes to ensure you can run clean, usable analytics

I was recently chatting with a friend about event tracking for a mobile app he’s building. The more we spoke, I realized that many of the concepts that are important to ensuring you have clean, usable event data may not be second nature. Especially for people new to event analytics.

I’ve implemented event tracking many times in the last few years. And since joining Keen IO, I’ve had even more opportunity to see what works, and what doesn’t, for event analytics. So I decided to write up this list of common mistakes to avoid when getting started tracking event data — many of which I’ve made myself in the past:

1. Tracking events without knowing what questions you want answered

This is the single biggest mistake I see made. Teams rush into tracking events without having figured out what they’re trying to achieve. They end up littering tracking code throughout their codebase.

You need at least a rough idea of what answers you’d like to get out of your event analytics. Otherwise, implementing event tracking is a waste of your time. You will pay a hefty price for not thinking things through beforehand, in the form of unusable data and technical debt.

Take the time to figure out what questions you want your event data to answer and you’ll start off on the right foot.

2. Trying to track every single event

Many times I’ve seen teams take the approach of tracking every possible event. They hope that they’ll “cover their bases” and ensure they have all the data they need for future analysis. This is usually a symptom of mistake #1.

“Tracking everything” is not only impossible, but it in no way guarantees that you’ll have what you need to get answers. Additionally, it’s a lot of work! Wouldn’t you want to avoid doing unnecessary work?

You may still need to track a large amount events. But without knowing the end result you’re after, you’ll end up with a tons of unneeded tracking code and unusable event data.

3. Putting technical details in event names

I often see people put technical implementation details into their event names. The most common one I see is adding the tracking location. It’s usually best to leave technical details out. Take the following event name for example:

trackEvent(“UsersController:Opened Some Item”, {
 …event properties…
});

What value do you get from the “UsersController:” part of that event name? Is it helping answer questions about what’s happening in your application? If not, it’s just making things more difficult to read when you run your analytics.

Remember; the underlying technical implementation may change. Maybe Opened Some Item is tracked from the UsersController now, but it may not be in the future. When the location changes, so will the event name. Now you’ll have two different event names to reconcile when running your analytics.

If you need the controller name, add a key called controller_name to your event’s properties. This will make sure your event name stays the same even if the place you’re tracking it changes. And you’ll still have access to that data when you run your analytics.

Here’s a better way to do it:

trackEvent(“Opened Some Item”, {
 controller: “UsersController”,
 …more properties…
});

4. Not defining any conventions for event and property naming and structure

Consistency is just as valuable with code style as it is with event data. Too often teams start tracking events without having agreed on how to name them and structure the properties.

Without agreed upon conventions, you’ll have one developer track events like this:

trackEvent("User Signed Up", {
    "user": {
        "id": 123,
        "email": "joe@gmail.com",
        "user_type": "enterprise"
    }
});

and another developer track a different event like this:

trackEvent("user_clicked_toggle", {
    "user_id": 123,
    "email": "joe@gmail.com",
    "user_type": "enterprise"
});

This is probably obvious enough to you to demonstrate the reason why you need conventions. Without conventions your team mates will not track events with the same structure and you’ll end up with difficult to use data.

What do I mean by difficult to use data?

• A property in a given event may not even exist in another event. Meaning you can’t even run your desired query at all.
• A property in a given event may be named completely differently in another event. Meaning you’ll have to double check with your team mate and/or source code to ensure the events are indeed the same.
• A property in a given event may be in a completely different location in another event. This means you’ll need exceptions in your source code for every event that’s different.
• A given event may not have the same name as another event that actually represents the same action. Meaning you’ll technically have two separate collections of events, making every query you run more difficult.
• Different event and property names means the labels on your charts won’t be the same, even though they represent the same data.

If your properties look different for every event, running queries gets much more difficult. You need to know that for one event, a property might be named a certain way and live at the root level of the properties object, but for another event, the property may be nested several levels deep and be named something completely differently.

You may also send data with an event that one of your team members does not. This means you’re now missing data completely and will be incapable of running certain queries at all.

5. Separating the same event into several different events

I’ve seen many people track events with naming patterns like this:

“Viewed Signup Page”
“Viewed Product Overview Page”
“Viewed Account Profile Page”

Do you notice a similarity here? They’re all just types of the “Viewed Page” event.

It’s likely that all the above events will have the same set of properties. Instead, track just the “Viewed Page” event and add a “type” or “name” property containing which page they viewed.

This will make reasoning about your event analytics much easier. You‘ll have fewer event types to work with less work to get the answers you’re after.

Most analytics software has an easier time working with fewer event types. Only separate events into different types when they are truly different events.

6. Only tracking events for the short term

It’s common for people new to event analytics to track only things they need right now. With event data, it’s always best to to think a few steps into the future.

You might only need events x, y and z to get answers to the questions you have today, but what about a few months from now? What questions will you have then and what data will you need to answer them?

If you don’t start tracking those events now, you won’t have the data to answer the questions you’re going to have down the road. Ask yourself, “What will we want to know 3 months from now? What data will we need to answer those questions?”

This is a difficult task, as anyone who’s tried to predict the future knows. But you should at least make an effort to get ahead of the curve and be ready for the important questions you’ll have soon.

That’s it! If there’s anything I missed or if you’d just like to discuss more, hit me up on twitter @theericanderson or start a discussion on this article. You can also find out more about Keen IO.