Eventy w Firebase jak je wykorzystać w marketingu dla aplikacji Unity, Android i iOS

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

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.

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?

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:

• Dokumentacja Firebase – pełna lista predefiniowanych eventów oraz dla GA A+W tutaj z podziałem eventów na app/web/app and web.
• Pierwszy artykuł o tym Czym jest Firebase i dlaczego konieczny jest przy kampaniach Google Ads (AdWords) oraz Facebook Ads.
• Opis usługi Google Analytics App+Web