Jakie wskaźniki badać w trakcie Soft Launchu aplikacji mobilnej?

Zawartość posta

Jak zlokalizować problemy na etapie tzw. Soft Launchu?

Gdy prowadzę konsultacje analityczne z developerami gier lub aplikacji mobilnych na etapie *Soft Launchu , często słyszę następujące stwierdzenie: „Nie ma czasu wszystkiego tłumaczyć, kupmy po prostu więcej ruchu”. Po publikacji gry lub jej nowej wersji, istotną kwestią jest kontrolować odpowiednie wskaźniki. Z doświadczenia wiem, developerzy dość często patrzą na nieodpowiednie wskaźniki lub oczekują niezwykle wysokich wyników, co przekłada się na złe decyzje.
W tym artykule, Vasiliy Sabirov, główny analityk w devtodev, podzieli się z Wami wiedzą o wskaźnikach natychmiastowych – wskaźnikach, które można analizować już w kilka dni po publikacji gry lub aplikacji mobilnej.

Wskaźniki dnia pierwszego

Prawdopodobnie najważniejszym oraz najbardziej popularnym wskaźnikiem na tym etapie jest Retencja dnia 1. Jest ona podana w każdym systemie analitycznym dostępnym na rynku. Pokazuje ona ułamek użytkowników, którzy powracają do aplikacji dzień po instalacji. Dopóki ten wskaźnik opisuje pierwsze wrażenie użytkowników na grę, by zwiększyć jego wartość należy zwrócić uwagę na pierwszą sesję i szeroko pojęty styl graficzny projektu. Jest w zasadzie wiele materiałów poświęconych retencji dnia pierwszego, więc proponuję, żebyśmy przeszli do mniej oklepanych, a wciąż bardzo użytecznych wskaźników.

Porównanie retencji dnia 1 oraz dnia 7 w devtodev

Zajmowaliście się kiedykolwiek retencją dnia zerowego w aplikacji mobilnej? To nie żart – nie wynosi ona z reguły 100%. Wskaźnik ten opisuje ułamek graczy, którzy powracają w ciągu 24 godzin od instalacji. Można ją obliczyć nawet szybciej niż retencję dnia pierwszego, przez co jest ona bardzo użyteczna, gdy trzeba szybko połapać się w sytuacji podczas Soft Launchu gry lub aplikacji mobilnej. Można oszacować, że w udanych projektach retencja dnia zerowego wynosi 60 do 70%.
Wiele gier zaczyna się samouczkiem, który można analizować wieloma ciekawymi wskaźnikami. Na przykład retencją samouczka. Niezależnie od tego, ile minut/godzin/dni zajęło graczom ukończenie samouczka, pytanie brzmi, czy wrócili potem, by zagrać w grę. Wskaźnik ten ukazuje, jaka część graczy powiedziała: „Dobrze, samouczek za mną, rozumiem, o co chodzi w grze – teraz chcę zobaczyć, jak gra się w nią naprawdę”. Nie ma sensu, żebym podawał Wam dokładne statystyki tego wskaźnika, ponieważ jego wartość w dużej mierze uzależniona jest od typu gry – jednakże wskaźnik ten jest idealny do obserwowania efektywności nowych wersji gry, szczególnie po dokonaniu zmian w samouczku. W idealnym scenariuszu wartość ta powinna rosnąć z każdą nową wersją.
Kolejnym ważnym wskaźnikiem jest konwersja samouczka – część graczy, którzy ukończyli samouczek. Wskaźnik pomaga zobaczyć poziom skomplikowania Twojego samouczka i jak łatwy do zrozumienia jest on dla graczy. Developerzy aplikacji i gier mobilnych zazwyczaj oczekują tutaj wartości w granicach 70 do 80%, jednakże zależy to w dużej mierze od typu i stopnia skomplikowania gry.

Tak wygląda wskaźnik konwersji samouczka w devtodev można go obliczyć dla każdego okresu i każdego profilu użytkowników.

