মোবাইল অ্যানালিটিক্সে 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 থ্রেড ব্লক না হয়। নিম্ন-স্তরের ডিভাইসে, পার্থক্য লক্ষণীয়।