Mobile app analysis as an area of digital analysis

Размещено на http://www.allbest.ru

State University of Trade and Economics

Mobile app analysis as an area of digital analysis

Balai N.O.



Introduction

In recent years, the analysis of mobile apps has become more and more common. The widespread adoption of data-driven business intelligence techniques at the operational, tactical, and strategic levels in the mobile industry, coupled with the integration of user-centric metrics, has brought about a paradigm shift. Historically, mobile app and game development have not been data-driven. However, this is changing as the benefits of implementing and adapting analytics to support decision-making at all levels have become a well-known and recognized necessity. mobile app digital analysis

While analytics play an important role in every aspect of business, the adoption of analytics in mobile app and game development is primarily driven by the need to better understand users (gamers). This demand is driven by the emergence and growth of online social games and free-to-play business models that rely heavily on user behaviour data analysis to grow revenue.

Users are increasingly involved in the development and testing of digital products. Against this backdrop, the target audience for mobile apps and games continues to grow in size and diversity. This enables the gaming and mobile industries to innovate in various forms of software applications, enabling different types of interaction and monetization. This development also marks the birth of the game user research (GUR) sector, which is still an emerging area of investment and development in the gaming and mobile industries and is one of the main drivers of analytics development, a key resource in the development of these products.[1]

Presentation of the main material. Mobile app analytics is becoming an increasingly important area of business intelligence for the industry. Quantitative data gathered through telemetry, market reports, quality control systems, benchmarks, and other sources all feed into business intelligence management systems and inform decision-making.[2]

Process, performance and user behaviour measurements collected and analyzed throughout the lifecycle provide stakeholders with detailed information on every aspect of their business. With an emphasis on user-centred analysis during development, there are many ways to leverage this data, including tracking and troubleshooting software bugs, user preferences, design issues, behavioural anomalies, monetizing data, and more.[2;3]

Although mobile app analytics is now widely used, it lacks clarity in the digital analytics framework and business analytics. There is a clear distinction between web analytics, mobile web analytics, and mobile app analytics. Mobile app analytics differs from traditional web analytics in several ways. First, mobile apps are characterized by a significantly higher level of hardware integration. Some even interact with other applications, allowing you to collect data about these interactions to identify bugs and compatibility issues. While maintaining full compatibility between hardware and app-to-app can be time-consuming, analyzing mobile applications can also help you determine which areas of compatibility are most important to users.

In addition, mobile apps will not have the analytics of inbound links and search engine traffic analysis. Traditional websites generate a lot of search engine traffic and inbound link data, but users don't land on mobile apps with search queries and must manually launch the app from the device.

Mobile app analytics also has richer data on device types and OS versions. The user's device type and operating system are not decisive for the website. Often, developers need to ensure that websites are responsive and run in the most popular browsers. With mobile apps, on the other hand, the operating system and device type have a major impact on how the app works (or whether it can be installed).[4]

Additionally, web analytics focuses on page view metrics, which in turn focus on metrics related to behaviour, user groups, sessions, interaction frequency, and user interaction with ads. Whereas, mobile app analytics generates more data to understand user behaviour. Mobile app analytics metrics focus on user location, downloads and installs, registrations, interaction windows, interaction time, financial components, and more.[5]

But just as digital analytics is not marketing analytics, mobile app analytics has its own differences. While mobile application analytics, such as marketing analytics, are used to achieve business goals, these processes differ significantly in how they accomplish this.

Mobile app analytics only focuses on apps. Mobile apps collect data about user events from multiple sources. The purpose of data collection is to provide decision-makers with information about the application and ways to improve the application to increase sales or utility.

Marketing analytics, on the other hand, checks whether a marketing campaign is successful or not. The process involves gathering data from multiple marketing channels. The goal of marketing analytics is to allow marketers to understand how and where marketing campaigns can be improved.

Mobile app analytics is also more complex than marketing analytics. For example, creating a marketing analytics funnel is easier because the user journey consists of fewer steps than a mobile app analytics funnel. Also, marketing analytics only focuses on the first few stages of the user journey, such as B. conversion and purchase, while mobile app analytics looks at the different possible stages of the journey. Additionally, mobile app analytics use sensitive user information, while marketing analytics using publicly available data. Sensitive data in mobile application analytics may include customer names, surnames, email addresses, physical addresses, and phone numbers. On the other hand, the data collected through marketing analytics is openly available to the public. [6]

