User analytics is one of the most fundamental features that every popular web application should perform. Without collecting data about user activities, one can never be sure of the user experience. The developer team will invest days on some functionality, but unless they know how many users use this precious feature, they will only guess and hope that the users are benefiting from it.
In other words, “Without data you’re just another person with an opinion.”, W. Edwards Deming.
To clarify the ambiguity, my production team (http://meldeskade.no) decided to use popular business analytics tool, Mixpanel. Our single page web application is built with ReactJS, uses Jøkul Design System and hundreds of users visit the website to report their insurance activities every day. In short, meldskade.no is a typical SPA which promises the user to follow a set of operations under some sections and completes the user request somewhere along the way.
From the perspective of a front-end developer, I thought including Mixpanel tracking would be a simple task. However, as our team gained more and more experience in the field, I started to realize the obstacles. We followed the path of ‘learning by doing’ and eventually, our Mixpanel tracking started to deliver us data. So, this article will help to those who are in the beginning of their Mixpanel journey and looking for some useful advice.
#1 Don’t underestimate the integration work
Know your enemy first! Adding Mixpanel to your web application is an integration process and system integration is maybe the most problematic fields in Information Technology. Because linking different systems increases the complexity. Although the relationship between a web application and Mixpanel is a one-way road, the integration will still be painful, and it has the potential to produce unforeseen errors.
For instance, if you perform some tracking event before initializing the Mixpanel with the code below, the application will have a fatal error and whole website will be down for the user. This error can seem obvious, but one exceptional case for some users might be the end of the show. Therefore, do not underestimate the complexity of integration process.
import { MixpanelUtils } from './MixpanelUtils';
...
MixpanelUtils.Init();
#2 Document every tracking operation first, code later
Teamwork is required in order to integrate a web application with Mixpanel. Naturally, a web developer cannot sit alone and write all the tracking operations on his/her own for a large system. Product owner, architect, tester, and tech lead should give their consent on what user activities will be tracked besides developers. Since people from different roles are involved in the process, it is important to keep decisions in one open document.
The team of meldskade.no created a table which lists all tracking events. We included many columns for every event such as definition, trigger case for the tracking, its parameters, development status and we even wrote down the JIRA ticket for each tracking. This strategy helped the team solve the complexity of the problem.
Besides, we still keep this document active. Whenever the team needs to implement a new Mixpanel tracking, we start the work by documenting. So, document first, code later.
#3 Don’t try to track too many events on first deployment
Since our team underestimated the complexity of adding Mixpanel to our website, we set an ambitious goal for our delivery. We tried to implement at least 10 different tracking operations in one go. However, you should also implement configuration code for Mixpanel. These are OptInTracking, alias, identify, getting cookie consent of the user, etc. This is the threshold that one team should initially come over to reach for tracking events. When a team wraps all of these in a single deployment, the development work grows much more than expected. Therefore, the goal on first deployment should be a successful configuration of Mixpanel and a couple of meaningful tracking operations.
#4 Surprise! Surprise! You need a backend developer 😀
This is a point that our team failed to foresee. We basically thought we had all the data out there. We should only write some well-organized tracking operations in JS and everything will go smoothly. However, the data flow of a web application is not like what you see on a webpage as a human being. For example, you want to track some category data after the user clicks a section, but the component that you are triggering the event from may not contain the category information as a prop. Therefore, you need to ask the backend developer to provide this additional data via corresponding API call.
This tip is very much related to the advice #2. If the developers communicate about where and how to obtain the data attributes in the documentation, the process will go simultaneous and smooth.
#5 You will discover defects along the way
This might be one of the greatest paybacks for all the effort performed to reach the goal. As you implement more tracking on different components of a React application, you will discover some defects that have been omitted by you and other fellow front-end developers. React redundant rendering problems are known, but mostly ignored defects. And they are not easily discovered by tester, neither they truly create some run time error, but they are there. While adding more tracking operations, you will clearly see those mistakes and you will have the opportunity to fix them with some refactoring process. This practice will increase the performance of the application.
#6 GDPR is everyone’s responsibility. Speak up when in doubt.
Every team member should be observant on potential GDPR violation. More data does not help to understand user interaction better, but key data does. Users’ private data does not play any role while measuring the efficiency of an application. Therefore, speak up when you are in doubt of some data that your team is about to collect.
Sercan Leylek
Stork's Nest 