For software to be effective, and in order to know how effective the software is and how it’s changing as we implement new features and fixes, we need to measure how it’s being used.
The primary method we use to discover how good an application solves the problem is has been designed to solve is to ask the users. People who interact with the application most can give us the best feedback on what their pain points are, what they find frustrating, and what the app is both good and bad at doing.
However, asking users is often expensive in terms of both money and time, and sometimes gives a false impression of how well something is working as users are people, and people don’t always like to give honest feedback if it’s very negative. This is especially true if the user is a friend or a family member as is often the case for an application for a new startup.
We can solve this challenge by using automated reporting and analytics.
Problems and bugs
When an application is deployed we use a variety of testing methodologies, automated test tools, and a thorough manual QA process to ensure our software is as bug free as we can make it, but pragmatically we’re aware that we might miss things. Running online software relies on a stack of technologies that sometimes mean things don’t work correctly.
In the past we would rely on a user reporting a bug. This approach doesn’t work. Users are often bad at reporting the information that developers need in order to work out what could be wrong with an application – users shouldn’t need to understand the deep technical information that’s required to write a bug report. Asking a user for operating system data, a browser version, details of plugins, and maybe requesting a screenshot or a video is unreasonable. That’s not the user’s jobs.
At Komodo we solve this problem with online bug reporting tools like Sentry.io. Adding Sentry is a very simple task (it’s a matter of adding about 3 lines of code) and then when an application the user is working with has a bug the Komodo developers get a report of exactly which line of code had a problem with all the necessary information to work out why it was an issue. This means we can proactively fix things. We can know about a bug, fix the code, and deploy a new version before the user has even reported that it’s an issue. This is a key advantage of online software-as-a-service.
Sentry is a useful tool for gathering more information when a problem occurs but that isn’t especially helpful for planning how to change and improve an existing app. Most of the time (hopefully) what needs to be recorded isn’t a problem, it’s an event.
Events in applications are simply “a thing that happened” on a fine-grained and discrete level. We can use event tracking in an application to find out how users are interacting with the app, which features they use most or least, and whether or not they appear to be frustrated or angry. With permission from the user we can go a step further and even record their entire session to playback later and see if there have been any steps in their workflow that could be improved.
There are a variety of event tracking applications that we can use from Google Analytics to Hotjar to Logrocket. Each has its own advantages and disadvantages. Google Analytics is good for event tracking at scale, while Hotjar and Logrocket are more appropriate for gathering more detail about individual users.
Optimising Web Applications with Google Analytics Events
Google Analytics event tracking can record interactions with a web application like clicking on a button or navigating to a particular link.
Each recorded event is defined by a category, action, label and value. The category and action for an event are required while the label and value are optional. By defining categories you can create logical taxonomies that help to report on the way a user is actually using your application. The action that’s passed to Google Analytics is simply a reference to what the user has actually done in the app.
Label is useful for adding an additional dimension to categories. For example, if a user has been browsing through a list of video content in an application the category would typically be something like ‘Videos’, and the label might ‘music’ or ‘learning’ depending on the type of video that the user has picked.
The Value that is passed is a number or a line of text that gives more meaning to the interaction event. In the case of tracking a user playing videos from a list, the value could be the position in the listing, or the length of the video. This would help to discover what sort of videos users are interested in, or to test the effectiveness of a new sorting algorithm.
Google Analytics also has a feature to aid in the optimisation of the performance of an application in the real world – User Timings tracking. Like Event tracking User Timings have Category, Label, and Value fields, but they have Var rather than Action.
The Category and Label work in the same way as they do in the Event tracking. Values are always passed as a number in milliseconds. The Var field is short for Variable. This is the variable that is to be tracked – eg ‘page load’ or ‘time to save’.
By building up a corpus of data about the timing of your application under real-world conditions it can be very obvious where to spend time on optimisation.
We help teams across the UK deliver successful digital projects. If you’d like to have a conversation with us, we’ll put the kettle on.