Как се чете прегледът на метода на доживотна стойност

стойност

Въпросът за изчисляването на стойността през целия живот (известен още като LTV, стойността на живота на клиента, CLV) рано или късно възниква пред разработчиците на мобилни (и не само) приложения. Има много методи за изчисляване и има толкова много хора, колкото и мнения за това как да се изчисли LTV. В тази статия реших да опиша най-често срещаните методи, да очертая техните плюсове и минуси. Тези методи са подходящи преди всичко за описване на модела f2p.

1. След факта
Този метод се откроява от всички следващи, тъй като не симулира LTV и не го предвижда, а изчислява действителния LTV.
За този метод трябва да вземете кохорта потребители, които вече определено са напуснали проекта, да видите колко пари е донесла цялата тази кохорта, след което да разделите тази сума на размера на кохортата. Желателно е потребителите да се регистрират по едно и също време (за един месец или по-добре - за един ден).
На практика обаче този метод е слабо приложим, тъй като със сигурност ще има поне един човек от кохортата, който все още е активен, независимо колко дълго е регистрирана кохортата. Следователно на практика LTV се симулира, а не се изчислява в действителност. И всички следващи методи точно ще симулират бъдещия LTV, а не ще оценяват миналото.

2. Вземете всичко и разделете, или метода на Шариков

метода

Най-бързият, но груб метод. Вземаме всички приходи от приложението за период и разделяме на общия брой потребители за същия период.

Плюс този метод има само един: той се изчислява доста бързо, буквално в едно действие.

Минус се крие в очевидната неточност на метода, която може да се дължи например на следните причини:

  1. доходите от тези потребители, които вече са се активирали (натиснете знаменателя), но все още не са успели да донесат доходи (които биха попаднали в числителя), не се вземат предвид;
  2. изчислението включва стойностите на показателите на приложението от самото начало на живота му; не забравяйте, че приложенията имат свой собствен жизнен цикъл и като правило в началото на техния жизнен цикъл производителността е по-добра от известно време след това (прочетете отлично проучване от GameAnalytics за това). При един и същ метод се комбинират всички етапи от живота на приложението.
  3. също така при този метод е трудно да се изчисли LTV поотделно за всеки потребителски сегмент, за това трябва предварително да знаете размера на сегмента и количеството пари, донесени от потребителите на този сегмент.

3. Живот по прост начин
Ако знаем колко дни средно живее потребителят в приложението и колко пари носи средно на ден от живота си, тогава можем да изчислим колко пари ще донесе през целия си живот в приложението. И това е нашата LTV. Формулата за този метод е:

Тогава възниква въпросът как да броим живота. Има два метода, а първият е просто изчисление (както може би сте забелязали от заглавието):
1) Определяме определен период на бездействие, т.е. времето, след което потребителят най-вероятно няма да се върне в приложението. Това се определя или въз основа на стойностите на задържане, или по-често експертно. Обикновено, експертно, тази стойност се задава равна на една или две седмици.
2) Всеки ден разглеждаме потребители, чийто срок на валидност е изтекъл в този конкретен ден.
3) За всеки потребител изчислете броя дни от първото му посещение до текущия ден.
4) Изчислете средната стойност за всички потребители. Това е цял живот.

Е, ARPU (в този случай ARPU = ARPDAU) се изчислява като дневен приход, разделен на DAU. Умножете живота по ARPU и вземете LTV.

професионалисти метод:

  1. Простота на изчисленията. По този начин е лесно да се изчисли живота, още по-лесно е да се изчисли ARPU. И всеки ученик може да умножава един по друг.
  2. Можете да изчислявате LTV дори всеки ден.
  3. LTV може да се изчисли за всеки потребителски сегмент поотделно.

Минуси отново се състоят в неточност, която в този случай се дължи на следните причини:

  1. Стойността силно зависи от периода на бездействие, който обикновено се определя от експерти.
  2. Умножаваме средния живот по средния ARPU, за да получим натрупаната грешка.
  3. Когато изчисляваме живота, разглеждаме онези потребители, които вече са напуснали приложението. Когато изчисляваме ARPU, ние разглеждаме потребителите на текущия ден. Оказва се, че наборите от потребители, които формират продължителността на живота и ARPU, не се пресичат: животът се изчислява според данните от предходни дни, ARPU - според текущия ден.
  4. Силно предположение за непроменен ARPU. Взимаме ARPU само за един ден и въз основа на него предсказваме LTV много дни предварително.