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 بتحميل المستند. في التطبيقات المحمولة، الشاشة هي حالة واجهة لا تتوافق بالضرورة مع عنوان منفصل.

• يرتبط 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، وليس البحث في جميع أنحاء الكود.

استخدم sealed class لوصف screen_name مع التجميع حسب الميزة: 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 يُظهر أين ينسحب المستخدمون.

• الخطوة 1: HomeScreen ← CatalogScreen (95% يستمرون)
• الخطوة 2: CatalogScreen ← ProductDetails (65% يستمرون — 35% يغادرون)
• الخطوة 3: ProductDetails ← AddToCart (30% يستمرون — نخسر 35% أخرى)

وفقًا لـ Mixpanel (2024)، يكشف تحليل Screen Flow عن ما يصل إلى 40% من مشاكل تجربة المستخدم التي لا تظهر عند تحليل الأحداث الفردية. على سبيل المثال، التنقل المتكرر ProductDetails ← HomeScreen بدون شراء يشير إلى مشكلة في السعر أو وصف المنتج.

تحليل الانسحاب (Drop-off)

Drop-off هو النقطة التي يغادر عندها المستخدم سيناريو. إذا غادر 60% من المستخدمين بعد شاشة التحميل، فالمشكلة في سرعة التحميل أو الرسوم المتحركة. إذا كان بعد Paywall — ففي تكلفة أو قيمة الاشتراك.

Screen Flow في Firebase وBigQuery

Firebase لا يوفر تقرير Screen Flow جاهز، لكن بيانات screen_view متاحة في BigQuery. قم ببناء استعلام يجمع التنقلات حسب الزوج (previous_screen، screen_name) ويحسب التكرار. النتيجة هي مصفوفة تنقلات يمكن تصورها في Looker Studio كمخطط Sankey.

عزِّز Screen Flow بالتقسيم: بشكل منفصل للمستخدمين الجدد (أول 7 أيام) والمستخدمين العائدين. المستخدمون الجدد غالبًا ما يعلقون في شاشات الإعداد، بينما المستخدمون ذوو الخبرة يصلون أسرع إلى الإجراءات المستهدفة. مقارنة التدفقين تكشف عن اختناقات التكيف.

أدوات تحليل Screen View

اختيار الأداة لتحليل Screen View يعتمد على الميزانية والتقنية ومستوى التفاصيل المطلوب. دعنا نستعرض ثلاثة حلول شائعة.

Firebase Analytics (مجاني)

Firebase يتتبع الشاشات تلقائيًا عبر معامل screen_view في كل حدث. لا يتطلب كودًا إضافيًا بعد دمج SDK. القيد: يتم إنشاء screen_name من Activity/ViewController، مما لا ينتج دائمًا أسماء قابلة للقراءة.

Amplitude (احترافي)

Amplitude يقدم Pathfinder مدمج — منشئ Screen Flow بصري. يدعم خصائص المستخدم والتقسيم حسب المجموعات. يسمح بإعادة تسمية الشاشات من جانب الخادم دون تغييرات في كود التطبيق.

Mixpanel (الشريحة المتوسطة)

Mixpanel يوفر تقرير Flows في الوقت الفعلي. يمكنه إظهار ليس فقط التنقلات الخطية ولكن أيضًا التفرعات — أي الشاشات تُزار بعد شاشة محددة. يتكامل مع SDKs لأنظمة iOS وAndroid وFlutter وReact Native.

تأثير Screen View على الأداء

كل حدث screen_view هو إرسال بيانات عبر الشبكة. إذا كان التطبيق يُرسل screen_view عند كل تبديل تبويب (20+ في الدقيقة)، فإنه يُنشئ حملاً غير ضروري. التحسين: خزِّن screen_view مؤقتًا وأرسله على دفعات كل 5 ثوانٍ. Firebase يجمع الأحداث تلقائيًا، لكن SDKs المخصصة قد تُرسل كل استدعاء فورًا.

قم بقياس العبء الإضافي للتتبع: أضف طابعًا زمنيًا إلى كل screen_view واحسب التأخير من onResume إلى الإرسال. إذا تجاوز التأخير 100 مللي ثانية، فإن التتبع يؤثر على تجربة المستخدم. استخدم خيطًا خلفيًا للإرسال لتجنب حظر خيط الواجهة. على الأجهزة منخفضة المستوى، الفرق ملحوظ.