UX insights, or how to build and read user-flow maps

The data-driven approach has gained significant popularity in recent years; more companies are trying to make decisions based on data. A large part of the analytics, especially those related to business metrics, is easy to build without complications. User behavior analytics often raises questions, especially in products that already have some data legacy.

Introduction

Sometimes the analysis of user behavior does not cause problems — the path in the product is linear and does not have particular branches and dozens of different scenarios. But sometimes that it is not so simple — the product can be complex, with a number of “buts” and inconsistencies from the simple funnel.

Our product is just like I described. We are an e-commerce platform. Our supply is events. Concerts, entertainment, and attractions. Each is unique — for some, the show takes place once, for others it is repeated on different dates. Some concert has a map of seats and another has only a “buy” button. Each of these steps affects conversions, making the funnel more complex.

How to find out which part of the product bounces the user the most? Which steps in the user journey are bottlenecks and which are drivers? I am convinced that these questions in a complex product can be answered by user path graphs, which will be described in this article.

What are Celonis and Retentioneering

Before we talk about tools, we need to understand what user path graphs are.

Let’s remember the standard analytics events in the database — if we simplify it a lot, it is usually some title of the action (event_action) and the time when this action was happened (timestamp):

Certain events can happen several times during one user session. Users can go back several times to look at the item in catalog, or even go to some other pages/screens:

And this is only for one session of one user, but just imagine what the table looks like if there are at least a thousand such sessions and users.

What are user path graphs and how do Celonis and Retentioneering help build them?

Let’s take from our table all the points that indicate a particular step/place in the interface. Let’s draw them on the plane and connect the sequences of actions one after the other, as it is written in the table:

There is only one more step left! Let’s do the following:

• add nominal start and end points, which mean that the user was “born” and “bounced”;
• display on the plane all possible places where users can get;
• let’s make the size of the points proportional to the volume of users who have reached this place;
• draw arrows from where and where users go;
• and the thickness of the arrows will indicate the volume of users who have passed along this path.

After this exercise, we get the following picture:

To build such maps with ease you can use such tools as Celonis and Retentioneering. By having prepared the data, it is enough just to upload it to one of these services (Celonis is a service, and Retentioneering is a library), the graphs will be built by themselves, and Celonis will even have a number of additional features that simplify reading and analysis processes.

I will describe below how to read such a map and find insights there.

How to prepare data

In order to avoid errors in the graph that will be built using one of the tools, you need to prepare the data.

The data structure for each tool is extremely simple, services need to have only three main parameters:

• session id — to understand the user’s path. It is the session ID that is needed here, not the user ID. Because it is logical that the user’s journey does not end with a purchase. They may return, buy again or visit other pages of the site outside the main path;
• event identifier — the name of the action, screen, or another unit of the user’s path;
• timestamp — the exact date in seconds (and often milliseconds) when the event happened.

Important notes on the data:

• The event must be part of the interface/path for all users, not just for a specific one.
  For example, highly personalized events like “product id12345 visit” will be a mistake and will create a huge incomprehensible web on the map, instead of a readable graph. If your events are written in this way, then it is better to group them and use the more general option — “product page visit”.
  This is especially true for pageview events in Google Analytics, where each page of an individual product is recorded as unique.
• A lot of data is needed! Since these are raw logs, feel free to load millions of raws into the tool — this will only make the report more accurate.

Basic Graph Knowledge

Before you start reading the map, let's dive into basic knowledge about such tools. The notes below will be given about Celonis, but it is relevant to Retentioneering too.

• Process start (start, beginning) — is a nominal start point of the user session. It’s not the exact place on your site or in your app. This is some nominal “birth” point about the user.
  Users may land on different parts of your product that you weren’t aware of before. It is easy to trace this by the arrows coming from Process start.

• Process end (end, finish, way-out) — this is the nominal “end” point of the user session. This is not a specific place in your product, but a nominal user exit door. This is the moment when the user closed the site or turned off the phone and his session ended.
  Events before “Process end” will help determine if the session was successful or not. If before the exit there was confirmation of a successful order, then its a happy path.

• Activities (slider, range setting) — helps increase or decrease the number of events displayed on the map.
  When setting the number of events, the priority of their display is formed from the volume of sessions in which this event was.

• Connections (slider, range setting) — helps control the number of “paths” or paths displayed on the map.
  The priority is formed in the same way.

How to find insights

After all the preparations and the final loading of data into Celonis, we get a beautiful and comprehensible graph, on which you can even start visualizing the movement of users:

You can play around with the sliders, try different functions and get to know the tool in more detail. There are many articles on the Internet about scenarios for using this tool, but I want to focus on one task — finding pain points that are the reasons for users to leave and, accordingly, fixing such points can well stimulate product growth.

If we are looking for the reasons for the churn, first of all, we need to look at the events that led to the exit of the user. To do this, just click on the “Process end” point and see what events preceded the exit:

In the example, there is an obvious outflow on the product pages, which can indicate a fairly organic outflow. But in addition to this organic outflow, you can pay attention to a number of problematic points that require further tests and investigations.

For example, some pop-up, which is the cause of the churn. In the screenshot above, the outflow occurs after a pop-up that leads to the installation of the application. To understand whether this is a problem or normal behavior that does not bounce away users, it is enough to look at whether users reached the application in the end and whether they performed subsequent actions in it.

The second example, these are some hall-map and select-tickets pages (in our case, this is part of a complex checkout), which require more detailed consideration on the map. Let’s find them and zoom in:

The screenshot above shows the second common pain case in the user path, which dramatically affects conversions — the cycle.

This pattern of behavior indicates that several steps along the way need to be combined. An example of how a user sees such a cycle when booking a flight ticket:

• the choice of type and available flight dates are separated into different steps and depend on each other;
• the user selects the “business” type and gets to the next page;
• the date he needs is not available in the business type, he goes back to change the type (if he even guesses that it depends on the type of the ticket);
• selects the “economy” type and gets back to the page with dates, but the required date is not there again;
• and so on

Most likely, after the second cycle, such a user will be disappointed and leave, but in fact, the “business+” type was very close, which is only 5% more expensive, but the dates and places the user needed were free.

Conclusion

There can be many similar patterns of behavior and problem points, I have given only a few possible options for reading such cards. A deeper dive into this approach should be done in the context of your product and your users.

You can use such tools both for monthly reconciliations or occasional grow hacking sessions, as well as for regular analytics, which is easy to set up by integrating the service with your data warehouse.

Additional note:

• The author of the article is a product manager, not an analyst. The article is specifically written for an audience without a strong analytical background, which may be reflected in the style and depth of the language, the terms may be simplified for ease of understanding. :)