Screen View در تحلیل موبایل — چیست، چه معیارهایی دارد و چگونه ردیابی کنیم

Screen View چیست؟

Screen View — رویداد تحلیلی است که هنگام باز شدن صفحه برنامه موبایل ارسال می‌شود. این رویداد شامل نام صفحه (screen_name)، کلاس (screen_class) و مهر زمانی است. برخلاف تحلیل وب، که page_view به URL متصل است، در برنامه‌های موبایل صفحه‌ها بر اساس نام Activity، Fragment، ViewController یا Custom View شناسایی می‌شوند.

ساختار رویداد Screen View

پارامتر previous_screen به ویژه مهم است: امکان بازسازی توالی انتقال‌ها و ساخت Screen Flow — نقشه مسیرهای کاربر در برنامه را فراهم می‌کند.

Screen View vs Page View: تفاوت‌های کلیدی

Screen View و Page View یک وظیفه — ثبت بازدید — را اما در محیط‌های مختلف حل می‌کنند. در وب، URL به طور یکتا صفحه را شناسایی می‌کند و Page View به بارگذاری سند متصل است. در برنامه‌های موبایل، صفحه یک وضعیت UI است که لزوماً با یک آدرس جداگانه مطابقت ندارد.

• Page View به درخواست HTTP و URL متصل است — Screen View به رویداد چرخه حیات Activity/ViewController متصل است
• Page View هنگام بازگشت به عقب تکراری نمی‌شود (از کش استفاده می‌کند) — Screen View با هر بار باز شدن صفحه دوباره ارسال می‌شود
• Page View به طور متوسط کوتاه‌تر است — کاربر صفحه وب را سریع‌تر از صفحه موبایل با عناصر تعاملی مرور می‌کند

تفاوت دیگر — عمق زمینه است. Screen View در برنامه موبایل شامل پارامترهای وضعیت است: آیا کاربر وارد شده است، چه داده‌هایی بارگذاری شده، آیا صفحه در حالت ویرایش باز است. Page View در وب به ندرت چنین زمینه‌ای دارد — فقط واقعیت بارگذاری URL را ثبت می‌کند. این باعث می‌شود Screen View برای تحلیل محصول اطلاعات‌بخش‌تر باشد، زیرا هر رویداد را می‌توان بر اساس وضعیت بخش‌بندی کرد.

اشتباهات معمول هنگام کار با Screen View

اشتباه اول — ارسال screen_view با هر تغییر وضعیت درون صفحه (تغییر زبانه، باز کردن پاپ‌آپ). Screen View باید فقط انتقال کامل به یک صفحه جدید را ثبت کند، نه ریزتعامل‌ها.

اشتباه دوم — استفاده از نام فنی کلاس به جای نام خوانا. «ProductDetailActivityKt» برای تحلیلگر بی‌فایده است — از «Product Details» در screen_name استفاده کنید.

اشتباه سوم — ارسال screen_view بدون فیلدهای مربوطه. screen_name خالی مجموعه‌ای از رکوردهای آشغال ایجاد می‌کند که قابل گروه‌بندی نیستند. همیشه حداقل screen_name و screen_class را ارسال کنید، حتی در صفحه‌های آزمایشی.

چگونه Screen View را ردیابی کنیم؟

پیاده‌سازی ردیابی Screen View به معماری ناوبری بستگی دارد. بیایید رویکردهای خودکار و دستی را با مثال Jetpack Compose و SwiftUI بررسی کنیم.

Android: ردیابی خودکار در Jetpack Compose

از LifecycleEventObserver در سطح NavigationComponent استفاده کنید. هر بار که کاربر به یک روت جدید می‌رود، رویداد screen_view فعال می‌شود.