In general, mobile app analytics is an analytical process of developing and researching apps based on collected user data for improving and retaining existing users. The purpose of mobile application analytics is to support decision-making at the operational, tactical and strategic levels and at all levels of the organization - design, creative, programming, marketing, user research, finance, etc. Mobile app analysis is an important source of business analysis in application development and considers the mobile application itself as a product and the business that develops and supports that product.

Analyzing a mobile application has two main goals: finding bottlenecks in the application and finding growth points. Former Hewlett Packard CEO Carly Fiorina said at the 2004 "Information: the currency of the digital age" conference that the goal of mobile app analytics is to turn data into information and information into insight.

The mobile app analytics process follows the standard process used in data-driven analytics. The analysis process consists of several phases/steps that are fundamentally cyclical in nature, meaning that the result of an analysis cycle can be fed into the next cycle. This is one of the ways of continuous optimization. The process of analysing a mobile application is shown in Figure 1.

Fig. 1 Mobile app analysis process

Defining attributes or setting goals. The first step in the process is to define goals and requirements. During this step, the user attributes to be tracked are selected, as well as the tracking strategy (event, frequency, or trigger). Domains for each attribute and goals for each domain are defined. This phase balances the predefined metrics and outcomes with the requirement to be able to explore and drill down cross- and end-to-end across future data sets.

Data collection. When the attribute set is defined, it is implemented in the data collection systems used by the enterprise.

Data pre-processing. During this step, the input data is transformed and loaded into the database structure, from where it is available for analysis. In addition, the data is cleaned and prepared for analysis.

Development of indicators. After preprocessing, the attribute data is converted into variables/functions and indicators.

Analysis and evaluation. During this step, KPIs are selected according to the requirements of the analysis. The selected analysis is performed and a model is created based on the results. In addition, the results are evaluated and it is checked whether the model achieves the set goals.

Visualization. The results are visualized in a way that is functional, taking into account the stakeholders they are aimed at, following the principles of visualization.

Reporting. Presenting the results of the analysis to stakeholders. The report/presentation should be made in such a way that stakeholders can understand, interpret the result and act on the conclusions.

Experimentation and testing. At this stage, changes are made and the conclusions drawn at the previous stage are tested for effectiveness and clarity for the target audience, which is the beginning of a new cycle.

The main method of collecting analytical data in a mobile application is a software development kit or SDK. An SDK is a software library that developers insert into the application code. It helps to track and record data.

At some point, the application needs to collect personal information from the user. Therefore, data protection and security are top priorities. Because violations of data protection regulations not only damage the trust of users, but also lead to significant financial consequences in the form of fines and lawsuits. This is especially dangerous when dealing with financial data such as bank accounts and credit card numbers. For example, the European Union has a General Data Protection Regulation (GDPR) that regulates data protection not only for web versions (websites), but also for mobile and gaming applications. Implementing a data governance policy (a set of

data handling rules, processes and systems that promote security and confidentiality) can help reduce the risk of information leakage. One of the most important methods here is anonymization, which removes all information that could be used to identify the owner of the data.

As for the key performance indicators, there is a certain classification formed by Mellon (2009), which is defined by the following categories:

User metrics or "player metrics"

These are indicators that are analysed from a dual perspective when they are either customers, i.e. sources of revenue, or players who behave in a particular way when interacting with the product. This distinction is used when calculating revenue-related metrics such as average revenue per user (ARPU), and daily active users (DAU), or when analysing churn, customer support efficiency, and microtransactions. This distinction is also used to study how users interact with the system and its components, as well as with other users.

Performance or productivity measures

These are indicators related to the performance of the hardware and software infrastructure. General performance metrics include the frame rate at which the application is updated on the client's hardware platform or, in the case of a game, the server.[3] Performance metrics are also used when monitoring feature variables or the impact of patches and updates. Performance metrics are widely used in QA to monitor health. It is also one of the most mature areas of analytics, as the methods used are derived from traditional software and QA techniques.

Process metrics.

These are metrics related to the actual development process. Development is a creative process that, like other creative fields, requires the use of agile methods. In turn, this leads to the development of ways to monitor and measure the development

process. Similar to performance indicators, a number of process indicators and related management and monitoring methods are adopted and/or adapted from methods used outside the games and apps sector. [3] Within this category, there are five key roles for analysis in development:

Product viability A variety of tools can test product

concepts, helping developers test, learn, adjust, and retest to speed up the product development and launch process.

Informed product decision-making. The analysis makes

decision-making more objective, reliable, and faster.

Measuring product progress. The analysis provides

information to team members about which features are working and which are not. Analysis plays a crucial role in creating a roadmap for the application.

Data on user interaction. Product teams can use analytics

to understand why users buy their product and how they use it.

