Podczas konsultacji marketingowych i szkoleń, które prowadzę 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 Google Analytics for 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ś. Zapraszam również na szkolenie Analityka z Firebase.

Events – najważniejsza część całego Google Analytics for Firebase

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.

W odróżnieniu do klasycznego Google Analytics, analitka w Firebase opiera się na eventach i parametrach, zamiast hitów. Widać to bardzo dobrze po tym jak połączy się Firebase z Google Analytics

*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.

WAŻNE! Eventy standardowe i standardowe SDK powinny być nadrzędne w definiowaniu własnych eventów dla Google Analytics for Firebase. Czyli jeżeli mamy na przykład mierzenie zakupu w naszej aplikacji mobilnej, która jest sklepem internetowym należy użyć eventu ecommerce_purchase, a nie tworzyć swojego np. zakup_w_sklepie. Ułatwi to machine learning wyciągać lepsze wnioski dla naszego biznesu lepiej optymalizując kampanie oraz dawać lepsze predictions i insights.

Event a parametr w Google Analytics for Firebase – 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łumaczony 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, product manager 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 w Firebase możemy mierzyć 10 parametrów tekstowych i 40 liczbowych. Chyba że stworzymy usługę apps and web w Google Analytics wtedy ten limit zwiększa się do 50 parametrów tekstowych i 50 liczbowych. Jak to zrobić pokazuje na youtube tutaj.
  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 dla Google Analytics for Firebase & Facebook Analytics. 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. session_start odpala się po 10 sekundach od włączenia aplikacji.

Szkolenie Firebase? A może konsultacje?

Szukasz kursu Firebase? Zamów szkolenie z Firebase dla swojej firmy – poznaj plan szkolenia na milowski.eu lub umówmy się na konsultacje online.
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
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.