Zwróć uwagę na to, kto pominął tutorial, czyli na tzw. stopę pominięcia (Twój samouczek ma wbudowany przycisk „pomiń”, prawda?). Wysoka wartość tego wskaźnika to nie zawsze zły znak. Bywały w moim doświadczeniu sytuacje, w których duże zmiany w grze sprawiły, że wrócili do niej doświadczeni gracze, którzy oczywiście nie chcieli musieć na nowo przechodzić samouczka.

Raport „Dynamika samouczka” w devtodev pokazuje, ile czasu zajmuje graczom przejście samouczka i jaki procent graczy nigdy go nie przechodzi tudzież go pomija.

Gracze mogą tutaj 1) pominąć samouczek, 2) ukończyć samouczek lub 3) zacząć samouczek, lecz nigdy go nie skończyć. By móc przyjrzeć się ostatniej kategorii, polecam zbudowanie tzw. wykresu lejka podzielonego wg etapów samouczka, który pozwoli na zobaczenie, przy których częściach gracze wychodzą.

W raporcie „Dynamika Samouczka” można zdefiniować nawet do 120 kroków, co w zupełności wystarczy, by zlokalizować odpychające części samouczka.

Ostatnim wskaźnikiem analizy samouczka, którym się z Wami podzielę, to prędkość ukończenia samouczka. Bardzo ważne jest, aby pamiętać, że zawsze znajdą się gracze, którzy spędzą znacznie więcej czasu na samouczek, niż byś się spodziewał – tydzień, dwa tygodnie, nawet miesiąc. Jeżeli obliczylibyśmy średnią wartość, tacy gracze mieli by na nią ogromny wpływ. Dlatego w tym przypadku polecam wykorzystanie mediany.
To wcale nie jest prawda, że im szybciej gracze przechodzą samouczek, tym lepiej. Ten wskaźnik jest jednak bardzo przydatny podczas analizy dynamiki samouczka: w jaki sposób się zmienia w nowych wersjach. Zobaczysz, w jaki sposób gracze będą reagowali na zmiany w samouczku. Najlepiej jest analizować prędkość ukończenia samouczka i jej relację z konwersją samouczka naraz.
Po ukończeniu samouczka, gracze zaczynają grać w grę. Na tym etapie trudno o uniwersalne wskaźniki zachowania graczy – jednakże wiele gier opartych jest na poziomach (np. poziomach graczy lub poziomach gry), więc można tutaj mówić o procencie graczy, którzy osiągnęli poziom N. Jest to przydatny wskaźnik pozwalający na śledzenie zachowania użytkowników już na początku gry. Później będzie się również dało stworzyć wykresy pokazujące konwersję użytkownika na różnych poziomach. Takie „lejki” konwersyjne również pomagają na znalezienie tzw. „zatorów” (miejsc, w których wiele graczy opuszcza grę) oraz zwiększenie wartości retencji poprzez poprawianie mechaniki gry lub przesyłanie dobrze ukierunkowanych dodatków/ofert/wskazówek.

W devtodev, śledząc ruch w aplikacji można obliczyć procent użytkowników pochodzących z konkretnego źródła, którzy dotarli do poziomu N oraz wiele innych ważnych wskaźników.

Wskaźniki pierwszego tygodnia

Wszystkie wskaźniki podane powyżej pomogą Ci śledzić zachowanie użytkowników już pierwszego dnia po publikacji gry (lub jej nowej wersji). Jednakże żeby obliczyć niektóre wskaźniki potrzeba trochę więcej czasu. W większości są to wskaźniki dotyczące monetyzacji gry mobilnej.
Na tym etapie, wielu developerów aplikacji zaczyna korzystać z podstawowego ARPU (ARPDAU – Average Revenue Per Daily Active User). Uważam, że jest to błąd: ARPU obliczane jest jako dochody podzielone na widownię, lecz na początku istnienia gry struktura widowni dużo się zmienia. Dla przykładu, pewnego dnia kupujesz ruch i 80% Twoich użytkowników składa się z nowych graczy. Po tygodniu sytuacja może się zmienić, a widownia składać się głównie z dość doświadczonych graczy. W obu tych scenariuszach ARPDAU jest obliczone przy użyciu tego samego wzoru, lecz wykazuje inne wartości.
Z tego powodu polecam korzystanie ze zbiorczego ARPU dla N dni. Wskaźnik ten pokazuje, ile jeden użytkownik średnio wnosi do projektu podczas jego pierwszych N dni po pobraniu. Z reguły ten wskaźnik dyktuje funkcję logarytmiczną: na początku rośnie szybko, lecz w późniejszych fazach zwalnia. Ten wskaźnik jest idealny do mierzenia zmian w monetyzacji gry, gdyż ukazuje prawdziwe oblicze widowni i jej potencjału monetyzacyjnego.
Dodam jeszcze tylko, że gdy N zmierza ku nieskończoności, wskaźnik zmienia się w LTV.

