Session در تحلیل موبایل: چیست، نحوه محاسبه و چه معیارهایی

نشست در تحلیل موبایل چیست؟

نشست بازه زمانی است که در آن کاربر به طور فعال با برنامه تعامل دارد. نشست از لحظه باز کردن برنامه (یا بازگشت از پس‌زمینه) شروع می‌شود و پس از دوره عدم فعالیت یا بسته شدن پایان می‌یابد.

پلتفرم‌های تحلیلی مختلف مرزهای نشست را متفاوت تعریف می‌کنند. Firebase Analytics نشست را پس از ۳۰ دقیقه عدم فعالیت تمام‌شده می‌داند، AppsFlyer — پس از ۶۰ دقیقه، Amplitude — پس از ۵ دقیقه یا با رویداد session_end. استاندارد واحدی وجود ندارد.

چرا نشست‌ها مهم هستند

معیارهای مبتنی بر نشست مبنای محاسبه نگهداشت (Retention Rate)، عمق درگیری (Stickiness Ratio) و توزیع کاربران بر اساس دفعات استفاده (Session Frequency) هستند. بدون تعریف صحیح نشست، همه معیارهای مشتق شده نادرست خواهند بود.

طبق داده‌های Mixpanel (2024)، برنامه‌هایی که Session Duration را ۱۵٪ بهبود داده‌اند، رشد LTV را به میزان ۲۲٪ در طول یک سه‌ماهه نشان می‌دهند. این همبستگی مستقیم بین زمان در برنامه و درآمدزایی است.

نشست چگونه اندازه‌گیری می‌شود؟

