< Back to articles

How We Help Products Grow and Save Through Metrics

Would you choose to take a trip with a car that has no speedometer and navigation? Hopefully not, and in a similar way it is impossible to efficiently manage products without metrics.

What specifically are metrics needed for?

  • They help us find domains of the life cycle of a user suitable for improvements.
  • We define success and product goals based on them.
  • With their help, we figure out the financial status and profitability of a product.
  • We monitor frequency and data about use of individual functions in the product and we are looking for room for improvement.

Even in case you have not dived deep into metrics yet, it is possible that you are already unknowingly using them, for example in the form of Google Analytics. The article is primarily focused on metrics for digital products.

Leading and lagging metrics

Before we start talking about specific metrics, it is necessary to define at least one categorization which I find absolutely crucial. That is how fast will the value of the metric reflect a change in input data. That is where we define leading and lagging metrics.

A leading metric is such a metric that reacts immediately to a change in input data and most probably influences another lagging metric. A lagging metric is delayed which means that it reflects our performance in the past.

For example if we were monitoring the performance of our sales team, a leading metric would be the number of calls with the customer and a lagging metric would be the number of closed deals.

An advantage of leading metrics is that it is possible to immediately evaluate whether we are going in the right direction and that is why we want to focus on them in our day-to-day tasks. A disadvantage is that such a metric does not reflect one to one the change in a lagging metric, it is more of its approximation. In order to make it even more complicated, some metrics also belong into both categories at the same time, such as the rate of abandonment of the product.

Metrics: What to monitor?

What to monitor is dependent on the specific product and our goals. In general, we can say that we want to cover the whole life-cycle of the user. There are different frameworks and methods for categorization of metrics, as an example we will use the AARRR framework.

AARRR framework consists of:

  • Acquisition/awareness – how do people find our product and how did they learn about it?
  • Activation – do users make the first steps that we want them to make?
  • Retention – do we lose users in a specific part? How do we ensure that they stay?
  • Referral – do users like the product enough in order to recommend it to others?
  • Revenue – do we efficiently convert users into paying users?

Metrics on a real product

Let’s take a look at part of the metrics that we monitor for our product Passwd in connection to the AARRR framework. It is important to mention that we are operating in a sector focused on security, so that we let our users have the option to say whether we can collect their data. The product has a “freemium” model, which means that we have an unpaid and a paid version and there is also a demo version for quick tryout. All the versions have similar metrics.

For visualization of the metrics, we are using Google Analytics and Google Data Studio, but for your use, the specific tools will depend on your technological stack. But now to the specific metrics.

Acquisition – the number of new users in a specific version of the product and their source (advertising, search, unpaid version of the product and so on). 

Activation – number or percent of the users that logged in and created at least one password. 

Retention – at least some kind of activity within the product within the last 30 days. That is a very mild definition of retention, but within this project we do not want to maximize the usage time, but quite the opposite - we want the user to copy their credentials as fast as possible and leave. 

Referral – sending the questionnaire about satisfaction within a couple of days after purchase, including the NPS score. Furthermore an evaluation dialogue within the application itself. In this case it is necessary to select the correct frequency of these activities in order not to bother the user. 

Revenue – we are calculating the user LTV (customer lifetime value), which is one of the most important metrics within revenue and MRR (monthly recurring revenue).

From that it is possible to visualize “conversion funnels” with percentages of transitions between different versions of the product (free, paid, demo). That gives us a manual for identifying possibilities for improvement. Furthermore, we use Google Analytics to monitor how often individual functionalities are being used.

However, these metrics are not a final list, their purpose is to serve as an example. Whenever there is a need to create a goal, it is possible to create new metrics or monitor something further. It is a long-term process.

How will metrics help you?

Without at least some basic metrics, it is very difficult to identify the right part of the product that we want to improve. In the whole conversion process, but also after it, there can be significant problems that cannot be identified without measurement. Metrics are the best way to efficiently invest into a product. It is not efficient to invest in internal functionality of the application as long as 60 % of users leave at the point of registration.

Thanks to our experience with digital products, we can recommend a basic set of metrics that would be suitable for a product. In the applications we can add a rate dialogue for evaluation of the application which links to reviews in stores. From reviews, the referral score can be derived. From stores we can get information about new users and data about login which makes it possible to estimate the current size of the active user base, retention of users and their engagement. From the data in the database, it is possible to calculate the activation ratio using specification of activation action. Last but not least, we have data about critical falls of the application. All of this helps us ensure the growth of our products and savings at the same time.

Marek Mouček
Marek Mouček
Product ManagerMarek is the Product Manager of our startup, Passwd. In addition, he is part of the Ackee PM team, where he fully uses his technical background from FIT CTU. If he is not agile in product management, he is mobile on his motorbike.

Are you interested in working together? Let’s discuss it in person!

Get in touch >