Analytics pentru aplicații mobile: ce măsori și ce ignori

Răspunsul scurt: pornești cu patru până la șase evenimente care urmăresc drumul până la banii tăi, plus raportarea erorilor. Nu cinci sute. Firebase îți oferă raportare gratuită și nelimitată pe până la 500 de evenimente distincte, iar generozitatea asta e exact motivul pentru care majoritatea aplicațiilor ajung cu un dashboard pe care nu îl citește nimeni și fără răspuns la singura întrebare care contează: ce construiești în continuare.

Un lucru merită spus de la început, pentru că explică tot ce vei citi pe tema asta: aproape toate ghidurile despre analytics pentru aplicații mobile sunt scrise de companii care vând un produs de analytics. Noi construim aplicații la Digital U, de la 5.000 $ pentru un proiect custom. Nu avem niciun dashboard de vândut, deci ăsta e setup-ul pe care îl punem efectiv, în ordinea în care îl punem, și părțile care se strică. Dacă preferi să ți-l punem noi pe aplicația ta, e la distanță de un call de 30 de minute.

Ce înseamnă analytics pentru aplicații mobile și de ce nu e la fel ca pe web

Analytics pentru aplicații mobile înseamnă înregistrarea a ceea ce fac oamenii în aplicația ta de iOS sau Android, sub formă de evenimente trimise de un SDK din aplicație către un serviciu care le transformă în pâlnii, curbe de retenție și rapoarte.

Diferența față de web nu e cosmetică. Pe web deții pagina și o poți schimba azi. Într-o aplicație, omul e pe o versiune instalată acum câteva săptămâni, s-ar putea să nu o actualizeze niciodată, iar o parte dintre utilizatori nu au acceptat deloc să fie urmăriți. Asta înseamnă că cifrele din aplicație sunt un eșantion cu goluri cunoscute, iar prima greșeală e să le tratezi ca pe o numărătoare completă.

Cele două instrumente care răspund la întrebări diferite

Ai nevoie de două lucruri, și nu sunt același lucru. Unul îți spune ce fac oamenii. Celălalt îți spune ce s-a stricat.

Perechea pe care o folosim e PostHog pentru analytics de produs și Sentry pentru monitorizarea erorilor, pentru că decizia utilă stă între ele. Sentry îți spune că un ecran aruncă erori. PostHog îți spune câți oameni ajung vreodată pe ecranul ăla. Niciunul singur nu îți spune dacă merită reparat azi.

Asta e treaba reală a unui sistem de măsurare într-o echipă mică: nu să producă dashboard-uri, ci să ordoneze munca. O eroare pe un ecran atins de 2% dintre utilizatori și o eroare în checkout arată la fel de roșu în instrumentul de erori și sunt decizii complet diferite pentru afacerea ta.

Ce măsori, în ordine

Măsoară drumul până la lucrul care îți aduce bani, apoi oprește-te. Un set de pornire care funcționează pentru majoritatea aplicațiilor:

Ce măsori	La ce întrebare răspunde
Deschiderea aplicației, cu versiunea aplicației	Cine e aici și pe ce versiune
Activarea, primul moment de valoare reală	Ajung oamenii noi vreodată la miez?
Acțiunea principală, repetată	Devine aplicația un obicei sau a fost o curiozitate?
Evenimentul care aduce bani (cumpărare, abonament, rezervare, lead)	Se transformă ceva din toate astea în venit?
Punctele de abandon de pe drumul ăla	Unde exact renunță oamenii?
Sesiuni fără erori, pe versiune	E versiunea curentă destul de stabilă ca să o împing mai departe?

Șase linii. Fiecare dintre ele e o decizie pe care chiar o vei lua. Adaugi altele mai târziu, când ai o întrebare concretă la care setul curent nu poate răspunde, și numești evenimentul după întrebare.

Motivul pentru care îl ții mic nu e ordinea de dragul ordinii. Un plan de evenimente cu 200 de intrări putrezește întotdeauna: numele o iau razna, nimeni nu mai știe care dintre checkout_done și purchase_complete e cel real, iar peste șase luni nimeni nu are destulă încredere în cifre cât să acționeze pe baza lor. Un dashboard în care nu ai încredere e mai rău decât niciun dashboard, pentru că tot te costă timpul în care vă certați pe el.

Ai o aplicație live și nu știi ce dintre astea măsori? Hai să ne uităm împreună într-un call gratuit de 30 de minute sau scrie-ne în două rânduri. Pleci cu lista scurtă a ce lipsește, chiar dacă nu lucrăm împreună.

