Google Analytics 4 – Część 4 – Firebase: Dane z aplikacji mobilnych

Dane z aplikacji mobilnych w Google Analytics 4 – jak do tego podejść?

Google Analytics 4 wprowadza możliwość łączenia danych o ruchu na stronie internetowej oraz w aplikacjach mobilnych. Jak zacząć? Jak wykorzystać potencjał połączonych danych? Na co uważać? O tym w poniższym artykule.

Analiza aplikacji mobilnych – dwaj główni gracze

Gdy w 2014 roku Google przejmował Firebase (obecnie Google Analytics for Firebase), platformę do budowy aplikacji, analizy marketingu i zarządzania danymi w aplikacjach mobilnych aplikacje mobilne nie odgrywały tak istotnej roli w budowaniu lojalności klientów. Ich dynamiczny rozwój obserwowany w ostatnich latach sprawił jednak, że potrzeba mierzenia ruchu w aplikacjach mobilnych stała się niezmiernie istotna

Najczęściej wybieranymi rozwiązaniami pozwalającymi mierzyć efektywność aplikacji mobilnych stały się Firebase oraz AppsFlyer. Rozwiązania te różnią się pod wieloma względami, zaczynając od kwestii ceny i sposobu rozliczania, poprzez sposób działania, aż po możliwość integracji z innymi systemami. Dotychczas pozwalały one jednak analizować jedynie ruch w aplikacjach. Wprowadzenie GA4 diametralnie zmieniło tą sytuację, umożliwiając pobieranie danych z Firebase.

Model danych oparty o zdarzenia, a nie sesje

Model danych GA4 został przebudowany w taki sposób by móc łączyć dane ze stron internetowych jak i z aplikacji mobilnych. Bazuje on na zdarzeniach i parametrach, a nie sesjach i wyświetleniach stron jak miało to miejsce w GA UA. Mierzenie ruchu na stronach internetowych zostało więc sprowadzone do sposobu wykorzystywanego już wcześniej w narzędziach dedykowanych aplikacjom mobilnym. W rezultacie możliwe jest otrzymanie pełnego obrazu użytkownika niezależnie od tego na jakich urządzeniach i w jakiej formie (aplikacja / strona internetowa) styka się on z firmą.

Źródło danych – Firebase

Aby móc korzystać z danych pochodzących z aplikacji mobilnych w GA4 niezbędnym jest posiadanie projektu Firebase. Na ten moment GA4 umożliwia podłączanie jedynie danych z tego źródła. Ponieważ oba systemy należą do ekosystemu Google, ich połączenie nie należy do skomplikowanych. Wystarczy jedynie podać identyfikatory aplikacji oraz identyfikator projektu Firebase.

Sam Firebase wyglądem, w części analitycznej, przypomina GA4.

Jego konfiguracja jest jednak zgoła odmienna od tej używanej w mierzeniu ruchu na stronach internetowych. Firebase wykorzystuje specjalną bibliotekę, Firebase SDK, do śledzenia zachowania użytkowników i wymaga specjalnej struktury zdarzeń zgodnej z językiem w jakim napisana jest aplikacja. Zarejestrowane w ten sposób zdarzenia trafiają zatem do Firebase, a następnie przekazywane są do Google Analytics 4.

Firebase – wdrożenie śledzenia i testowanie

