It’s been a long time since my last post about professional topics…I decided to take a break from blogging last year to get acquainted with my new role as a product manager at a new company and spend quality time with Capi, a lovely dog (and now part of our family) that we adopted in August 🐕

During this time, I’ve collected plenty of ideas to share with you on my blog. One of the ideas that resonated with me is how to unveil the potential of Analytics to prioritize a backlog, a sometimes challenging task that, ideally, should be based on data. Needless to say Analytics should not be the only source of truth for prioritizing stories. Information can be also collected from interviews with end-users of your product, from the pre-sales and sales teams, and internally from your development teams, among others. However, Analytics can really provide you with some in-depth insights on how and how often your customers are using your application.

I would like to add another consideration when relying on Analytics for this purpose. It only provides insights into the usage of current features and does not allow for comparison between the return on investment of existing features and the potential impact of new features. Thus, while Analytics is a valuable resource, it cannot predict the benefits of future implementations.

Defining the Goals

In order to make the most out of Analytics data, first, you need to make sure that the goals of your development project are clearly defined. That is, basically, which customer needs you want to meet (why somebody would use your app) and your definition of success (ideally with some target metrics). A good example could be: our users can order a customized meal in less than 2 minutes and get it delivered within the next 30 minutes. You can compare the defined metrics for different aspects of your app with the actual data usage provided by Analytics.

Another important step is to clearly define the user roles to be used in your stories and try to match them with the user segmentation/cohorts defined on Analytics. More on that below.

Analytics Reports

Google Analytics collects useful information about customer behavior that its AI component translates into trends. To visualize it, you can create different types of reports:

Realtime

What is going on right now. How many active users are on your site, from where they connect, and how many pages and which ones are being viewed per minute. You can also get information on the devices that are being used (desktop vs mobile). Note: there are more categories that I’ve intendedly left out because they’re not so relevant for the purpose of this post. This report can be used as a reference, but it’s not very helpful to make decisions about priorities, as it only provides data based on a snapshot.

What you can use to get more accurate information about the average use are time ranges. Most of the cards allow you to select a date range (e.g. Last week, last month, last year, custom…). As a product manager, you can compare data from two different time ranges and find out if the current behavior is similar to historical behavior, if there is a new trend on how users are navigating your app, or, in case you have legacy stories/bugs in your project, to assess if it’s worth to work on an enhancement or bug fix (based on the number of visits) or if you should rather focus on other topics (opportunity cost: saying “yes” to something always means saying “no” to something else).

Audience

All about your users. How many returning users visit your app vs new users, their language and location (including city), browser, operating system, and screen resolution. How much time do they spend on average on your site and how many times do they visit it. You can also configure demographic and interest reports to get segmented data about gender, age, and interest category.

You can analyze the behavior of cohorts, which are groups of users who have something in common, and compare them to identify the differences between two cohorts or between the cohort and all users. Afaik for now, you can only create cohorts based on the acquisition date. However, within a cohort, you can add any custom segments that you have previously created in Analytics.

Acquisition

How do your users find your site/app: do they have a bookmark they use everytime they want to access your app? Do they google it? Do they use a referral link? This section can be especially helpful for planning marketing campaigns and investing in SEO (not in the scope of product development, but still interesting).

Behavior

Here you can follow the user flow, which is extremely useful to design and update your app. You can filter by country (e.g. where do my German customers start), browser, language, and even screen colors! and then follow their journey throughout your app with 1st, 2nd, and 3rd interactions.

Conversions

You can define activities that are important to measure the success of your app and track which users are completing them. There are macro-conversions (e.g. the user buys something on your app) or micro-conversions (e.g. the user signs up to receive a newsletter). As a product manager, you will be mainly interested in micro-conversions to keep track of how many users complete an end-to-end workflow.

Most Frequently Visited Pages

The All pages view in Analytics lists the pages that are visited more frequently. Based on this data, you can make informed decisions about prioritization. Working on the most visited pages first is a good way to implement the Pareto rule and make sure that you will focus on something that is relevant to a higher number of customers and/or sessions.

Backlog prioritization should be also oriented to increment the return of investment, which can be calculated as an intersection of the business value and the effort required to implement a feature. And here is where Analytics also comes into play. Stories that have higher business value (that is, impacts a higher number of users) and require lower effort (fewer story points) can be moved to the top of the backlog.

With this, I’m not saying that the customers should define the roadmap. The product roadmap should be planned by the project manager in alignment with the product owner. However, when features are translated into epics and stories, criteria like the number of customers using a feature can be used to decide which stories should be implemented first (provided there are no dependencies).