Session в мобилната аналитика: какво е това, как се изчислява и какви метрики

Какво е сесия в мобилната аналитика?

Сесия е времеви период, през който потребителят активно взаимодейства с приложението. Сесията започва от момента на отваряне на приложението (или връщане от фонов режим) и приключва след период на бездействие или затваряне.

Различните аналитични платформи определят границите на сесията по различен начин. Firebase Analytics счита сесията за приключила след 30 минути бездействие, AppsFlyer — след 60 минути, Amplitude — след 5 минути или чрез събитие session_end. Няма единен стандарт.

Защо сесиите са важни

Метриките, базирани на сесии, са основа за изчисляване на задържането (Retention Rate), дълбочината на ангажираност (Stickiness Ratio) и разпределението на потребителите по честота на използване (Session Frequency). Без правилно определение на сесията всички производни метрики ще бъдат грешни.

Според данни на Mixpanel (2024), приложенията, които са подобрили Session Duration с 15%, показват ръст на LTV с 22% в рамките на тримесечие. Това е пряка корелация между времето в приложението и монетизацията.

Как се измерва сесията?

Измерването на сесията се базира на събития от жизнения цикъл на приложението: open (session_start) и close (session_end). В промеждутъка между тях се регистрират всички действия на потребителя.

// Най-прост тракер на сесии за 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
    }
}

Кодът проследява началото и края на сесията чрез системни обратни извиквания. Параметърът SESSION_TIMEOUT (30 минути) определя кога връщането от фонов режим се счита за нова сесия, а не за продължение на предишната.

Правила за таймаут на различните платформи

Изборът на таймаут влияе на метриките: кратък таймаут (5 мин) създава повече сесии, дълъг таймаут (60 мин) — обединява взаимодействията. Най-важното — да се установи правило и да не се променя при сравняване на периоди.

Ключови метрики на сесията

Анализът на сесиите се опира на четири основни метрики. Всяка разкрива определен аспект от поведението на потребителя.

Session Duration

Продължителност на сесията — средното време, което потребителят прекарва в приложението за едно посещение. За новинарски приложения нормата е 2–4 минути, за игри — 8–15 минути, за стрийминг услуги — 20+ минути. Ако Session Duration пада, това е сигнал за проблеми със съдържанието или производителността.

Session Interval

Интервал между сесиите — времето между края на предишната сесия и началото на следващата. Кратък интервал (минути или часове) показва висока ангажираност. Дълъг интервал (дни) — нисък интерес или сценарий на полезност, когато приложението е необходимо рядко.

Sessions Per User

Брой сесии на потребител за период (ден, седмица, месец) — индикатор за Stickiness. Формула: DAU / MAU (Day Active Users / Monthly Active Users). Стойност над 20% се счита за добра, над 50% — за отлична за повечето категории приложения.

Session Depth

Дълбочина на сесията — брой екрани или действия в рамките на една сесия. Показва колко дълбоко потребителят навлиза във функционалността на приложението. Ниска дълбочина при висока продължителност показва проблеми с навигацията.

• Session Duration — време в приложението на посещение
• Session Interval — честота на връщанията
• Sessions Per User — ниво на ангажираност
• Session Depth — качество на взаимодействие

Сесия в iOS и Android

Платформени различия в жизнения цикъл на приложението пряко влияят върху определението на сесията. iOS и Android обработват фоновете състояния и известията по различен начин.

Android — жизнен цикъл на Activity

На Android сесията започва при извикване на onStart() на първото Activity и завършва при onStop() на последното Activity. Системата обаче може да убие процеса във фонов режим, което фалшиво приключва сесията. Препоръчва се използване на Application.ActivityLifecycleCallbacks за надеждно проследяване.

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()
                }
            }
        })
    }
}

Броячът activityReferences определя дали потребителят вижда поне един екран. Когато активността стане 0 — приложението е преминало във фонов режим, сесията е приключила.

iOS — UIApplicationDelegate

На iOS сесията е свързана с методите applicationDidBecomeActive и applicationDidEnterBackground. Известията за кликване върху push известие могат изкуствено да повишат брояча на сесии — това трябва да се вземе предвид в аналитиката.

Пример на Swift:

import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {

    func applicationDidBecomeActive(_ application: UIApplication) {
        Analytics.trackSessionStart()
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        Analytics.trackSessionEnd()
    }
}

Обърнете внимание: на iOS превключването между приложения (App Switcher) не приключва сесията — само преминаване в дълбок фонов режим или плъзгане за затваряне.

Как да анализираме потребителските сесии?

Анализът на сесии надхвърля простото преброяване. Сегментирането и кохортният анализ разкриват модели на ангажираност, които не се виждат в агрегираните данни.

Кохортен анализ на сесии

Групирайте потребителите по седмица на инсталиране и вижте средния брой сесии през първите 7 дни. Ако в кохортата на последните инсталации Sessions Per User е по-нисък от по-старите, това е сигнал за влошаване на onboarding или качеството на трафика.

• Ден 0 — инсталиране + първа сесия
• Дни 1–3 — период на активиране (очакват се 3+ сесии)
• Дни 7–30 — формиране на навик (стабилни 1–2 сесии на ден)
• Ден 30+ — задържане на лоялни потребители

Аномалии на сесията: как да ги откриваме

Аномалиите в метриките на сесията са ранни индикатори за проблеми. Внезапно нарастване на кратки сесии (до 5 секунди) след издаване показва грешка при стартиране. Пад на Session Duration с 30% за един ден — възможна повреда на сървър или промяна на API. Настройте мониторинг с прагове: ако средната Session Duration е паднала с повече от 2 стандартни отклонения от 7-дневната плъзгаща средна — аларма в системата.

Използвайте сегментиране по версия на приложението в отчетите за сесии. Версия 3.2.0 показва Session Duration 4 минути, версия 3.2.1 — 2 минути. Причина — промяна в onboarding. Връщането на версията възстановява метриката. Без сегментиране по версия бихте видели среден спад, но не бихте намерили причината.

Сегментиране по честота на сесиите

Power Users (5+ сесии на ден) — вашата ключова аудитория. Casual Users (1–2 сесии на седмица) — група за реактивация. Dormant Users (0 сесии за 30 дни) — кандидати за ретаргетиране или отписване от push известия.

За всеки сегмент изчислявайте отделни метрики: Session Duration за Power Users ще покаже дълбочината на използване, а за Casual — бариерите за влизане. Според данни на Amplitude (2024), приложенията, които персонализират съдържанието според сегмента на сесията, увеличават Session Duration средно с 18% на месец.

Използване на сесии в отчетите за задържане

Задържането се изчислява чрез сесии: потребителят е задържан на ден N, ако е имал поне една сесия. Различните продукти обаче изискват различни определения. За социалните мрежи сесията може да бъде 1 секунда (просто отворил да провери известията), за стрийминг услуга — 15 минути.

Използвайте сесии за деинсталиране като индикатор за качество: ако след актуализация е нараснал броят на кратките сесии (по-малко от 10 секунди), потребителите не намират необходимата функционалност. Това е ранен сигнал за UX проблеми преди нарастване на деинсталиранията.

Сесийна атрибуция на трафика

Свържете сесиите с източника на трафик: потребителите от платени канали трябва да имат повече сесии и по-голяма Session Duration. Ако органичният трафик показва Session Duration с 40% по-висок от платения, проблемът е в качеството на таргетиране. Сесийната атрибуция помага за оптимизиране на бюджета за привличане.