Podobnie jak w przypadku Google Analytics 4, Firebase po wdrożeniu biblioteki SDK, zbiera szereg zdarzeń i powiązanych z nimi parametrów automatycznie. Pierwsze uruchomienie aplikacji, jej usunięcie czy aktualizacja to tylko przykłady (lista: https://support.google.com/firebase/answer/9234069?hl=en). 

Większość najistotniejszych biznesowo zdarzeń takich jak dodania do koszyka czy zakupy wymaga samodzielnej konfiguracji poprzez dewelopera w kodzie aplikacji. W celu usprawnienia pracy i utrzymania kontroli nad sposobem wdrożenia śledzenia tak w aplikacjach mobilnych jak i na stronie internetowej rekomendowanym działaniem jest przygotowanie dokumentacji w formie tzw. tracking planu. Uwzględnia on wszystkie rejestrowane zdarzenia, uspójnia nazewnictwo oraz wskazuje strukturę i listę zmiennych w zdarzeniu. Stanowi on więc wytyczne dla deweloperów i punkt odniesienia dla osób testujących konfigurację.

Zgodnie z ogólnie przyjętą normą wdrażania zmian, deweloper przygotowuje aplikacje uwzględniające niezbędne śledzenie w środowisku testowym. Sposób testowania poprawności śledzenia zdarzeń zależny jest od tego na jakim systemie operacyjnym jest uruchomiona aplikacja. W przypadku iOS aplikacja udostępniana jest na urządzenie na jakim będą wykonywane testy poprzez dedykowaną aplikację TestFlight. Dzięki niej możliwym jest zainstalowanie aplikacji testowej, a następnie weryfikacja zdarzeń i parametrów np. w module testowym GA4.

W przypadku wersji na urządzenia z systemem Android niezbędnym jest pobranie pliku aplikacji (.apk) i odpowiednie zasymulowanie aplikacji w programie Android Studio na urządzeniu wirtualnym i/lub podłączonym urządzeniu fizycznym.

Testowanie zbieranych zdarzeń odbywa się poprzez ich symulowanie w podłączonych aplikacjach testowych i module DebugView GA4 oraz w przypadku uprzedniego podłączenia przesyłania surowych danych z GA4, w BigQuery. Symulowane zdarzenia powinny pojawiać się w obu tych miejscach po kilku / kilkunastu sekundach.

Wykorzystanie połączonych danych

Zunifikowane dane pochodzące ze stron internetowych i aplikacji mobilnych otwierają możliwości prowadzenia holistycznych analiz, w GA4 lub w BigQuery, wspomagających podejmowanie strategicznych decyzji w firmach. Poniżej nasza lista 3 przykładów takich analiz.

1. Pełny obraz klienta

W biznesach, które bazują na powtarzalnej sprzedaży do klientów dużo istotniejszym wydarzeniem od pozyskania zamówienia jest pozyskanie nowego klienta. Stosunek wartości klienta w cyklu jego życia (tzw. LTV – Lifetime Value) do kosztu jego pozyskania (tzw. CAC – Customer Acquisition Cost) oraz czas spłaty tego kosztu (tzw. Payback Period), a więc czas po jakim marża wygenerowana na kliencie zrównuje się z kosztem pozyskania, są jednymi z najważniejszych wskaźników biznesowych. Niestety bez możliwości połączenia danych z różnych kanałów sprzedażowych niemożliwym jest stworzenie pełnego obrazu klienta, a co za tym idzie obliczenie kluczowych wskaźników.

2. Efektywność kampanii marketingowych

Celem wprowadzenia aplikacji mobilnych jest podniesienie powtarzalności sprzedaży do użytkownika i jego lojalności. Aplikacje mobilne z zasady ułatwiają dokonywanie kolejnych zamówień i sprawiają, że oferta danego biznesu jest zawsze pod ręką. Pozyskani użytkownicy / klienci zachęcani są często poprzez promocje, kody rabatowe czy zniżki do instalacji aplikacji. Co więcej, część kampanii marketingowych wprost ukierunkowana jest na pobrania aplikacji. 

Instalacja aplikacji przeważnie sprawia jednak, że transakcje dokonywane przez użytkownika są traktowane jako transakcje bezpośrednie. W rezultacie, z punktu widzenia marketingu, pozyskiwanie użytkowników następnie konwertowanych na aplikacje mobilne wpływa niekorzystnie na efektywność kampanii (koszt poniesiony nie jest spłacany kolejnymi zamówieniami klienta). Cele marketingowe są zatem sprzeczne z celami ogólno firmowymi.

Dzięki połączeniu danych modelowanie atrybucji uwzględnia wszystkie zamówienia składane przez klienta niezależnie od ich sposobu. Kampanie marketingowe odrabiają poniesiony koszt dzięki przyszłym przychodom generowanym dzięki aplikacjom mobilnym i tym mocniej promują pozyskiwanie nie jednorazowych, a lojalnych klientów.

3. Analiza wąskich gardeł w procesie zakupowym

Użytkownicy posiadający aplikacje mobilne nie zawsze dokonują transakcji przy ich użyciu. Często zdarza się, że transakcje dokonywane są częściowo na stronie internetowej, a częściowo w aplikacji mobilnej. Dzieje się tak ze względu na zniżki czy promocje dostępne tylko w aplikacji mobilnej. Innym powodem mogą być wąskie gardła występujące w jednym bądź drugim kanale. Błędy techniczne, wydajność czy trudność korzystania sprawiają, że część klientów rezygnuje z zakupu a część najbardziej zdeterminowanych stara się je dokończyć w inny sposób. 

Analizując połączone dane możliwym jest dokładne odtworzenie ścieżki zachowania użytkownika i identyfikacja miejsc sprawiających problemy użytkownikom.

Pułapki w śledzeniu zdarzeń w aplikacjach

Niestety śledzenie zdarzeń w aplikacjach mobilnych i ich unifikacja ze zdarzeniami rejestrowanymi na stronach internetowych nie jest wolna od niuansów i pułapek. Poniżej dwa często popełniane błędy.

1. Ruch oznaczony jako (not set)

Użytkownicy instalują aplikacje mobilne pobierając je z oficjalnych sklepów. Są to odpowiednio dla iOS i Android, App Store i Google Play. Mogą oni samodzielnie wyszukiwać aplikacji w tychże sklepach lub zostać tam przekierowani. poprzez przycisk na stronie czy link w newsletterze. Brak wskazania parametru odsyłającego (w przypadku Google Play) sprawia, że źródłem pozyskania użytkownika (zmienną zapisywaną raz na zawsze) zostaje wartość (not set). W przypadku iOS jest to Direct. Następnie każdorazowe wejście do aplikacji, nawet po zmianie na urządzenie z systemem iOS, bez parametrów kampanii skutkuje tym, że GA4 traktuje taki ruch jako (not set). Prowadzi to do wielu problemów począwszy od postrzegania rzetelności danych przez korzystających z GA4, aż po błędne analizy.

Dlatego też wdrażając śledzenie w aplikacjach mobilnych za pomocą Firebase bardzo istotnym jest odpowiednie oznaczenie odniesień do sklepów z aplikacjami. Nie wyeliminuje to w pełni rejestrowanego ruchu (not set), w dalszym ciągu można wyszukać aplikację bezpośrednio w sklepie z aplikacjami, natomiast zdecydowanie zmniejszy jego udział.

2. Brak wykorzystania linków dynamicznych

Często niewykorzystywaną możliwością są tzw. linki dynamiczne. Umożliwiają one odpowiednie kierowanie użytkownika na stronę internetową bądź do aplikacji czy odpowiedniego sklepu z aplikacjami. Dzięki wykorzystaniu linków dynamicznych możliwym jest podniesienie efektywności kampanii marketingowych oraz następnie lepiej zmierzenie ich efektu. W przypadku użytkowników posiadających aplikację mobilną, kierowanie z kampanii marketingowych na stronę internetową często kończy się jej zamknięciem i samodzielnym uruchomieniem aplikacji (celem aplikacji jest zwiększenie rekurencji poprzez podniesienie wygody dokonywania transakcji). Utrudnia to, a niejednokrotnie uniemożliwia, dokładne połączenie kosztów i przychodów.

Możliwość łączenia danych z aplikacji mobilnych z tymi ze stron internetowych to rewolucyjna funkcja wprowadzana przez GA4, z której bez wątpienia warto skorzystać.

Jeżeli masz pytania związane z tematami poruszonymi w tym artykule, napisz do nas!

Leave a Reply