Predictions

LTV Forecast

This tool gives you a fairly precise LTV forecast powered by Machine Learning. Training data for the machine learning algorithms are payments and other activities of users who use your app for at least 3 days. Later on, after we acquire more data about cohorts, the model is recalculated and the forecast accuracy improves even more. It happens on the 7th and 10th days of the cohort’s ‘life’ in the app. We calculate user LTV on their 7, 14, 30, and 60 days since app install.

Why use LTV:

• Traffic quality evaluation. When purchasing traffic, it should be considered that you need to keep the cost per install (CPI) less than LTV, otherwise purchasing such traffic will only lead to losses.

• Finding out the exact time when you will recoup acquisition costs.

• Finding out how much revenue you will earn from existing users and planning your budget

Requesting the report

By default, the functionality is available for all apps. If you would like to get a report, navigate to your project, click the ‘Forecast’ tab, open the ‘LTV Forecast’ report, and request model building. Notice that if you want us to build an accurate model, your app has to meet certain requirements:

• The app is integrated with devtodev for at least 90 days.

• The MAU is 30k or more

• Payment events are integrated.

• Custom events are integrated.

LTV forecast for day 360

After your D7, D14, D30 and D60 LTV models have been run for 390 days for a particular project, you will get access to an LTV forecast for day 360. The forecast results will be displayed on all report tabs automatically.

If you have just connected a new project to devtodev and would like to get a day 360 LTV forecast, you need to request us for building of a model as described above and wait for a year. This delay is due to the fact that we need to collect one year of data about the project for generating a more accurate yearly forecast.

Or, if you have historical data for more than 390 days, you can upload it to devtodev using this instruction. Then, we can use the data to train our LTV forecasting model (and to build a forecast for day 360).

Please note that if you choose to follow this path, you need to inform us about your wish to receive a day 360 forecast before completing the process of historical data import. Contact your manager using the ‘Contact Us’ form on the devtodev website or via email - [email protected].

By days from install

In the top right corner, you need to specify a date range. It will limit the dates of users’ first visit to the app (keep in mind that we can calculate LTV only after three days since install, so the latest three calendar days will be unavailable). The chart below represents revenue per average active user after 1, 2, ..., N days from the first visit (Predicted LTV) and the amount of money they have brought in till now (Actual LTV). For the Actual LTV calculation, we take into account only the income earned for the number of days all the selected cohorts have ‘lived’ in the app. Therefore, when on the 31st day you build a report on users acquired from the 1st to the 10th day, you get the Actual LTV data for 20 days because the cohort that came to the project on the 10th day has ‘lived’ for 20 days only.

‘Overview’ above the graph and the table below it display the traffic sources, the amount of money spent on their acquisition, the income earned, and the expected total revenue from all the cohorts after 60 days in the project. In case you need to select only a specific user segment, you can apply a wide range of filters on each report page, and build the LTV forecast only for your target audience.

By calendar dates

The second page of the report shows how the Predicted LTV metrics are changing over time. Here for any selected N-days Predicted LTV metric you can see the deviation between the Predicted LTV and the Actual LTV for every cohort according to their install dates.

For the latest N-days, we can’t calculate the actual LTV, so we use gray candlesticks to show predicted data and the dashed blue line to show the actual data.

When you move the pointer over a cohort, you can see the intervals of predicted lifetime values (from min to max), and the actual LTV.

Detailed stats

The third ‘Detailed stats’ page is represented by a table that shows all the necessary information about your traffic and its profitability. For every group in the table, you can see the actual and predicted N-days LTV and the ROI for N-days. Data can be grouped using up to three levels by Countries, Sources, Channels, Campaigns, Platforms, and Languages. For example, if you want to see the progress of your Ad campaigns in terms of traffic sources and then examine how well it goes in every country, you can set Group by Campaigns, Sources, and then by Countries in the report settings. Keep in mind that the more groupings you choose, the fewer users you will have in each group and the less precise your forecast becomes.

The table can be exported as a .csv file by clicking the ‘Export’ button in the top right corner.

Payment prediction

devtodev uses Machine Learning algorithms to identify paying users before they make their first payment. We predict payment behavior of each individual user and assign them a value from 0 to 1, where 0 - the user will not pay, 1 - the user will make a payment sometime in the future. Based on these values, users are automatically divided into groups: - will pay - more likely to pay - more likely not to pay - won’t pay not yet defined (the user is completely new and the probability is still being calculated).

In the user card, you can find this information in the ‘Predicted paying status’ field.

The ‘Predicted paying status’ field can be used in reports as a filter, for creating segments, or for sending push notifications.

In the ‘Predictions’ section in the top menu you can find a ‘ Paying status prediction’ report that contains statistics on the probability of making a payment by new users.

The users who installed the app during a certain period of time are grouped by the probability of making a payment: will pay, more likely to pay, more likely not to pay, won’t pay.

The data for the same period may change over time because the predictive model is real-time and is regularly recalculated. The forecast on a user may be adjusted and the user gets moved into another segment.

Click a segment on the chart or in the table and open a menu with the following actions:

• Create segment (use a certain user group to build a segment for further analysis by using other reports)

• Export to CSV (export user data)

• Send push notification

• Create cohort for export (send an audience to Google Ads or Facebook to set up targeting for your ad campaigns).

The model is calculated on the basis of data obtained by the first, third, and seventh days since installation and it takes into account user actions in the application. After recalculation, the user’s status may change because the algorithms have processed more user behavior data. The forecast is automatically enabled for projects that meet the following conditions:

• There are 90 days of data During the 90 days, the basic and custom events (including the payment event) were sent

• The number of paying users is at least 1 per every 10,000 active users

• The average DAU is at least 300 At least one payment is made every 3 days