Understanding how people are using your app is crucial to your mission as a developer. If you don’t know how your users are interacting with your code, how can you work out how to improve it? As the first instalment of my new blog series on behaviour data collection and analysis, this post covers some of the foundations. So, if you’re new to behaviour data and want to learn more, read on…

This series grew from some notes I’d written over the past few months. A few practical tips I’d built up whilst working on behavioural data. As I was writing that post, I realised it had ballooned to several thousand words, so I’ve decided to make it a series. This first instalment was the introduction and serves as a basic (non-technical) primer on the what and why of behaviour data collection and analysis.

“Understanding user behaviour” is obviously a very broad term. There are loads of ways to approach the problem. Even if you’ve never thought about it, you’re probably trying to get into your users’ heads when you make decisions about your project. We all have a common sense (“heuristic”) understanding of how people will behave in a given situation. And hey, we’re probably dogfooding to a certain extent anyway, right?

Even when we start to get more rigorous in our quest to understand the user, there are plenty of options. For a start, we could look at the data the user has provided us. Perhaps you’ve got some information in your database already that you can use to draw some inferences.

For instance, if a user has successfully published a blog post, we can infer that:

1. They were motivated to use your blogging app at that time
2. They were (at least somewhat) successful in doing what they set out to do

But that leaves so many questions unanswered! Did they mean for there to be so little formatting? Or did they try, but come up against some sort of issue? Did they spend longer than we’d expect to complete a simple action, like adding an image?

Answering questions like this (or at least trying to) can be a great way of coming up with fixes and features, as well as being a strong signal when it comes to prioritising your time. So how do we go about answering them?

Usability researchers have all sorts of tricks up their sleeves to help answer questions like this. These include the interviews and surveys that might spring to mind, but also observational methods, task analysis, and A/B testing. Whilst insights from proper usability research can be invaluable, the process of conducting studies and synthesising the findings can take large amounts of time and money.

The technique I’m going to talk about today is pretty quick and cheap but will add enormously to your ability to understand how your users are interacting with your code. This, in turn, will allow you to make informed decisions about your next bug, your next iteration, and maybe even your next product.

Behavioural data tracking is a bit like logging: by adding a few extra lines of code to our app, we can start collecting a wealth of data about how your users are behaving, without them needing to do anything. Whenever a user does something we’re interested in, we’ll fire off an event to be aggregated and analysed in the cloud.

What to track?

If you’ve read this far, I’m going to assume you’re quite interested in getting some data on the behaviour of your own users. You’re probably itching to get started and want to dive straight into the tech. I’m going to talk about the mechanics of wiring everything up in the next few posts in this series, but for now, let’s take a step back and think about what we might want to track.

You’ll see plenty of guides out there that advocate a Proper Tracking Strategy. There will likely be spreadsheets you’re supposed to fill in. Some of these “strategies” seem designed primarily to nix whatever enthusiasm you had for behavioural data. My advice? Ignore them.

You probably already have a pretty good idea in your head of what you need to track. Start with that. As you start to use the data to try and answer real questions, let your tracking evolve to meet your needs.

Some events will be more useful than others. Whilst there’s not a lot of harm in tracking more events than you need to, it’s going to be a time-sink and snarl up your attempts at analysis. Once you’ve got your long-list of possible things to track, go through it with a red pen.

When I’m evaluating what events to track, I’ve found it helpful to consider if it falls into any of the following four categories:

1. “Pulse” events: These are good indicators of user activity. E.g. “we count Weekly Active Users by looking at the number of unique …” This is a useful metric in its own right but also serves as a denominator for other metrics. Think about whether you want this to apply to all users, or maybe some subset (such as registered users) and design your event appropriately.
2. KPI events: Are you aiming for a certain number of actions? Perhaps you need 100 purchases a week? Or perhaps you need 50 completed registrations a day. I find it’s best to track these things directly, or you’ll end up relying on poor proxies, which will inevitably cause confusion.
3. “Grit” events: When something goes wrong, it’s not always an error or a bug. Sometimes your UI will inadvertently encourage “incorrect” behaviours. Tracking instances where you display an error message to users, for example, can help to spot trends and allow you to eliminate sources of friction.
4. Trigger events: I mentioned that Mixpanel allows one to trigger targetting messages in response to events. Think about whether the messages you might want to trigger would be in response to events you’re already tracking.

With a good selection of events, you will start to get a good sense of how your users (in aggregate) are interacting with your app. Consider using your “pulse” events as a baseline to help you distinguish useful signals from the noise. Metrics like “email validation errors per successful sign-up” or “purchases per active user” can be useful bellwethers (or perhaps canaries-in-the-mine).

Another thing that can be helpful to bear in mind is that we’re only dealing with event data (i.e. “things that happened”). Some of the questions that you’ll want to answer will require you to blend state data (i.e. “the way things are”). This can be hard to do in these hosted platforms, as the best approach would usually involve data from your database. In Mixpanel you can add properties to your user records, but it’s still pretty limited. If you find yourself in a situation like this, try to think about whether you could fire off an event as a proxy for a certain state, or transition between states.

Wrapping up

There’s loads more we could talk about on the topics of why we track behavioural data and what events we should track, but hopefully, that’s given you enough of an introduction to get stuck in without making the mistakes I did.

Done well, behavioural data can become a central feature in your team’s decision-making process. Ultimately, good behavioural tracking will empower you to make intelligent decisions about how to improve your product

In the next few posts in this series, I’ll be talking about:

• The tools we use at HeadUp Labs – Segment, Mixpanel and Google Analytics
• Some things we’ve learnt so far, with regards to those tools.
• The next parts of the puzzle that I’m investigating

So stay tuned for a dive deep into our experiences!

If you’ve got any thoughts on the “whys” or “whats” of behavioural data, please share them in the comments!