How to make the most of web analytics and event tracking

Posted by Benjamin Dell Benjamin Dell on .

This is part of an ongoing series of posts called Building Updatey, where we share our ideas, methods, results and learnings with the aim to help people in similar situations and learn from the wider community. We’d love your comments and input.

Back to basics

We love data, in fact we’re decidedly goofy about it! But this makes it all the more important to remain disciplined in this area. It’s all too easy to become transfixed with daily Google Analytics charts - beautiful sure, but are they actually helping you gain clarity? When I think of web analytics (and our approach to it) I liken it to stock trading, in the sense that it’s very easy to become drawn in and mesmerised with the daily stock ticker - where companies can see headline 20% gains in a day, as well as spiralling drops. Whilst these make great news stories (and of course, some people very rich) many people would argue that reacting to daily fluctuations is no better than gambling.

Here at Updatey, when we ask ourselves what we want to get out of our web analytics, we think first of the questions we want answered. For instance, how many tasks does an average user need to add before they start inviting people to participate in their project? Or how many milestones does a typical user need to add before they start coming back to their Updatey timeline more often? Armed with specific questions like these, we find it far easier to know where (and how) to start looking for the answers. What we don’t want is a broad brush approach to analytics (because, lets be honest - there’s a hell of a lot of data out there at your fingertips) but instead, a highly focused, results driven one.

Ask the right questions

As alluded to above, there are a few primary questions we’re really keen on answering at this moment in time. Updatey is a relatively new product in the market place and although we’ve had some fantastic reactions and traction so far, we now need to get serious about what we monitor, track and react to. Ultimately, it’s all about making sure we evolve based on tested hypothesis and real data (don’t worry - there’s a bundle of unabashed intuition thrown in there as well!).

Ultimately, it’s all about retention! So when we sat down to think about the questions we needed answering, we found that they naturally centered around how X impacts retention rates etc. Here’s what we came up with:

  • Does inviting members to a project increase the likelihood that the a greater number of ‘actions’ will be performed on the project (i.e. adding milestones, tasks and posts)?
  • On average, how many tasks need to be added to a project before a member is invited to participate in a project?
  • Does the simple act of creating a task, post or milestone impact whether or not a user will come back to Updatey to manage their project? And if so, how many are needed of each to see a increase in retention rates?
  • If a newly signed up user completes our tutorial, does this increase the likelihood that they will do more with their project, and ultimately come back more often?

The above are just a selection of the possible questions one might come up with in this situation. Rule number one is focusing on a few, focused questions at a time. We want to fix (or improve) these scenarios first before moving onto the next questions.

Using actual user events, rather than page views

Google Analytics is great, but its not so great at tracking user behaviour and well, you’ll see from the above questions that it’s pretty much all to do with behaviour! As a result of this, we want to look at user event tracking to give us the answers. Step in Mixpanel! At it’s core, Mixpanel lets us send user events which are then tracked. It’s real power though, lie in its ability to let you slice and dice that data in a multitude of ways. For instance, we can perform calculations to look at the average number of 'task' events logged per user, before a user invites a member. Suddenly, we’re able to start answering real world questions in meaningful and powerful ways.

Firing the right events - and planning for future growth

Firing a Mixpanel user event in Javascript is pretty easy, and I think that’s part of the problem (or was for us when we first started). We ended up firing off all sorts of events (such as when a task was created and another one when it was marked as complete. We even fired events when tabs were opened. Sounds logical right? Well yes, but not really that clean as it turns out. We ended up with dozens of unique events in Mixpanel which made it really difficult to see what was going on. So last week we effectively started from scratch and re-through through our event tracking approach. Hopefully by reading this you can learn from our mistakes.

Effectively, you need to think hard about what the key actions are that a user can make that have some impact on an end goal (such as inviting a member to their project, creating a task or upgrading to a more expensive payment plan). This helped us refine the list of events that we wanted to track to:

  • Beta signup (with just email)
  • Actual user signup (after beta activation)
  • Project created
  • External integration added
  • Member invited
  • Milestone created
  • Milestone marked as started
  • Milestone marked as complete
  • Task created
  • Task marked as complete
  • Activity post created
  • Activity post commented on
  • Tutorial started
  • Tutorial completed

A sensible list for now, but there’s some more refining to be done. We saw these written up on our whiteboard and realised that they could be ‘normalised’ a little more by grouping certain events together. Our next round ended up with:

  • Signup
  • Project created
  • Tutorial
  • Milestone activity
  • Project management
  • Task activity
  • Activity feed action

When you send an event to Mixpanel you can create any number of custom properties for that event. This meant that we could effectively combine related events together, but differentiate them through their properties. So the three milestone events from the first list are all linked to the ‘Milestone activity’ event. We sub-divide them by creating a property ‘type’ which is either ‘created’, ’started’ or ‘completed’. Suddenly, we have a hierarchy and an approach that enables us to expand the events we track without having to re-think our whole taxonomy.

We’re very happy and now, we just need to start tracking and analysing the data that these new events produce. We’ll try and share some of these findings in a future post.

If you have any questions about the above just pop us a comment and we’ll get right back to you!