Insights. Analytics can drive innovation and help an

existing product remain viable over a long period of time. Quantitative analysis methods are used in conjunction with qualitative methods to provide a more holistic view of the app and help product management teams make targeted improvements and adjustments that will help maintain value and increase longevity.

In general, the analysis process within a mobile application is as follows:

Early releases

This is the stage at which the implementation of your own analytical system begins. During the first few releases of the app, all that happens on the analytics side is collecting feedback and fixing bugs. At this stage, the viability of the product is analyses

and the main indicators collected are downloads, retention rates, etc.

Audience growth

The main goal of this stage is to attract users. At this stage, there is a need to have an established analytical system that is integrated with the product. The analytical platform should collect data on all traffic sources and provide tools for evaluating such indicators as CPI (cost per app install), number of attracted users, retention rate, cost per acquisition, ROI (return on investment), etc.

In addition, this stage analyses how well and how quickly users are ready to perform targeted actions. So, several target actions are selected, such as following step-by-step instructions, setting up a profile, making the first payment, etc., and the path to them is analysed.

Another task at this stage is to identify the steps with the highest churn rate in the funnel. At this stage of product development, it is quite easy to find problem areas and fix them.

Stable audience size

This is the stage of improving user understanding, and increasing conversions, and retention rates. On the analytical side, special events and a comprehensive analytics system are mandatory at this stage. These two tools can be used to solve the main problem of this stage - a sharp drop or increase in metric groups. So, at this stage, basic segmentation, the use of funnels, the study of user flows, and the detailed study of special events and each user take place. At this stage, the audience is large enough to launch A/B testing and get statistically significant results.

Growth of requests

This is the stage when dashboards containing the main indicators are formed. These can be the following dashboards: KPIs, promotion reports, statistics on the use of product

functionality and stability, data on traffic sources, real-time metrics, and financial indicators.

Personalisation

This stage is quite complicated, as the audience is segmented and each segment is handled separately. The parameters used are basic information (OS, country, device, etc.), the total number of days spent in the mobile application (engagement time), frequency of visits, payments and their total amount, user ratings, available features, days without payments, etc. In addition, segmentation provides a clear picture of which segments exist and the number of users they include.

Forecasting

At this stage, churn rate, payment probability, and completion of the target action are forecasted, but most often LTV (lifetime value of the customer) is forecasted. Machine learning is used for more accurate forecasts. The results are much more accurate, but there are several limitations: to build a model, you need a year's worth of data (current or historical) and full integration that includes special events.

Since every business, like a mobile app, is different, different data is needed to make the best decisions. Understanding your needs and short- and long-term goals helps you focus on one or more mobile analytics options, namely:

Mobile advertising analytics

Monetisation analytics

Today, many businesses offer apps for free download and generate revenue through monetisation through advertising, an in- app premium currency for real money, in-app store creation, and streaming media rental.

Performance analysis

Analytics of interaction in the app [7]

Mobile app analysis goes beyond traditional methods of analysis and analytics. It combines three different types of

analytical methods to provide a holistic picture of user behaviour: quantitative, qualitative, and technical analytics.

While all of these methods individually provide useful information, combining them improves the quality of the data obtained.

Quantitative analysis methods deal with aggregate data. The most common way to perform the quantitative analysis is to group a data object, such as users or sessions, by several attributes. Once the relevant attributes have been identified, the segmented data can be organised in a variety of structured formats. There are three main methods:

Session and user analytics. This method looks at a wide

range of details, combining technical information with demographic data.

Funnel analysis. Funnels break down the user journey into

key steps that users need to take to reach the end goal. Most funnels only work in conjunction with special event analytics.

Individual event verification. This method differs from the

classic metrics and allows you to analyse specific user journeys and explore new aspects of the application.

Session research. This method combines quantitative data

points to get a complete picture of the sessions that take place in a mobile application. By analysing these metrics over time, you can identify trends and draw conclusions about specific cohorts.

Technical analytics are especially important in the case of mobile applications and include crash analytics and user interface freeze analytics:

Crash analytics. This method displays technical issues that

can hurt the customer experience and decipher the drop in the defined funnel.

UI freeze analytics or problem analysis. This method goes

beyond crash analysis and investigates the issues that cause crashes.

Qualitative analysis is known for usability testing and user feedback. While these methods can be useful, they are not able to provide comprehensive information about what users are doing or thinking they are doing in the application. When combined with data visualisation, qualitative analysis methods can be easily interpreted. The main methods used are:

Voice of Customer (VoC) research. This method takes into account the opinions of customers about the mobile application and is based on its perception. It is useful for getting feedback and understanding how users talk about the product.