class ScreenTrackingObserver(
    private val analytics: AnalyticsProvider
) : LifecycleEventObserver {

    override fun onStateChanged(
        source: LifecycleOwner,
        event: Lifecycle.Event
    ) {
        if (event == Lifecycle.Event.ON_RESUME) {
            val route = source.getRouteFromLifecycleOwner()
            analytics.logScreenView(
                screenName = route.screenName,
                screenClass = source.getLocalClassName()
            )
        }
    }
}

// اتصال در NavHost
fun NavBackStackEntry.trackScreenView(analytics: AnalyticsProvider) {
    lifecycle.addObserver(ScreenTrackingObserver(analytics))
}

این رویکرد تضمین می‌کند که screen_view با هر بار بازگشت صفحه به پیش‌زمینه، از جمله بازگشت از پس‌زمینه، ارسال می‌شود. Lifecycle.Event.ON_RESUME لحظه مناسب برای ردیابی است، نه ON_START و نه ON_CREATE.

iOS: ردیابی خودکار در SwiftUI

در SwiftUI از اصلاح‌کننده onAppear تعبیه‌شده در هر View استفاده می‌شود. برای خودکارسازی، یک ViewModifier ایجاد می‌شود.

struct ScreenTrackingModifier: ViewModifier {

    let screenName: String

    func body(content: Content) -> some View {
        content.onAppear {
            Analytics.shared().logScreenView(
                name: screenName,
                className: "\(Self.self)"
            )
        }
    }
}

extension View {
    func trackScreen(_ name: String) -> some View {
        modifier(ScreenTrackingModifier(screenName: name))
    }
}

// استفاده:
ProductDetailView()
    .trackScreen("Product Details")

اصلاح‌کننده trackScreen با یک خط به هر View اضافه می‌شود. این یک راه‌حل تمیز و مقیاس‌پذیر برای پروژه‌های SwiftUI است.

Screen View در پروژه‌های چندماژوله

در پروژه‌های با معماری ماژولی، هر ماژول ممکن است از نام‌گذاری خاص خود برای صفحه‌ها استفاده کند که منجر به تکراری شدن screen_name می‌شود. enum متمرکز ScreenName مشکل را حل می‌کند — همه صفحه‌ها بر اساس یک استاندارد واحد در یک مکان نام‌گذاری می‌شوند. افزودن یک صفحه جدید فقط به یک ثابت جدید در enum نیاز دارد، نه جستجو در کل کد.

برای توصیف screen_name با گروه‌بندی بر اساس ویژگی‌ها از sealed class استفاده کنید: ProfileScreen.CHANGE_PASSWORD، OrdersScreen.ORDER_HISTORY، CatalogScreen.SEARCH_RESULTS. این کار فیلتر کردن در گزارش‌های تحلیلی را ساده می‌کند.

Screen Flow: تحلیل انتقال بین صفحه‌ها

Screen Flow (یا Path Analysis) — تجسم توالی صفحه‌هایی است که کاربر طی می‌کند. این ابزار اصلی برای شناسایی تنگناها در ناوبری است.

ساخت Screen Flow

هر Screen View با پارامتر previous_screen یک یال از گراف ایجاد می‌کند: CatalogScreen → ProductDetails → CartScreen. با تجمیع همه انتقال‌ها، نقشه مسیرها ساخته می‌شود. قیف سه مرحله‌ای مبتنی بر Screen Flow نشان می‌دهد کاربران در کجا ترک می‌کنند.

• مرحله ۱: HomeScreen → CatalogScreen (۹۵٪ عبور می‌کنند)
• مرحله ۲: CatalogScreen → ProductDetails (۶۵٪ عبور می‌کنند — ۳۵٪ ترک می‌کنند)
• مرحله ۳: ProductDetails → AddToCart (۳۰٪ عبور می‌کنند — ۳۵٪ دیگر را از دست می‌دهیم)

