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?

Nos, egy mobil appban sokkal inkább megszokott a bejelentkezés funkció, ezért még olyan cégek esetében sem ördögtől való ötlet bevezetni egy appban, ahol a weboldalon esetleg nem lenne túl hatékony ehhez kötni a felhasználást.

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