Heat maps based on gestures. Heat maps visualise how users interact with an app. Tracking gestures (e.g., double tap, long tap, angry tap, etc.) can be useful for understanding customer needs and avoiding churn.

Session recording or session playback. This method allows you to view the user's work with the mobile application from start to finish.

Behavioural screen. Screen streams confirm the sequence of transitions, prove hypotheses, or show unexpected ways users use the app to achieve their goals.[5]

Mobile apps evolve with feedback. The teams building them need to know what their users are doing so they can improve the product. Mobile app analytics metrics are indicators of mobile app effectiveness: from how users find your app to what drives engagement, shares, or churn.

Mobile app metrics are critical because without them, businesses cannot determine the success of their apps. Businesses

without precise metrics are forced to rely on general metrics, such as total revenue or total downloads provided by an app store. These top-level metrics can obscure the fact that apps can lose money or lose users faster than they can attract them.

Because indicators do not exist in a vacuum, they are all interrelated and affect each other. When the value of one metric drops sharply, the others change too--some of them may go down, some of them may go up. So there is no perfect set of metrics, but there are some basic metrics that can help you analyze and understand how and where your application is performing.

Number of app installations

There are three main cycles that determine the number of downloads. The more users who download your app, the better. This is especially beneficial from a financial standpoint because the more users your product has, the more users are willing to pay and the more sales you can generate.

In addition, the growth of downloads will also drive new downloads, forming a cycle. The number of downloads affects an app's position in mobile app store search results. Therefore, the more downloads, the higher the ranking and the more users will download.

The second cycle is the viral cycle, where users share information about the product with others. So, the happier users the app has, the more people will recommend it to others and download it.

The third cycle is the acquisition cycle - when more users are added to the app as a result of traffic purchases, this process triggers the above cycles, and these users start paying, thus creating a budget for further traffic purchases.

From these cycles, it follows that there are two types of app installations:

Organic - when users find and download an app directly from the store;

Paid - when the developer pays to attract new users.

The first and second cycles have a greater impact on organic installs, as they lead to users finding and downloading the app better. In addition, organic downloads are influenced by a set of measures - ASO (App Store Optimization), which is responsible for the attractiveness of the page in the store and the speed of the user's search for the application. Working with ASO involves selecting an icon and screenshots, a concise and meaningful description, the right keywords and title, as well as the availability of localizations for different countries, and working with reviews. Properly selected elements ensure that the app is found by relevant queries and increases the number of installations.

As for paid traffic, the developer pays to get a new user. There are several types of traffic acquisition campaigns, for example, pay-per-impression, clicks, and installs.

Therefore, the following metrics are analysed when attracting users:

conversion for registration or purchase;

