Why Data Tracking Matters for a Product
“Sometimes it’s the journey that teaches you a lot about your destination.”
It’s almost one year and a half since I joined GDP Labs as a Data Analyst, which is also my first job after graduating from college. There are a lot of things I did (and learned, sure) since day one. I was assigned to one of GDP Labs sister company, Kaskus, the Largest Indonesian Community Platform.
What I actually did and what this article covers
In terms of what I did, just as you imagine about Data Analyst, the day-to-day task is to play around with raw data. Most of the time I‘m dealing with ad-hoc requests, sometimes dashboarding in BI tools to reduce it, and at times doing deep-dive analysis that mostly lies in descriptive and diagnostic levels.
Something that never crossed my mind is dealing with the collection of the data itself, especially collecting information on how the product behaves. We need to take care of those data so it comes in proper form before we start doing any of the tasks as I mentioned before.
I may say data is divided into two types,
- Transactional, or the outcome-related data in a product or feature, that comes from the backend side. Like order data in eCommerce, or for instance in our case thread creation, community creation, etc.
- Behavioral, data tells us how users interact with a product or feature in granular detail. All of their activities belong to this part.
I deal with both of them in doing my day-to-day tasks, but let’s focus on the collection of behavioral data since it takes a decent amount of my working portion even though it’s still relatively new for me.
A brief definition
Speaking of behavioral data itself, there comes a term called data tracking. It is a sort of activity of identifying and categorizing data points through events that happen on a product. All those event data are collected by placing a tracking code in a website or app, and it will connect to the analytics tracking application we use and could be our behavioral data source later, which at the same time could be a complement of our transactional data.
A lot of options are available when it comes to analytics tracking tools like Google Analytics, HubSpot, Mixpanel, and many more that offer you different features (and limitations as well). Here, we use Google Analytics as the main analytics tracking tool as well as the behavioral data source, which is also connected to other tools like Tag Manager (GTM) and Firebase.
Back to the previous data tracking definition, the output will be a data tracking documentation so we have a clear guide on which behavioral data to track for our reporting requirement as well as supporting future exploration. Mostly, the one who asks for those data is the PM and UX Designer, So as time goes by I won’t be surprised if one of them comes up with a sprint plan and ask me about the reporting requirement of the feature they plan to release which will lead me to design (or update) the documentation.
“Unfortunately, we haven’t tracked that yet” :(
Enough said all the theories, it won’t be really clear without a real use case. Understandable, even in the first month I don’t know the real essence of all these tracking things until I do a lot of hands-on and have some use case to deal with. This section is also the starting point of the “Why”.
Long story short, in the middle of a meeting, a new member of the product team suddenly asks, “Just out of curiosity guys, what features actually drive users to sign-up to our platform? Could it be creating a thread? or joining a community?”. Sounds like a fundamental question, maybe he wants to know what is the ‘selling point’ that makes users intend to convert. Turns out, we can’t answer it at that meeting. Hence, I highlight it as a bold subtitle above.
At that time we had no data about what drives the user to sign in or sign-up even though we tracked some of the sign-up journeys. Then we realized our sign-up journey tracking was not holistic enough, because we don’t track the top of the funnels which actually tells us more about the sign-up.
Soon after that, we track events in every entry point where it triggers the sign-in and sign-up modal. I attach a code snippet below based on that requirement, luckily the requirement isn’t that complex thus the code will be very simple as well, we don't need many parameters as a detail of the event.
Anyway, in data tracking implementation, at least you need to define,
- Event: a sort of user action that we want to collect. It could be a click, impression, or even a pageview. From the previous case, we can name the event
pre_intent_to_sign_inthat will be fired when users want to use the feature and get a sign-in modal because they are in a non-login state. - Parameter: details we want to send once the event is fired. We can send it alongside the event if it happens in more than one entry point or if the event has any granular detail to drill down. Some people might refer to it as the event property. From the previous example, we can add the
section_referrerparameter since the event can happen in many entry points like create thread, reply, upvote, etc. during the non-login state.
If you find the code snippet on the web seems different and confusing, hold on. Basically, the tracking on the Web uses a data layer, a JavaScript object to pass information from our website to the Tag Manager container. Thus we need to map that by creating Google Analytics Tags that will send the same event and parameter value as shown below. All is set for that requirement, now we can get the information that drives users to sign-up the most.
Later on, another question comes from the UX Designer, “Have you found any particular sign-up process where it seems to decrease a lot from the previous process? or maybe a process where it takes a long time to do”. Sigh.
Luckily we have already planned it since we took the previous lesson learned where we missed one of the funnels. Just like the previous implementation, we need to define all the events we are going to collect alongside the journey, as well as the parameters to add a better granularity of information.
Now we have the tracking of the registration process and we can explore which process (events) is extremely decreasing and affecting overall funnels. Even better, with parameters, we can gain more specific information. For instance, later on, we find out that sign_up is decreasing and affecting the last funnels. Turns out “google”, the most used 3rd party sign-up method, has an issue by looking at how each event_method performs in sign_up.
Another question we can answer from the UX Designer is which process takes a long time for users to do in both event and parameter levels in the latest Google Analytics funnel report. As shown in the illustration, we find that a particular section_referrer like “upvote” on top of the funnel doesn’t end up having a good conversion and takes a long time for users to go to the next step, then after exploring the product we found that upvote in a non-login state indeed acts differently by only showing a toast to warn people to login instead of directly showing the modal like any other entry point.
section_referrer (Data are Self-created)That’s one of the real yet very simple cases of why we need behavioral data through data tracking. It enriches the story behind the final results of your feature. So the more features you have, the more events might need to be tracked. As long as it is important to know, go track it. As a side note, pay attention to parameters that are sent alongside the events (in terms of what kind of parameters, and how many parameters) because in some cases the query process to retrieve that parameter value could affect performance.
Common questions Data Tracking can help
The previous section is actually just a sort of question that is coincidentally interconnected from only one feature and I find it interesting to tell. There are a lot of other questions that make me realize the essence of data tracking and maintaining the product’s behavioral data i.e.
- “How many percent of users that visit this thread, then finally convert?”
- “How does the behavior of creating a thread differ in Web and App?”
- “Can I get section distribution where people open community the most?”
- “How does our latest feature behave ya? does it affect our main metrics?”
- “Is this person replying a lot in our event really active in the community by at least opening some threads and related community?”
- ..and many more questions require only behavioral data or even require both combinations of transactional and behavioral data.
As it sounds, all those questions can come from various roles like Product Manager, UX Designer, and Software Engineer, or even from Operational Teams like Content, Marketing, and Community. Then all the answers might end up as an insight for them or even a future improvement. Up to this point, I think we all have got some idea why this is all-important.
Recall of the “Why”
From all previous use cases and common questions, I could say data tracking really takes a crucial part especially when a product grows even further. It gives you another reference of how users behave in a product whether it’s a journey, entry point, preference, or any granularity of the event besides only relying on the transactional data that only represents the end results.
As a new person in this field, at least I got a new lesson on how to collect data through maintaining data tracking besides wrangling data every day, though at first, I rant quite often on the old tracking documentation and implementation. Data tracking also taught me the perspective of managing a product from other people in different roles that work around me.
To end this article, I want to recall and clarify the quote in the beginning: There will come a time when it’s the ‘journey’, or behavioral data, that will teach you a lot about your ‘destination’, or main metrics you want to track mainly from transactional data. It’s a good complement after all.
