Question

Track specific events or track everything?

  • 12 February 2019
  • 33 replies
  • 2351 views
A
Userlevel 2
Badge
  • amp
  • Frequent Contributor
  • 5 replies

What are the best practices on picking what events to track?


We're split between tracking specific events or tracking everything (but then building custom reports).


The benefit of tracking only specific events is that it:

  • reduces noise
  • lower Mixpanel credit usage


However, the problems with it are:

  • regular have to ask developers to change tracking events
  • no historical data; if we want to track a new event, we start gathering data for it from scratch


Alternatively we can track everything. This increases noise but maybe we can overcome this by creating specific reports based on our quarterly goals. It will cost more (Mixpanel credits) but we won't need to pull-in our developers nor have to worry about missing data.


What are the best practices here?


33 replies

R
Userlevel 2
Badge

This is a great question I'd also like to hear suggested solutions.


E
Badge

Like you said, there are pros and cons to both approaches. We found it most useful by focussing on specific events that we felt gave us insight into how far down the funnel users went. However we have the benefit of having very granular events stored in our applications database, so we didn't have to worry about having no historical data.


That way mixpanel acted as a complimentary product for our product team.


K
Badge

I worked in a company where decisions were made on mixpanel funnels and event.
We tracked only specific events and the events to be tracked with every property was thought out and documented before a developer was asked to do it.
Advantages(other than already mentioned above):
1) Very planned events and easy for a new product manager to be on boarded.
2) Also if you track everything there is bound to be overlap between different events, this increases chance of bugs as there are multiple events that can be used to come at the same conclusion.


S
Badge

I concur, and since we're currently a small team, we prefer tracking all the events and building dashboards for answering specific questions. Agree with you on the credits but saves a lot of developer time.


O
Badge

I would personally not track everything. Instead, the process to decide which events to track can be a process just as intensive as the UX design process overall.

I've sometimes had a situation where I thought "oh, if only I had thought to track X", but I've never had a situation where beginning to track something new did not bring the same value that looking at historical data would have. Historical data also goes stale as your product design evolves and iterates.

I think you need to start with looking at the funnels that matter to you, e.g. visit to signup to conversion. Then that should give you an idea of what events you need to track to fill that funnel with data.

Being selective saves Mixpanel credits, as you say. And you need to bring the developers in anyway when the design of the product changes based on the insights you learn from Mixpanel; therefore folding the analytical component into the overall design process makes it easier to implement changes to how and what you track.

I hope that helps!


P
Userlevel 2
Badge

So we were in the same dilemma a few months back when we were tracking everything and our mixpanel bill was shooting through the roof.

If cost wasn't a constraint, I would ask you to track everything. But if cost is a constraint, I would suggest the following:

1. Track all events which won't be triggered with very high frequency. e.g. a profile edit button on FB
2. Discard events which can be derived from other events. For e.g. instead of having both NextButton and NextScreenDisplay events, you should just have one.
3. Focus on the most important questions you want to answer today. Let's say you are building a social network, onboarding is an extremely important flow, so don't compromise there. But may be you can compromise on events that show how your users are interacting with the Like button.
4. Do check for any duplicate events, if any.
5. Don't track events which can be easily queried from your DB. e.g. tracking likes, comments on FB.


Don't bother about regularly asking developers to change events. It's a very small job. The only worrying thing is not having history, which if you are a very young company, should be fine. If that event was super important, you would anyways be tracking it. I hope it helps.


Z
Badge

Such a great question! on a previous project we decided to use Mixpanel to track almost everything and we enabled funnels to display some key metrics only.

Later on we decided to integrate our own data warehouse platform and fonrtunately Mixpanel offered us a way to export the data which we could easily integrate on our data warehouse.


M
Badge

We usually go with tracking specific events tied to what we are currently working on or looking to work on. Once we are happy with the results or impact of the change we usually stop tracking that event. In the past we used to track EVERYTHING but we didn't do anything with all the data.


C
Badge

This is what I prefer while implementing Mixpanel in a new Project.

  • In First version, I use to track most high level features.
  • Based on user interaction, I keep adding depth of tracking to each major features in each release.

R
Badge

We initially did a mistake of tracking almost everything, what we realized with that was Mixpanel was throwing a lot of data at us which didn't actually make sense. A quarter down the line, we revisited and started tracking parts of problems that were burning issues and slowly built around it.

What it helped us with was,

  1. easy understanding of the analytics for the team members
  2. easy configuration - becuase when you are stating off, Mixpanel and the analytics and dat it provides can be overwhelming and its easy to get lost in so much data.

Question:

  1. Do you use multiple products to track activities - if so, then try the same analytics with MixPanel data first and see if MixPanel data is useful to you. Here you get a chance to compare apples to apples and you know what to expect and then go from there.



A
Userlevel 1
Badge

I've implemented mixpanel in two projects and both have different implementation.


1. Track specific events

SPA project which only tracks specific user actions. Over here the idea being to listen for more qualitative information rather than everything. This also solves the problem of exhaustion of the limit.

One drawback I saw implementing for the web projects with recent Firefox browser being default enabled with the tracking protection which blocks the events triggered from the JS.


2. Track everything

In one of our internal project, I've implemented mixpanel-php library which tracks all events. This also solves the problem of JS based blocking from browsers or other plugins.


I hope it helps someone.


T
Badge

It's more important to be thinking through if you're being descriptive enough with your event names/categorization that a PM can easily navigate your analytics dashboard. If you can be descriptive/purposeful and track everything, go for it.


