A Google Analytics, 2005-ös megjelenése óta, lényegében a webes mérések de facto eszközévé vált. A kis- és középvállalkozások között (itthon és külföldön is) kevés olyan weboldal van, amely ne használná – ebben például erős kivétel Németország és Ausztria, ahol a cégek, illetve a törvényhozás talán az átlagnál jobban utálja a Google-t és a Facebookot, így ott mérések terén sokkal inkább a szerényebb tudású, de a feltételeket jobban teljesítő webtrekk a befutó.

Mobil appok terén már más helyzet: ott bár a Google igyekezett hasonló székbe ülni, de kevésbé sikerült neki. Ugyan a Google Analyitcs mostanában kivezetett mobilalkalmazás-mérésekkel adott valamit a népnek, ami megvallom, nem volt rossz, azonban az évek során kiderült, hogy nem feltétlenül a jó oldalról közelíti meg a problémát.

Amíg a Google Analytics alapvetően a mérésekre és az ezekből képezhető és célozható közönségekre épített, addig szépen sorban alakultak ki azok a komplex keretrendszerek, amelyek nemcsak mérték az applikációt és az abban megjelenő interakciókat, de funkciók egész garmadáját építették az így beérkező adatokra: célzott push üzenetek, dinamikusan viselkedő app elemek és még sorolhatnánk a gyűjtött adatok érdekes és értékes felhasználását, ami nem feltétlenül hirdetésekről és még inkább nem Google-hirdetésekről szólt.

Talán ezt is felismerve ugrott bele a Google egy újabb felvásárlásba és kebelezte be az addig független alkalmazásfejlesztési keretrendszert, a Firebase-t.

A történet ráadásul az elmúlt években odáig fejlődött, hogy a Firebase kínálta lehetőségekre építve gondolja épp újra a Google azt, amit az elmúlt 14 évben megszoktunk a weben, illetve hibrid módon (mobil app + web kombinációban) a Google Analyticstől.

Na, de mit is adtak nekünk a rómaiak a Google mérnökei?

Teljesen új adatmodell

A már megszokott webes mérésekben az adatgyűjtés ún. hitekből épül fel. Egy hit lehet egy oldalmegtekintés, oldalon belüli esemény, időzítőmérés, esetleg e-kereskedelmi tranzakció. Minden hitnek van egy elvárt és egy opcionális paraméterlistája, ami az ingyenes Google Analyticsben kiegészíthető 20 egyéni dimenzióval és 20 egyéni metrikával.

A gyűjtött adatokat 4 szinten aggregálja nekünk a rendszer:

• felhasználó/user,
• munkamenet/session,
• oldalmegtekintés/pageview
• és esemény/event.

A Google Analytics for Firebase-ben egy teljesen új adatmodellel találkozunk, amit nem is igazán lehet megfelelően párosítani a weben megszokott elemekkel:

Események

A Firebase mérésekben végső soron minden egy mért esemény: az app első elindulása, egy új munkamenet, a felhasználó interakciói az applikációval, egy appon belüli vásárlás és még sorolhatnám: ami a weben jól elkülönülő entitás, az az applikációs méréseinkben innentől mind esemény.

Így pedig a munkamenet igazából csak egy láncolata a mért eseményeknek, mely eventekhez nagyok sok paraméter is kapcsolható:

Amíg weben megszoktuk, hogy egy eseménynek 4 fix paramétere van, addig a Firebase méréseknél ez egy sokkal rugalmasabb lehetőség: egyrészt nincs meghatározva egyik paraméter neve sem, másrészt 25 különféle paraméter kapcsolható egy-egy mért eseményhez.

Sőt, amíg weben történő adatgyűjtésnek megvannak a maguk határvonalai, addig Firebase-ben ezek a limitek teljesen másként alakulnak:

• nincs korlátja a gyűjtőtt adatpontoknak: lehet kis applikáció vagy nagy volumenű giga app, a rendszer (jelenleg) hírből sem ismeri azt a weben megszokott fogalmat, hogy mintavételezés;
• ugyanakkor legfeljebb 500 különféle eseményneved lehet, tehát 500 különböző interakciót mérhetsz, amibe nem számítanak bele azok az események, amiket a Firebase rendszerszinten, magától mér (pl. first_open, session_start stb.).

A már linkelt oldalon megtekintheted a jelenleg érvényes határvonalakat, de igazából egyik se olyan, ami miatt most hirtelen el is vetnéd a Firebase használatát.

User Property

Az eseményekkel és eseményparaméterekkel lényegében nagyon sok munkamenetszintű, vagy épp eseményszintű információt hozzáadhatsz a rendszerhez.

A felhasználóról magáról viszont nem feltétlenül az események „árulkodnak”. Hogy is írtam? A munkamenet igazából eventek hosszú láncolata Firebase-ben. A felhasználók pedig általában ezen munkamenetek láncolatából definiálhatóak.

A felhasználó mint entitás annyira szorosan jelen van a rendszerben, hogy amíg a klasszikus, webes Google Analyitcsben sokan még mindig a munkamenetekre vetített metrikák és trendek bűvöletében élnek, addig Firebase-ben már most is minden alapvetően a felhasználóról szól. Minden riport a felhasználók mennyiségét írja le, minden ehhez kapcsolódó funkció a felhasználókkal és azok számosságával foglalkozik.

