Why auto-tracking does not deserve its bad reputation

Dear Data-Traveller, please note that this is a Linkedin-Remix.

I posted this content already on Linkedin in May 2022, but I want to make sure it doesn´t get lost in the social network abyss.

For your accessibility-experience and also for our own content backup, we repost the original text here.

Have a look, leave a like if you like it, and join the conversation in the comments if this sparks a thought!

Screenshot with Comments:

Plain Text:

Last week I finished something new.

My first tracking design sprint – and we had a great topic – explicit auto-tracking.

When I approach a topic where I haven’t done plenty of tests and implementation, I like to use a sprint to test out different ways to solve the issue.

In this case, a big fintech startup told me about their major data problem: they are moving too quickly with product & growth teams that implementing tracking slows them down significantly. And even worse, when they add tracking, they often find missing data once they start analyzing because new questions came up.

This sounded very familiar to me. Honestly, this might say familiar to most of you.

Auto-tracking has a terrible reputation. And I was part of this too. Too easy, I told teams not to use it because it creates unchecked and unreliable data. It does that, but it’s wrong not to use it.

With all tools and approaches, you need to find the right angle to use them.

With the sprint finished, I would say – we found something interesting that might change how I approach product feature tracking.

Today many applications are single-page applications using React, Vue, Angular, or some variations.

One interesting thing here is the component structure. You nest components until you get a product feature, and these components hold some state. The top parts are usually a pretty big state (imagine the state as a big JSON object).

And components get reused. So a button component can be used in 100 places within the app.

So we placed an explicit auto tracking at these components (eg. the button component). It then pulls the state from the main component and dumps everything into a central operator function.

This operator function has a whitelist mapping where we define what values we want to pass on with a form submit. These values are picked from the state object and sent as auto events to Mixpanel.

In Mixpanel, product teams can pick them and qualify them by creating custom events (using properties as filters).

With this approach, we added tracking for a complete application flow in 1 day (whereas the manual implementation took 4-5 weeks).

There will still be some more testing and refinements, but the general approach looks 100% viable, and I will be pushing this more in projects.

So, if you struggle with implementing tracking and want to learn more, contact me.