Ce ignori

Unele cifre arată a progres și nu spun nimic:

• Numărul total de descărcări. Măsoară marketingul, nu produsul. O aplicație poate aduna instalări în fiecare săptămână și, în același timp, să piardă pe absolut toți cei care o instalează.
• Durata sesiunii, fără context. Mai lung e bine într-o aplicație socială și prost într-una utilitară. Singură, cifra nu are direcție.
• Utilizatori activi zilnic, ca număr izolat. Fără să știi dacă sunt aceiași oameni care revin sau oameni noi care se perindă, cifra ascunde abandonul în loc să îl arate.
• Vizualizările de ecrane. Îți spun că oamenii s-au uitat. Nu îți spun că a ajuns cineva undeva.
• Nota medie, urmărită zilnic. Se mișcă prea încet ca să acționezi pe ea și prea emoțional ca să fie discutată calm.

Niciuna dintre ele nu e inutilă pentru totdeauna. Sunt doar inutile ca primele șase evenimente ale tale, ceea ce e exact locul în care ajung de obicei.

Capcanele despre care nu vorbește nimeni care îți vinde un dashboard

Datele de test îți vor polua cifrele de producție. Dacă build-urile de development și cele de producție folosesc aceeași cheie de analytics, rapoartele se umplu discret cu propriile tale apăsări, cu rulările de QA și cu sesiunile din simulator. Graficele arată în continuare plauzibil, și exact asta le face scumpe: se iau decizii pe date contaminate și nimeni nu are motiv să le pună la îndoială. Chei separate pe medii, din prima zi, și tratează cheia de analytics exact ca pe orice altă configurare de mediu.

Consimțământul înseamnă că cifrele tale sunt incomplete prin construcție. Framework-ul App Tracking Transparency de la Apple cere aplicațiilor să solicite permisiunea înainte de a urmări utilizatorii în aplicații și site-uri deținute de alte companii, iar fără ea aplicația nu poate folosi identificatorul de publicitate. Peste asta se adaugă consimțământul GDPR. O parte dintre utilizatori va refuza, și nu există nicio setare prin care să îi recuperezi. Planifică să îți citești datele ca pe un eșantion constant în timp, nu ca pe un recensământ.

Plafonul de 500 de evenimente e un buget, nu o țintă. Firebase oferă raportare gratuită și nelimitată pe până la 500 de evenimente distincte. Echipele citesc asta ca pe o invitație. E un plafon, iar când îl atingi nu mai poți adăuga exact evenimentul de care ai nevoie.

Cifrele nelegate de o versiune de aplicație sunt greu de folosit. Când o metrică se mișcă, prima întrebare e mereu dacă s-a lansat ceva. Dacă evenimentele tale nu poartă versiunea aplicației, nu poți răspunde, iar în mobil asta contează mai mult decât oriunde, pentru că mai multe versiuni ale aplicației tale sunt mereu live în același timp. Am scris despre controlul versiunilor în ce rămâne după ce AI scrie codul.

Gratuit e, de obicei, suficient la început

Nu trebuie să cumperi nimic ca să răspunzi la primele întrebări:

• Firebase Analytics e gratuit, cu raportare nelimitată pe până la 500 de evenimente distincte.
• App Store Connect raportează gratuit afișări, vizualizări ale paginii de produs, descărcări, sesiuni, retenție și rata de erori, plus comparații cu aplicații similare.
• Google Play Console raportează achiziții, dezinstalări, utilizatori activi, erori și ANR-uri, și retenție la 2, 3, 7, 14 și 28 de zile.
• Amândouă sunt singurele surse pentru ce se întâmplă înainte de instalare, unde SDK-ul tău nu are cum să vadă.
• PostHog și Sentry au amândouă niveluri gratuite care acoperă confortabil o aplicație în prima ei fază.

Variantele plătite devin justificate când rulezi experimente continuu sau ai nevoie de session replay ca să înțelegi un flux pe care nu îl poți deduce. Nu înainte. Cumpărarea unui dashboard mai mare ca să rezolvi „nu știm ce să construim” produce, constant, un dashboard mai mare.

Cum se transformă asta în decizii

Tot ce e mai sus nu valorează nimic dacă nu se uită nimeni. Ce îl face să funcționeze e plictisitor: un slot recurent, lunar e suficient la început, în care cineva deschide patru lucruri.