A felhasználók fókuszba helyezése olyan paradigmaváltozás, amit a webes Google Analyticsben már megpróbáltak átvinni, Firebase-ben viszont az alapok része és nem holmi evolúció során a rendszerre erőszakolt számadat.

Márpedig, ha a felhasználók ennyire fókuszban vannak, fontos mérni és tárolni azok jellemzőit is (szigorúan GDPR-nak megfelelő módon és szigorúan nem tárolva közvetlen személyes adatot).

Milyen jellemzőkről beszélünk?

Így viszont sokkal több jellemzője lehet egy felhasználónak, amit Firebase felé el lehet küldeni mint adatot és amit később rengeteg módon tudunk hasznosítani:

• életkor,
• nem,
• város,
• klubtagság/pontrendszerszint (pl. VIP, Prémium, Bronz, Ingyenélő, Újgazdag stb.),
• elért pontok száma (pl. egy játék appban),
• csillagozott előadások témái (pl. egy konferencia alkalmazásban),
• vásárlások száma (pl. egy ecommerce applikációban),
• eddigi vásárlások értéke,

… és még sorolhatnám. Annyi, de annyi információ alapján igyekszünk szegmentálni az adatokat az egyéb riportok során. Ezeket mind-mind érdemes átültetni Firebase-be, amíg nem közvetlenül személyes adatról beszélünk – tehát név, e-mail-cím, teljes lakcím, rendszám, bankkártyaszám stb.

Tervezni, tervezni, tervezni

Mint minden hasonló feladatot, célszerű a mérések bevezetését és szofisztikálását is tervezéssel kezdeni. Én ma már kevésbé vagyok a papír híve, de nem én fogom eldönteni, hogy neked a táblára ragasztott post-itek vagy egy online whiteboard alkalmazás, esetleg egy mezei táblázatkezelő jelenti majd a megoldást.

Én (mi) Excel ésvagy Google Sheet-ben kezeljük ezt a feladatot, többek között azért is, mert a táblázatkezelők képletezési lehetőségei félig automatikus dokumentálást tesznek lehetővé.

Az alábbi linken egy minta Google Sheetet értek el, amely talán nem túl kreatív módon az Android számológép applikációjának egyik képernyőjét mutatja: http://bit.ly/jabjab_mobileapp_measurement_planner

Ebben a Google Sheet-ben olyan oszlopokat is láttok, amivel a Facebook felé is meg lehet tervezni a méréseket. Ennek nagyon egyszerű oka van: a Facebook eléggé zárt rendszer és nem integrálható Firebase-zel. Ezért a Firebase felé közlendő információt külön közölni kell Facebook felé is. Ebben a cikkben viszont ezt most részletesebben nem mutatnám be, maradjon a fókusz a Firebase méréseken.

A fájl első munkalapja fix: itt soroljuk fel azokat a user propertyket, amiket használni szeretnénk az appban. Ez nem is olyan régen többek között azért is volt fontos, mert a user propertykhez nemes egyszerűséggel nem volt törlő/archiváló funkció, így ha ad hoc vittük fel a felületen az új user propertyket, akkor bizony könnyen lyukra futhattunk, mivel ezekből legfeljebb 25 hozható létre. Most már jobb a helyzet, van archiválás funkció, de ezzel együtt is érdemes végig gondolni, mire lesz szükségünk.

A fenti táblázat második munkalapja egy konkrét képernyő az appban. Ezt célszerű egy drótvázas ábrával vagy akár már egy konkrét képernyőképpel megoldani, mert így a tervezés során ott van egy sorvezető, egy mankó, hogy mit is lát a felhasználó, amikor az adott interakciót mérni szeretnék.

Itt pedig már csak fel kell sorolni a mérendő eseményeket, ami persze most így egyszerűen hangozhat, de majd garantáltan vissza fogunk térni ehhez a listához, amikor jobban megismerjük, mi mindenre lehet felhasználni a gyűjtött adatokat.

A „Firebase event name” oszlopnál az alábbi szabályokat tartsuk be:

• csak az angol ábécé kisbetűit használjuk;
• esetleg számokat, de inkább csak módjával;
• ahol szóközt írnánk, oda alulvonást (_) írjunk;
• végül célszerű lehet minden eseménynevet angolul megadni, így akárki kezébe is kerülnek a tervek és később a riportok, nem lesz gond annak megértésével.

A „Firebase event parameters” oszlopban tudjuk felsorolni, hogy adott eseményhez milyen kiegészítő adatokra lesz szükségünk:

• a paraméterek nevénél célszerű betartani a fenti intelmeket;
• mi jellemzően egy cellába írjuk a paraméterlistát, 1 paraméter/sor formában, de ha valakinek kényelmesebb, használhat további sorokat és cellaösszevonásokat a B és C oszlopokban.

Lényegében minden alkalmazás-képernyő kap egy külön munkalapot, amire így akár több iterációban, alaposan végiggondolva lehet felvinni a mérési tervet

Ezt osztjuk meg aztán a fejlesztőkkel, akik már a megfelelő iOS és Android fejlesztési dokumentációk birtokában (remélhetőleg) könnyedén elkészítik az összes mérőkódot.