Generally I'll focus on explicit actions to make sure I have proper context when I go to my various dashboards.


E
Badge

When a new feature is being developed, my team will try to approach it by understanding what the feature is trying to solve, and how we can measurably show that it has solved that problem.

Once that question has been answered, we can then craft our events to make sure we're getting back the correct information to generate a report to actually show the results.

Before doing this, we've had instances where events were tracked, but they didn't gather enough information to actually answer important questions that became more specific the more we looked at the data.


A
Badge

Our team uses React, and we put mixpanel callbacks in each loading and update method for each component. We also have hooks into our graph libraries whenever the user hovers over our analytics graphs and for how long.


D
Badge

I think for an initial implementation you would like to avoid noise that prevents you from getting the grasp of the metrics you want to track. What I like to do is think of the key funnels for my apps and start tracking those. After that you can continue to add events as they make sense for your implementation and metrics.


D
Badge

One good approach that has worked for us is to rely on page views as a catch-all tracking, but then specify events that you want to track. We also started tracking everything but were quickly overwhelmed with irrelevant events and wouldn't recommend scoping out what you want to track and adding them with each feature as others have suggested.


Segment released a good format for deciding what events should be tracked and keeping track of them, to add them to developer backlog when you want to add/remove events.

https://segment.com/docs/guides/sources/can-i-see-an-example-of-a-tracking-plan/

https://docs.google.com/spreadsheets/d/1CCx7VU1ioHdWsRmMjywOKhoioh_ObR_V6Cp2RZmbA1Y/edit?__hstc=222691652.f2c5ed50a3a9703ac3be5283918044ad.1436399176206.1437082421955.1437085712408.17&__hssc=222691652.23.1437085712408&__hsfp=2203243415#gid=639423297


C
Userlevel 3
Badge

Usually we track specific events to avoid too much rumors. Too much data usually are not used so it's not useful collect all you can collect. We prefer stay focused on our target.


Z
Userlevel 1
Badge

Include it in the 'definition of done' per user story (if working with scrum / agile).

I am positive about tracking only specific events, that makes also your panel in Mixpanel much much clear overview.


M
Userlevel 2
Badge

This! It's definitely great to have the full history of all the possible events to track, but it can get so messy without good naming/labeling conventions.


R
Badge

Accurate, actionable and preferably granular data is usually the best resource when using tools like MixPanel.. I would highly recommend you assess what data you need OUT of your users interactions and flows and design you events from that specific data.


We have, in the past, developed insight plans that incorporate both macro and event level tracking.. which helps to provide both a high level overview that's quickly accessible from the dashboard and the additional data points that we can dive into to assess specific use cases, test theories, etc.


best of luck.


T
Badge

Hi @amp,

I touched on this in a recent blog post:

Some events will be more useful than others. Whilst there’s not a lot of harm in tracking more events than you need to, it’s going to be a time-sink and snarl up your attempts at analysis. Once you’ve got your long-list of possible things to track, go through it with a red pen.

When I’m evaluating what events to track, I’ve found it helpful to consider if it falls into any of the following four categories:

  1. “Pulse” events: These are good indicators of user activity. E.g. “we count Weekly Active Users by looking at the number of unique …” This is a useful metric in its own right but also serves as a denominator for other metrics. Think about whether you want this to apply to all users, or maybe some subset (such as registered users) and design your event appropriately.
  2. KPI events: Are you aiming for a certain number of actions? Perhaps you need 100 purchases a week? Or perhaps you need 50 completed registrations a day. I find it’s best to track these things directly, or you’ll end up relying on poor proxies, which will inevitably cause confusion.
  3. “Grit” events: When something goes wrong, it’s not always an error or a bug. Sometimes your UI will inadvertently encourage “incorrect” behaviours. Tracking instances where you display an error message to users, for example, can help to spot trends and allow you to eliminate sources of friction.
  4. Trigger events: One of the tools we use allows one to trigger targetted messages in response to events. Think about whether the messages you might want to trigger would be in response to events you’re already tracking.

To be honest, the fact that you're even thinking about it is probably puts you in good stead. Whatever you end up deciding, you'll probably make a few mistakes along the way, but you'll be OK overall.

Good luck!

Tom


J
Badge

For us( we're a small startup), we chose to track everything. Every page change & every button/mouse press. Yes, this does bring in a lot of noise and overlap data. But we felt was, you can remove redundant data, but you can't "generate" data. Thus, it made more sense for us to track and hide/delete later if data is bad. We haven't reach the cost constraint yet, but we are still optimising our analytics!


R
Badge

When you have an opportunity to track everything. Please go ahead. When I say everything, it includes anything that your business may need. Any data is a good metric to be captured. But just to reduce the burden on developers to keep working on the tracking events etc. Plan the project well enough. Make a list of all the possible things you would want to start with. Things will fall into place and you will have all you need. Thanks!


T
Badge

Personal opinion is only track stuff where you can forsee a strategic need to use that data. Maybe it aligns with your companies 6 month strategy or will help analyse a specific feature, AB test, etc.

If you treat your users as you would like to be treated - i believe we shouldnt be taking mountains of data that we just don't have a need for (yet), and actually i guess this would breaks GDPR as well!

Given that most products pivot in terms of strategy or direction quite regularly, your always going to want to access data that you simply dont have.


A
Userlevel 6
Badge

Track everything, and dump data to a data warehouse on a regular basis. You never know when you are going to need something. If it is too much data, you can filter it out at the analytics stage.


Reply


Mixpanel