Retenția pe cohorte săptămânale, ca să vezi dacă oamenii veniți după ultima lansare rămân mai mult decât cei dinainte. Abandonul de pe drumul către bani, ca să alegi următorul lucru de reparat. Sesiunile fără erori pe versiune, ca să decizi dacă versiunea curentă e sigură de împins mai departe. Și singurul experiment pe care îl rulai, ca să îl închizi cu o decizie în loc să îl lași să curgă la nesfârșit.

Asta e toată bucla. Lansezi, măsori raportat la versiune, decizi, lansezi din nou. Instrumentele sunt partea ușoară, și sunt exact partea pe care ți-o vinde cu plăcere orice alt articol pe tema asta.

Întrebări frecvente

Ce înseamnă analytics pentru aplicații mobile? Înseamnă colectarea și măsurarea a ceea ce fac utilizatorii într-o aplicație de iOS sau Android. Un SDK din aplicație înregistrează acțiunile ca evenimente, le trimite către un serviciu în cloud, iar acesta le transformă în dashboard-uri, fluxuri de utilizare, pâlnii și rapoarte de retenție.

Care e cel mai bun instrument de analytics pentru aplicații mobile? Nu există unul singur, pentru că datele de comportament și erorile sunt probleme diferite. Pentru o echipă la început, combinația obișnuită e un instrument de analytics de produs (PostHog, Mixpanel, Amplitude sau Firebase) plus unul de monitorizare a erorilor (Sentry). Firebase Analytics e gratuit, cu raportare nelimitată pe până la 500 de evenimente distincte, deci e punctul obișnuit de pornire.

Pot folosi Google Analytics pentru aplicații mobile? Da. Google Analytics for Firebase e versiunea pentru aplicații a Google Analytics, acoperă iOS, Android, web, C++ și Unity, și nu costă nimic. Raportează pe până la 500 de evenimente distincte per aplicație, cu volum nelimitat în interiorul lor.

Ce e App Analytics din App Store Connect? E raportarea gratuită a Apple despre performanța aplicației tale în magazin și în uz. Apple documentează afișări, vizualizări ale paginii de produs, descărcări, rata de conversie, dispozitive active, sesiuni, rata de retenție și rata de erori, plus comparații cu aplicații similare. E separată de orice SDK instalezi și e singurul loc din care vezi ce s-a întâmplat înainte ca cineva să instaleze aplicația.

Există analytics gratuit pentru aplicații mobile? Da. Firebase Analytics e gratuit, cu raportare nelimitată pe până la 500 de evenimente distincte, App Store Connect și Google Play Console raportează gratuit instalările și erorile, iar PostHog și Sentry au niveluri gratuite care acoperă faza de început.

Ce ar trebui să măsori într-o aplicație mobilă? Începe cu patru până la șase evenimente care urmăresc drumul către venit: deschiderea aplicației cu versiunea, activarea (primul moment de valoare reală), acțiunea principală repetată, evenimentul care aduce bani, punctele de abandon de pe drum și sesiunile fără erori pe versiune. Adaugi altele doar când ai o întrebare la care setul curent nu răspunde.

De ce nu se potrivesc cifrele mele cu cele din App Store? Pentru că măsoară lucruri diferite și populații diferite. App Store Connect numără evenimente din magazin, precum afișări și descărcări, iar Apple precizează că datele includ doar utilizatorii care au acceptat să partajeze diagnostice. SDK-ul tău, la rândul lui, vede doar oamenii care au deschis aplicația și au acceptat urmărirea, iar framework-ul App Tracking Transparency cere permisiune înainte de urmărirea în aplicațiile și site-urile altor companii. Niciuna dintre cifre nu e o numărătoare completă.

Prin ce diferă analytics pentru aplicații de analytics pentru site-uri? Pe web, toată lumea vede versiunea curentă la următoarea încărcare. Într-o aplicație, oamenii stau pe versiuni instalate acum câteva săptămâni, actualizează când vor ei și pot refuza complet urmărirea. Asta face din versiunea aplicației o dimensiune obligatorie pe fiecare eveniment și transformă totalurile tale într-un eșantion constant, nu într-o numărătoare completă.

Construiești o aplicație sau încerci să înțelegi de ce nu crește cea pe care o ai? Scrie-ne în două rânduri sau rezervă un call de 30 de minute: trecem prin drumul către banii tăi și prin evenimentele care ar trebui să stea pe el, fără obligații. Costurile și termenele sunt în cât costă o aplicație mobilă în 2026.