W devtodev da się obliczyć, ile użytkownik przyniesie pieniędzy w ciągu jego pierwszych dni po pobraniu, a ile w ciągu całego zaangażowania w projekt.

Kolejnym wskaźnikiem ukazującym potencjał monetyzacyjny widowni jest konwersja pierwszej płatności. Można ją obliczyć na podstawie informacji z pierwszego tygodnia – pokazuje ona, jak skłonni użytkownicy są do płacenia. W idealnej sytuacji procent płacących użytkowników powinien rosnąć z każdą nową wersją.

Raport „Okres przed płatnością” w devtodev wskazuje, w jakim dniu oraz na jakich poziomach gracze dokonują swoich pierwszych/drugich/trzecich płatności.

Nie zapomnij jednak o retencji dnia 7 – procencie graczy, którzy powrócili do gry 7 dni po jej instalacji. Są to zazwyczaj gracze, którzy ukończyli już samouczek i zaczęli grać. W magicznym modelu 40-20-10 retencja dnia 7 znajduje się w środku, co oznacza, że 20% jest w tym wskaźniku dobrą wartością.
Na koniec wróćmy więc na sam początek. Kupiliśmy ruch dla naszej gry w fazie Soft Launchu. Sukces gry jest w dużej mierze uwarunkowany jej popularnością w sieci (ile graczy podzieli się nią ze znajomymi). Po tygodniu będziesz już w stanie obliczyć tzw. K-factor (wskaźnik popularności aplikacji) poprzez porównanie ilości płacących i niepłacących użytkowników w danym okresie. Im większy okres, tym bardziej dokładne rezultaty. Dlatego właśnie tydzień to minimalny okres, przy którym takie obliczenie ma sens.

Powiedzmy, że wykupiłeś 500 instalacji w pierwszym tygodniu i 300 graczy dotarło do Ciebie w sposób organiczny. Super! To znaczy, że zyskujesz 0.6 organicznych instalacji za każdą płatną.

W późniejszych etapach, gdy będziesz liczyć K-factor dla miesiąca lub jeszcze dłuższego okresu, polecam wzięcie liczby organicznych instalacji i podzielenie jej przez widownię w poprzednim okresie (nie liczbę płatnych instalacji).

Powiedzmy, że w styczniu twoja miesięczna aktywna widownia (MAU) wynosi 1000 graczy. W styczniu uzyskałeś 400 nowych graczy. W tym przypadku K-Factor wynosi 0.4, więc można powiedzieć, że każdy użytkownik aktywny w styczniu przekonał do Twojej gry 0.4 nowych użytkowników.

Wszystkie informacje powyżej mogą zostać wykorzystane do mierzenia jakości gry mobilnej na jej wczesnych etapach, w etapie Soft Launch lub po publikacji nowej wersji. Jednakże możesz zawsze sam dodać do tej listy własne wskaźniki – nikt przecież nie zna Twojej gry lepiej niż Ty.
*Soft Launch: Wejście z grą lub aplikacją mobilną początkowo na 3-4 rynki podobne (kulturowo) z wyborem do 3-4 źródeł akwizycji użytkowników. Soft Launch ma na celu znalezienie właściwego źródła akwizycji, ograniczenie przepalania budżetu na marketing aplikacji mobilnej przed wejściem na rynek główny oraz zbadanie zachowań, flow użytkownika w aplikacji mobilnej w pierwszej wersji aplikacji.