Podczas konsultacji marketingowych i szkoleń, które prowadzę najczęstszym problemem doświadczonych marketerów i analityków jest zrozumienie eventów (zdarzeń), 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 (GA4F), ale również w Google Analytics App+Web (GA A+W) i Facebook Analytics, bo proces wdrażania ich wygląda w obu przypadkach podobnie.

Eventy występują nie tylko w GA4F (tam pojawiły się jako pierwsze), ale również w nowej usłudze Google Analytics App+Web, który możliwe że jest cichym następcą klasycznego Google Analytics Universal. Na blogu dostępny jest również artykuł o Google Analytics App+Web.

Events – najważniejsza część Google Analytics for Firebase oraz Google Analytics App+Web

W odróżnieniu do klasycznego Google Analytics, analityka w Firebase oraz w Google Analytics App+Web opiera się na eventach i parametrach, zamiast sesji i hitów. Widać to bardzo dobrze po połączeniu nasze aplikacji mobilnej z wgranym Firebase SDK i skonfigurowanymi naszymi eventami z Google Analytics App+Web.

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 SDK – 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 oraz w Google App+Web (klik) jest to np. session_start (wspólne dla GA4F oraz GAA+W) oraz first_open (GA4F app)/first_visit (GAA+W web). Maksymalna liczba zdefiniowanych eventów to 500. Na starcie usługi było ich tylko 50, dlatego trzeba było przemyśleć co chcemy mierzyć w naszej aplikacji o wiele bardziej niż aktualnie.

2 podziały eventów w Google Analytics dla Firebase (GA4F) oraz GA A+W

Zdarzenia w GA4F oraz GA A+W możemy podzielić na 2 podstawowe rodzaje ze względu na ich sposób wdrożenia:

  • Standard SDK (automatyczne) – działające automatycznie po zaimplementowaniu Firebase SDK w aplikacji. Lista eventów automatycznie zbieranych przez Firebase tutaj, przez GA A+W tutaj.
  • Standard – zdefiniowane przez Firebase, warto z nich korzystać przed stworzeniem własnych eventów. Lista predefiniowanych eventów dostępna tutaj.
  • Custom – własne eventy – zdefiniowane przez nas.

oraz ze względu na wstępowanie w zależności od rodzaju platformy

  • app – tylko w aplikacjach mobilnych np. first_open
  • web – tylko na webie np. first_visit
  • app and web – w aplikacjach oraz na webie np. session_start

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 (automatyczne) powinny być nadrzędne w definiowaniu własnych eventów dla Google Analytics for Firebase oraz GA A+W. 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 np. 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 i GA A+W – 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ę, otwiera sesję. 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 przypisane cechy dla eventów, które mogą mieć wartość tekstową lub liczbową. Maksymalna ilość własnych (customowych) paramentów przy evencie to 25.

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 o wartości tekstowej.

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.

Eventy w Fireabse - podgląd
Zakładka events / zdarzenia w Analytics for Firebase (na screenie widać dane z konta demo w okresie 28 dni)

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

Jeżeli pracujemy nad wdrożeniem nowej analityki opartej o eventy, przed podjęciem działań zalecam spotkać się ze wszystkimi osobami, które potrzebują informacji na temat działania aplikacji. A przed tym najlepiej jeszcze konsultacje ze mną, szczegóły na dole 😉

Przed samym wdrożeniem eventów Firebase, warto aby aplikacja miała również wdrożonego Google Tag Managera. Tworzy się go podobnie jak w przypadku weba, osobno 2 kontenery dla iOS i Androida. W przyszłości ułatwi nam to prace z eventami jeżeli będziemy potrzebować zmienić ich nazwę i/lub zawiesić ich wysyłanie z aplikacji do Firebase.

Google Tag Manager dla iOS i Android
GTM dla aplikacji mobilnych dwa osobne kontenery dla iOS i Androida

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 nowego modelu mierzenia danych czy to poprzez sam Firebase do aplikacji, czy Google App+Web gdy posiadamy stronę internetową i aplikację mobilną. Czasami jest to product owner, product manager lub w większych firmach dział Big Data.

  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.
    Pomagałem przygotować lub tworzyłem od zera tego typu excela m.in. dla: Diet by Ann, OXY, InterCars, MiiMove.
  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 połąćzymy usługę GA4F z Google Analytics App and Web, 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ć do marketów Google Play i App Store.

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.

3 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.
  • screen_view – mierzy ekrany, na których znajduje się użytkownik, tak aby wiedzieć jak użytkownik porusza się po aplikacji i ile czasu spędza na poszczególnych screenach. Jego poprawne wdrożenie (automatyczna implementacja przez SDK zazwyczaj jest nic nie warta) wymaga zrozumienia parametrów z nim związanych: firebase_screen, firebase_screen_id, firebase_screen_class.

Szkolenie Firebase? A może konsultacje?

Potrzebujesz pomocy z Firebase / App+Web Umówmy się na konsultacje online lub zamów szkolenie (również online)- oferta szkolenia Firebase dla firm.

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

Przeczytaj również artykuł – Czym jest Firebase? Marketing aplikacji mobilnych i Unity w którym opisałem do czego może przydać się zaimplementowany w aplikacji nowego narzędzia Google – Firebase.

Przygotowuje na zamówienie excel z eventami, parametrami oraz user properties na potrzeby wdrożenia:
Firebase, Google Analytics App+Web oraz FB Analytics
Zamów poprzez marcin@milowski.eu lub Facebook messeger

Przydatne linki:

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