Podczas konsultacji najczęstszym problemem doświadczonych marketerów i analityków jest zrozumienie eventów, które są kluczowe w przypadku analityki i promocji aplikacji mobilnej. Artykuł ma na celu ułatwić zrozumienie eventów i parametrów w Firebase, ale również w Facebook Analytics, bo proces wdrażania ich wygląda w obu przypadkach podobnie.

Przeczytaj również artykuł – Czym jest Firebase? Marketing aplikacji mobilnych i Unity w którym opisałem ogólnie do czego może przydać się zaimplementowany w aplikacji mobilnej / Unity narzędzie Google – Firebase. Warto do niego zajrzeć jeżeli jeszcze go nie czytałeś.

Events – najważniejsza część całego Firebase od strony marketingu aplikacji

Event (zdarzenie), a co to dokładnie jest? Event to zdefiniowana akcja w aplikacji o określonej nazwie, która jest rejestrowana przez analityczną część Firebase – Google Analytics for Firebase. Event daje nam możliwość analizowania ile użytkowników* wykonało daną akcję oraz jak często to robiło, w określonym przez nas czasie. Dodatkowo każdy z eventów może mieć przypisane parametry, o których więcej w dalszej części artykułu.

*Użytkownik to według Firebase synonim jednej instancji aplikacji, dla przykładu:

  • Przykład 1: Jeżeli aplikacja została zainstalowana na urządzeniu A, a potem odinstalowana i zainstalowana ponownie na urządzeniu A to dla Firebase są to 2 różni użytkownicy.
  • Przykład 2: zainstalowałeś aplikację X na Samsungu S7, a potem kupiłeś sobie drugi telefon np. Samsung S8 i zainstalowałeś również aplikację X. W tym przypadku, również masz dwóch różnych użytkowników w kolumnie users.

Zrozumienie, kim jest użytkownik ma bardzo duże znaczenie w przypadku analizy danych, bez tego nie można wyciągać dobrych wniosków.

To dzięki dobrze zdefiniowanym event’om jesteśmy w stanie budować zaawansowane listy remarketingowe do Google Ads (AdWords) oraz mierzyć skuteczność działań marketingowych. Część zdarzeń jest już zdefiniowana przez Firebase – lista predefiniowanych eventów, jest to np. session_start oraz first_open. Maksymalna liczba zdefiniowanych eventów to 500, wcześniej było ich tylko 50, dlatego warto było przemyśleć co chcemy mierzyć w naszej aplikacji.

3 rodzaje eventów w Firebase

Zdarzenia w Firebase możemy podzieli na 3 podstawowe rodzaje.

  1. Standard SDK – działające automatycznie po zaimplementowaniu Firebase SDK w aplikacji. Lista eventów automatycznie zbieranych przez Firebase tutaj.
  2. Standard – zdefiniowane przez Firebase, warto z nich korzystać przed stworzeniem własnych eventów. Lista predefiniowanych eventów dostępna tutaj.
  3. Custom – własne eventy – zdefiniowane przez nas.

Dodatkowo w panelu z czasem mogą pojawić się Recommened Events, które bazują na standardowych zdarzeniach. To co zauważyłem u swoich klientów to w przypadku innej kategorii aplikacji niż gra też dostaniemy rekomendacje eventów dedykowanych typowo dla gier jak np. level_completed, co należy oczywiście zignorować. Jest to prawdopodobnie chwilowe niedociągnięcie ze strony Firebase.

Event a parametr – jaka jest różnica?

Event to najprościej mówiąc akcja, którą wykonuje użytkownik np. kończy etap gry, dokonuje zakupu, rejestruje się. Event może mieć pod sobą parametry. Event w panelu Firebase po przełączeniu na język polski przetłumacozny jest jako: zdarzenie.

Parametr to przypisana cecha dla eventu, która może być tekstowa lub liczbowa.

Przykład: rozpiszmy event in_app_purchase. Event ten informuje o zakupie w aplikacji mobilnej. Załóżmy że nasz użytkownik kupuje w aplikacji książkę (book), „Sztuka Gotowania” o wartości 100 . Podkreślone słowa to wartości parametrów.

Event in_app_purchase ma powiązane ze sobą parametry:
item_category: book
item_id: zazwyczaj pojawia się tutaj unikalne ID produktu nadawane przez sklep
item_name: Sztuka Gotowania
value: 100
currency: PLN
transaction_id: numer transakcji jak np. nr paragonu ADS2423

Wszystkie powyższe parametry z naszego przykładu za wyjątkiem parametru value są parametrem tekstowym.

Tworząc własne (customowe) parametry należy pamiętać, aby nie rozpoczynać ich od słów: „firebase_”, „google_”, and „ga_”. Są one zarezerwowane wyłącznie dla Google.

Jak dobrze wdrożyć eventy z parametrami, które chcemy śledzić w aplikacji?

Jeżeli pracujemy w firmie nad dużym projektem – bardzo rozbudowaną grą w Unity lub aplikacją mobilną na Androidzie / iOS, która posiada mnóstwo funkcji, przed podjęciem działań zalecam spotkać się ze wszystkimi osobami, które potrzebują informacji na temat działania aplikacji.

Poniżej 7 kroków, dla działu marketingu. Zakładam, że to właśnie dział marketingu w większości firm będzie inicjatorem wdrożenia Firebase do aplikacji. Czasami jest to product owner lub w większych firmach dział Big Data.