completion of a business-targeted action(s) in the app (browsing the store, following a tutorial, adding to favorites, etc.;

1st day return;

ARPU;

number of sessions per user;

time to first payment, etc.

You can start tracking these metrics in the first days after the user installs the app.

Over time, you can calculate such indicators as cumulative ARPU, LTV, and ROI. These indicators are necessary to make an

unambiguous conclusion about the effectiveness of the acquisition channel and estimate its payback period. But when comparing different channels, you need to use cohort analysis. It allows you to work with campaigns launched at different times and with different durations.

First session

The first session allows the user to understand whether it is worth using this application at all. Therefore, the main task of the developer is to make the first session as simple and useful as possible, to convey the essence of the product, to interest the user in further exploration of the functionality, and the analyst is to analyse these aspects. First-time user experience (FTUE) is a complex indicator that is studied at different stages of the user journey. The analysis begins with determining the retention of the 0th and 1st days.

Day 0 retention is the percentage of users who accessed the app for the second time 0-24 hours after the first visit.

Day 1 Retention is the percentage of users who logged into the app the next day.

The largest outflow of users occurs on the first day, and this is the first bottleneck. The analysis of this bottleneck begins with the statistics of the tutorial and the number of users who have reached the main functionality of the application. In the analysis of the first session, there is an indicator of the "aha moment" - this is the stage of the user journey where the user performed an action, which means that the user is likely to leave the application on the device. The aha moment demonstrates that the user has understood the app's functionality.

Similarly, you can study the FTPUE (First-Time Paying Users Experience) - the first payment session - to understand what makes a user buy something: what actions they take before going to the store and making a purchase, how they behave in the

store itself, whether they make an easy choice of what product they buy, and how long it takes to make the first payment.

Retention.

For a project to generate income, it must have paying users. For this audience to exist, new users must be interested in the project and return to it as often as possible. The Retention rate is responsible for returning to the app. It is calculated for cohorts on a certain day from the date of installation and shows what percentage of users logged into the app on the X day after its installation.

The largest outflow of users occurs in the first days after installation, then the rate of Retention drops, and those users who enter the app on the 20th-30th day are more likely to stay in it for a long time.

Retention is usually tracked on days 1, 7, and 28. The standard indicators are:

Day 1 retention - 40%.

Retention on the 7th day - 20%

Retention on the 28 th day - 10%.

The 1-day retention rate affects the retention rate of the following days, so this indicator requires a detailed analysis if it deviates from the standard. On the first day, you need to ensure that the user understands the product, its value, essence and benefits (this is called activation).

Retention on the 7th day shows whether users like the app.

In 28 days, the user should fully get used to the app, get used to it, and start using it with a certain frequency. Retention on the 28th day demonstrates whether an app or game can become a "habit" for a user.

Retention rates correlate depending on the type and genre of the app. For example, users check social networks every day, while taxi services are checked no more than a few times a week or a month.

Retention rates can be calculated both in terms of calendar days and by the hour. Hourly retention on the 1st day is the percentage of users who returned to the product within 24-48 hours of installation.

It's also worth segmenting retention rates when analysing by traffic source, country, platform, and other criteria, as the behaviour of users in different categories may differ.

There are four different types of retention, in addition to the above:

Rolling Retention - Rolling Retention on Day N shows the percentage of users who returned to the app on Day N after installation or later.[8]

Full Retention - Full Retention on day N shows the percentage of users who logged into the app every day until day N.

Return Retention - Return Retention on Day N shows the percentage of users who returned at least once in N days. .[8]

Bracket-Dependent Return Retention - Bracket-Dependent Return Retention on the Nth day is one of the options for return retention. To calculate this retention, an additional N parameter m is set, which limits the time range for users to return. In this case, the retention is calculated as the percentage of users who returned to the app within m-N days.

Analysts most often use Rolling Retention. At the same time, Rolling Retention is always higher or equal to the classic retention rate, as it takes into account users who visited not only on one particular day but also on the following days.

The recurring retention rate is recalculated every day since a user who has not visited the app for several days can use it, which will affect the retention of all previous days. The point of using recurring retention is to take into account users who haven't

actually left the app, so this return rate is useful for apps that aren't necessarily used every day.

Lifetime

Lifetime or LT is a metric that describes how long a user is active in a project on average. Moreover, activity does not mean daily visits, but the amount of time that has passed between the first and last launch of the application. Usually, Lifetime is calculated for cohorts, and the more time that has passed since the installation, the fewer users of that cohort continue to use the app. [9]

Several calculation options are used to calculate Lifetime, namely:

A cohort of users is taken and investigated when users stopped using the app, and then the average duration of the user's stay in the app is calculated. However, this method is not effective due to the bias and inability to draw qualitative conclusions from a single cohort. [9]

According to certain criteria, users return to the application. The period for which it can be assumed that the user has left the application is determined, it can be 7, 14, 30 or more days, usually a period of 1-2 weeks is used.

Calculate the integral of the Retention function. To do this, you need to find the Retention value for several days. It is desirable that the number of days is as large as possible since the accuracy of the calculated Lifetime depends on this.

When working with the Lifetime indicator, segmentation is used. It is used in two directions: standard segments - the type of country or device, as well as by the time spent in the application.

In addition, Lifetime is associated with Lifetime Value - an indicator that shows how much money a user brings in during his or her lifetime in the application (Lifetime).

Therefore, despite the fact that, at first glance, Lifetime is a non-financial indicator and has no financial component, it still

affects revenue, because the longer the user stays in the application, the more likely the user is to make a purchase.

The audience of the application: DAU / WAU / MAU

All users who have had at least one session during the study period are called Active Users. The period under study can be different, but most often the daily, weekly, and monthly audiences of the project are studied, while similar calculations can be made for any other periods:

DAU - the number of unique users per day (Daily Active Users);

WAU - the number of unique users per week (Weekly Active Users);

MAU - the number of unique users per month (Monthly Active Users). [10]

At the same time, WAU is not the sum of DAU for 7 days, as it refers to unique users. Similarly, MAU is not the sum of four WAUs and thirty DAUs. From the point of view of calculation, these indicators are not related to each other and are calculated separately.

In general, it is recommended to track Active Users in realtime, as in the event of a broken application/application component, this metric will be immediately affected.

For the category of active users who are currently in the application, the Users Online or CCU (Concurrent Users) metric is distinguished - users who are in the application at a certain moment, and PCCU (Peak Concurrent Users) - the maximum number of users who are simultaneously in the application.[11]

These indicators are also analysed by segments, namely:

By the frequency of payments.

By the period from the moment of installation.

According to the frequency of calls to the application/

There is also segmentation by country, device, operating system, and custom event. The use of segmentation helps to avoid a statistical anomaly - Simpson's paradox.

Average Session Length

The metric used to measure the length of time a user stays in an app is called Average Session Length, or it also goes by the names Session Duration, Session Length, or Visit Duration.

The principle of calculating this indicator differs from company to company, as some analytical reports consider the time of application activity as a session, while others consider it the difference between the time of the first and last action. Session interruption (automatic termination after a certain period of inactivity, in case of application closure or loss of activity) is also calculated differently. In addition, this metric is calculated as an arithmetic mean.

This metric has no correlation with revenue, but it can provide a qualitative assessment of the user experience and clarity of the interface and serves as an indicator for analysing the latest updates and their impact on the application.

Total Daily Play Time

Almost always, businesses are interested in getting users to use their product as often, as long as possible, and as much as possible. After all, the more time a user spends in an app, the more likely he or she is to pay or at least become an advocate for the app.

Total Daily Play Time is a metric that shows how much time a user spends in an app. To do this, divide the total duration of all sessions per day by the number of active users. As a result, we get data on how much time a user spends in the app on average.

This metric is similar to the average session length or Average Session Length. They differ in the denominator: Average Session Length is the number of sessions, and Total

Daily Play Time is the number of users. Despite the fact that the totals of these two metrics are quite different, the values themselves depend on the same factors (for example, game genre) that influence their use. In addition to calculating the time spent in an app, you can overlay it with various actions performed by users to better understand their behaviour.

Understanding how much time a user spends in the app and what they manage to do during this time, you can plan marketing activities with greater efficiency by linking them to the time spent in the app rather than to the day.

Like other behavioural metrics related to sessions, Total Daily Play Time does not directly affect revenue and depends primarily on the genre and features of the application.

However, tracking this indicator gives an impetus to the analysis of other metrics and the search for answers to questions: "Why did the user start spending less time in the app?".

Sticky Factor

The interest, loyalty, and degree of user engagement are characterised by several metrics, one of which is the Stickiness Factor, an indicator that allows you to assess the regularity of app visits and the stability of the user base. The sticky factor also shows how likely a newly attracted user is to stay in the app, and how much the product is able to retain the user.

It is usually calculated as the ratio of the number of unique users per day to unique users per month. This indicator usually depends on the genre and purpose of the app. Thus, for games, a Sticky factor of about 20% is considered good, and for social networks and messengers - about 50%. [12]

The sticky Factor is not directly related to revenue, but it characterises the loyalty and activity of the audience, which in turn affects monetisation and revenue, as the more stable and interested the user base is, the faster the product audience is formed and grows, and the larger it is, the more payments users

make. At the same time, there is a correlation between Sticky Factor and revenue (it is about 50-60%), but correlation does not mean causation, and both the Sticky Factor and monetisation metrics are a reflection of user loyalty.

Funnels

In order to study user behaviour in the application, understand how they see it, find bottlenecks, find out at what steps users "fall off", and optimise processes within the application, you can use such a tool as Conversion Funnels.

A conversion funnel consists of a sequence of user actions and shows how many unique users performed each of the events.

Thus, the funnel shows the conversion between steps (the ratio of users at step N to users at step N-1), allowing you to identify bottlenecks where this conversion drops more than at other steps, i.e. where the greatest user churn occurs.

Once you have the funnel results, you can identify the weaknesses with the lowest conversion, then make changes and build the funnel again to see how the changes affected the conversion.

When analysing the results of a funnel, you can also calculate the total conversion from the first step to the last, as experiments can result in an increase in conversion at one step but a decrease in the next. Therefore, when optimising funnel steps, it is worth tracking the conversions of all steps, not just the one you are working on. Also, when analysing funnels, you can apply different segments to them.

With the help of a funnel, you can study completely different processes in the application, you can evaluate the effectiveness of email campaigns, compare traffic sources, evaluate the passage of users through stages or levels of the game and any other processes in the application that affect monetisation and user engagement.

Paying Conversion

Conversion is the percentage of users who have performed any targeted action. This action can be clicking the "Register" button on the landing page, following an advertising link, or making a payment.

The peculiarity of calculating this indicator is that it is calculated for a cohort, i.e., a group of users who have installed the app in a certain period. Thus, conversion to payment is the percentage of users who made a purchase out of those who installed the app.

Conversion has a direct impact on revenue, which means that by increasing the number of conversions, the number of users making payments increases, which leads to an increase in revenue.

However, if an increase in conversion comes at the expense of a decrease in the average user check (or product price), the result can be negative. This is an important aspect to consider when conducting marketing activities and promotions. There is no direct correlation between price cuts and revenue growth.

Conversion analysis can be expanded by using some additional approaches in the analysis:

Separation of payments. Conversion should be calculated not for all payments, but separately for the first and repeated payments, which will give a better understanding of user behaviour in the product. In this case, the conversion to repeat payment is the percentage of users who made more than one payment during the analysed period. Finding patterns in the context of the frequency of payments helps to plan marketing activities, increasing the likelihood of making the next payment.

In addition, if there are any stages in the application, it is worth considering the moment of the first (or any other) payment in the context of these stages. Such a breakdown may be relevant for gaming apps that have levels, as well as educational or fitness apps where the user's progress can be divided into separate steps.

Comparison of cohorts. Conversion rates can be calculated per cohort, and this feature should be used to track its changes over time for a certain group of users, as well as to compare different cohorts with each other. This analysis helps when conducting experiments - you can evaluate how changes affected the conversion of cohorts formed before and after these changes.

Paying Users and their share of the total audience (Paying Share)

Paying Users is a quantitative metric that equals the number of users who make a payment in a certain period. The more such users an app has, the better. Users who have paid money show their loyalty to the product and are more likely to return to the app.

Separately, from the total number of payers, it is worth distinguishing users who made their first payment (New Paying Users), since after the first payment, repeated payments usually occur, which often bring in most of the revenue.

Paying Users is an absolute value, and its growth or decline depends on various factors. An increase in the number of paying users does not always lead to an increase in revenue (for example, their number has started to grow, but the amount of payments has decreased). For revenue, as well as for other quantitative indicators, there is a relative metric that shows what percentage of users out of the entire active audience make payments in the app. For paying users, this is the share of the total audience (Paying Share or Paying Users Rate). This value depends on the type of application, but most often it is around 1-2%. It is believed that the median Paying Users rate in mobile f2p games is 1%, which means that the vast majority of the audience usually does not pay. When analysing these two metrics, it is worth paying attention to related indicators, for example, ARPPU, because the number of paying users may grow, while the revenue may fall. Or the share

of those who pay may fall, but due to the growth of the average check, this will have a positive impact on revenue.

The issue of audience segmentation in the context of paying users lies in the types of behaviour of these players, namely:

Segmentation by the total amount of payments.

Segmentation by the number of payments;

Segmentation by the time of payment;

Segmentation by time since the application was installed.

RFM analysis

There is another tool for segmenting paying users - RFM analysis. It divides users into certain groups depending on the recency, frequency, and total amount of their payments.

Usually, the task of such analysis is to study user behaviour and how they make payments in order to make more relevant offers to each of the selected groups formed by three criteria.

Recency - the difference between the current date and the date of the last payment made by the user;

Frequency - the number of transactions made by the user during the period under study;

Monetary - the amount of the user's purchases for the same period under study.

All three of these indicators are calculated separately for each user for the selected period, after which they should be rated according to each of the three criteria.

The range of scores can be different: 1-3, 1-4, 1-5, and so on. The wider the range, the more groups you will get, and the more "sensitive" and accurate the indicators will be, but at the same time, the more difficult it will be to work with them due to the wide variety of combinations.

The purpose of RFM analysis and segmentation is to influence users in a certain way depending on their payment behaviour. As a result of these actions, you can improve retention

by returning to the project those users who pay but are no longer active, you can increase revenue by converting users who have made one payment, thus preventing the outflow of loyal users.

Consumer Basket and purchase structure

In the process of using the application, users purchase various products to facilitate further progression through the game, to access the main content or to obtain some unique content. This is analysed in the context of the Consumer Basket metric.

The term "consumer basket" is used in various fields (most often in economics). It refers to a set of goods and services that are purchased on average by one user over a certain period of time.

The composition and value of the consumer basket can be adjusted in various ways, so it is not enough to simply calculate these indicators, it is important to track their changes over time.

Knowing what products the user has at the first level, you can understand what is most in demand and at what time, what products/currencies the user has in excess, and what is missing, and offer a relevant promotion based on this.

Another option for analysing the purchase structure is ABC/XYZ analysis. Its task is to identify those products that bring the most profit to the project and then increase their share among the purchased products.

ABC analysis divides products into groups depending on their contribution to the total income among all purchased products. XYZ analysis characterises the stability of demand by the coefficient of variation and forecasting accuracy. After dividing all products into ABC and XYZ groups, they are combined into one table.

Often, the task of analysing user purchases is to identify combinations of purchased goods, especially if it is not a game but any online or offline store. In this case, it is additionally

worth analysing the set of products purchased by the user within one purchase. Knowing the most popular combinations, you can change the location of products or the order in which they are displayed in the store, make discounts on related products, make the desired products more visible, or remove certain products from sale. In addition, this information will allow you to conduct personalised promotions for related products, push notifications, and email campaigns to increase the average checkout.

Average revenue per user (ARPU)

ARPU is one of the most important and popular monetisation indicators. It is used to compare the effectiveness of projects.[13]

ARPU (Average Revenue Per User) is the income that one user of an application generates on average over a certain period of time. To calculate ARPU, you need to divide the revenue for the selected period by the active audience. You can also often find such a metric as ARPDAU or Average Revenue Per Daily Active User. This is the same ARPU, but calculated per day, that is, the revenue of one day is divided by the number of active users of that day (DAU). Similarly, ARPMAU (Average Revenue Per Monthly Active User) can be calculated by dividing the monthly revenue by the product's MAU.

ARPU is one of the key indicators of monetisation efficiency and directly affects revenue. Accordingly, the higher the ARPU, the higher the revenue of the application. It also follows that ARPU is an effective metric for evaluating changes made to the app and various experiments, as it takes into account both paying and non-paying users and contains two additional parameters at once, which greatly simplifies the analysis.

ARPU is used to analyse:

pricing experiments;

traffic;

segment comparison.

Average revenue per paying user (ARPPU)

ARPPU (Average Revenue Per Paying User) is the average revenue generated by a user who has made at least one payment over a certain period of time. It characterises the reaction of paying users to the value of the project.

ARPPU is calculated using the following formula: the ratio of revenue to the number of paying users. When calculating ARPPU, it is important to take into account the period under study. Users can make repeated payments during the month, but the monthly ARPPU will not be equal to the sum of the daily ones, since the divisor (users paying for the month) will not be the sum of users who paid by day, but the number of unique users paying for the month. [14]

Unlike ARPU, this metric does not take into account users who have not paid anything, and therefore, ARPPU is always significantly higher than ARPU.

Like ARPU, ARPPU has a direct impact on revenue. ARPPU is a very good indicator of repeat payments, as they do not increase the number of payers, but increase revenue.

Another metric close to ARPPU, which is also used to evaluate payments by paying users, is the Average Check, or Revenue Per Transaction - the average check, the average transaction value, or the arithmetic mean of all payments made. The difference between this metric and ARPPU is that it measures the average revenue not from one paying user, but from one transaction, and does not take into account the number of users who made these payments.

The difference from ARPPU is that if one paying user makes a repeat payment, the denominator in ARPPU will not change, but the number of transactions will increase, and this will affect the size of the average check. [15]

Cumulative ARPU (Cumulative revenue per user)

Cumulative ARPU (or CARPU) is another derivative metric that is useful for assessing traffic quality and choosing the optimal CPI indicator.

This indicator is calculated in the same way as regular ARPU - by dividing the income by the audience, and its difference is that it is calculated not for the entire audience, but only for a certain cohort of users, and this cohort is formed from users who have installed the application in a certain period.

The cumulative ARPU of the Nth day for a certain cohort is equal to the revenue generated by this cohort for N days divided by the number of users in this cohort. [16] However, its growth may stop at some point. This will be caused by the fact that users of the cohort will stop paying or using the product at all. This level of CARPU, when the metric stops growing, can be considered Lifetime value (LTV or CLV) - the average revenue per user for the entire time of their life in the project.

Lifetime value

In fact, LTV is a cumulative ARPU that has reached a certain constant value. That is, it is a certain average income that one user gradually brings to the application. LTV directly affects the revenue, because the more money one user brings to the project, the higher the total revenue. When working with LTV, it makes sense to analyse this indicator in the context of different segments, as users behave and pay differently.

One of the most common ways to use this metric is to evaluate purchased traffic. LTV gives you an understanding of how much one user will pay for their entire life in the project. Therefore, when purchasing traffic, you should pay attention to the fact that the cost of attracting a user (Customer Acquisition Cost, or CAC) should be less than its LTV, otherwise, buying such traffic will only bring losses.

Moreover, using Lifetime Value, you can find out when a user will recoup the cost of his or her acquisition. This will happen when LTV equals CAC.