Track specific events or track everything?

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

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.

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!

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.

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.

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.

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.

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.

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.

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.

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

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!

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.