Session în analitica mobilă este o perioadă de interacțiune continuă a utilizatorului cu aplicația, limitată în timp. Metrica servește ca bază pentru calcularea retenției, implicării și LTV. Conform datelor Adjust, 2025, lungimea medie a sesiunii în aplicații este de 4–7 minute, dar variază foarte mult între categorii. Înțelegerea metricilor sesiunii este esențială pentru evaluarea calității experienței utilizatorului.
Principalele idei
Sesiunea este o perioadă de timp în care utilizatorul interacționează activ cu aplicația. Sesiunea începe din momentul deschiderii aplicației (sau revenirii din fundal) și se termină după o perioadă de inactivitate sau închidere.
Diferite platforme analitice definesc limitele sesiunii în mod diferit. Firebase Analytics consideră sesiunea încheiată după 30 de minute de inactivitate, AppsFlyer — după 60 de minute, Amplitude — după 5 minute sau prin evenimentul session_end. Nu există un standard unic.
Metricile bazate pe sesiuni stau la baza calculării retenției (Retention Rate), adâncimii implicării (Stickiness Ratio) și distribuției utilizatorilor după frecvența de utilizare (Session Frequency). Fără o definiție corectă a sesiunii, toate metricile derivate vor fi incorecte.
Conform datelor Mixpanel (2024), aplicațiile care au îmbunătățit Session Duration cu 15% demonstrează o creștere a LTV cu 22% în decursul unui trimestru. Aceasta este o corelație directă între timpul petrecut în aplicație și monetizare.
Măsurarea sesiunii se bazează pe evenimentele ciclului de viață al aplicației: open (session_start) și close (session_end). În intervalul dintre ele se înregistrează toate acțiunile utilizatorului.
// Cel mai simplu tracker de sesiuni pentru Android
class SessionTracker {
private var sessionStart: Long = 0L
private val SESSION_TIMEOUT = 30 * 60 * 1000L
fun onAppOpened() {
sessionStart = System.currentTimeMillis()
Analytics.logEvent("session_start")
}
fun onAppClosed() {
val duration = System.currentTimeMillis() - sessionStart
Analytics.logEvent("session_end") {
param("duration_ms", duration)
}
}
fun isNewSession(lastActive: Long): Boolean {
return (System.currentTimeMillis() - lastActive) > SESSION_TIMEOUT
}
}
Codul urmărește începutul și sfârșitul sesiunii prin callback-uri de sistem. Parametrul SESSION_TIMEOUT (30 de minute) determină când revenirea din fundal este considerată o sesiune nouă, nu o continuare a celei anterioare.
| Platforma | Timeout sesiune | Mod de determinare |
|---|---|---|
| Firebase Analytics | 30 min | Automat, fără personalizare |
| Amplitude | 5 min (implicit) | Configurabil prin SDK |
| AppsFlyer | 60 min | Interval fix |
| Mixpanel | 30 min | Configurabil prin opțiunea minimumSessionDuration |
| Adjust | 60 min | Automat, legat de ciclul de viață |
Alegerea timeout-ului influențează metricile: un timeout scurt (5 min) creează mai multe sesiuni, un timeout lung (60 min) — combină interacțiunile. Cel mai important — stabiliți regula și nu o modificați la compararea perioadelor.
Analiza sesiunilor se bazează pe patru metrici de bază. Fiecare dezvăluie un anumit aspect al comportamentului utilizatorului.
Durata sesiunii — timpul mediu pe care utilizatorul îl petrece în aplicație într-o singură vizită. Pentru aplicațiile de știri, norma este de 2–4 minute, pentru jocuri — 8–15 minute, pentru serviciile de streaming — 20+ minute. Dacă Session Duration scade, este un semnal al problemelor cu conținutul sau performanța.
Intervalul dintre sesiuni — timpul dintre sfârșitul sesiunii anterioare și începutul următoarei. Un interval scurt (minute sau ore) indică o implicare ridicată. Un interval lung (zile) — interes scăzut sau un scenariu utilitar, când aplicația este necesară rar.
Numărul de sesiuni per utilizator într-o perioadă (zi, săptămână, lună) — indicatorul Stickiness. Formula: DAU / MAU (Day Active Users / Monthly Active Users). O valoare peste 20% este considerată bună, peste 50% — excelentă pentru majoritatea categoriilor de aplicații.
Adâncimea sesiunii — numărul de ecrane sau acțiuni într-o singură sesiune. Arată cât de mult se adâncește utilizatorul în funcționalitatea aplicației. O adâncime mică la o durată mare indică probleme de navigare.
Diferențele de platformă în ciclul de viață al aplicației influențează direct definiția sesiunii. iOS și Android gestionează diferit stările de fundal și notificările.
Pe Android, sesiunea începe la apelarea onStart() primului Activity și se termină la onStop() ultimului Activity. Cu toate acestea, sistemul poate ucide procesul în fundal, ceea ce va încheia fals sesiunea. Se recomandă utilizarea Application.ActivityLifecycleCallbacks pentru o urmărire fiabilă.
class AnalyticsApp : Application() {
private var activityReferences = 0
override fun onCreate() {
super.onCreate()
registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks {
override fun onActivityStarted(act: Activity) {
if (++activityReferences == 1) {
Analytics.trackSessionStart()
}
}
override fun onActivityStopped(act: Activity) {
if (--activityReferences == 0) {
Analytics.trackSessionEnd()
}
}
})
}
}
Contorul activityReferences determină dacă utilizatorul vede cel puțin un ecran. Când numărul de activități devine 0 — aplicația a intrat în fundal, sesiunea s-a încheiat.
Pe iOS, sesiunea este legată de metodele applicationDidBecomeActive și applicationDidEnterBackground. Notificările de apăsare pe o notificare push pot crește artificial contorul de sesiuni — acest lucru trebuie luat în considerare în analitică.
Exemplu Swift:
import UIKit
class AppDelegate: UIResponder, UIApplicationDelegate {
func applicationDidBecomeActive(_ application: UIApplication) {
Analytics.trackSessionStart()
}
func applicationDidEnterBackground(_ application: UIApplication) {
Analytics.trackSessionEnd()
}
}
Rețineți: pe iOS, comutarea între aplicații (App Switcher) nu încheie sesiunea — doar intrarea în fundal profund sau glisarea pentru închidere.
Analiza sesiunilor depășește simpla numărare. Segmentarea și analiza pe cohorte dezvăluie modele de implicare care nu pot fi văzute în datele agregate.
Grupați utilizatorii după săptămâna de instalare și verificați numărul mediu de sesiuni în primele 7 zile. Dacă pentru cohorta instalărilor recente Sessions Per User este mai mic decât pentru cele mai vechi, acesta este un semnal de deteriorare a onboardingu-lui sau a calității traficului.
Anomaliile în metricile sesiunii sunt indicatori timpurii ai problemelor. O creștere bruscă a sesiunilor scurte (până la 5 secunde) după o lansare indică o eroare la pornire. O scădere a Session Duration cu 30% într-o zi — o posibilă defecțiune a serverului sau o schimbare a API-ului. Configurați monitorizarea cu praguri: dacă Session Duration medie a scăzut cu mai mult de 2 abateri standard de la media mobilă pe 7 zile — alertă în sistem.
Utilizați segmentarea după versiunea aplicației în rapoartele de sesiuni. Versiunea 3.2.0 arată o Session Duration de 4 minute, versiunea 3.2.1 — 2 minute. Cauza — o modificare în onboarding. Revenirea la versiunea anterioară restabilește metrica. Fără segmentarea după versiune, ați vedea o scădere medie, dar nu ați găsi cauza.
Power Users (5+ sesiuni pe zi) — publicul vostru cheie. Casual Users (1–2 sesiuni pe săptămână) — grupul pentru reactivare. Dormant Users (0 sesiuni în 30 de zile) — candidați pentru retargeting sau dezabonare de la notificările push.
Pentru fiecare segment, calculați metrici separate: Session Duration pentru Power Users va arăta adâncimea utilizării, iar pentru Casual — barierele de intrare. Conform datelor Amplitude (2024), aplicațiile care personalizează conținutul pe segmentul de sesiuni cresc Session Duration cu 18% în medie pe lună.
Retenția se calculează prin sesiuni: utilizatorul este reținut în ziua N dacă a avut cel puțin o sesiune. Cu toate acestea, diferite produse necesită definiții diferite. Pentru rețelele sociale, sesiunea poate fi de 1 secundă (doar a deschis să verifice notificările), pentru un serviciu de streaming — 15 minute.
Utilizați sesiunile de dezinstalare ca indicator de calitate: dacă după o actualizare a crescut numărul de sesiuni scurte (sub 10 secunde), utilizatorii nu găsesc funcționalitatea necesară. Acesta este un semnal timpuriu al problemelor de UX înainte de creșterea dezinstalărilor.
Conectați sesiunile cu sursa de trafic: utilizatorii din canalele plătite ar trebui să aibă mai multe sesiuni și o Session Duration mai mare. Dacă traficul organic arată o Session Duration cu 40% mai mare decât cel plătit, problema este în calitatea targetării. Atribuirea sesiunilor ajută la optimizarea bugetului de achiziție.
Întrebări frecvente
Durata medie a sesiunii depinde de categorie: jocuri — 8–15 minute, rețele sociale — 5–10 minute, utilități — 1–3 minute. Tendința este mai importantă: dacă Session Duration scade cu 20% într-o lună, este necesar un audit UX.
Multe SDK-uri analitice nu înregistrează evenimentul de sfârșit la minimizare — așteaptă timeout-ul. Dacă utilizatorul a minimizat aplicația pentru 1 minut și s-a întors, aceasta este considerată o singură sesiune. Doar după timeout (30–60 min) începe o sesiune nouă.
Retenția utilizatorului în ziua N se calculează ca proporția celor care au instalat și au avut cel puțin o sesiune în acea zi. Dacă sesiunile nu sunt urmărite corect, retenția va fi sistematic subestimată sau supraestimată.
Da, activitatea în fundal (redarea muzicii, navigația, sincronizarea) poate menține aplicația în stare activă. Este mai bine să separați sesiunile de prim-plan (utilizatorul vede ecranul) de sesiunile de proces (activitate în fundal fără interfață).
Pentru serviciile cu abonament (streaming, fitness, educație) se recomandă un timeout de 5–10 minute. Utilizatorii revin adesea după o pauză scurtă — și fiecare pauză ar trebui să fie considerată o sesiune nouă pentru a nu distorsiona Session Duration.
Concluzii
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și