There is a problem in the web development community when it comes to tracking user data. Not a problem, as in "it's broken again". But more of a problem as in "how do you do this again?". Because many folk don't seem to know. And you can't really blame them as there is no real standard when it comes to tracking. There are 2 schools of thought that come to mind when tracking data.
And those are the track minimally approach or the track everything approach. Both somewhat problematic for various reasons. So today let's break down tracking from those 2 perspectives, and let's introduce a few new methods that fall somewhere in between that might be more beneficial.
In the long run it is better to track more than to track nothing. You're way better off with way too much data, than with nothing to look at.
Data debt is a common occurrence in the business realm. You just discovered something amazing about your company and it's goals, and you need to know how far back this goes. Well, you can't. Because prior to this moment, you don't have a speck of data on it. Welcome to data debt.
So track everything...?
So yes, technically it is better to track everything, as oppose to tracking nothing. But that will only happen if you have that "aha!" moment. Otherwise, you'll suffer from data blindness. And that is when you have so much data, that you can't make any sense of it. Equally, a big problem.
At a minimum you should have some form of analytics running on every page of your website. Not the most useful metric as you'll more than likely end up learning that your home page has the highest engagement and that your bounce rate is somewhere between 60% and 80%. But that definitely beats the "between 0 and 10000 users visit us daily" metric.
Also, a very popular method. The mentality being that the more data one tracks the more aware you will be of your entire company. Not so. And that comes down to the fact that if all data is important, then no data is important. It's a problem that we faced in our company Renly, and one that we're continuously trying to improve by limiting the tracking data that comes in.
Tracking everything only works if your data is manageable and if you know how to retrieve the parts that you require. This comes down to having a good schema in place for data tracking storage or using 3rd party tracking to the best of your ability. And it also comes down to having a good data analyst on your team.
Working for previous employers, one of the recurring challenges we faced was the exponentially growing amount of tracking data that we were keeping in the database, 99% of which was never looked at again. In total, a whopping 100GB of data was accrued during the first few years of operation. This not only caused a serious problem with reporting and analytics, but it came with a price tag as 100GB aren't normally free. Backups became expensive and overall reporting essentially came to standstill as processing billions of records is also expensive.
Yet another option
But there's also a 3rd alternative that you can try, which we'll dive into down below. It's a bolder version in a way, because it may result in some data loss, but more beneficial to your overall goals as a growing company. And you won't know the result until much later in the timeline.
Tracking dynamically is key here. You'll be tracking different events during different times in your project. In the beginning maybe user acquisition is more important, however once you have those users, behavior will be key. And soon after you get a feel for that, you'll be able to customize your tracking even further.
Track what you want to see
Another option that we have been playing around with is to track what you want to see and/or attract. If your company is looking to grow it's user base, then track user sign up related page elements to the best of your technical ability. If you're looking to increase engagement, then track engagement. This accomplishes a few things, which we'll go into down below.
For one, you won't end up with a million records to parse through and decipher, which is many later stage companies find themselves dealing with.
Did you find this article helpful?
Stay up to date with my weekly coding tips!
Walter G. is a software engineer, startup co-founder, former CTO of several tech companies and currently teaches programming for a coding bootcamp. He has been blogging for the past 5 years and is an avid BMX rider, bio-hacker
and performance enthusiast.