Zakładka events / zdarzenia w Analytics for Firebase screen z konta demo
Zakładka events / zdarzenia w Analytics for Firebase (na screenie widać poprzednią wersje wyglądu panelu Firebase)
  1. Ustalmy roboczo co chcemy mierzyć. Wypiszmy główne zdarzenia, na podstawie których chcemy budować listy remarketingowe (robi się to w zakładce zakładka odbiorcy (ang. audiences)) do Google Ads (AdWords) oraz funkcjonalności aplikacji, które są kluczowe by wiedzieć czy użytkownicy tam w ogóle zaglądają i jak często.
  2. Ustalmy jednolity schemat nazewnictwa oraz spiszmy je w jednym excelu. Dobrą praktyką jest tworzenie własnych (customowych eventów) w formacie np.: Nazwa_Eventu lub NAZWA_EVENTU bez PL znaków. W osobnej kolumnie piszemy dokładnie dla developera kiedy dane zdarzenie ma się odpalać. Tego typu plik polecam stworzyć w Google Spreadsheet, gdzie możemy online komentować i zmieniać rzeczy tak by wszyscy to widzieli na żywo.
  3. Każdy z eventów może wysłać również do Firebase parametry. Jest to przydatne aby nie dublować na siłę niektórych eventów jak na przykład zaliczenia kolejnego poziomu w grze. Zamiast robić eventy 1_lvl_completed, 2_lvl_completed…. lepiej zrobić event lvl_completed z parametrem lvl_number. Należy pamiętać że aktualnie w Firebase możemy mierzyć 10 parametrów tekstowych i 40 liczbowych.
  4. Sprawdzamy czy na naszej liście nie ma eventów, które są standardowe lub standardowe SDK, o różnicy pomiędzy nimi pisałem kilka wersów wyżej. Pełna aktualna lista standardowych (SDK) eventów tutaj. Nie tworzymy własnych eventów z nazwami istniejącymi na oficjalnej liście Firebase. Dla przykładu: jeżeli w naszej aplikacji mamy dodawanie do koszyka to korzystamy z add_to_cart, zamiast tworzyć customowy event np. ADD_TO_BASKET. Dzięki temu machine learning będzie lepiej rozumieć naszą aplikację, co przełoży się na lepsze wyniki aplikacji w dalszej jej rozwoju.

    Możesz również zamówić szkolenie, konsultacje, szablon lub gotowego excela dla swojej aplikacji mobilnej z rozpisanymi eventami i parametrami. Odezwij się na: marcin@milowski.eu

  5. Po wypracowaniu nazewnictwa i opisaniu eventów możemy przekazać plik do programistów do zaimplementowania.
  6. Po zaimplementowaniu warto usiąść z developerami i zdebugować (sprawdzić) czy wszystkie eventy i parametry zliczają się poprawnie, tak jak tego pierwotnie chcieliśmy.
  7. Wszystko działa tak jak chcieliśmy? Jeżeli tak, to wersja może lecieć na produkcję.

Trzeba pamiętać, że każdy nowy event lub dodanie parametrów w kodzie aplikacji (iOS/Android) wymaga za każdym razem aktualizacji przez użytkownika. Nowe eventy po pierwszym zarejestrowaniu przez Firebase pojawią się w statystykach do 24 godzin. Jeżeli eventy zostaną zarejestrowane przez Firebase, możemy zacząć budować listy remarketingowe w zakładce Odbiorcy (ang. Audiences), które automatycznie po połączeniu Firebase z Google Ads pojawią się na naszym koncie reklamowym.

2 wybrane predefiniowane przez Firebase zdarzenia dla marketingowca to:

Te zdarzenia są już automatycznie zaimplementowane w aplikacji (rodzaj eventu: standard SDK), po wrzuceniu podstawowego kodu Firebase do aplikacji i nie trzeba ich ustawiać.

  • first_open – jeżeli prowadzimy kampanie na instalowanie aplikacji ten event będzie mówił nam czy nasze działania są skuteczne, bo mówi o pierwszym po instalacji otwarciu aplikacji.
  • session_start – dzięki niemu poznamy z jakiego źródła nasza aplikacja jest najczęściej otwierana. Bez działań marketingowych na zaangażowanie użytkowników, będzie to direct, czyli otwarcia bezpośrednie.

Szkolenie Firebase? A może konsultacje?

Konsultacje Firebase zamiast kursu

Szukasz kursu Firebase? Zamów szkolenie z Firebase dla swojej firmypoznaj plan szkolenia na milowski.eu lub umówmy się na konsultacje online, gdzie omówimy na przykładach działanie Firebase potrzebne do efektywnych działań marketingowych.

Godzina konsultacji to inwestycja 160 zł netto, w pakiecie min. 4 godzin cena za 1 godzinę spada do 120 zł netto. Zapraszam do kontaktu poprzez e-mail: marcin@milowski.eu lub Facebook (blog ITIQ). Więcej o mnie na: milowski.eu

Przydatne linki:

6 KOMENTARZE

  1. Niby podobne do google analytics, ale jednak te parametry dobrze porozdzielać bo juz chciałem robić w swojej apce X eventów różniących się numerkiem, dzięki!

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here