Getting started: What actions should I measure?

The hardest part of integrating with an action based analytics service, such as Calq, is actually defining the actions that you want to measure.

Cataloguing actions

Here at Calq we do a lot of data modelling for clients and have developed a process that works well for us. We start by focusing on actions and user journeys rather than the business questions the platform is to answer. We normally find that our customers think of a few questions up front, and then add more and more as they become familiar with Calq's functionality. Calq can only report on data which has already been measured, and this is why it’s normally better to start from an action perspective rather than a questions perspective. If everything that a user can do is being measured from day 1, then Calq can normally make the required reports to answer business questions as they arise.

For a website, we would look at each page in turn and make a list of the possible actions that a user can perform on that page. We do this independently of user journeys (though it’s good to keep them in mind just to make sure you cover all pages).

Keep in mind that in Calq any of the actions you record can also take additional custom data. This custom data is often where you get the most value so be sure to include anything that is relevant. For example, for a “Message Sent” action, you might want to also include, the number of recipients, the length of the message, and how long the author spent composing it.

You can look at user journeys once you have compiled a complete list of actions. The purpose here is just to map out the possible journeys within your app and ensure you have the needed actions for each part of the journey. We normally find we have overlooked a couple of actions the first time through. Mapping out the user flows explicitly also gives you a list of user flows to convert into funnels later on.

Business questions

With a thorough action list the final stage is to get some initial intelligence questions. The business questions you will want to report on typically change depending on the department that needs the data (though in a smaller company, those lines blur as everyone overlaps).

Management normally want top line overviews and have a fixed set of KPIs they want insight in (new users, total users, number of sales etc). Marketing teams often want an idea on how their acquisitions are performing – it’s typical to get a channel that is converting well, but you need to check those users are actually valuable within your app by looking at actions. Lastly, product teams (often the same as the development team in a small business) want to know how the product is being used so they can iterate and improve on it.

Some simple examples to get you going:

  • Management
    • How many new visitors do we get per day/week/month?
    • Average sale value per day/week/month
    • Number of sales in last day/week/month
  • Sales & Marketing
    • What is the retention (the amount a user comes back) for a user acquired through channel X?
    • Which campaigns are most likely to convert into sales?
    • What are our users doing before they pay for the first time?
  • Product
    • What % of our users use feature X?
    • We just updated feature Y. Does that make it better?

The goal is to get a list (doesn’t have to be big) of initial business questions that each team wants answering and check that against your list of actions (i.e. do we have appropriate actions, and data to answer this question). It’s quite typical to find you have all the actions mapped out, but you may not have include sufficient custom properties to build a report.

We are always happy to take a look at any model you have made to see if we notice anything. Just reach out to us.