بر اساس داده‌های Mixpanel (۲۰۲۴)، تحلیل Screen Flow تا ۴۰٪ از مشکلات UX را که در تحلیل رویدادهای فردی قابل مشاهده نیستند، آشکار می‌کند. به عنوان مثال، انتقال مکرر ProductDetails → HomeScreen بدون خرید نشان‌دهنده مشکل در قیمت یا توضیحات محصول است.

تحلیل Drop-off

Drop-off — نقطه‌ای که کاربر سناریو را ترک می‌کند. اگر پس از صفحه بارگذاری ۶۰٪ کاربران ترک کنند، مشکل در سرعت بارگذاری یا انیمیشن است. اگر پس از Paywall — در قیمت یا ارزش اشتراک.

Screen Flow در Firebase و BigQuery

Firebase گزارش آماده Screen Flow ارائه نمی‌دهد، اما داده‌های screen_view در BigQuery در دسترس هستند. یک کوئری بسازید که انتقال‌ها را بر اساس جفت (previous_screen, screen_name) گروه‌بندی و فراوانی را محاسبه کند. نتیجه — یک ماتریس انتقال که می‌تواند در Looker Studio به عنوان نمودار Sankey تجسم شود.

Screen Flow را با بخش‌بندی تکمیل کنید: جداگانه برای کاربران جدید (۷ روز اول) و کاربران بازگشتی. کاربران جدید بیشتر در صفحه‌های راهنمایی گیر می‌کنند، کاربران با تجربه سریع‌تر به اقدامات هدف می‌رسند. مقایسه دو جریان، تنگناهای سازگاری را آشکار می‌کند.

ابزارهای تحلیل Screen View

انتخاب ابزار برای Screen View به بودجه، پشته فناوری و جزئیات مورد نیاز بستگی دارد. بیایید سه راه‌حل محبوب را بررسی کنیم.

Firebase Analytics (رایگان)

Firebase به طور خودکار صفحه‌ها را از طریق پارامتر screen_view در هر رویداد ردیابی می‌کند. پس از ادغام SDK نیازی به کد اضافی ندارد. محدودیت: screen_name از Activity/ViewController تولید می‌شود که همیشه نام‌های خوانا نمی‌دهد.

Amplitude (حرفه‌ای)

Amplitude Pathfinder داخلی — سازنده بصری Screen Flow — را ارائه می‌دهد. از user property و بخش‌بندی بر اساس گروه‌ها پشتیبانی می‌کند. امکان تغییر نام صفحه‌ها در سمت سرور بدون تغییر در کد برنامه را فراهم می‌کند.

Mixpanel (بخش متوسط)

Mixpanel گزارش Flows را در زمان واقعی ارائه می‌دهد. می‌تواند نه تنها انتقال‌های خطی، بلکه انشعابات را نیز نشان دهد — کدام صفحه‌ها پس از یک صفحه خاص بازدید می‌شوند. با iOS، Android، Flutter و React Native SDK ادغام می‌شود.

تأثیر Screen View بر عملکرد

هر رویداد screen_view یک ارسال داده شبکه‌ای است. اگر برنامه در هر بار تغییر زبانه (۲۰+ بار در دقیقه) screen_view ارسال کند، بار اضافی ایجاد می‌کند. بهینه‌سازی: screen_view را بافر کرده و هر ۵ ثانیه به صورت دسته‌ای ارسال کنید. Firebase رویدادها را به طور خودکار تجمیع می‌کند، اما SDKهای سفارشی ممکن است هر فراخوانی را فوراً ارسال کنند.

سربار ردیابی را اندازه‌گیری کنید: یک مهر زمانی به هر screen_view اضافه کنید و تأخیر از onResume تا ارسال را محاسبه کنید. اگر تأخیر بیش از ۱۰۰ میلی‌ثانیه باشد، ردیابی بر UX تأثیر می‌گذارد. از یک نخ پس‌زمینه برای ارسال استفاده کنید تا نخ UI مسدود نشود. در دستگاه‌های سطح پایین، تفاوت قابل توجه است.