मोबाइल एनालिटिक्स में 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” विश्लेषक के लिए बेकार है — screen_name में “Product Details” का उपयोग करें।

तीसरी गलती — संबंधित फ़ील्ड के बिना screen_view भेजना। खाली screen_name कचरा रिकॉर्ड का एक सेट बनाता है जिसे समूहित नहीं किया जा सकता। हमेशा कम से कम screen_name और screen_class पास करें, परीक्षण स्क्रीन पर भी।

Screen View कैसे ट्रैक करें?

Screen View ट्रैकिंग का कार्यान्वयन नेविगेशन आर्किटेक्चर पर निर्भर करता है। आइए Jetpack Compose और SwiftUI के उदाहरण पर स्वचालित और मैन्युअल दृष्टिकोण देखें।

Android: Jetpack Compose में स्वचालित ट्रैकिंग

NavigationComponent स्तर पर LifecycleEventObserver का उपयोग करें। हर बार जब उपयोगकर्ता किसी नए रूट पर जाता है, 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 में प्रत्येक View में निर्मित onAppear मॉडिफ़ायर का उपयोग किया जाता है। ऑटोमेशन के लिए, एक 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 का दोहराव होता है। एक केंद्रीकृत ScreenName enum समस्या को हल करता है — सभी स्क्रीन एक ही स्थान पर एक मानक के अनुसार नामित की जाती हैं। नई स्क्रीन जोड़ने के लिए केवल enum में एक नए स्थिरांक की आवश्यकता होती है, पूरे कोड में खोजने की नहीं।

सुविधा के अनुसार समूहीकरण के साथ screen_name का वर्णन करने के लिए sealed class का उपयोग करें: ProfileScreen.CHANGE_PASSWORD, OrdersScreen.ORDER_HISTORY, CatalogScreen.SEARCH_RESULTS। यह एनालिटिक्स रिपोर्ट में फ़िल्टरिंग को सरल बनाता है।

Screen Flow: स्क्रीन के बीच संक्रमण का विश्लेषण

Screen Flow (या Path Analysis) उन स्क्रीन के अनुक्रम का एक विज़ुअलाइज़ेशन है जिससे उपयोगकर्ता गुज़रता है। यह नेविगेशन में बाधाओं की पहचान करने का प्राथमिक उपकरण है।

Screen Flow बनाना

previous_screen पैरामीटर वाला प्रत्येक Screen View एक ग्राफ़ किनारा देता है: CatalogScreen → ProductDetails → CartScreen। सभी संक्रमणों को एकत्रित करके, एक पथ मानचित्र बनाया जाता है। Screen Flow पर आधारित तीन-चरणीय फ़नल दिखाता है कि उपयोगकर्ता कहाँ बाहर निकलते हैं।

• चरण 1: HomeScreen → CatalogScreen (95% आगे बढ़ते हैं)
• चरण 2: CatalogScreen → ProductDetails (65% आगे बढ़ते हैं — 35% छोड़ देते हैं)
• चरण 3: ProductDetails → AddToCart (30% आगे बढ़ते हैं — हम और 35% खो देते हैं)

Mixpanel (2024) के अनुसार, Screen Flow विश्लेषण 40% तक UX समस्याओं को प्रकट करता है जो अलग-अलग इवेंट्स के विश्लेषण पर दिखाई नहीं देती हैं। उदाहरण के लिए, बिना खरीदारी के बार-बार ProductDetails → HomeScreen संक्रमण मूल्य या उत्पाद विवरण में समस्या का संकेत देता है।

ड्रॉप-ऑफ विश्लेषण

Drop-off वह बिंदु है जहाँ उपयोगकर्ता परिदृश्य छोड़ देता है। यदि लोडिंग स्क्रीन के बाद 60% उपयोगकर्ता चले जाते हैं, तो समस्या लोडिंग गति या एनिमेशन में है। यदि Paywall के बाद — सदस्यता की लागत या मूल्य में।

Firebase और BigQuery में Screen Flow

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 रिपोर्ट प्रदान करता है। यह न केवल रैखिक संक्रमण बल्कि शाखाएँ भी दिखा सकता है — किसी विशिष्ट स्क्रीन के बाद कौन सी स्क्रीन देखी जाती हैं। iOS, Android, Flutter और React Native SDK के साथ एकीकृत होता है।

प्रदर्शन पर Screen View का प्रभाव

प्रत्येक screen_view इवेंट एक नेटवर्क डेटा भेजना है। यदि कोई ऐप हर टैब स्विच (प्रति मिनट 20+) पर screen_view भेजता है, तो यह अनावश्यक लोड बनाता है। अनुकूलन: screen_view को बफ़र करें और हर 5 सेकंड में बैच में भेजें। Firebase स्वचालित रूप से इवेंट एकत्र करता है, लेकिन कस्टम SDK तुरंत प्रत्येक कॉल भेज सकते हैं।

ट्रैकिंग के ओवरहेड को मापें: प्रत्येक screen_view में एक टाइमस्टैम्प जोड़ें और onResume से भेजने तक की देरी की गणना करें। यदि देरी 100 ms से अधिक है, तो ट्रैकिंग UX को प्रभावित करती है। भेजने के लिए एक पृष्ठभूमि थ्रेड का उपयोग करें ताकि UI थ्रेड ब्लॉक न हो। निम्न-स्तरीय उपकरणों पर, अंतर ध्यान देने योग्य है।