اندازه‌گیری نشست بر اساس رویدادهای چرخه حیات برنامه است: باز کردن (session_start) و بستن (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 (۳۰ دقیقه) تعیین می‌کند که چه زمانی بازگشت از پس‌زمینه به عنوان نشست جدید محسوب می‌شود نه ادامه نشست قبلی.

قوانین تایم‌اوت پلتفرم‌های مختلف

انتخاب تایم‌اوت بر معیارها تأثیر می‌گذارد: تایم‌اوت کوتاه (۵ دقیقه) نشست‌های بیشتری ایجاد می‌کند، تایم‌اوت طولانی (۶۰ دقیقه) — تعاملات را ترکیب می‌کند. نکته اصلی — قانون را تعیین کرده و هنگام مقایسه دوره‌ها آن را تغییر ندهید.

معیارهای کلیدی نشست

تحلیل نشست‌ها بر چهار معیار اساسی استوار است. هر کدام جنبه خاصی از رفتار کاربر را آشکار می‌کند.

Session Duration

مدت زمان نشست — میانگین زمانی که کاربر در یک بازدید در برنامه سپری می‌کند. برای برنامه‌های خبری نرمال ۲–۴ دقیقه، برای بازی‌ها — ۸–۱۵ دقیقه، برای سرویس‌های پخش — ۲۰+ دقیقه است. اگر Session Duration کاهش یابد، این نشانه مشکلات محتوا یا عملکرد است.

Session Interval

فاصله بین نشست‌ها — زمان بین پایان نشست قبلی و شروع نشست بعدی. فاصله کوتاه (دقیقه یا ساعت) نشان‌دهنده درگیری بالا است. فاصله طولانی (روزها) — نشان‌دهنده علاقه کم یا سناریوی کاربردی است که در آن برنامه به ندرت نیاز است.

Sessions Per User

تعداد نشست‌ها به ازای هر کاربر در یک دوره (روز، هفته، ماه) — شاخص چسبندگی (Stickiness). فرمول: DAU / MAU (Day Active Users / Monthly Active Users). مقدار بالای ۲۰٪ خوب و بالای ۵۰٪ برای اکثر دسته‌های برنامه عالی محسوب می‌شود.

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 تعیین می‌کند که آیا کاربر حداقل یک صفحه را می‌بیند. وقتی تعداد فعالیت‌ها به ۰ می‌رسد — برنامه به پس‌زمینه رفته، نشست پایان یافته است.

iOS — UIApplicationDelegate

در iOS، نشست به متدهای applicationDidBecomeActive و applicationDidEnterBackground متصل است. اعلان‌های کلیک بر روی اعلان فشاری می‌توانند به طور مصنوعی شمارنده نشست را افزایش دهند — این باید در تحلیل در نظر گرفته شود.

مثال Swift:

import UIKit

class AppDelegate: UIResponder, UIApplicationDelegate {

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

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

توجه کنید: در iOS، جابجایی بین برنامه‌ها (App Switcher) نشست را پایان نمی‌دهد — فقط رفتن به پس‌زمینه عمیق یا کشیدن برای بستن.

چگونه نشست‌های کاربران را تحلیل کنیم؟

تحلیل نشست‌ها فراتر از شمارش ساده است. بخش‌بندی و تحلیل گروهی الگوهای درگیری را آشکار می‌کند که در داده‌های تجمیع‌شده دیده نمی‌شوند.

تحلیل گروهی نشست‌ها

کاربران را بر اساس هفته نصب گروه‌بندی کنید و میانگین تعداد نشست‌ها در ۷ روز اول را بررسی کنید. اگر در گروه آخرین نصب‌ها Sessions Per User کمتر از گروه‌های قدیمی‌تر باشد، این نشانه بدتر شدن راهنمای ورود یا کیفیت ترافیک است.

• روز ۰ — نصب + اولین نشست
• روز ۱–۳ — دوره فعال‌سازی (انتظار ۳+ نشست)
• روز ۷–۳۰ — شکل‌گیری عادت (۱–۲ نشست ثابت در روز)
• روز ۳۰+ — نگهداشت کاربران وفادار

ناهنجاری‌های نشست: چگونه آنها را شناسایی کنیم

ناهنجاری‌ها در معیارهای نشست نشانه‌های اولیه مشکلات هستند. افزایش ناگهانی نشست‌های کوتاه (تا ۵ ثانیه) پس از انتشار نشان‌دهنده باگ در راه‌اندازی است. کاهش Session Duration به میزان ۳۰٪ در یک روز — احتمال خرابی سرور یا تغییر API. نظارت را با آستانه‌ها تنظیم کنید: اگر میانگین Session Duration بیش از ۲ انحراف معیار از میانگین متحرک ۷ روزه کاهش یافت — هشدار در سیستم.

در گزارش‌های نشست از بخش‌بندی بر اساس نسخه برنامه استفاده کنید. نسخه ۳.۲.۰ Session Duration را ۴ دقیقه نشان می‌دهد، نسخه ۳.۲.۱ — ۲ دقیقه. دلیل — تغییر در راهنمای ورود. بازگشت نسخه معیار را بازیابی می‌کند. بدون بخش‌بندی بر اساس نسخه، کاهش متوسط را می‌دیدید اما دلیل را پیدا نمی‌کردید.

بخش‌بندی بر اساس دفعات نشست

کاربران قدرتمند (۵+ نشست در روز) — مخاطب کلیدی شما. کاربران معمولی (۱–۲ نشست در هفته) — گروه برای فعال‌سازی مجدد. کاربران غیرفعال (۰ نشست در ۳۰ روز) — نامزدهای هدف‌گیری مجدد یا لغو اشتراک اعلان‌های فشاری.

برای هر بخش معیارهای جداگانه محاسبه کنید: Session Duration برای کاربران قدرتمند عمق استفاده را نشان می‌دهد و برای کاربران معمولی — موانع ورود. طبق داده‌های Amplitude (2024)، برنامه‌هایی که محتوا را بر اساس بخش نشست شخصی‌سازی می‌کنند، Session Duration را به طور متوسط ۱۸٪ در ماه افزایش می‌دهند.

استفاده از نشست‌ها در گزارش‌های Retention

نگهداشت از طریق نشست‌ها محاسبه می‌شود: کاربر در روز N نگهداشته شده در نظر گرفته می‌شود اگر حداقل یک نشست داشته باشد. با این حال، محصولات مختلف نیاز به تعاریف مختلف دارند. برای شبکه‌های اجتماعی، نشست ممکن است ۱ ثانیه باشد (فقط برای بررسی اعلان‌ها باز کرده)، برای سرویس پخش — ۱۵ دقیقه.

از نشست‌های حذف نصب به عنوان شاخص کیفیت استفاده کنید: اگر پس از به‌روزرسانی تعداد نشست‌های کوتاه (کمتر از ۱۰ ثانیه) افزایش یافت، کاربران عملکرد مورد نیاز را پیدا نمی‌کنند. این نشانه اولیه مشکل UX قبل از افزایش حذف نصب‌ها است.

تخصیص نشست به منابع ترافیک

نشست‌ها را به منبع ترافیک متصل کنید: کاربران کانال‌های پولی باید نشست‌های بیشتر و Session Duration بالاتری داشته باشند. اگر ترافیک ارگانیک Session Duration را ۴۰٪ بالاتر از ترافیک پولی نشان می‌دهد، مشکل در کیفیت هدف‌گیری است. تخصیص نشست به بهینه‌سازی بودجه جذب کمک می‌کند.